When pre-provisioned symmetric keys are used, some kind of globally unique identifier must also be provided so that services can look up the key in their own server-side database. In other words, a cryptographic operation using a pre-provisioned key looks just like a cryptographic operation using a session key.Ĭontinuity of Device / Key Identification The APIs in this document are agnostic to the type of key deployment used. These keys are exchanged, derived or otherwise created at runtime by the application using them. In this case, the app writer doesn’t really care whether the keys were “pre-shared” or “field-provisioned” all that matter is that the keys are “pre-provisioned”. Note that the distinction between pre-shared and field-provisioned keys is fuzzy enough in some cases to simply lump them all together into “pre-provisioned”: a manufacturer may burn “pre-shared” keys into a device’s ROM, but later decide to field provision a new set of keys via firmware update. These keys already exist prior to the running of apps that use them. These keys are pre-shared or field-provisioned keys which are put into a key store by a device manufacturer, by an individual user, an enterprise IT staff or some other entity. This document assumes that every cryptographic key is one of the following types: An actual API definition may want to have more flexibility, supporting a first class KeyHandle object, for example. Generate the named key with the given sizeįor the sake of simplicity, this document references keys by names in calls to functions like encrypt(). Returns a boolean notifying the caller if such named key exists Additionally, the key store allows keys to be added, deleted, etc.Īt a minimum the key store should allow the following: In this document we assume this is simply a string value chosen by the calling code. Further, “bar.com” may have its own key named “MySecretKey” without conflicting with the key of the same name for domain “foo.com”.Įach key has a unique local identifier used to refer to it over the Javascript API. The key named “MySecretKey” used by an app running from “foo.com” may not be accessed by an app running from “bar.com”. In most cases, it will be desirable to have a per-origin key store.
NETFLIX CLIENT STATISTICS CODE
This “key store” must not allow Javascript code to access the raw bytes of a key (public keys being a notable exception) but instead marshals requests for cryptographic operations using the stored keys. This document assumes the availability of key storage in the browser or browser framework. This secure protocol is then used for functions such as authorization to play movies, device registration, reporting of usage statistics, etc. Authentication may be bootstrapped from some pre-provisioned credential bound to the device. Netflix would like to implement a fast, lightweight, secure application protocol for communication between a Netflix client implemented in Javascript, running in a browser or other HTML/CSS/JS-based platform and Netflix servers (running on a cloud computing platform).