OpenPGP: hardwareCrypto functions

[koto]

From [email protected] on August 11, 2014 21:30:47

We need to write the functions that interact with the Chrome App API for hardware devices once that API is integrated into e2e

Original issue: http://code.google.com/p/end-to-end/issues/detail?id=130

[koto]

From [email protected] on August 11, 2014 21:19:37

Can you give a bit more detail Josh?

[koto]

From [email protected] on August 11, 2014 23:47:04

Labels: Component-Logic Maintainability

[koto]

From [email protected] on August 12, 2014 09:11:59

In various places, primarily in schemes and key generation, we have places for code to interact with hardware. No code is written there yet since we are waiting on a CL to land that gives us an API we can use to talk to a hardware device. Once that CL is submitted and integrated into e2e, we should write code to interact with it.

[koto]

From [email protected] on August 15, 2014 12:24:12

Here's a braindump of what my thoughts for the refactor were, so we have them available after my internship ends:

ecdh_agent:
  hasKeyWrapper_():
    if it does:
      encrypt(plaintext) which gives {'u': keyWrapper.wrap(plaintext), 'v': message.pubKey}
        agent handles all operations with privkey/shared secret
    else:
      alice(bobpubkey) -> shared secret
      does getKeyWrapper_() from e2e js with that
==============================================================================
Keyring:
  For webcrypto and hardware, instead of a private key in the keyring, we'll
  have some kind of opaque key reference that the hardware device or webcrypto
  take in to perform their crypto operations.
  keys will also all contain some field indicating whether they are for use
  in webcrypto, JS, or hardware

Cipher:
  Add an enum indicating where the key is (webcrypto, JS, hardware) and a
  variable that takes a value from it

  This variable will be set in the constructor, based on the key
Rsaes and the like
  look into the cipher to determine whether its private key is in webcrypto,
  JS, or hardware and act appropriately

  have implementation for each of these three, ideally with the same interface
e2e.scheme.Scheme
  modify to allow this.crypto to take on different values for, e.g., webcrypto,
  JS, and hardware, based on values set in the |this| object

encryptedcipher.js:
  modify keyring unlock to allow for pin


details:
algorithm/key.js:
  add an enum type for location, put one as a field in all of the keys (except
      symmetric key)
keyring.js:
  add parameter to keyring.js:importKey indicating where key is?
    tricky because if they're importing anywhere other than e2e, they've already
    revealed the privkey to e2e by doing this. maybe acceptable to some, but does
    add risk over generating in webcrypto/hardware
  add parameter to generateKey for location
    if it's not e2e, call out to the appropriate device to do the generation.
    return a subkey instead.

    we will also need to make generateKey async, since hardware will be.
      see extension/ui/settings/settings.js, unit tests, maybe others?
        maybe openpgp/contextimpl.js

    same necessary in generateECKey
  maybe also importKey_?

  all code here will need to maintain awareness of the location field in the key
  and set that appropriately
rsaes.js (also add similar files for elgamal, ecc, and signing algorithms):
  look at the key to determine what kind of key it is and hence which crypto
  functions to use
e2e.scheme.Scheme:
  modify common code for all schemes to look at key, determine location of key,
  which functions to use

  potentially this introduces some redundancy with rsaes and scheme; this would
  be cleaned up

encryptedcipher.js:
  lockKey: Modify to destroy token, maybe? token wouldn't be destroyed in memory
    because JS doesn't let you
  unlockKey: Modify to send PIN to device and return device reply. This would
    then need to become async...

openpgp/packet/publickey.js: update types and whatnot

openpgp/encryptedcipher.js: maybe nothing?

add field, everything is JS, no parsing
schemes
s2k, encryptedcipher, unlocking secret keys
  unlockKey_

[martinholovsky]

Hi,
in short I think that Josh is looking for U2F support, which is by the way already included in Chrome, so extension could offload crypto operations to HW token/HSM or use it as storage of keyring/keys/certificates as it is much safer to not have private key exportable (located on disk).
If so, I'm looking for that as well :]