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]

On Tue, Aug 28, 2012 at 4:16 PM, Ali Asad <Asad.Ali@gemalto.com> wrote:
> 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 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

Thanks for providing the text, Asad. I am not comfortable with the
proposed text, but I appreciate that it provides a better
understanding of your concerns.

I believe the text to 5.2 is factually and technically acurate - the
API, as spec'd, provides no guarantees. Thus, as far as security
considerations goes, then regardless of secure elements or not,
consumers of the API (rather than consumers of a particular vendors'
implementation of the API) SHOULD be aware that no such guarantees are
made.

My concerns are such:
1) As repeatedly discussed, pre-provisioned keys are an implementation
specific solution. While non-normative, I don't think we should be
promoting as "solutions" items which are not and, perhaps, cannot, be
reliably used or implemented in a cross-implementation compatible way.
I think the proposed text directly undermines the utility and value of
this work, since it may be seen as directly encouraging out-of-scope
behaviour.
2) As written, it directly promotes the use of smart cards, although
the general security benefits provided are not tied to smart cards as
much as the scope of secure elements and protected storage (of which
there are many ways to provide this).
3) The placement of the new text immediately following the text on
oracles creates confusion as to what the benefits of smart cards are.
As discussed previously on the mailing list regarding PKCS#11
security, smart cards are and can be compromised and coerced to reveal
key material.
4) The change of "keying material" to "generated keying material"
immediately limits the scope of considerations to key generation.
However, the concerns apply equally to key derivation and import, and
in that regard, I think the original text was better specified.

I would be more than happy to add text that acknowledges and
specifically calls out that pre-provisioned keys may be exposed by
this API, and that further, they may be stored in mechanisms outside
of the user agent's storage, such as via secure elements or smart
cards. I agree that such text would be useful, since it also
highlights some of the design concerns and constraints that have been
utilized by this API.

Where I have problem is when that is taken a step further to suggest
that implementations SHOULD support them or that applications SHOULD
attempt to utilize them, since I believe either recommendation,
normative or not, is an immediate acceptance that this is not a
meaningful cross-implementation solution.

Perhaps there is suitable text to add to section 4, once Virginie's
proposed changes have been reviewed and incorporated.

Would this be something that would meet your needs?

>
>
>
>
> -----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.
>
>
>
>
>
>

Received on Tuesday, 28 August 2012 23:55:02 UTC