Project

General

Profile

Actions

Bug #1589

closed

KeyChain::sign is slow with tpm=osx-keychain

Added by Junxiao Shi almost 10 years ago. Updated about 5 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
Security
Target version:
-
Start date:
05/10/2014
Due date:
% Done:

0%

Estimated time:

Description

Environment: OSX 10.9 on Mac Mini

Steps to reproduce:

  1. in ~/.ndn/client.conf, set tpm=osx-keychain
  2. install a self-signed default certificate
  3. prepare one Data packet with 4096 octet payload
  4. call keyChain.sign(data) in a loop of 1000 times, and observe time spent in the loop

Expected: signing 1000 packets takes less than 5 seconds

Actual: signing 1000 packets takes more than 15 seconds


Files

sign-bench.cpp (1.36 KB) sign-bench.cpp KeyChain::sign benchmark tool Junxiao Shi, 05/10/2014 11:29 PM

Related issues 2 (2 open0 closed)

Related to ndn-cxx - Feature #2488: Asynchronous API for data signingNew

Actions
Blocks NFD - Bug #2174: Multiple register prefix gives NFD error "request timed out (code: 10060)"New11/13/2014

Actions
Actions #1

Updated by Junxiao Shi almost 10 years ago

My benchmark results:

OS CPU TPM nIterations duration
OSX 10.9 2.5G osx-keychain 1000 19550ms
OSX 10.9 2.5G file 10000 25227ms
Ubuntu 12.04 2.7G file 10000 25270ms
Actions #2

Updated by Alex Afanasyev almost 10 years ago

This is a known issue and I would like to reject this.

For security to be secure, private key should never be exposed to the application, not mentioning be cached in memory. This basically defeats the purpose of security and key protection in the first place (there are well-known "cold boot" attacks, where keys are being extracted from RAM). And as long the key is secured, there is obviously large overhead and we would see extremely slow performance, such the one with OSX keychain.

Separate issue #1204 should address signing performance problem, without sacrificing much of security benefits by clearly separating keys that are used by applications and user keys that can be used to sign application keys. The former keys can be "less secure" (as they are cheap), kept, and used directly from RAM.

Actions #3

Updated by Junxiao Shi almost 10 years ago

  • Target version deleted (v0.2)

You are admitting this is "a known issue", thus it is a bug.

This bug would be fixed when KeyChain is able to sign Data using a Data Signing Key instead of relying on osx-keychain TPM.

Actions #4

Updated by Jeff Burke almost 10 years ago

I agree with the fix proposed in #1204. This issue may block low-latency / high-throughput applications from using signing in the current security library. Can its priority be increased and example code be provided for how applications should generate derived keys?

Actions #5

Updated by Lixia Zhang almost 10 years ago

Jeff, I am afraid that this is NOT a priority question.
We do not have a solution at this time, no matter how high the priority one wants to set it.

Actions #6

Updated by Junxiao Shi over 9 years ago

  • Blocks Bug #2174: Multiple register prefix gives NFD error "request timed out (code: 10060)" added
Actions #7

Updated by Junxiao Shi over 9 years ago

One proposed solution to this Bug is Task #1204, although it has design challenges in itself.

Actions #8

Updated by Junxiao Shi over 8 years ago

  • Related to Feature #2488: Asynchronous API for data signing added
Actions #9

Updated by Junxiao Shi over 8 years ago

At 20150803 conference call, Alex classifies this as a "corner case".

However, I disagree with this classification unless the default TPM for OS X is changed to something other than osx-keychain.

Actions #10

Updated by Junxiao Shi about 5 years ago

  • Status changed from New to Rejected

OSX 10.9 is no longer supported by ndn-cxx.
If a similar issue appears on a supported platform, please open a new bug with test logs.

Actions

Also available in: Atom PDF