Re: crypto-ISSUE-29 (block modes): Handling of block encryption modes and padding [Web Cryptography API]

On Mon, Aug 27, 2012 at 2:59 AM, Vijay Bharadwaj
<Vijay.Bharadwaj@microsoft.com> wrote:
> I agree with Wan-Teh here. Requiring key tainting significantly increases the implementation complexity for the UA, and leads to potential inconsistencies across implementations as most native APIs don't support tainting.

I'm not sure I follow with what you see as potential inconsistencies.
Do you mean the fact that it's (currently) in an informative section?

Would making it normative, and specifying the exact tainting
algorithm, resolve those concerns?

I'm particularly concerned with the relationship with cross-origin
access. Whether this be through an origin-authorized key or through a
multi-origin key, the fact that origins are themselves isolated from
eachother means that they cannot effectively communicate their
'tainted' status.

Further, the only place they can reliably (for the duration of key
storage) store the tainted state is within the KeyAttributes, but only
as a read-write attribute. This would mean that any form of ephemeral
XSS may lead to a compromise of secrets, by having the attacker
"switch" the tainting state.

While I recognize the complexity, it seems to be an acceptable
security trade-off, one that is unfortunately lacking in present APIs.
Tracking the tainted state "SHOULD" be as simple as remembering the
algorithm first used with a given Key, and then persisting that as a
read-only attribute, and ensuring any future CryptoOperations do not
violate the (algorithm-specific) invariants.



>
> -----Original Message-----
> From: Ryan Sleevi [mailto:sleevi@google.com]
> Sent: Friday, August 24, 2012 6:14 PM
> To: Wan-Teh Chang
> Cc: David McGrew (mcgrew); Web Cryptography Working Group
> Subject: Re: crypto-ISSUE-29 (block modes): Handling of block encryption modes and padding [Web Cryptography API]
>
> On Fri, Aug 24, 2012 at 6:04 PM, Wan-Teh Chang <wtc@google.com> wrote:
>> Ryan,
>>
>> Thank you for the info. I found the guidance you quoted in RFC 3447
>> for RSAES-OAEP and EMSA-PSS. The recommendation is repeated in RFC
>> 4055 Section 3.1 for RSASSA-PSS keys:
>>
>>    When signing, it is RECOMMENDED that the parameters, except for
>>    possibly saltLength, remain fixed for all usages of a given RSA key
>>    pair.
>>
>> I did not find similar language that recommends using a fixed hash
>> algorithm for a given signing key in X9.62-2005 and FIPS 186-3. Also,
>> RFC 5480 still uses the completely unrestricted id-ecPublicKey
>> algorithm identifier for ECDSA keys.
>>
>> So it seems that these standards and RFCs, especially for ECDSA keys,
>> still allow key algorithms to be less restrictive/specific than crypto
>> operation algorithms. In PKCS #11, key algorithms and crypto operation
>> algorithms come from two namespaces -- CKK_xxx for key types and
>> CKM_xxx for mechanisms.
>>
>> The implication is that this kind of "tainting" will need to be
>> maintained by the user agents, and it would be difficult to migrate
>> key  tainting from one computer to another for keys in smart cards
>> unless the smart cards themselves carry key tainting information.
>>
>> Wan-Teh
>
> Correct. The concept of restricting a key (which may be a generic type, such as RSA), to a particular subset of both algorithm (PSS) and algorithm parameters (eg: hash), is one that is not widely supported within generic APIs.
>
> Thus, when granting access to a particular key to multiple applications - whether they be native applications or web applications
> - the key "should" be used consistently. This is part of why I'm extremely hesitant to support exposing OS keys to arbitrary web applications, since there is, I believe, even less of a chance that they will preserve the invariants.
>
> Currently, the security considerations section lists tainting as a non-normative recommendation of one possible way for dealing with the security issues that may arise. However, as you point out, by normatively making key generation take the more specific algorithm, this presumes that key tainting MUST be implemented. If we make the Key.algorithm contain a 'generic' set of parameters, then it will be up to every web application to manage the 'state' of the key themselves (in addition to any user agents also maintaining that state), as well as be prepared for 'retry until you find the right combo' for keys that have been tainted.
>
> I'm not thrilled with such a proposal, since I'm convinced it will lead to poor implementations/undermine the security, but I can understand the appeal for implementation simplicity. If we do go that route, I think it further argues for the importance of keeping keys single origin.
>
>

Received on Tuesday, 28 August 2012 02:08:11 UTC