Re: Use case classification, and associated security models

On Tue, Jun 12, 2012 at 12:38 PM, Mitch Zollinger <mzollinger@netflix.com>wrote:

>  On 6/12/2012 1:07 AM, Vijay Bharadwaj wrote:
>
> <snip>
>  ** **
>
> ** **
>
> In all the above cases, once a key is obtained, all the actual crypto
> operations are pretty much the same. So is we define all operations in the
> API which require a key such that they take a key object as a parameter,
> then the only difference between the above scenarios (from an API
> perspective) is the operations used to instantiate that key object. The
> above 3 scenarios would then correspond to 3 different instantiation
> methods for key objects:****
>
> ** **
>
> 1.       GenerateKey – create a new key for use with a specific
> algorithm. Choice of crypto provider left up to the platform.****
>
> 2.       ImportKey – take a key blob obtained from key agreement and
> create a key object from it. Choice of crypto provider left up to the
> platform.****
>
> 3.       OpenKey – Locate a key on the host system that matches a set of
> criteria. Choice of crypto provider to be made by platform depending on the
> location of the key.****
>
> ** **
>
> There is also a fourth primitive which is often used with scenario 3 –
> credential enrollment. This would be the operation where the user employs
> the trusted key to obtain a credential (e.g. enrolling for a smart card
> certificate by signing a request using one’s existing smart card key).****
>
> ** **
>
> Does that seem reasonable? Any other families of use cases that I’m
> overlooking?****
>
>
> Good write up.
>
> I would like to better understand what you (and the group) think about
> "crypto providers". When I think about crypto providers, I think of the JCE
> (Java Cryptography Extensions) Crypto Providers & OpenSSL "engines". In
> that context, it would seem to me that the app has varying behavior with
> regard to crypto provider selection that may be orthogonal to the type of
> the key. One example:
>
> * If my app detects that a smart card is plugged in & I can use keys on
> the smart card for service authentication, I will not ask the user a
> security question when they connect to my webapp. However, if I'm using
> another crypto provider (likely the default provided by the browser) --
> with the same keys that would have been stored in the smart card if the
> user had it plugged in -- then I will ask my security question.
>
> Mitch
>
>
I think that any app that would do what you propose, without any other
additional proof, would be making a naive assumption that doesn't really
improve the security. I certainly do not want to expose any such concept to
the web API for exactly that reason.

In your example, you're relying on the user agent to honestly answer "smart
card" or "not smart card" for where the key is stored, and then making a
server side security decision based on that. Such a decision seems a lot
like sticking form validation code in the client to prevent against SQL
injection. Browsers can be mislead or manipulated, so I don't think it can
be reasonably assumed to give an answer that is reliably accurate.

Using Vijay's ontology, if you want to make the distinction between secure
element or not, you, as a service provider, would do so based upon whether
or not you (as a service provider) were responsible for the provisioning
ceremony of those keys. If you controlled the ceremony, you know the
provenance of those keys, and you know how and where they're stored.

Whether this means mailing out a smart card, using some other
application/protocol/platform. Examples might be GlobalPlatform, with it's
proof of possessions, some work product of the IETF's KeyProv WG, something
like Anders Rundgren's Keygen2, etc. However, the size and scope of work,
and the many competing interests involved, seem very much out of scope for
this WG (although admittedly very interesting and perhaps parallel work to
solve)

To modify your scenario into something that I think would provide some
reasonable assurances:
* If your app detects that the user has a (pre-provisioned Key ID X), then
you can allow that user to authenticate using Key X.
* If your app does not detect Key X, but detects a (previously generated
via <keygen> or the ephemeral API Vijay proposed), then it uses Key Y, plus
some form of challenge/security question.
* If your app detects neither Key X nor Key Y, it offers the user the
chance to (online enroll a Key Y, contact you to obtain a smart card with
Key X)