Re: ACTION-84: Finishing support for key derivation/key agreement (take 2)

On Mon, Jul 15, 2013 at 9:08 AM, Jim Schaad <ietf@augustcellars.com> wrote:
> I was going through things and came up with a question I would like to pose.
>
> How does one go about implementing RSA-KEM?
>
> RSA-KEM is basically something that looks a lot like a key agreement
> algorithm, but uses RSA rather than DH for transporting the secret.  Thus
> you do
>
> Decrypt the RSA encrypted secret
> Run a KDF on the secret
> Execute a key wrap algorithm using the derived key
>
> Currently, I think that I would need to do something strange like

Why do you think that's strange? We already have a number of
algorithms that take an AlgorithmIdentifier as parameters.

>
> {name:"RSA-KEM", params: {kdf:<KDF Algorithm>}}
>
> And running decrypt on that would produce a Key rather than a ArrayBuffer.

Decrypt should never produce a key. Call a wrap a wrap :)

Let's say you're using RSA-KEM to transport an RSA private key for use
with RSA-PSS (eg: provisioning a new key)

Presumably, this could look something like

let unwrapAlg = {
  name: "RSA-KEM",
  kdf: { name: "CONCAT", hash: "SHA-256", algorithmId: "x",
partyUInfo: "y", partyVInfo: "z" }
};
let tempAlg = {
  name: "AES-KW",
  length: 192,
};
let destAlg = {
  name: "RSA-PSS",
};

window.crypto.subtle.unwrapKey("raw", rsaKEMKeyData, rsaKey,
unwrapAlg, tempAlg).then(tempKey => {
  return window.crypto.subtle.unwrapKey("raw", wrappedKeyData,
tempAlg, destAlg);
}).then(unwrappedKey => {
  // Do something with the new RSA-PSS key.
});

This presumes that the caller can distinguish between the RSA-KEM key
data (eg: the first 1024 bits of a message) and the KEK-protected
data.

This has RSA-KEM unwrap the secret, then feeds it through the KDF to
generate a key of tempAlg type - an AES-192 key for use with AES Key
Wrap.

The AES Key Wrap key is then used unwrap the KEK-protected data,
yielding unwrappedKey as a result.

Have I missed something?

>
> If we have to do this with RSA-KEM, is there a reason why we should not make
> the DH algorithms behave in a similar manner?

Am I missing why the above does or does not work for the DH case?

