Re: Extractability

SSL/TLS is the transport layer of OSI 7 layers which is applied between
host-to-host communication
WebCryptography technologies will be used on application layer of OSI 7
layers which is applied between UA and Server application.

I got to know the differences between TLS and WebCrypto.
both can be co-exist and can not be replacement for each other.




On Thu, Aug 1, 2013 at 4:23 PM, Mark Watson <watsonm@netflix.com> wrote:

> I'll reply more generally later, but quickly regarding the relationship of
> our use-case to TLS: we have designed and deployed a secure application
> protocol using WebCrypto which meets our particular application security
> needs when running over plain http. This includes confidentiality and
> mutual authentication. Such protocols are presumably exactly the kind of
> thing WebCrypto is intended to be used for and so not in any sense
> unreasonable. It's also not "technically unrealistic" since we have done it.
>
> Clearly, when scripts are delivered over HTTP the level of trust that one
> might have in the Javascript will be substantially less than one might have
> in the browser. Nevertheless, even when HTTPS is used it's obvious that
> script and browser are different things, subject to different attacks by
> different actors. It's obvious that they "might" be subject to different
> levels of trust. But whether they *are* subject to such different levels of
> trust, and the implications of this, are highly application dependent.
>
> Our requirement to work without TLS arises from the need to access content
> at HTTP URLs as explained in my earlier mail.
>
> ...Mark
>
>
> On Tue, Jul 30, 2013 at 8:50 PM, Ryan Sleevi <sleevi@google.com> wrote:
>
>> Virginie,
>>
>> I apologize, but I'm not sure I entirely follow your response.
>>
>> We're certainly agreed that extractability is a desirable feature, and
>> has been since the beginning. We also agree that supporting key
>> wrap/unwrap are desirable features, and being able to define the
>> extractability of keys that are wrapped/unwrapped are likewise
>> entirely reasonable. I've only seen one member of the WG suggest
>> otherwise, and only when building an unrealistic strawman argument.
>>
>> However, your points on the trust model are a bit confusing for me.
>> The core of the technical discussion here has been precisely upon what
>> is an acceptable trust model - whether or not the existing web trust
>> model that exists for all other Web/JS APIs is sufficient, or whether
>> it's our responsibility in the WG to attempt to define something
>> beyond that.
>>
>> The *key* question for this discussion is whether or not the API can
>> or should presume 'trust' in the validity and veracity of the script
>> being executed. All other Web APIs presume exactly that. WebAppSec/Web
>> Security provide the tools and techniques to establish that further -
>> eg: HTTPS, CORS, CSP, etc. Are you suggesting this is not the case -
>> and that we must face some additional presumptions, or that we cannot
>> rely on the vast body of work that came before this WG?
>>
>> I again position that there is absolutely no value in the API - either
>> the inputs or the outputs - if you don't have some degree of assurance
>> that the script is executing. I have argued, from the very beginning,
>> that attempts to build an alternative to TLS *on the general web*
>> through the use of this API are both unreasonable requirements and
>> technically unrealistic, given the very web security model defined and
>> expanded upon by WebAppSec (and, to a lesser degree, DAP/SysApps).
>> With respect to the SysApps model, I acknowledge it's a very different
>> threat model - one that provides even *more* guarantee about the
>> veracity of the script being executed, ergo the concerns raised by
>> Mark are arguably even less pressing.
>>
>> This is not a position that it somehow specific to the Netflix
>> proposal - I've expressed this position for other cases (eg:
>> http://lists.w3.org/Archives/Public/public-webcrypto/2013Apr/0088.html
>> ), and we've seen a similar position by Arun when editing the use
>> cases and considering the 'threat model' of what was colloquially
>> termed the "Facebook Use case"
>>
>> I'm hoping you can clarify as to what you mean when you say "This is
>> not the job of the web crypto WG do define this trust model" - since
>> this trust model so clearly affects and influences the requirements
>> and design.
>>
>> Cheers,
>> Ryan
>>
>> On Mon, Jul 29, 2013 at 1:35 AM, GALINDO Virginie
>> <Virginie.GALINDO@gemalto.com> wrote:
>> > Hello Mark, Ryan, and all,
>> >
>> >
>> >
>> > I need obviously to get into the details of your mail exchanges, but in
>> > order that we focus on the right tasks in the working group, I would
>> like to
>> > sumup my understanding of the situation :
>> >
>> > -          The extractability attribute is something the WG would like
>> to
>> > have,
>> >
>> > -          The trust models between javascript and browser are
>> different –
>> > even if in the end both of them are breakable, efforts you involve to
>> break
>> > it are different,
>> >
>> > -          This is not the job of the web crypto WG do define this trust
>> > model, as we mentioned that security model would be a general work
>> treated
>> > in collaboration with WebAppSec and Web Security IG.
>> >
>> >
>> >
>> > Note that if we fail to manage the extractability in border cases (such
>> as
>> > wrap/unwrap/import/export) then we can think either about dropping the
>> > extractability or dropping the border case functions. In both cases, our
>> > deliverable will miss the opportunity to be really valuable and answer a
>> > real market demand.
>> >
>> >
>> >
>> > So lets work on a technical solution, not to have this happening.
>> >
>> >
>> >
>> > Regards,
>> >
>> > Virginie
>> >
>> >
>> >
>> >
>> >
>> > From: Mark Watson [mailto:watsonm@netflix.com]
>> > Sent: samedi 27 juillet 2013 10:56
>> > To: Ryan Sleevi
>> > Cc: Harry Halpin; GALINDO Virginie; public-webcrypto@w3.org
>> > Subject: Extractability
>> >
>> >
>> >
>> > All,
>> >
>> >
>> >
>> > I changed the subject of this thread, because Ryan is raising again the
>> > question of whether the extractable attribute makes sense at all. Or,
>> > rather, the more general question of whether use-cases where the
>> Javascript
>> > is less trusted by the service than the UA is in scope for our work.
>> >
>> >
>> >
>> > I believe we should decide on this more general question and then
>> consider
>> > the implications for extractable and for wrap/unwrap.
>> >
>> >
>> >
>> > On that question, I don't believe it is our job in WebCrypto to perform
>> > detailed application security analysis. We are providing tools to
>> > application security engineers and the tools we provide are based on
>> > use-cases.
>> >
>> >
>> >
>> > For our use-case, we cannot use HTTPS to deliver our page because we
>> have to
>> > access non-SSL resources such as CDN content. Switching CDNs to SSL is
>> > expensive in terms of cost, computing resources, and network overhead.
>> And,
>> > we no longer want to use SSL because our target devices do not and
>> cannot
>> > get accurate time. (There are a number of CE devices that wish to use
>> the
>> > HTML5 solution -- the standard has to consider them and not just desktop
>> > browsers.). In fact our whole reason for using WebCrypto is to build
>> our own
>> > secure application protocol to use instead of SSL.
>> >
>> >
>> >
>> > As a result, MITM attacks against the Javascript are relatively easy.
>> >
>> >
>> >
>> > Further, in the Netflix case then there is value in attacking the
>> crypto to
>> > extract the keying material because that allows you to bypass Netflix
>> > service restrictions or deny service to the legitimate user. If keying
>> > material is known to be non-extractable (modulo TOFU), then we can
>> still be
>> > assured that it is the same browser we are talking to (or at least a
>> browser
>> > to which the same user has migrated the keys, if they are sophisticated
>> > enough to do that.)
>> >
>> >
>> >
>> > ...Mark
>> >
>> >
>> >
>> > On Thu, Jul 25, 2013 at 9:42 PM, Ryan Sleevi <sleevi@google.com> wrote:
>> >
>> > On Thu, Jul 18, 2013 at 7:30 PM, Mark Watson <watsonm@netflix.com>
>> wrote:
>> >>
>> >>
>> >> On Thu, Jul 18, 2013 at 7:09 PM, Ryan Sleevi <sleevi@google.com>
>> wrote:
>> >>>
>> >>> On Mon, Jul 8, 2013 at 5:12 PM, Mark Watson <watsonm@netflix.com>
>> wrote:
>> >>> > Returning to the subject of the original post, and to start off the
>> >>> > discussion.
>> >>> >
>> >>> > Ryan has mentioned two other possibilities for solving this
>> problem, so
>> >>> > I'd
>> >>> > like to take a moment to describe my understanding of those.
>> >>> >
>> >>> > (1) Implicit unwrap semantics in pre-provisioned keys
>> >>> >
>> >>> > A pre-provisioned key with usage unwrap could be imbued with
>> behaviors
>> >>> > that
>> >>> > dictate the extractable and usage attributes of keys that it
>> unwraps or
>> >>> > even
>> >>> > that imbue the unwrapped keys with other such properties. The former
>> >>> > would
>> >>> > be sufficient for "single step" key wrapping, where the final key
>> to be
>> >>> > used
>> >>> > for encryption, decryption, signature or signature verification is
>> >>> > wrapped
>> >>> > directly with the pre-provisioned key. The special property of the
>> >>> > pre-provisioned key ensures that the final key has extractable =
>> false.
>> >>> >
>> >>> > If you want to have two steps, for example the key you are
>> transferring
>> >>> > is
>> >>> > encrypted using a temporary Content Encryption Key (as in JWE) and
>> then
>> >>> > this
>> >>> > CEK is wrapped using the pre-provisioned key, then you not only need
>> >>> > the
>> >>> > pre-provisioned key to force extractable = false and usage = unwrap
>> on
>> >>> > the
>> >>> > CEK, but it must also transfer a special property to the CEK, so
>> that
>> >>> > when
>> >>> > this in turn is used for unwrapping the resultant key always has
>> >>> > extractable
>> >>> > = false.
>> >>>
>> >>> Correct. The "Named Pre-provisioned keys" is already imbued with
>> >>> special properties by definition, so this is consistent.
>> >>>
>> >>> JWK is not unique in this 'two step' form - consider multi-party
>> >>> RSA-KEM - you have the RSA key, the derived per-party KEK, and the
>> >>> shared, protected key.
>> >>>
>> >>> >
>> >>> > (2) Explicit attributes on wrapping keys
>> >>> >
>> >>> > A key with usage "unwrap" also has properties which dictate the
>> >>> > attributes
>> >>> > of keys that it unwraps. Let's call these properties
>> >>> > "unwrap-extractable"
>> >>> > and "unwrap-usages". Whenever a key, W, is used to perform an unwrap
>> >>> > operation, the unwrapped key, K, gets it's attributes set as
>> follows:
>> >>> >
>> >>> > K.extractable = W.unwrap-extractable
>> >>> > K.usages = W.unwrap-usages
>> >>> >
>> >>> > Again, this is sufficient for single-step unwrapping. When the
>> wrapping
>> >>> > key
>> >>> > W is generated, the unwrap-extractable and unwrap-usages properties
>> are
>> >>> > set
>> >>> > to 'false' and the intended usages of the expected wrapped key,
>> >>> > respectively, When it comes to unwrapping the unwrapped key, K, gets
>> >>> > the
>> >>> > appropriate properties.
>> >>>
>> >>> Correct.
>> >>>
>> >>> This matches PKCS#11's CKA_WRAP_TEMPLATE and CKA_UNWRAP_TEMPLATE
>> >>> properties, for which the smart card and secure element industry have
>> >>> long since embraced as sufficient for a variety of high-security needs
>> >>> (eg: eID cards, as a number of members have pointed out)
>> >>>
>> >>> >
>> >>> > However, if the intended usage of the key K is also for unwrapping
>> (as
>> >>> > in
>> >>> > the two-step key wrapping described above), we need a way to set
>> >>> > K.unwrap-extractable and K.unwrap-usages.
>> >>> >
>> >>> > Theoretically, we could go down the path of having
>> unwrap-extractable
>> >>> > and
>> >>> > unwrap-usages each be an array, popping the first value on each
>> unwrap
>> >>> > operation, i.e.
>> >>> >
>> >>> > K.extractable = W.unwrap-extractable[ 0 ]
>> >>> > K.usages = W.unwrap-usages[ 0 ]
>> >>> > K.unwrap-extractable = W.unwrap-extractable[ 1 : ]
>> >>> > K.unwrap-usages = W.unwrap-usages[ 1 : ]
>> >>> >
>> >>> > (using python-like slice notation)
>> >>> >
>> >>> > It may not be necessary to explicitly expose these attributes on the
>> >>> > Key
>> >>> > object: it may be sufficient to have them settable at key creation
>> >>> > time.
>> >>> >
>> >>> > The other option is to have the extractable and usage attributes
>> >>> > carried
>> >>> > securely with the wrapped key, as I have proposed.
>> >>>
>> >>> Note: This solution ONLY works with JWE-protected-JWK keys - it does
>> >>> not and cannot work with 'raw' or 'pkcs8'/spki. The smart card / HSM /
>> >>> SE industry certainly seems to recognize that mixing/matching as you
>> >>> propose only really works in an implementation-specific manner - see
>> >>> the CKM_SEAL_KEY proposal in the OASIS TC to see how the very nature
>> >>> of 'opaque' key blobs is left up to implementations because of this.
>> >>>
>> >>> You missed the third option though - which is that the (JavaScript)
>> >>> caller specifies the policy.
>> >>
>> >>
>> >> As you explain below, that's not an option that maintains the
>> >> extractability
>> >> functionality. In this mail, I was exploring options which do that.
>> >>
>> >>>
>> >>>
>> >>> If I can sum up the discussion so far, the two objections against this
>> >>> last point (eg: what is currently specified) are:
>> >>> 1) It allows end-users to manipulate variables (eg: in the Javascript
>> >>> console) to circumvent this
>> >>> 2) In the event of an XSS, an attacker can unwrap a key and set
>> >>> extractable to false.
>> >>>   2.1) The first attack requires the attacker has previously observed
>> >>> a wrapped key in transit (eg: MITM) before an XSS, then later XSSes
>> >>> and replays the original key with 'extractable' as true.
>> >>>   2.2) The second attack requires the attacker have XSSed the site,
>> >>> the server send a wrapped key, and the XSS change 'extractable' to
>> >>> true.
>> >>>
>> >>> I see #1 as an explicit non-goal for a general web spec - it's a
>> >>> feature, not a bug.
>> >>
>> >>
>> >> I don't see it as consistent with the existing extractable attribute
>> >> though.
>> >> We should be consistent. Following your approach, we should remove the
>> >> extractable attribute (not that I am proposing this).
>> >>
>> >>>
>> >>> #2.1 can (and should) be mitigated via HTTPS and related.
>> >>> #2.2 can (and should) be mitigated via CSP and related.
>> >>
>> >>
>> >> There are many ways in which the Javascript running on the users
>> machine
>> >> may
>> >> not be the Javascript that either the user or the service provider
>> >> expects.
>> >
>> > If you think that this is relevant to the threat model, you absolutely
>> > need to provide an expansion on this.
>> >
>> > If you're suggesting the UA defend against "malware", then that's a
>> > non-starter. If you're talking about extensions or other such, then
>> > either the user was informed and consented, or it's malware. I don't
>> > see how you can arrive in a situation where neither party has
>> > authorized something AND that being a situation that we as a WG must
>> > deal with.
>> >
>> >
>> >> The extractability attribute provides some protection against such
>> scripts
>> >> obtaining the raw keying material once it has been installed, provided
>> the
>> >> browser itself is not compromised. We're not in a position to do
>> security
>> >> engineering for every possible application here, we're providing tools
>> and
>> >> extractability is a useful one.
>> >>
>> >> Given the above, it's completely reasonable to want to maintain this
>> >> property with wrapped keys.
>> >
>> > Again, if this is the malware case, it's completely unreasonable to
>> > want to maintain this property.
>> >
>> >
>> >>
>> >>>
>> >>>
>> >>> Finally, the Structured Clonability of Key objects permits other
>> >>> creative uses that have strong parallels to existing software such as
>> >>> middleware, for example, by having a 'trusted' origin perform the
>> >>> unwrapping, and then postMessaging() to the untrusted origin (which,
>> >>> for example, may not be able to support strict CSP policies), while
>> >>> still preserving attributes.
>> >>
>> >>
>> >> Sure, but you are making a bunch of assumptions or imposing a bunch of
>> >> constraints on how applications are designed. What I can say is that
>> for
>> >> our
>> >> application, this wouldn't work. Our security analysis suggests that we
>> >> should in all cases attach a different level of trust to the Javascript
>> >> code
>> >> than we do to the browser code. Both can be compromised, of course, but
>> >> the
>> >> ways in which the Javascript can be attacked are more numerous and
>> varied.
>> >>
>> >> ...Mark
>> >>
>> >
>> > Naturally, I strongly disagree with this as being a reasonable goal for
>> the
>> > API.
>> >
>> > It is, in my view, unreasonable to simultaneously suggest you 'trust'
>> > JS to perform crypto but then don't trust the JS performing the
>> > crypto. As we discussed from the very beginning, the mere act of
>> > permitting cryptographic operations is often more than sufficient to
>> > leverage any number of attacks - the formal analysis of PKCS#11 we
>> > discussed in our first F2F was very much a demonstration of this and
>> > why such a goal is unreasonable for any generic API.
>> >
>> > You're right, it absolutely makes a statement that "If you're going to
>> > run code, you trust the code you're going to run" - and using *other*
>> > mechanisms to improve or augment that trust (eg: extensions/sysapps,
>> > as we've also discussed extensively).
>> >
>> > As has also been discussed at length, if you're assuming a MITM that
>> > can modify JS, then it's entirely reasonable to assume that if they're
>> > not attacking the crypto, they're attacking any number of other
>> > aspects - including stripping out the crypto entirely. It's a never
>> > ending game of whack-a-mole that benefits no one, compared to actually
>> > dealing with the trust problem where it belongs - with the JS itself.
>> >
>> >
>>
>
>


-- 
Mountie Lee

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

=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World