Project

General

Profile

Bug #1589

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

Added by Junxiao Shi over 4 years ago. Updated over 3 years ago.

Status:
New
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

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

Related issues

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

Blocks NFD - Bug #2174: Multiple register prefix gives NFD error "request timed out (code: 10060)"New2014-11-13

History

#1 Updated by Junxiao Shi over 4 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

#2 Updated by Alex Afanasyev over 4 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.

#3 Updated by Junxiao Shi over 4 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.

#4 Updated by Jeff Burke over 4 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?

#5 Updated by Lixia Zhang over 4 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.

#6 Updated by Junxiao Shi about 4 years ago

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

#7 Updated by Junxiao Shi about 4 years ago

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

#8 Updated by Junxiao Shi over 3 years ago

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

#9 Updated by Junxiao Shi over 3 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.

Also available in: Atom PDF