RE: do we need secure removal function for keys in low level API?

Mountie,

generateKey() is an example of the first point in my email. It generates a key object, with underlying key material living in some UA-specific place (see actions 81 and 82). The simplest case is where the UA holds the key material in memory, but the spec does not require this. So the UA knows when this key object is destroyed/released/garbage collected, and can choose to do something about wiping any traces of the underlying key material.

In the second case, while semantic complications like those pointed by Michael are indeed tricky, the UA at some low level knows when it wipes an IDB item from disk. It could potentially do something then.

However, both of these are highly dependent on specific UA behavior, and one or both may be unnecessary or infeasible in a given UA. Hence my feeling that there should be no normative text regarding this topic.

From: Mountie Lee [mailto:mountie@paygate.net]
Sent: Thursday, April 25, 2013 1:58 PM
To: Ryan Sleevi
Cc: Hutchinson Michael; Vijay Bharadwaj; Web Cryptography Working Group
Subject: Re: do we need secure removal function for keys in low level API?

Hi.
I understand the scoping.

but

please share the idea that
how the "key material" can be erased when user need or agree / or web application need or agree?

regards
mountie.

On Thu, Apr 25, 2013 at 1:54 PM, Ryan Sleevi <sleevi@google.com<mailto:sleevi@google.com>> wrote:
On Thu, Apr 25, 2013 at 1:40 PM, Mountie Lee <mountie@paygate.net<mailto:mountie@paygate.net>> wrote:
> I meant the counter method for generateKey();
>
> erasing key means not for the pointer (reference) of the key, but for the
> key object itself.
The comments from Vijay, Michael, and myself all reflected that
understanding - we're talking about the key material, not the key
object. All of our comments are consistent with that.

>
> when the key is generated by API, it will create the key object that is not
> pointer of existing key.
>
> but erasing generated key is out of scope?
Yes.

>
> logically there's a missing point.
>
No. Hopefully the above replies will make more sense when understood
that we were all on the same page of talking about key material.

>
>
> On Thu, Apr 25, 2013 at 12:10 PM, Ryan Sleevi <sleevi@google.com<mailto:sleevi@google.com>> wrote:
>>
>> On Thu, Apr 25, 2013 at 12:06 PM, Hutchinson Michael
>> <Michael.Hutchinson@gemalto.com<mailto:Michael.Hutchinson@gemalto.com>> wrote:
>> > In terms of removal...what happens if the key was cloned to IDB multiple
>> > times...does there also need to be a note about reference counting by the
>> > UA?
>> >
>> >>Michael
>>
>> That's why I would explicitly prefer not to.
>>
>> A Key object is structured cloneable.
>>
>> If you vend Key A, then clone it into Key B, and attempt to erase Key
>> A, what does that mean?
>> Is Key B valid or not?
>>
>> This relates to our neutering discussion, but "generally" speaking,
>> you don't have distinct objects affecting eachother - particularly not
>> with structured clone.
>>
>> Expand the thought experiment further:
>> Key A at origin foo.example.com<http://foo.example.com> clones it to Key B at origin
>> bar.example.com<http://bar.example.com>
>>
>> Does foo.example.com<http://foo.example.com> attempting to erase A also affect B - a resource
>> at an entirely different origin?
>>
>> For these reasons (and I'm sure we can find many more), I'm a huge -1
>> to the erasure.
>>
>> I don't think a note for UAs can be suitably descriptive while
>> flexible - the requirements and nature for key storage have been
>> (intentionally) entirely omitted from the spec, so there's little that
>> we can say that doesn't also imply a particular view of key storage,
>> which I think would only serve to confuse the spec.
>>
>> >
>> > -----Original Message-----
>> > From: Vijay Bharadwaj [mailto:Vijay.Bharadwaj@microsoft.com<mailto:Vijay.Bharadwaj@microsoft.com>]
>> > Sent: Thursday, April 25, 2013 1:57 PM
>> > To: Ryan Sleevi; Mountie Lee
>> > Cc: Web Cryptography Working Group
>> > Subject: RE: do we need secure removal function for keys in low level
>> > API?
>> >
>> > I agree with Ryan that this should not impact the API itself.
>> >
>> > Look at the cases when keys are removed:
>> > 1. Key object is released. This is a UA issue. A careful UA might for
>> > example zeroize the memory.
>> > 2. Key object which was cloned to IDB is deleted from IDB. Again, a UA
>> > issue.
>> >
>> > At best, we might add a note to Section 5 that implementers should watch
>> > out for these.
>> >
>> > -----Original Message-----
>> > From: Ryan Sleevi [mailto:sleevi@google.com<mailto:sleevi@google.com>]
>> > Sent: Thursday, April 25, 2013 11:49 AM
>> > To: Mountie Lee
>> > Cc: Web Cryptography Working Group
>> > Subject: Re: do we need secure removal function for keys in low level
>> > API?
>> >
>> > On Wed, Apr 24, 2013 at 10:25 AM, Mountie Lee <mountie@paygate.net<mailto:mountie@paygate.net>>
>> > wrote:
>> >> when key is generated,
>> >> I think how we can remove keys securely.
>> >>
>> >> key is sensitive data.
>> >> when remove, it should be unrecoverable.
>> >>
>> >> any comment?
>> >> --
>> >> Mountie Lee
>> >>
>> >> PayGate
>> >> CTO, CISSP
>> >> Tel : +82 2 2140 2700<tel:%2B82%202%202140%202700>
>> >> E-Mail : mountie@paygate.net<mailto:mountie@paygate.net>
>> >>
>> >> =======================================
>> >> PayGate Inc.
>> >> THE STANDARD FOR ONLINE PAYMENT
>> >> for Korea, Japan, China, and the World
>> >>
>> >
>> > This seems to be an implementation detail for UAs, not something that
>> > needs to be exposed to applications.
>> >
>> > The UA is responsible for deciding what keys are exposed and how key
>> > storage is maintained. The application does not have any intrinsic
>> > guarantees on the nature of keys or their storage - nor can it, given the
>> > way the web works, short of out-of-band knowledge (either of the UA and how
>> > it is implemented or of the keys, such as pre-provisioned keys).
>> >
>> > Further, there's no point specifying an API for secure erasure of key
>> > material, since the UA has plenty of opportunity to leak it within its
>> > implementation. Applications that are particularly sensitive to the set of
>> > regulatory frameworks that "require" secure erasure are thus equally
>> > dependent on the UAs operating in a mode compatible with those requirements,
>> > so there's nothing the application can or should do.
>> >
>> > So -1.
>> >
>> >
>
>
>
>
> --
> Mountie Lee
>
> PayGate
> CTO, CISSP
> Tel : +82 2 2140 2700<tel:%2B82%202%202140%202700>
> E-Mail : mountie@paygate.net<mailto:mountie@paygate.net>
>
> =======================================
> PayGate Inc.
> THE STANDARD FOR ONLINE PAYMENT
> for Korea, Japan, China, and the World
>



--
Mountie Lee

PayGate
CTO, CISSP
Tel : +82 2 2140 2700
E-Mail : mountie@paygate.net<mailto:mountie@paygate.net>

=======================================

PayGate Inc.

THE STANDARD FOR ONLINE PAYMENT

for Korea, Japan, China, and the World