RE: crypto-ISSUE-32 (Key security): Section 5.2 in API draft should mention use of secure element in the context of key security [Web Cryptography API]

To the Editors,

To address the point raised in Issue-32, I suggest that we modify section 5.2 http://www.w3.org/2012/webcrypto/WebCryptoAPI/#security-developers<http://www.w3.org/2012/webcrypto/WebCryptoAPI/> of the Draft API as follows: [red text is new]

While the API in this specification provides a means for applications to request that the generated keying material be kept private from a web application, this should not be misinterpreted as providing secure key storage. The only guarantee is that the application should not be able to extract the raw key material directly, not that the key is protected from users with access to the device. For example, a conforming user agent may choose to store the key material unencrypted in plain text on device storage, which would permit any user with access to the device access to the key. Alternatively, applications that have been granted access to the key may be able to use certain algorithms and messages to act as an oracle, recovering key material through a combination of messages. If applications are concerned about such direct access to keys, they should consider use of pre-provisioned keys that reside in secure elements such as smart cards. Smart cards will allow use of such keys in cryptographic operations once user authorization requirement have been met, but will prevent key extraction in raw form. Thus, because However, regardless of where the keys are stored, complete security of the key itself or its use cannot be guaranteed by this API. Depending upon the storage, keys may either be extracted in the clear or otherwise used in a manner not anticipated by the application. Application developers are therefore also encouraged to provide a means for users to revoke keys or to address key compromise.

Regards,
--- asad




-----Original Message-----
From: Web Cryptography Working Group Issue Tracker [mailto:sysbot+tracker@w3.org]
Sent: Tuesday, August 28, 2012 12:22 PM
To: public-webcrypto@w3.org
Subject: crypto-ISSUE-32 (Key security): Section 5.2 in API draft should mention use of secure element in the context of key security [Web Cryptography API]

crypto-ISSUE-32 (Key security): Section 5.2 in API draft should mention use of secure element in the context of key security [Web Cryptography API]

http://www.w3.org/2012/webcrypto/track/issues/32


Raised by: Asad Ali
On product: Web Cryptography API

Initial email from Asad:

This section talks about key security from a developer’s perspective, but does not mention that key can be stored securely in a secure element such as a smart card. While developers have no guarantee that keys residing in local storage, or indexed DB are safe, secure element storage does offer this assurance. This scenario should be pointed out here.


Comments from Ryan:

Please do raise such an issue.

User agents are NOT required to implement support for secure elements or smart cards, nor (again, speaking as one implementation) if they do implement, are they likely to expose it to 'any' web origin. Thus, I don't know how well this can be promoted as a general purpose solution
- it's very much tied to particular implementations.

Also, with the above text, "local storage, or indexed DB" is a misinterpretation of the text. It's talking about device storage.
"local storage, or indexed DB" are two different APIs for storing name/value pairs (where name is typically called 'key', but for purposes of disambiguation, shall be called name). Just wanted to make sure we're on the same page.

Equally, secure element access has its own security considerations, as mentioned in 5.2, so the overall recommendation stands regardless of device storage vs secure element.

It would be helpful if you could propose some text that you think might address these concerns.