>
> Jim
>
>
>> -----Original Message-----
>> From: Vijay Bharadwaj [mailto:Vijay.Bharadwaj@microsoft.com]
>> Sent: Tuesday, June 04, 2013 12:04 AM
>> To: public-webcrypto@w3.org
>> Cc: Richard Barnes; Jim Schaad; Ryan Sleevi (sleevi@google.com); Israel
>> Hilerio
>> Subject: ACTION-84: Finishing support for key derivation/key agreement
>> (take 2)
>>
>> Following up on the previous thread (see
>> http://lists.w3.org/Archives/Public/public-webcrypto/2013May/0106.html),
>> here is a more fully-fleshed-out proposal based on the latest working
> draft.
>> Please let me know if I missed anything from the previous discussion, or
> if
>> you have new comments.
>>
>> Notes:
>> - I am leaving out MQV from the algorithm definitions for now. If there is
>> interest, this can be added. I'd like to point out that Windows and
> OpenSSL
>> at least do not implement it and adoption may be low due to IPR-related
>> concerns such as Ryan expressed on the earlier thread.
>> - This is defined with reference to Futures. This is for consistency with
> the
>> current draft. To the extent that open issues remain with Futures in the
>> spec, those issues apply here as well.
>> - This is also subject to the existing open issues around separation of
>> operational and algorithm parameters.
>> - Naming is hard. Existing methods are named <verb> or <verb><noun>.
>> However agreeSecret and computeSecretAgreement sound clunky to me. If
>> you have a better idea please share.
>>
>> Section 11:
>> Add a new value "secretAgreement" to enum KeyUsage.
>>
>> Section 14:
>>
>> Add to interface SubtleCrypto:
>>
>> Future<any> secretAgreement(Key localPrivateKey, Key peerPublicKey,
>> AlgorithmIdentifier agreementAlgorithm, AlgorithmIdentifier
>> derivationAlgorithm, bool extractable = false);
>>
>> Future<any> deriveBits(AlgorithmIdentifier kdfAlgorithm, Key baseKey,
>> unsigned long bitLength);
>>
>> Section 14.2:
>>
>> Add new subsections describing the above methods:
>>
>> 14.2.x. The secretAgreement method
>>
>> When invoked, secretAgreement MUST perform the following steps:
>>
>> 1. Let normalizedAgreementAlgorithm be the result of processing
>> agreementAlgorithm according to the algorithm normalizing rules.
>>
>> 2. If normalizedAgreementAlgorithm does not describe a registered
>> algorithm that supports the secretAgreement operation, throw a
>> NotSupportedError and terminate the algorithm.
>>
>> 3. Let normalizedDerivationAlgorithm be the result of processing
>> derivationAlgorithm according to the algorithm normalizing rules.
>>
>> 4. If normalizedDerivationAlgorithm does not describe a registered
>> algorithm that supports the derive operation, throw a NotSupportedError
>> and terminate the algorithm.
>>
>> 5. Let future be a new Future object and resolver its associated resolver.
>>
>> 6. Return future and continue executing the remaining steps
> asynchronously.
>>
>> 7. If an error occurs, run these substeps and then terminate the
> algorithm:
>>       1. Let result be null.
>>       2. Execute resolver's reject(value) algorithm, with result as the
> value
>> argument.
>>
>> 8. If localPrivateKey, peerPublicKey, agreementAlgorithm.localPrivateKey2
> (if
>> present), agreementAlgorithm.localPublicKey2 (if present), and
>> agreementAlgorithm.peerPublicKey2 (if present) are not all keys of type
>> normalizedAgreementAlgorithm, terminate this algorithm with an error.
>>
>> 9. If localPrivateKey, peerPublicKey, agreementAlgorithm.localPrivateKey2
> (if
>> present), agreementAlgorithm.localPublicKey2 (if present), and
>> agreementAlgorithm.peerPublicKey2 (if present) do not all contain the
>> "secretAgreement" KeyUsage in their keyUsage properties, terminate this
>> algorithm with an error.
>>
>> 10. Let secret be the result of executing the secret agreement algorithm
>> defined by the algorithm indicated in normalizedAgreementAlgorithm.
>>
>> 11. Let result be the result of executing the importKey algorithm, with
> "raw"
>> as format, with secret as keyData, with normalizedDerivationAlgorithm as
>> algorithm, with extractable as extractable, and "derive" as keyUsages.
>>
>> 12. If the key import algorithm failed, terminate this algorithm with an
>> error.
>>
>> 13. Execute resolver's resolve(value) algorithm, with result as the value
>> argument.
>>
>>
>> 14.2.y The deriveBits method
>>
>> When invoked, deriveBits MUST perform the following steps:
>>
>> 1. Let normalizedKdfAlgorithm be the result of processing kdfAlgorithm
>> according to the algorithm normalizing rules.
>>
>> 2. If normalizedKdfAlgorithm does not describe a registered algorithm that
>> supports the derive operation, throw a NotSupportedError and terminate the
>> algorithm.
>>
>> 3. Let future be a new Future object and resolver its associated resolver.
>>
>> 4. Return future and continue executing the remaining steps
> asynchronously.
>>
>> 5. If an error occurs, run these substeps and then terminate the
> algorithm:
>>       1. Let result be null.
>>       2. Execute resolver's reject(value) algorithm, with result as the
> value
>> argument.
>>
>> 6. If baseKey.keyUsage does not contain the "derive" KeyUsage, terminate
>> this algorithm with an error.
>>
>> 7. Let result be an ArrayBuffer object containing the result of executing
> the
>> key derivation algorithm defined by the algorithm indicated in
>> normalizedKdfAlgorithm, with baseKey as the base key, to generate
>> bitLength bits of output. If bitLength is not a multiple of 8, set the
> unused
>> bits in the last byte of result to zero.
>>
>> 8. Execute resolver's resolve(value) algorithm, with result as the value
>> argument.
>>
>>
>> Section 18
>>
>> 18.8. ECDH
>>
>>
>> 18.8.1. Description
>>
>> This describes using Elliptic Curve Diffie-Hellman (ECDH) for key
> generation
>> and key agreement, as specified by X9.63.
>>
>>
>> 18.8.2. Registration
>>
>> The recognized algorithm name for this algorithm is "ECDH".
>>
>>
>> Operation             Parameters                      Result
>> generateKey           EcKeyGenParams          KeyPair?
>> secretAgreement       EcdhSecretAgreementParams       Key?
>>
>>
>> 18.8.3. EcdhSecretAgreementParams dictionary
>>
>> IDL
>>
>> dictionary EcdhSecretAgreementParams : Algorithm {
>>   // The caller's secondary (ephemeral) private key, if used
>>   Key? localPrivateKey2;
>>   // The peer's secondary (ephemeral) public key, if used
>>   Key? peerPublicKey2;
>> };
>>
>> 18.8.4. Operations
>> *Generate Key
>> *Secret Agreement
>> Perform the appropriate ECDH secret agreement scheme from SP 800-56A
>> Section 6, depending on whether localPrivateKey2 and peerPublicKey2 are
>> specified. The result is a Key object created by importing the shared
> secret Z.
>>
>> Note: X9.63 Section 5.4.2 and NIST SP 800-56A Section 5.7.1.2 specify a
>> modified ECDH primitive that multiplies the shared secret value by the
>> cofactor of the curve. The cofactor of the NIST recommended curves P-256,
>> P-384, and P-521 is 1, so the standard and modified ECDH primitives are
>> equivalent for those curves.
>>
>>
>> 18.15. Diffie-Hellman
>>
>> 18.15.1. Description
>>
>> This describes using Diffie-Hellman for key generation and key agreement,
>> as specified by PKCS #3.
>>
>> 18.15.2. Registration
>>
>> The recognized algorithm name for this algorithm is "DH".
>>
>> Operation             Parameters                      Result
>> generateKey           DhKeyGenParams          KeyPair?
>> secretArgeement       DhSecretAgreementParams Key?
>>
>> 18.15.3. DhKeyGenParams dictionary
>>
>> IDL
>>
>> dictionary DhKeyGenParams : Algorithm {
>>   // The prime p.
>>   BigInteger prime;
>>   // The base g.
>>   BigInteger generator;
>> };
>>
>> 18.15.4. DhSecretAgreementParams dictionary
>>
>> IDL
>>
>> dictionary DhSecretAgreementParams : Algorithm {
>>   // The caller's secondary (ephemeral) private key, if used
>>   Key? localPrivateKey2;
>>   // The peer's secondary (ephemeral) public key, if used
>>   Key? peerPublicKey2;
>> };
>>
>> 18.15.5. Operations
>> *Generate Key
>> *Secret Agreement
>> Perform the appropriate DH secret agreement scheme from SP 800-56A
>> Section 6, depending on whether localPrivateKey2 and peerPublicKey2 are
>> specified. The result is a Key object created by importing the shared
> secret Z.
>

Received on Friday, 19 July 2013 00:45:23 UTC