Patent Description:
The present disclosure relates generally to anti-piracy and, more specifically, to methods, devices, and systems of server controlled client authorization proof of possession.

Web security systems, including content distribution systems (e.g., content delivery networks (CDNs)), grapple with the problem of gating access to content and/or services, e.g., assuring that access is granted to authenticated and authorized clients. Many systems have one authentication sub-system for ascertaining that the user at a client device is who they claim to be and another separate authorization sub-system for allowing access to the information provided by a server. The separation between the client authentication and authorization sub-systems complicates the aforementioned problem but is necessary for various reasons.

First, one set of business entities for providing subscription services to users is often responsible for authentication, e.g., managing user accounts, while a different set of business entities (e.g., entities running CDNs) typically provides content and/or cache media content requested by the users. As such, while one in the business of subscription selling, e.g., a subscription seller, is responsible for authentication and authorizing the authenticated subscribers, a different business is responsible for providing resources based on the authorization, e.g., providing the content and/or services for which a subscription is purchased based on the authorization provided by the subscription seller.

Second, authentication often involves a human user providing something they know, e.g., a password or a one-time code provided out-of-band. Frequent authentications are burdensome. As such, systems are often designed to perform authentications as few times as possible to reduce user annoyance, which may drive users away and cause revenue loss. On the other hand, to protect against unauthorized access, systems typically perform frequent authorizations, e.g., whenever a file or service is requested and/or for every asset and/or file retrieval request.

Some previously existing systems use tokens (also referred to hereinafter as "authorization tokens" or "access tokens") to eliminate direct communications between separate sub-systems that belong to separate business entities. The tokens carry information from the authentication stage to the resource access stage, where an authorization token is required to access resources. Upon authenticating a user, the authentication sub-system issues a signed token. When a user requests content, the signed token is sent along with the request as a proof of identity. The authorization sub-system verifies the signed token and responds to the request upon determining that the signed token is authentic. However, while the authorization sub-system has the means to validate a token, it has no means to directly authenticate the user. Consequently, in such previously existing systems, the authorization sub-system cannot verify that the token being presented has really been granted to the client. Accordingly, in the case of a pirate pretending to be a legitimate user, e.g., by presenting a copied or cloned token, the authorization sub-system in such previously existing systems cannot verify the authenticity of the token, thus allowing unauthorized access to resources by the pirate.

<CIT> discloses techniques for using two tokens to request access to a secure server. The tokens allow the server to verify, without an external call, that the requesting device is one identified in the request and that the requesting device is authorized by a trusted identity provider. A first token is an authentication token issued by the trusted identity provider and including a client device public key. The second token is a proof-of-possession token that is signed by a client device using a client device private key corresponding to the client device public key. The server obtains the client device public key from the authentication token, and then uses the client device public key to validate the proof-of-possession token. <CIT> discloses a system whereby a client computing device may obtain access to protected resources with a proof-of-possession (Pop) token. The client computing device may request an access token from an authorization server via an application server. The request may include key material (e.g., token binding type, key, and key parameters) that the client computing device possesses or has access to, such as a public key of an asymmetric public/private key pair.

So that the present disclosure can be understood by those of ordinary skill in the art, a more detailed description may be had by reference to aspects of some illustrative embodiments, some of which are shown in the accompanying drawings.

In accordance with common practice the various features illustrated in the drawings may not be drawn to scale. Accordingly, the dimensions of the various features may be arbitrarily expanded or reduced for clarity. In addition, some of the drawings may not depict all of the components of a given system, method, or device. Finally, like reference numerals may be used to denote like features throughout the specification and figures.

Numerous details are described in order to provide a thorough understanding of the example embodiments shown in the drawings. However, the drawings merely show some example aspects of the present disclosure and are therefore not to be considered limiting. Those of ordinary skill in the art will appreciate that other effective aspects and/or variants do not include all of the specific details described herein. Moreover, well-known systems, methods, components, devices, and circuits have not been described in exhaustive detail so as not to obscure more pertinent aspects of the example embodiments described herein.

In accordance with some embodiments, an end-to-end (E2E) system with enhanced authentication and authorization mitigates the aforementioned authentication and authorization issues. The E2E system includes a security headend on the server side and a security engine on the client side in accordance with some embodiments. On the client side, in some embodiments, the security engine creates a secure security association (e.g., activation during login) with the security headend as part of client authentication that requires user credentials. Using the information exchanged during the initial login, the security headend provisions keys for a client device, sends the keys to the client device through secure messages, and establishes a secure time base to prevent potential tampering or misconfiguration. The client device can then use the keys provisioned by the security headend to prove its identify as it requests authorization tokens and present an authorization proof token to resource servers in accordance with some embodiments. With the server provisioning the keys and the secure time base, the E2E system described herein, e.g., including the security headend and the security engine, enhances the overall system security and protects the cryptographic proof of possession (e.g., the authorization proof token) from potential tampering.

In accordance with various embodiments, a provisioning method for server controlled client authorization proof of possession is performed at a first server (e.g., a security headend) that includes one or more processors and a non-transitory memory. In some embodiments, the first server provisions for a client device a real-world time, a client public key, and a client private key. The first server further generates one or more provisioning response messages that include one or more of the client public key, the client private key, the real-world time, and an assertion object, where the assertion object includes a reference to the client public key. Additionally, the first server sends the one or more provisioning response messages to the client device.

In accordance with various embodiments, a method for a client presenting a server provisioned authorization proof for authorization and access to resources is performed at a client device that includes one or more processors and a non-transitory memory. In some embodiments, the client device obtains an authorization proof token, where the authorization proof token is generated based on a client public key, a client private key, and a real-world time provisioned by a first server. The client device further generates a request including the authorization proof token and an assertion object obtained from the first server that is signed by a server private key of the first server and includes an expiration time and a reference to the client public key. The client device then sends the request to a second server.

Some previously existing methods propose using a cryptographic proof of possession to mitigate the authentication and authorization issues described above. These methods fall short of describing how to protect the cryptographic proof from cloning attacks on the client side and how to protect the overall system from an attacker that manufactures bogus cryptographic identities. Moreover, some methods rely on the assumption that the client environment is trustworthy. As such, once the client environment is hacked into, previously existing systems cannot verify the authenticity of access tokens and are vulnerable to attacks initiated by pirates that present bogus cryptographic proofs. In contrast, the authentication and authorization system described herein provisions keys and a secure time base for client devices on the server side. The server side provision allows servers (e.g., authorization servers and/or resource servers) to ascertain that client keys in the requests from the client devices are indeed issued to the clients by a security headend on the server side. Accordingly, the server controlled client authorization proof of possession described herein enhances the security of the overall system and improves the protection of the cryptographic proof from attacks.

As explained above, many systems that have separate authentication and authorization sub-systems use tokens (also referred to hereinafter as "authorization tokens" or "access tokens") to carry information from the authentication stage to the resource access stage. Over-the-top (OTT) streaming is an example of such a system, where authentication of a user using a client device is carried out by one sub-system, referred to hereinafter as "the control plane", and the resource service is performed in another sub-system, e.g., a content delivery network (CDN). The authentication and authorization sub-systems in OTT streaming are thus precursors to getting an authorization token provided to the subscriber for access to resources (e.g., media content and/or services). <FIG> is a block diagram of an exemplary OTT content delivery system <NUM>, in accordance with some embodiments.

In <FIG>, a legitimate user <NUM>-<NUM> uses client device <NUM><NUM>-<NUM> to login to a control plane <NUM> and to request tokens from the control plane <NUM>. In some embodiments, the control plane <NUM> is a server that performs multiple tasks, such as login authentication, authorization, and/or providing resources. During the login phase, the control plane <NUM> authenticates the legitimate user <NUM>-<NUM> based on the information received from client device <NUM><NUM>-<NUM>. Upon authenticating the legitimate user <NUM>-<NUM>, the control plane <NUM> sends to client device <NUM><NUM>-<NUM> authorization tokens for CDN access. Client device <NUM><NUM>-<NUM> can then use the CDN authorization token to request content and access media on a CDN <NUM>. In some embodiments, for access to resources, the control plane <NUM> also sends to client device <NUM><NUM>-<NUM> digital rights management (DRM) licenses, etc. In the case of the media content being protected with DRM, client device <NUM><NUM>-<NUM> uses a DRM authorization token as part of a license request to get specific DRM license(s) for decryption.

In the system <NUM> as shown in <FIG>, a pirate <NUM>-<NUM> obtains a copy of the authorization tokens from client device <NUM><NUM>-<NUM>, e.g., by observing the authorization tokens for the control plane <NUM> and/or the CDN <NUM> or by observing tokens in open platforms such as a browser used for running a web application on client device <NUM><NUM>-<NUM>. The pirate <NUM>-<NUM> at client device <NUM><NUM>-<NUM> then uses a cloned CDN authorization token to request and obtain media content from the CDN <NUM>. Even if the media content is protected with DRM, the pirate <NUM>-<NUM> may use a cloned DRM authorization token and/or other cloned tokens obtained from the control plane <NUM> to get license key(s) for DRM protected media content. As such, the client side in the exemplary OTT content delivery system <NUM> is insecure and the security weakness allows the pirate <NUM>-<NUM> to gain access to resources in the system <NUM>.

<FIG> is an exemplary content delivery system 200A that controls client authorization proof of possession at the server side in accordance with some embodiments. In some embodiments, the server side includes one or more servers <NUM>, e.g., server <NUM><NUM>-<NUM>, server <NUM><NUM>-<NUM>, server <NUM><NUM>-<NUM>, etc., and the client side includes a plurality of client devices, including an exemplary client device <NUM>. In some embodiments, the exemplary client device <NUM> includes one or more processors <NUM> for executing one or more applications <NUM> stored in a non-transitory memory <NUM>, the non-transitory memory <NUM>, and a secure engine <NUM> that interacts with the plurality of servers <NUM>. In some embodiments, server <NUM><NUM>-<NUM> includes a security headend that performs security provisioning of the client device <NUM> and performs security heartbeat to align a client notion of real-world time (also referred to hereinafter as "a client notion of time", "a client time", or "a notion of real-world time at the client device") with a server notion of real-world time (also referred to hereinafter as "a server notion", "a server time", or "a notion of real-world time at the server"). In some embodiments, the security engine <NUM> interacts with server <NUM><NUM>-<NUM>, obtains data provisioned by server <NUM><NUM>-<NUM> (e.g., keys <NUM>), and stores the data, a client notion of real-world time <NUM>, and/or an assertion object <NUM> in the non-transitory memory <NUM>.

In some embodiments, using the keys <NUM> and the client notion of real-world time <NUM>, the security engine <NUM> generates an authorization proof token with an expiration time and sends the authorization proof token to server <NUM><NUM>-<NUM> (e.g., a secure control plane). Server <NUM><NUM>-<NUM>, upon validating the authorization proof token, sends token and/or other information for access resources to the client device <NUM>. The client device <NUM> can then use the tokens and/or other access details to request and access resources and/or content on server <NUM><NUM>-<NUM>, e.g., a CDN with protection.

Relative to the exemplary system <NUM> in <FIG>, the content delivery system 200A is more secure because the keys <NUM>, the client notion of real-world time <NUM>, and the assertion object <NUM> are provisioned and controlled by secure server <NUM><NUM>-<NUM>. Further, the authorization proof token is generated by the security engine <NUM> based on the server provisioned keys <NUM> and the client notion of real-world time <NUM>. As such, the servers <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM> can verify the legitimacy of the information presented by the client device <NUM>. Accordingly, even with different business entities running different servers <NUM> that have different authentication and/or authorization roles, e.g., server <NUM><NUM>-<NUM>, server <NUM><NUM>-<NUM>, and/or server <NUM><NUM>-<NUM> are distinct, separate, and/or non-collocated, the secure system 200A can verify the cryptographic proof of possession and protect the resources on the servers <NUM>.

It should be noted that the exemplary secure system 200A can include more, less, and/or different elements than shown in <FIG>. Further, each of the elements in the exemplary system 200A can include more, less, and/or different sub-elements than shown in <FIG>. For example, the memory <NUM> stores programs, modules and data structures, or a subset thereof including an optional operating system and the security engine <NUM> in addition to the application(s) <NUM>, the keys <NUM>, the client notion of real-world time <NUM>, and/or the assertion object <NUM>. As such, the security engine <NUM> includes a set of instructions and heuristics and metadata to be executed by the processor(s) <NUM>. Additionally, each of the elements in the exemplary system 200A can include appropriate hardware, software, firmware, and/or virtual machines to perform the operations attributed to the element herein. Operation(s) attributed to an element in the exemplary system 200A herein should not be considered binding and in some embodiments, other element(s) in the exemplary system 200A may additionally or alternatively perform such operation(s). Various embodiments of the exemplary system 200A are shown in <FIG> and <FIG> and described in further detail below.

<FIG> shows an example of an end-to-end secure content delivery system 200B with multiple servers on the server side for server controlled client authorization proof of possession, in accordance with some embodiments. In step <NUM> of <FIG>, a legitimate user <NUM>-<NUM> uses client device <NUM><NUM>-<NUM> to login to a secure control plane <NUM> (e.g., server <NUM><NUM>-<NUM> in <FIG>). In some embodiments, client device <NUM><NUM>-<NUM> includes the security engine <NUM>, e.g., a security software development kit (SDK) implementing the security engine <NUM> as described above with reference to <FIG>. In some embodiments, the login process initiates the activation flow for the security engine <NUM>.

In some embodiments, in response to receiving the login request from client device <NUM><NUM>-<NUM>, the secure control plane <NUM> interacts with a security headend <NUM> (e.g., server <NUM><NUM>-<NUM> in <FIG>) to initiate activation and security provisioning of client device <NUM><NUM>-<NUM> in step <NUM>. In some embodiment, the security headend <NUM>, which has security services running on one or more servers, takes part in the security provisioning of client device <NUM>-<NUM>, interacts with the security engine <NUM>, and sends the output of the security provisioning in one or more messages to the security engine <NUM> in step <NUM>. In some embodiments, the output of the security provisioning includes a secured cryptographic identity corresponding to client device <NUM><NUM>-<NUM>, which is represented as secured keys with which client device <NUM><NUM>-<NUM> can subsequently sign requests and demonstrate proof of possession of tokens, and/or an assertion object signed using a private key of the security headend <NUM>. In some embodiments, the output of the security provisioning also includes a secured and aligned time base, which makes sure that a client notion of time is aligned with the server it interacts with, e.g., aligned with the server notion of time on various server(s) such as the security headend <NUM>, the secure control plane <NUM>, and/or a CDN <NUM> with proof of possession protection.

As used herein, a token is a piece of data that has no meaning or use on its own, but when combined with certain tokenization systems, the token becomes a vital player in secure applications. Token-based authentication works by ensuring that each request to a server is accompanied by a signed token, where the server responds upon verifying the authenticity of the signed token.

Also as used herein, an assertion object (also referred to as "an assertion" or "a client assertion") is a package of information that facilitates the sharing of identity and security information across security domains. In some embodiments, the assertion object is used as part of an open standard for access delegation (e.g., OAUTH) flow, in which a client requests an authorization token from an authorization server and provides in the request an authorization grant received from the entity that authenticated and/or approved the client identity. In such embodiments, the assertion is created by the entity that validated client information so that the authorization server can validate the client when the client signs in.

Additionally, as used herein, an authorization server provides eligible clients with authorization tokens, which may later be used by the clients when accessing resources and services on resource servers as well as when requesting from the authorization server to refresh an expired authorization token. A resource server, as used herein, provides resources (e.g., media files) or services (e.g., facilitating a DRM license request) to eligible clients, where the eligibility is determined based on the authorization token and possibly based on the proof of possession presented by the clients when requesting the resources and/or services.

In some embodiments, in addition to or as part of the login request in step <NUM>, client device <NUM><NUM>-<NUM> also requests authorization tokens from the secure control plane <NUM>. In some embodiments, to request the authorization tokens, client device <NUM><NUM>-<NUM> presents an authorization proof token and an assertion object (e.g., the assertion object <NUM> in <FIG>). For example, the authorization proof token can be a demonstrating proof of possession (DPoP) token as defined in the Internet Engineering Task Force (IETF) Web Authorization Protocol (OAuth) Demonstrating Proof-of-Possession at the Application Layer draft) or any other data so that that the combination of the data and the assertion object demonstrates the keys presented by client device <NUM><NUM>-<NUM> (e.g., the keys <NUM> in <FIG>) are indeed issued to client device <NUM><NUM>-<NUM> by the security headend <NUM>. As such, an authorization proof token is also referred to hereinafter as a DPoP token, a proof of possession token, a proof token, or a proof of possession.

It should be noted that the secure control plane <NUM> has multiple roles. During the login phase, the secure control plane <NUM> is a login authentication server that authenticates the clients. In the initial provisioning phase, the secure control plane <NUM> is an application initial provisioning server to facilitate the generation of an initial provisioning token by the security headend <NUM>. In the application authorization phase, the secure control plane <NUM> is an application authorization server that produces application access tokens (e.g., application authorization tokens and/or application authorization refresh tokens). In the resource access authorization phase, the secure control plane <NUM> is an application resource access server for obtaining access details to resource servers (e.g., CDNs), including obtaining access tokens (also referred to hereinafter as "resource server access tokens" or "CDN access tokens") as tokens to resource servers other than the application resource server or the secure control plane <NUM>. Further, in some embodiments, the secure control plane <NUM> can be a resource server for services rendered to a client presenting an application access token.

For verification, in some embodiments, the authorization proof token is signed with a client private key provisioned by the security headend <NUM> and verifiable by a client public key inside the authorization proof token. For example, the authorization proof token can include a client public key and a client private key provisioned by the server and securely stored as the keys <NUM> (<FIG>) on client device <NUM><NUM>-<NUM>. In some embodiments, the assertion object (e.g., the assertion object <NUM>, <FIG>) includes the client public key that the security headend <NUM> provisioned for client device <NUM><NUM>-<NUM>, and the assertion object is signed by a server private key of the security headend <NUM>. As such, once the security headend <NUM> shares a server public key of the security headend <NUM> with the secure control plane <NUM> in step <NUM> in accordance with some embodiments, the secure control plane <NUM> can apply the server public key and validate that indeed the client public key is provisioned by the security headend <NUM> for client device <NUM><NUM>-<NUM>. Upon successful authentication and validation, the secure control plane <NUM> sends tokens and/or other information to client device <NUM><NUM>-<NUM> in step <NUM> for access to resources, e.g., sending CDN authorization tokens, DRM authorization tokens, and/or DRM licenses, etc. to client device <NUM><NUM>-<NUM>.

In some embodiments, when sending the information to client device <NUM><NUM>-<NUM> in step <NUM>, the secure control plane <NUM> binds the tokens and/or licenses to the proof of possession information for validation. For example, the CDN authorization tokens are bound to the authorization proof token so that client device <NUM><NUM>-<NUM> can then use the CDN authorization tokens bound to its client public key to request media from the CDN <NUM> and include an authorization proof token in the request to the CDN <NUM> in step <NUM>. The CDN <NUM> with proof of possession protection can then validate that indeed the authorization token presented by client device <NUM><NUM>-<NUM> is issued to client device <NUM><NUM>-<NUM> making the media access request. In some embodiments, in the case of the media content being DRM protected, client device <NUM> uses the DRM authorization token bound to the client public key as part of the license request, so that the secure control plane <NUM> can validate that the DRM authorization token presented by client device <NUM><NUM>-<NUM> is issued to client device <NUM><NUM>-<NUM> making the DRM license request. In another example, in an access to media content request, the DRM license is bound with the DRM authorization token and the client public key so that the resource server can validate the request before providing the media content, e.g., checking the validity of the authorization token and the authorization proof token.

In <FIG>, a pirate <NUM>-<NUM> at client device <NUM><NUM>-<NUM> may obtain a copy of the authorization tokens from client device <NUM><NUM>-<NUM> in step <NUM> using methods as explained above with reference to <FIG>. The pirate <NUM>-<NUM> may then attempt to use cloned CDN and/or DRM authorization tokens to request and obtain media content from the CDN <NUM>. However, different from the system in <FIG>, because the pirate <NUM>-<NUM> in the end-to-end secure content delivery system 200B cannot provide the server provisioned client authorization proof of possession when presenting the authorization tokens to the servers <NUM> and/or <NUM>, the secure control plane <NUM> and/or the CDN <NUM> with proof of possession protection can block such requests from client device <NUM><NUM>-<NUM>.

In particular, client device <NUM><NUM>-<NUM> cannot sign an authorization proof without the client private key that the security headend <NUM> provisioned for client device <NUM><NUM>-<NUM>. Further, because the keys for client device <NUM><NUM>-<NUM> keys were securely produced in the security headend <NUM>, e.g., in a secure environment that is unknown to the pirate <NUM>-<NUM>, even using known attack techniques with random generators, the pirate <NUM>-<NUM> cannot replicate the server side key production process to generate a client private key that matches the client private key the security headend <NUM> provisioned for client device <NUM><NUM>-<NUM>. Additionally, because client device <NUM><NUM>-<NUM> cannot produce a valid assertion object using a client public key of client device <NUM><NUM>-<NUM>, the pirate <NUM>-<NUM> cannot request new authorization tokens from the secure control plane <NUM>. As such, the secure control plane <NUM> and/or the CDN <NUM> with proof of possession protection would block any request to resources from client device <NUM><NUM>-<NUM>, such as the requests for DRM licenses and/or content access.

<FIG> shows an example of a secure over-the-top (OTT) media delivery system 200C, in accordance with some embodiments. In <FIG>, the exemplary client device <NUM> includes a media player <NUM>, an application <NUM> (e.g., one of the application(s) <NUM> as shown in <FIG>), and the security engine <NUM> as described above with reference to <FIG> and <FIG>. In some embodiments, the media player <NUM> communicates with the CDN <NUM> with proof of possession protection to request media content.

In some embodiments, the application <NUM> (e.g., for presenting a user interface (UI)), coupled with the security engine <NUM> and the media player <NUM>, communicates with the secure control plane <NUM> on the server side. In some embodiments, the application <NUM> activates the security engine <NUM>, uses the security engine <NUM> for request signing (e.g., signing the requests using the keys provisioned by the security headend <NUM>), participates in provisioning flows as described in further detail below, and instructs the media player <NUM> to play media content obtained from the CDN <NUM>.

In some embodiments, the security engine <NUM> coordinates with the security headend <NUM> to provide proof of possession based on the keys (e.g., the keys <NUM> in <FIG>) and to facilitate the time alignment, e.g., obtaining the client notion of real-world time <NUM> in <FIG> provisioned by the security headend <NUM>. In some embodiments, the client device <NUM> is protected with software obfuscation and/or secure storage techniques as known in the art to protect the application <NUM> and other data stored in the non-transitory memory <NUM> (<FIG>).

In some embodiments, when the media player <NUM> requests media assets from the CDN <NUM>, the security engine <NUM> intercepts the requests and adds the authorization proof token to the requests. In some embodiments, the security engine <NUM> further secures the requests with keys provided by the security headend <NUM>. Further, in some embodiments, the security engine <NUM> adds an authorization proof token header to the request to facilitate the token binding, validation, and/or subsequent session token creation on the CDN <NUM>.

In some embodiments, the secure control plane <NUM> authenticates and authorizes the client device <NUM> (e.g., via its communication with the application <NUM>). In some embodiments, the secure control plane <NUM> also facilitates the initial provisioning flows for the security engine <NUM>. In some embodiments, the secure control plane <NUM> is involved in validating that the assertion object includes the client public key provisioned for the client device <NUM> and is signed with the private key of the security headend <NUM>. In some embodiments, the secure control plane <NUM> also directly ascertains the validity of the assertion object presented by the client device <NUM>, e.g., by calling an application programming interface (API) provided by the security headend <NUM>.

In some embodiments, the security headend <NUM> provides the security engine <NUM> with a secure client public and private key pair for demonstrating proof of possession as well as a secure notion of real-world time. In some embodiments, the security headend <NUM> also provides the security engine <NUM> with an assertion object, where the assertion object includes the provisioned client public key and is signed with the server private key for the security headend <NUM>. In some embodiments, the security headend <NUM> further provides the security engine <NUM> with time alignment, e.g., as the security engine <NUM> periodically executes the heartbeat procedure. In some embodiments, the security headend <NUM> additionally provides an interface (e.g., an API) to the control plane <NUM> in the initial client provisioning flow, provides information elements used in initial provisioning, and/or provides another interface (e.g., another API) to the secure control plane <NUM>. With the interface(s), the secure control plane <NUM> can conduct an introspection to directly ascertain the validity of an assertion object presented by the client device <NUM> in accordance with some embodiments.

In some embodiments, the CDN <NUM> provides media content to the media player <NUM>, e.g., after validating access tokens and/or signatures attached to the proof of possession tokens, etc. Further, in some embodiments, the CDN <NUM> detects that an additional header is presented with a thumbprint of the client public key. The CDN <NUM> can then use the information in the additional header to validate the information during authorization and facilitate the session token production in accordance with some embodiments.

<FIG> is a flowchart <NUM> illustrating various sequences and states (or phases) of server controlled client authorization proof of possession for secure authorization in accordance with some embodiments. In some embodiments, the operations in the flowchart <NUM> are performed by an exemplary secure content delivery system as shown in <FIG>. The interactions between the client side and the server side within the exemplary secure content delivery system at various states are described in further detail below with reference to <FIG>, <FIG>, <FIG>, <FIG>, and <FIG>.

In some embodiments, the client device (e.g., the client device <NUM> in <FIG>) operates in a login state <NUM> to initiate the server controlled client authorization proof of possession operations. In the login state <NUM>, the secure control plane (e.g., the secure control plane <NUM> in <FIG>) as a login authentication server authenticates credentials provided by a client. In some embodiments, the client provides the credentials out of band. The login state <NUM> is the initial state as well as the state the client device reverts to in the case of the security engine (e.g., the security engine <NUM> in <FIG>) or the application (e.g., the application <NUM> in <FIG> and <FIG>) determining that the client security information (tokens and/or keys, etc.) has become invalid, e.g., not renewable by an automated process. The login state <NUM> is described in further detail below with reference to <FIG>.

In some embodiments, upon successful authentication, the client device operates in an initial provisioning state <NUM>. In the initial provisioning state <NUM>, the security engine on the client device securely receives from the security headend (e.g., the security headend <NUM> in <FIG>) an initial set of client private and public keys, an assertion object that includes an expiration time for the keys, and an initial time alignment. The security engine stores the keys, the expiration time, and/or the time in the storage on the client device, e.g., in the non-transitory memory <NUM> in <FIG>. Also in the initial provisioning state <NUM>, the security headend generates the keys, the assertion object, and the time alignment based on the information received in the login state <NUM> from the secure control plane. In some embodiments, a failure in the initial provisioning state <NUM> reverts the client device to the login state <NUM>, e.g., the secure control plane requesting login information from the client device and/or requiring re-authentication of the client. The initial provisioning state <NUM> is described in further detail below with reference to <FIG>.

In some embodiments, following the initial provisioning state <NUM>, the client device enters an application authorization state <NUM>. In the application authorization state <NUM>, the application on the client device uses the authorization grant received in the login state <NUM> to request an application authorization token for subsequent application control services. In some embodiments, the security engine on the client device generates an authorization proof token (e.g., a DPoP token) and includes the authorization proof token in the request. Further, in some embodiments, the request includes the assertion object provisioned by the security headend, so that the secure control plane acting as an application authorization server can ascertain that the client public key presented in the authorization proof token is indeed provisioned for the client device by the security headend. Alternatively, in some embodiments, the secure control plane queries the security headend to ascertain the validity of the assertion obtained from the security headend, e.g., sending a query for every request, for a random subset of the requests, and/or pursuant to a policy that takes into account the temporal information, the type of the client, the client network information, and/or the client geo location, etc..

In some embodiments, the secure control plane also provides a refresh authorization token as well as an expiration time of the access token. The refresh authorization token can be used when the authorization token is about to expire, e.g., the expiration time of the authorization token is within a threshold limit from the real-world time (e.g., the client notion of the real-world time and/or the server notion of the real-world time). In some embodiments, when the expiration for the server provisioned proof of possession information as provided in the assertion object obtained from the security headend is eminent, e.g., within the threshold limit from the real-world time, the client device enters a provisioning refresh state <NUM> to request new server provisioned proof of possession information. As shown in <FIG>, the application authorization state <NUM> is the initial state of operation following a reboot of the client device once the client device completes the initiate provisioning state <NUM> successfully and securely persists the keys and the assertion object, e.g., storing the keys and the assertion object in the non-transitory memory <NUM> (<FIG>). In some embodiments, the client device uses secure store hardware (e.g., key chain and/or a secure section of the non-transitory memory) for persisting the keys and/or the assertion object. In some embodiments, the client device encrypts and stores the keys and/or the assertion object on file system(s) using hardcoded and/or obfuscated key(s). The application authorization state <NUM> is described in further detail below with reference to <FIG>.

In some embodiments, following the application authorization state <NUM>, the client device enters a resource access authorization state <NUM>. In the resource access authorization state <NUM>, the application on the client device uses the application authorization token received in the application authorization state <NUM> to obtain subsequent authorization tokens. The client device then uses subsequent authorization tokens against resource servers that are decoupled from the security headend, e.g., DRM systems and/or CDN systems, etc. Also in the resource access authorization state <NUM>, the security engine on the client device generates an authorization proof token and includes the authorization proof token in various authorization requests. In some embodiments, when the application authorization token expires, the client device goes through a refresh flow to return to the application authorization state <NUM>. The resource access authorization state <NUM> is described in further detail below with reference to <FIG>.

In some embodiments, using the authorization tokens and the authorization proof token prepared in the resource access authorization state <NUM>, the client device requests access to resource servers. In some embodiments, in an authorized access state <NUM>-<NUM>, the application on the client device requests access to resource servers (e.g., the secure control plane) by presenting the authorization proof token and the authorization token. The authorized access state <NUM>-<NUM> is described in further detail below with reference to <FIG>. In some other embodiments, in an authorized media access state <NUM>-<NUM>, the media player (e.g., the media player <NUM> in <FIG>) sends a request that is intercepted by the security engine on the client device. In some embodiments, the security engine injects the authorization proof token as well as with an authorization proof token header that includes a thumbprint and/or hash of the client public key and attaches the authorization token to a request to resource servers such as CDNs. The injected information allows the CDNs to efficiently determine the binding state of the attached authorization token and produce a session token bound to the client public key, e.g., via the value of the authorization proof token header. The authorized media access state <NUM>-<NUM> is described in further detail below with reference to <FIG> and <FIG>.

In some embodiments, the client device activates a security heartbeat state <NUM> (e.g., as a periodic activity) following the initial provisioning state <NUM>, e.g., following a reboot and once the client device has persisted the keys, the assertion object, and/or a client notion of the real-world time, etc. In the security heartbeat state <NUM>, the security engine <NUM> securely contacts the security headend to obtain the client notion of the real-world time and updates its persisted notion of the real-world time, e.g., to adjust or align the delta between the client notion stored on the client device and the real-world time from the security headend. In the security heartbeat state <NUM>, the security headend in accordance with some embodiments also instructs the security engine on the client device to invalidate the security information (e.g., the server provisioned keys, etc.) persisted on the client device, thus reverting the client device to the login state <NUM>. The security heartbeat state <NUM> is described in further detail below with reference to <FIG>.

In some embodiments, in the provisioning refresh state <NUM>, the security engine on the client device requests a new set of client keys, a new assertion object, and time alignment from the security headend. The provisioning refresh state <NUM> is different from the initial provisioning state <NUM> in that in the provisioning refresh state <NUM>, the information the security engine presents to the security headend is based on previous provisioning. In some embodiments, the client device initiates the provisioning refresh process (e.g., from the application authorization state <NUM>) when the expiration time set in the assertion object that accompanied the client keys is about to expire, e.g., within a threshold limit from the real-world time. The provisioning refresh state <NUM> is described in further detail below with reference to <FIG>.

<FIG> is a sequence diagram <NUM> illustrating the login state <NUM> described in <FIG> in accordance with some embodiments. In the login state, the secure control plane <NUM> verifies the user identity and creates an initial secure association between the user, the application <NUM> on the client device, and the secure control plane <NUM>. In some embodiments, in step <NUM>, the application <NUM> presents the information to the secure control plane <NUM> so that the secure control plane <NUM> can validate the login and identify the user in step <NUM>. A client is authenticated to the secure control plane <NUM> using any identity verification techniques, such as using credentials possessed by the user (e.g., a user name and a password and/or biometric information), sending a text code to a phone the user operating the client device, and/or using a third-party identity provider, etc..

Once the secure control plane <NUM> validates the login information, the secure control plane <NUM> generates a code and sends the code to the application <NUM> for subsequent usage in step <NUM>. In some embodiments, the secure plane <NUM> also returns additional information for the application <NUM> to use in subsequent flows, such as a unique identifier used in the identification of a client device, e.g., an endpoint unique identifier (EUID). In some embodiments, the communication between the application <NUM> and the secure control plane <NUM> is protected using secure protocols, e.g., the application <NUM> sending the login credentials in step <NUM> and receiving the code in step <NUM> using transport layer security (TLS) as an encryption protocol.

In some embodiments, the code returned to the application <NUM> at the end of a successful login is associated with (e.g., bound to) one or more identifiers in the secure control plane <NUM>. For example, the one or more identifiers can include a user identifier (ID or UID), which is an ID that uniquely identifies the subscriber, user, and/or account in the subscriber, user, and/or account management system on the secure control plane <NUM>. In another example, the one or more identifiers include a specific instance of the login attempt, and/or a unique identifier associated with the client device (e.g., an EUID). The EUID can be generated by the secure control plane <NUM> in some embodiments. In some other embodiments, the application receives the EUID from the security engine (e.g., the security engine <NUM> in <FIG> and <FIG>) and provides to the secure control plane <NUM> as part of the login attempt. In some embodiments, the one or more identifiers also include any other information that the secure control plane <NUM> would validate in the assertion object to be received in subsequent flows.

In some embodiments, the code is associated with other information, such as a unique code ID and/or an expiration time. The unique code ID allows for subsequent uniqueness checks of the code. The expiration time can be specified explicitly or implicitly, e.g., relying on the known issued time when processing the code in subsequent flows. In some embodiments, the association of the code to the one or more identifiers, the unique code ID, and/or the expiration time is intrinsic to the code, e.g., including the one or more identifiers, the unique code ID, and/or the expiration time in cookies. Conversely, in some other embodiments, the code is a pointer to a record with the one or more identifiers, the unique code ID, and/or the expiration time stored in a database on the secure control plane <NUM>. In yet some other embodiments, the code includes a mixture of explicit specification of some elements intrinsic to the code and binding some other elements through a database record ID embedded in the code.

In some embodiments, the code is protected so that when presented in subsequent flows to the secure control plane <NUM>, the secure control plane <NUM> can validate its authenticity. Various cryptographic operations can provide such protection, e.g., encryption, decryption, and/or signing with a digital signature, etc. In some embodiments, failures in completing the login with a successful outcome result in reverting back to the start of the login state.

<FIG> is a sequence diagram 500A illustrating the initial provisioning state <NUM> in <FIG> in accordance with some embodiments. In the initial provisioning state, the security headend <NUM> securely provisions a first set of security elements that will be used in subsequent flows to secure the communication among the client device, the secure control plane <NUM>, and the resource servers. In some embodiments, the first set of security elements includes a client public and private key pair, a secure notion of real-world time, a client assertion object, and any other initial provisioning for modifying the behaviors of the security engine <NUM>, e.g., for controlling the level of error logging, etc. In some embodiments, the security engine <NUM> uses the key pair in subsequent cryptographic operations, e.g., for creating an authorization proof token. In some embodiments, during the initial provisioning, the communications among the client device, the secure control plane <NUM>, and the security headend <NUM> (e.g., steps <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>) are protected using secure protocols, e.g., using TLS as an encryption protocol.

In some embodiments, the initial provisioning starts with the application <NUM> on the client device requesting initial provisioning from the secure control plane <NUM> in step <NUM>, e.g., by providing the code the application <NUM> received at the end of the login state described above with reference to <FIG>. In some embodiments, the application <NUM> provides additional parameters along with the request, e.g., the EUID. In some embodiments, the secure control plane <NUM> validates various properties of the code in step <NUM>. In some embodiments, validating such properties includes validating that the code is signed with a key known to the secure control plane <NUM>, validating the format of the code and/or the expiration time of the code, validating that the same code has not been used more than a threshold number of times, validating that the code is associated with a valid user ID, validating that the combination of the user ID and the EUID has not been used more than a threshold number of times, and/or validating that the information bound to the code matches the additional information the application <NUM> has provided as part of the initial provisioning request. It should be noted that such validations can occur when the code embeds the properties and/or when the code points to database record(s) that hold the properties.

In step <NUM>, the secure control plane <NUM> requests an initial provisioning token from the security headend <NUM> and provides the security headend <NUM> with one or more of the user ID and EUID. In some embodiments, the secure control plane <NUM> also includes any other item(s) in the request that the secure control plane <NUM> may receive in subsequent flows as part of the client assertion object for validation. In step <NUM>, the security headend <NUM> generates an initial provisioning token (IPT) that includes the information provided by the secure control plane <NUM>. In some embodiments, the initial provisioning token also includes a unique ID for the token, an expiration time for the token, and/or a purpose code of the token (e.g., initial provisioning of keys), etc. In some embodiments, the security headend <NUM> protects the initial provisioning token, e.g., by encrypting, decrypting, signing, and/or validating, etc. In step <NUM>, the security headend <NUM> returns the initial provisioning token to the secure control plane <NUM>, and the secure control plane <NUM> returns the initial provisioning token to the application <NUM> in step <NUM>.

In step <NUM>, the application <NUM> requests initial provisioning from the security engine <NUM> and provides the security engine <NUM> with the initial provisioning token. In some embodiments, the security engine <NUM> requests initial provisioning of keys, time, and an assertion object from the security headend <NUM> and presents the initial provisioning token in step <NUM>. It should be noted that the steps shown in <FIG> are some embodiments of initiating the provisioning request. The secure system described herein may use other methods for requesting the initial provisioning and for receiving the server provisioned keys in place of or in conjunction with the embodiment described herein. For instance, some methods may have different flows, such that step <NUM> is preceded by another step, which presents the initial provisioning token, obtains some other code(s), and uses the additional code(s) to request the client keys for the first time. Such preliminary steps can be repeated multiple times in various embodiments until the initial provisioning is requested. In another example, instead of the client device initiating an explicit request, e.g., sending a request marked as "get provisioning keys", the server sends the keys to the client device as a response to a query that is not explicitly marked or as server-initiated messages (e.g., using web-socket technology).

In step <NUM>, the security headend <NUM> validates and decodes the initial provisioning token, e.g., validating the expiration time and/or the uniqueness of the initial provisioning token. Further, in step <NUM>, upon validating and decoding the initial provisioning token, the security headend <NUM> generates a provisioning response message. In some embodiments, the provisioning response message includes a client public and private key pair, the server notion of real-world time from the security headend <NUM>, and a client assertion object. In some embodiments, the provisioning response message also includes the periodic refresh interval for the security heartbeat.

In some embodiments, the client public key and the client private key are securely generated by the security headend <NUM> and protected, e.g., encrypted with a key that is hard coded in an obfuscated manner in the security engine <NUM>. In some embodiments, the client assertion object is signed with a server private key of the security headend <NUM>, where the corresponding server public key is known to the secure control plane <NUM>. In some other embodiments, the client assertion object is signed with a key shared with the secure control plane <NUM>. In some embodiments, the client assertion object includes the client public key from the server provisioned key pair and/or the corresponding hash or thumbprint, the information provided in the initial provisioning token (e.g., the user ID and/or the EUID), and/or an expiration time for the assertion object.

In step <NUM>, the security headend <NUM> sends a secure provisioning response message to the security engine <NUM>. In some embodiments, the security headend <NUM> protects the server provisioned client public key, client private key, client assertion object, and the time base using encryption and/or other cryptographic methods. For example, the response message can be encrypted using a key shared between the security headend <NUM> and the security engine <NUM> and/or signed with the server private key of the security headend <NUM>.

In step <NUM>, upon receiving the secure provisioning response message, the security engine <NUM> processes the secure message by decoding the secure message, extracting the server provisioned information, and validating that such information is indeed from the security headend <NUM>. In particular, the security engine <NUM> aligns the client notion of real-world time with the server notion of real-world time from the security headend <NUM>. Further, the security engine <NUM> decodes the client public and private key pair and prepares and securely persists the server provisioned data, e.g., using secure store software, hardware, firmware in combination with techniques such as encryption and/or obfuscation, etc. Further, in step <NUM>, the security engine <NUM> returns the client assertion object to the application <NUM>. In some embodiments, the client assertion object is signed by the server private key of the security headend <NUM> and includes the client public key (or a hash or thumbprint of the client public key) provisioned by the security headend <NUM>.

As shown in <FIG>, once the initial provisioning is completed for the client device, the security engine <NUM> has the configuration required for generating authorization proof information in subsequent flows and refreshing the client keys as well as the client notion of real-world time. Further, once the initial provisioning is completed, the application <NUM> has the client assertion object that can be presented in subsequent flows. In some embodiments, failure to complete the steps in the initial provisioning state with a successful outcome results in reverting back to the login state as shown and described above with reference to <FIG> and <FIG>.

In some scenarios, standard validation for CDN media access relying on asymmetric cryptography (e.g., public and private key pairs) for signing and validating the signature of the tokens. For example, asymmetric cryptographic operations may not be available at edge computing facilities in some CDNs, where simpler symmetric cryptographic operations are offered, e.g., symmetric hash-based message authentication code (HMAC) signing and/or validation operations. In another example, some client devices with low capacity hardware cannot perform multiple asymmetric signing operations efficiently, e.g., not capable of issuing <NUM>-<NUM> media requests per second.

To maintain the value of the authorization proof token in preventing CDN access tokens and CDN session tokens from being cloned, in some embodiments, symmetric cryptographic operations are performed for signing and validation. In such embodiments, each client has a unique secret key for signing using a symmetric signing method (e.g., secure hashing algorithm (SHA)-<NUM>). When processing a symmetric authorization proof token (e.g., an authorization signed with a symmetric key), CDNs performing simpler symmetric cryptographic operations can retrieve the unique secret key of the client and validate the signature of the symmetric authorization proof token. As used herein, the symmetric authorization proof token is also referred to hereinafter as a symmetric DPoP (SDPoP) token.

In some embodiments, upon receiving a request from the client, the CDN validates the symmetric authorization proof token in the request. For example, the CDN can validate that the method matches that of the request. In another example, the CDN can validate that the Uniform Resource Identifier (URI) matches that of the request. In still another example, the CDN can validate that the symmetric authorization proof token issue time is within the acceptable time difference from the current time, e.g., within a threshold from the expiration time. Optionally, in some embodiments, the CDN validates that the symmetric authorization proof token has not been processed before, e.g., based on a unique token identifier. In yet another example, the CDN validates that the symmetric authorization proof token is bound to the CDN access token and/or session token, e.g., by having a value in the token that is also uniquely present in the CDN access and/or session token. In some embodiments, the value is the hash of a standard public key associated with the client and presents in the SDPoP token as well as in the CDN access and/or session token. This allows the control plane to generate a CDN access token in the same way regardless of whether the client will use DPoP or SDPoP. The symmetric signing and validation method has different variants in accordance with various embodiments as shown in <FIG> and <FIG>.

<FIG> is a sequence diagram 500B illustrating one embodiment of symmetric key provisioning during the initial provisioning state <NUM> (<FIG>). The sequence diagram 500B is similar to and adapted from the sequence diagram 500A shown in <FIG>. Elements common to <FIG> and <FIG> include common step numbers, and the differences between <FIG> and <FIG> are described herein for the sake of brevity. To that end, in some embodiments, before the application <NUM> performs step <NUM> to request the initial provisioning token, the security control plane <NUM> synchronizes a shared secret key (SSK) (also known as the shared global key) with the security headend <NUM> in step a, and the secure control plane <NUM> then shares the synchronized shared secret key with the CDN <NUM> in step b. The shared secret key is thus shared between the security headend <NUM> and the CDN <NUM> but not shared with the client. Using the shared secret key, the security headend <NUM> can encrypt the unique key of a particular client security engine <NUM> and create an object that can be safely shared in the open with the CDN <NUM> within a media request from the media player on the client device.

In reference to the sequence of operations, steps 10a and 11a in <FIG> are variants of steps <NUM> and <NUM> in <FIG> in accordance with some embodiments. In step 10a, while the security headend <NUM> provisions for the security engine <NUM> the public and private key pair, the client assertion object, and the secure time base, the security headend <NUM> also generates a unique signing key for symmetric signing operations (also referred to hereinafter as a proof token key) and a wrapped key, which is the unique signing key encrypted with the shared secret key shared between the security headend <NUM> and the CDN <NUM> in step b. In some embodiments, the encryption uses a symmetric encryption method (e.g., AES-<NUM>). In some embodiments, in step 10a, the security headend <NUM> also generates a key identifier (KID) of the shared secret key. In step 11a, when the security headend <NUM> sends a secure provisioning response message to the security engine <NUM>, which includes the unique signing key, the wrapped key, and the KID.

The key wrapping method as shown in <FIG> allows the CDN <NUM> to determine the key without accessing a database, thus supporting stateless rapid processing at the edge. It further allows the key generation method to be secretive within the security headend <NUM>. However, some CDNs may have limited edge processing capability, e.g., too limited to support even symmetric encryption and/or decryption operations. Moreover, some edge processing does not support standard symmetric encryption and/or decryption operations and does not have the CPU resources for performing such operations in the edge environment. In such constrained computing environments, a more efficient key derivation method is described in further detail below with reference to <FIG> in place of the key wrapping method.

<FIG> is a sequence diagram 500C illustrating one embodiment of symmetric key provisioning during the initial provisioning state <NUM> (<FIG>). The sequence diagram 500C is similar to and adapted from the sequence diagram 500A shown in <FIG>. Elements common to <FIG> and <FIG> include common step numbers, and the differences between <FIG> and <FIG> are described herein for the sake of brevity. To that end, in some embodiments, before the application <NUM> performs step <NUM> to request the initial provisioning token, the security control plane <NUM> synchronizes a shared secret seed (SSS) (also known as the shared global seed) with the security headend <NUM> in step a, and the secure control plane <NUM> then shares the synchronized shared secret seed with the CDN <NUM> in step b. The shared secret seed is thus shared between the security headend <NUM> and the CDN <NUM> but not shared with the client. Using the shared secret seed, both the security headend <NUM> and the CDN <NUM> can derive the unique secret key used by a particular client security engine <NUM> without exposing the unique client key.

In reference to the sequence of operations, steps 10a and 11a in <FIG> are variants of steps <NUM> and <NUM> in <FIG> in accordance with some embodiments. In step 10a, while the security headend <NUM> provisions for the security engine <NUM> the public and private key pair, the client assertion object, and the secure time base, the security headend <NUM> also generates a unique signing key for symmetric signing operations that is derived from the shared secret seed obtained in step b. For example, the unique signing key can be the SHA-<NUM> HMAC of the shared secret seed with the public key created for the client in the same step 10a. In some embodiments, in step 10a, the security headend <NUM> also generates a KID of the shared secret seed. In step 11a, the security headend <NUM> sends a secure provisioning response message to the security engine <NUM>, which includes the unique signing key and the KID.

Similar to the key wrapping method shown in <FIG>, the key derivation method as shown in <FIG> allows the CDN <NUM> to determine the key without accessing a database, thus supporting stateless rapid processing at the edge. Different from the key wrapping method shown in <FIG>, because the key derivation method is deterministic and requires less from the execution environment, the key derivation method as shown in <FIG> allows the key determination method to fit within the processing constraints of some CDNs.

In both the key wrapping and key derivation methods described above, there is secret information shared between the security headend <NUM> and the CDN <NUM>. In some CDNs, the edge processing is incapable of accessing external configuration or data source when deployed, necessitating that the shared secret be hardcoded into the edge node. This potentially exposes the secret and complicates changing the secret. As such, to enhance the security of the symmetric signing and validation system, in some embodiments, a secret provisioning system is deployed to periodically create a new secret with a new KID (e.g., the shared global key in <FIG> of the shared global seed in <FIG>), generate a CDN edge execution package from a template file, add the new shared secret and its KID to the new template, and/or delete the old KID and the old secret. The new CDN edge execution package is then deployed to the CDN <NUM> and the security headend <NUM> retires the old secret upon provisioning the new secret. Using such key rotation scheme described above, in some embodiments, the secret provisioning system retains in the CDN <NUM> the old KID and the old secrets for as long as possible to allow for requests signed with the old key to be serviced until the new key is in use.

It should be noted that the key wrapping method and the key derivation method described in <FIG> and <FIG> are exemplary key provisioning methods in symmetric signing and validation systems. Other methods can be used in place of or in conjunction with the methods described with reference to <FIG> and <FIG>. For example, the CDN <NUM> can use a database for storing secret keys the security headend <NUM> provisioned for each client. When processing a client request, such CDNs <NUM> use the client ID, e.g., provided in the request, to lookup the symmetric signing key used by the client in the database. Upon locating the symmetric signing key in the database, such CDNs <NUM> retrieve the key from the database and use the key to decode the token.

<FIG> is a sequence diagram <NUM> illustrating the application authorization state <NUM> in <FIG> in accordance with some embodiments. In some embodiments, the application <NUM> checks the expiration time of the client assertion object in step <NUM>. In some embodiments, upon determining that the client assertion object is close to expiration, the client device enters the provisioning refresh state as will be described in further detail with reference to <FIG>. Upon determining that the client assertion object is not close to expiration, in step <NUM>, the application <NUM> requests the security engine <NUM> to provide an authorization proof token for signing a pending request of an application authorization token from the secure control plane <NUM>. The application <NUM> provides the URL and the method for accessing the server in the pending request. In some embodiments, in the case of the intended request including an authorization token, the application <NUM> also provides the authorization token.

In step <NUM>, the security engine <NUM> uses the client public and private key pair provisioned by the server and the client notion of real-world time to generate an authorization proof token. In step <NUM>, for the first application authorization token request after the login state, the application <NUM> requests the secure control plane <NUM> to provide an initial application authorization and refresh token. In some embodiments, the request includes the code received by the application <NUM> in the login state as described above with reference to <FIG>, the client assertion object provisioned by the security headend <NUM> (e.g., the client assertion object signed with the server private key of the security headend <NUM> and including the client public key as well as other information such as the user ID, etc.), and the authorization proof token (or the authorization proof token header) as generated in step <NUM>. In step <NUM>, for a subsequent application authorization token request, the application <NUM> requests a new application authorization and refresh token from the secure control plane <NUM>. In some embodiments, in the request to the secure control plane <NUM>, the application <NUM> includes the refresh token received by the application <NUM> in the previous run of the application authorization request, the client assertion object provisioned by the security headend, and the authorization proof token (or the authorization proof token header) as generated in step <NUM>.

In step <NUM>, the secure control plane <NUM> validates the request, e.g., validating the code and/or the client assertion object. For example, the secure control plane <NUM> can validate that the validity of the code (e.g., not expired) and/or validate that the code applies to a valid user ID, etc. In another example, the secure control plane <NUM> can use a server public key of the security headend that the security headend shares with the secure control plane <NUM> to validate that the client assertion object is signed by the security headend. In some embodiments, the secure control plane <NUM> validates that the client public key (or a client public key thumbprint or hash) in the assertion object matches the client public key provided by the security engine <NUM>. In yet another example, the secure control plane <NUM> validates other content of the client assertion object (e.g., the user ID) matches expected values (e.g., the identifiers bound to the code) and/or other properties of the client assertion object (e.g., the client assertion object has not expired, etc.). In some embodiments, the secure control plane <NUM> queries the security headend by providing the security headend with the assertion object and asking for verification by the security headend that the assertion object is produced by the security headend.

Upon validating the client request, in step <NUM>, the secure control plane <NUM> generates an authorization and refresh token and binds the authorization and refresh token to the client public key in the authorization proof token generated by the security engine <NUM>. In step <NUM>, the secure control plane <NUM> sends the authorization and refresh token to the application <NUM> for subsequent use. In some embodiments, during the application authorization, the communications between the client device and the secure control plane <NUM> (e.g., steps <NUM>, <NUM>, and <NUM>) are protected using secure protocols such as TLS.

As shown in <FIG>, when the client assertion object is not close to its expiration, once the application authorization is completed, the application <NUM> is in possession of a valid authorization token for accessing the secure control plane <NUM> services, a valid refresh token for refreshing the authorization token as well as the client public and private key pair. Failures in completing the steps shown in <FIG> result in reverting back to the login state shown in <FIG>.

<FIG> is a sequence diagram <NUM> illustrating the resource access authorization state <NUM> in <FIG> in accordance with some embodiments. In the resource access authorization state, the application <NUM> receives authorization tokens to resource services other than the secure control plane <NUM>, where the resource services do not share certain information with the security headend and may not be aware of the specifics of the client assertion object. In some embodiments, the client device enters the resource access authorization state each time a play catalog is displayed to the user with links to different media assets or when the resource server access fails and requires a refresh of the resource server access details. At the end of the resource access authorization state, the application <NUM> has the authorization token(s) to access resources on various resource servers, where the authorization token(s) are bound to the client public key in accordance with some embodiments. Failures in completing the steps in the resource access authorization state result in reverting back to the application authorization state as described above and shown in <FIG>.

In step <NUM> of the resource access authorization state <NUM>, the application <NUM> checks if the control plane authorization token is about to expire. In some embodiments, the client device reverts to the application authorization state shown in <FIG> for the control plane authorization token refresh when the application <NUM> receives an error from the secure control plane <NUM> indicating that the control plane authorization token has expired or is close to expiration. Having determined that the time-to-live value of the control plane authorization token is sufficient, e.g., not within a threshold from the expiration time, in step <NUM>, the application <NUM> requests the security engine <NUM> to provide an authorization proof token for a pending request of resource access details from the secure control plane <NUM>. In some embodiments, the application <NUM> includes in the request the URL and the method for accessing a particular resource server and optionally the control plane authorization token in some embodiments. In response to the request, the security engine <NUM> uses the client public and private key pair and the client notion of real-world time to generate an authorization proof token in step <NUM>.

In step <NUM>, the application <NUM> requests the access details for a resource server by providing the control plane authorization token and the authorization proof token. In step <NUM>, the secure control plane <NUM> validates the request, e.g., checking the validity of the authorization token, the authorization proof token, and the binding between the two. In step <NUM>, upon validating the request, the secure control plane <NUM> generates the authorization access token(s) for accessing the particular resource server and binds the authorization access token(s) to the client public key in the authorization proof token received in step <NUM>. In some embodiments, the secure control plane <NUM> also adds additional access details for the application <NUM> to access the media assets, e.g., a list of media manifest URLs combined with the authorization access tokens. In step <NUM>, the secure control plane <NUM> sends the resource server access details to the application <NUM>. In some embodiments, during the resource access authorization, the communications between the client device and the secure control plane <NUM> (e.g., steps <NUM> and <NUM>) are protected using secure protocols, e.g., TLS.

<FIG> is a sequence diagram <NUM> illustrating the authorized access state <NUM>-<NUM> in <FIG> in accordance with some embodiments. In the authorized access state <NUM>-<NUM>, the application <NUM> uses protected authorization to access a third-party system, such as a DRM system. In particular, the application <NUM> securely accesses resources on resource servers by providing proof of possession, e.g., presenting the authorization proof tokens. In some embodiments, the media player on the client device accesses resources on resource servers such as CDNs without changes to the media player with enhanced security, e.g., by using the authorization proof token for the authorization and session tokens.

In step <NUM> of the authorized access state, the application <NUM> requests the security engine <NUM> to provide an authorization proof token for a pending request to access resources from a resource server <NUM>. The request includes the URL and the method used for accessing the resource server <NUM>. In some embodiments, the request optionally includes the authorization token for accessing the resource server <NUM>, where the authorization token establishes bindings to the authorization proof token. In step <NUM>, the security engine <NUM> uses the client public and private key pair and the client notion of real-world time to generate an authorization proof token and sends the authorization proof token to the application <NUM>. In step <NUM>, the application <NUM> sends an access request to the resource server <NUM>, where the access request includes the access authorization token and the authorization proof token. In step <NUM>, the resource server <NUM> validates the request, e.g., by checking the validity of the resource authorization token, the authorization proof token, and the binding between the two. In step <NUM>, the resource server <NUM> sends a response to the application <NUM>, e.g., a resource such as a file, or a reply to an application program interface (API) call upon a successful validation. In some embodiments, the resource server <NUM> sends an error upon a failed validation. In the case of a failed validation, the client device reverts to the resource access authorization state as shown in <FIG> to refresh its notion of the resource server access details.

<FIG> is a sequence diagram 900A illustrating the authorized media access state <NUM>-<NUM> in <FIG>, e.g., accessing media from the CDN <NUM>, in accordance with some embodiments. In step <NUM>, the application <NUM> instructs the media player <NUM> to start playing a media asset. In some embodiments, the instruction includes a URL to the media manifest file on the CDN <NUM> and the CDN authorization token obtained from the secure control plane. In some embodiments, when the media player <NUM> makes a request to the CDN <NUM> for the manifest, in step <NUM>, the security engine <NUM> intercepts the request before the request is sent over the network to the CDN <NUM>. In some embodiments, the media player <NUM> provides interception filters or plug-ins for the request interception. In some other embodiments, the application <NUM> changes the manifest URL to point to a local host IP address where the security engine <NUM> implements a web proxy for the request interception.

In step <NUM>, the security engine <NUM> computes an authorization proof token for the intercepted request and injects the authorization proof token into the request. In some embodiments, the security engine <NUM> also injects an authorization proof token header (e.g., a DPoP-CNF header) and provides the hash or thumbprint of the client public key. Further, in some embodiments, the security engine <NUM> obtains the CDN authorization token, e.g., from the request URL or a cookie header and/or based on a text search for the appropriate field names such as "accesstoken=*;".

In step <NUM>, the CDN <NUM> validates the CDN access token and the authorization proof token header. In some embodiments, when the CDN <NUM> is protected with authorization proof, the CDN <NUM> uses the client public key in the authorization proof token header to validate the binding to the CDN access token. The binding validation is a preliminary step to the more computationally intensive tasks such as decoding the authorization proof token and validating the binding to the public key within the authorization proof token in accordance with some embodiments.

In step <NUM>, the CDN <NUM> returns the manifest file to the media player <NUM>. In some embodiments, the CDN <NUM> computes a new CDN access token and a session token to return to the media player <NUM> (e.g., in a cookie header). The media player <NUM> can then use the CDN access token and the session token in subsequent requests for files referenced by the media manifest. In some embodiments, the CDN <NUM> uses the value of an HTTP header as described in step <NUM> to compute the secret for validating the new CDN access and/or session token. In some embodiments, the value carried in the authorization proof token header is part of the secret, thus binding the new token(s) to the client public key without requiring the CDN <NUM> to change the format of the session token or the method of producing the session token.

In some embodiments, steps <NUM>-<NUM> are repeated for requesting segments of the media asset until the media asset finishes playing. In step <NUM>, the media player <NUM> generates request(s) to the CDN <NUM> for segment(s) and/or file(s) pointed by the manifest. Each request is intercepted by the security engine <NUM>, e.g., using the same mechanism as in step <NUM>. In step <NUM>, as in step <NUM>, for each request intercepted by the security engine <NUM>, the security engine <NUM> generates an authorization proof token and injects the authorization proof token into the request. In some embodiments, the security engine <NUM> optionally injects the authorization proof token header prior to sending the request to the CDN <NUM>. In step <NUM>, the CDN validates the CDN access token. In some embodiments, the CDN <NUM> validates the CDN access token via the authorization proof token header binding and/or the authorization proof token and the binding of the authorization proof token to the CDN authorization token, which is the new session token as generated in step <NUM>. In step <NUM>, the CDN <NUM> returns the segment and/or the file to the media player <NUM>, and the media player <NUM> renders the segment and/or the file as received and continues to make requests until the manifest is completed.

In some embodiments, in case of failing to access the media asset from the CDN <NUM>, e.g., a validation error in step <NUM> or step <NUM>, the CDN <NUM> returns an error response at the beginning of the loop, e.g., in step <NUM>, or at the end of the loop, e.g., in step <NUM>. In such embodiments, the media player <NUM> reports an access error message to the application <NUM>. In some embodiments, upon receiving the access error reporting, the application <NUM> goes back to the resource access authorization state as shown in <FIG> to refresh the CDN access details. In some embodiments, CDN authorization failures in completing the steps in <FIG> result in reverting back to the resource access authorization step as shown in <FIG>.

<FIG> is a sequence diagram 900B illustrating one embodiment of using symmetric key in the authorized media access state <NUM>-<NUM> in <FIG>. The sequence diagram 900B is similar to and adapted from the sequence diagram 900A shown in <FIG>. Elements common to <FIG> and <FIG> include common step numbers, and the differences between <FIG> and <FIG> are described herein for the sake of brevity. To that end, in some embodiments, the security engine <NUM> adds a proof token header to each media request made by the client, including adding the proof token header to both the manifest request and the segment request to the CDN <NUM>. For instance, after the manifest request was intercepted in step <NUM>, the security engine <NUM> inserts a proof token header (e.g., an SDPoP header) that is signed with the symmetric key provisioned by the security headend to the manifest request in step 3a before the request is sent to the CDN <NUM> in step 3b. Likewise, after the request for a segment was intercepted in step <NUM>, the security engine <NUM> inserts a proof token header (e.g., SDPoP header) that is signed with the symmetric key provisioned by the security headend to the segment request in step 7a before the request is sent to the CDN <NUM> in step 7b.

In some embodiments, the proof token header includes a header section, a payload section, and a signature of the security engine <NUM> with the client unique secret key. In some embodiments, the payload section includes the request method (e.g., GET method), the request URI, the timestamp the token was issued, a unique identifier for the token, and a conformation of the client public key to be compared with the one bound to the CDN access and session tokens. The header section can include various items depending on the method used for provisioning the client secret key. For instance, using the key wrapping method as described above with reference to <FIG>, in some embodiments, the header section includes a token type (e.g., SDPoP, etc.), the specification of the symmetric signing method (e.g., "HS256" indicating SHA-<NUM> cryptographic hash function), the wrapped client key (e.g., the wrapped key generated in step 10a of <FIG>), the KID of the shared secret key (e.g., the KID generated in step 10a of <FIG>). In another example, using the key derivation method as described above with reference to <FIG>, in some embodiments, the header section includes the token type (e.g., SDPoP, etc.), the specification of the symmetric signing method (e.g., "HS256" indicating SHA-<NUM> cryptographic hash function), and the KID of the shared secret seed (e.g., the KID generated in step 10a of <FIG>).

Upon receiving the request, in step 8a, the CDN <NUM> processes the access and session tokens in the request in accordance with some embodiments. In some embodiments, the CDN <NUM> also determines the value of the client unique secret key. For instance, when the CDN <NUM> determines that the request includes a wrapped key, e.g., based on the information in the proof token header, the CDN <NUM> decrypts the proof token header using the secret key shared with the security headend <NUM> and uses the KID to select a specific shared secret key from a possible set (e.g., provided in support of the shared secret key rotation processes). In another example, when the CDN <NUM> determines that the request includes a shared secret seed identifier, e.g., based on the information in the proof token header, the CDN <NUM> derives the client unique secret key using the secret seed shared with the security headend <NUM> and uses the KID to select a specific shared secret seed from a possible set (e.g., provided in support of the shared secret seed rotation processes). The CDN <NUM> then applies the same key derivation method as used by the security headend <NUM> (e.g., SHA-<NUM> HMAC of the shared secret seed with the public key).

<FIG> is a sequence diagram <NUM> illustrating the provisioning refresh state <NUM> in <FIG>, in accordance with some embodiments. In some embodiments, the provisioning refresh state can be reached from the application authorization state. In the provisioning refresh state, the client public and private key pair as well as the client assertion object are refreshed. In step <NUM>, the application <NUM> requests refresh provisioning from the security engine <NUM>. In some embodiments, the request includes the current client assertion object. In step <NUM>, the security engine <NUM> requests refresh provisioning of keys and the client assertion object from the security headend <NUM>. In some embodiments, the security engine <NUM> uses the client private key to sign the client assertion object and attaches the client public key to the client assertion object. Because the client assertion object was signed using the server private key when provisioned by the server, the client assertion object sent to the security headend <NUM> in step <NUM> is signed with one inner signature corresponding to the server private key of the security headend <NUM> and one outer signature corresponding to the client private key.

In step <NUM>, the security headend <NUM> validates and decodes the client assertion object. In some embodiments, the security headend <NUM> validates multiple signatures associated with the client assertion object. In some embodiments, because the client assertion object was signed using the server private key of the security headend <NUM>, the security headend <NUM> uses the server public key of the security headend <NUM> to validate the inner signature of the client assertion object. In some embodiments, because the client assertion object was also signed with the client private key as described in step <NUM> above, the security headend <NUM> uses the client public key attached to the client assertion object to validate the outer signature. Further, in some embodiments, because the client assertion object includes the client public key (or a client public key hash), the security headend <NUM> validates the client assertion object by matching the client public key attached to the assertion object with the client public key included in the client assertion object. In some embodiments, the security headend <NUM> also validates additional data, e.g., incrementing a count of provisioning refresh requests from the client device and determining whether the number of provisioning refresh requests from the client device has exceeded a threshold over a period of time. Such validations make sure that the number of refresh provisioning requests received from the particular client device identified by the client assertion object over a period of time is lower than a threshold.

In step <NUM>, the security headend <NUM> generates a provisioning response message that includes a client public and private key pair and a new client assertion object. In some embodiments, the client public and private key pair is securely generated by the server and protected, e.g., encrypted with a key in an obfuscated manner on the client device. In some embodiments, the security headend <NUM> signs the new client assertion object with a server private key of the security headend <NUM>, where the corresponding server public key is known to the secure control plane. In some other embodiments, the security headend <NUM> signs the new client assertion object with a key shared with the secure control plane. In some embodiments, the new client assertion object includes the client public key from the client public and private key pair or a representation (e.g., a hash or thumbprint) of the client public key. In some embodiments, the client assertion object also includes the information provided in the initial provisioning token (e.g., the user ID and/or the EUID) and/or an expiration time for the new assertion object.

In some embodiments, the provisioning response message is protected and verifiable by the security engine <NUM>. In particular, the security engine <NUM> can decode the information in the provisioning response message and validate that the information indeed came from the security headend <NUM>. For example, the provisioning response message can be encrypted by a key shared between the security headend <NUM> and the security engine <NUM>, where the key is protected in accordance with some embodiments, e.g., obfuscated on the client device. In another example, the provisioning response message can be signed with a server private key of the security headend <NUM>, where the security engine <NUM> has a corresponding server public key.

In step <NUM>, the security headend <NUM> sends the provisioning response message to the security engine <NUM>. Upon receiving the provisioning response message, in step <NUM>, the security engine <NUM> processes the provisioning response message and validates the information in the message. For example, the security engine <NUM> analyzes and/or records the client assertion expiration time, decodes the client public and private key pair, and prepares to use them in subsequent flows. In some embodiments, the security engine <NUM> securely persists the server provisioned data, e.g., using a secure hardware storage, applying encryption, and/or storing obfuscated key(s), etc. In step <NUM>, the security engine <NUM> further sends the client assertion object to the application <NUM>.

In some embodiments, during the provisioning refresh, the communications between the client device and the security headend <NUM> (e.g., steps <NUM> and <NUM>) are protected using secure protocols, e.g., TLS. Once the provisioning refresh is completed, the security engine <NUM> is in possession of a new pair of client public and private keys that is resistant to attacks on the client environment. Further, the application <NUM> is in possession of a new client assertion object for subsequent flows, such as entering the application authorization state as shown in <FIG>. In some embodiments, failures in completing the steps shown in <FIG> result in reverting back to the login state as shown in <FIG>.

<FIG> is a sequence diagram <NUM> illustrating the security heartbeat state <NUM> in <FIG>, in accordance with some embodiments. In some embodiments, the client device periodically enters the security heartbeat state <NUM> to align the client notion of real-world time with the server notion of real-world time from the security headend <NUM>. As such, in some embodiments, steps <NUM>-<NUM> are repeated every heartbeat period T to create a secure notion of time on the client side.

In step <NUM>, the security engine <NUM> sends the security headend <NUM> a heartbeat request. In some embodiments, the heartbeat request includes a signed identifier known to the security headend <NUM> (e.g., the EUID signed by the client private key). In step <NUM>, the security headend <NUM> validates the request, e.g., validating that the EUID is indeed signed by the client private key. In some embodiments, to validate the request, the security headend <NUM> looks up the matching client public key provisioned for the particular EUID. In step <NUM>, the security headend <NUM> generates a protected message including the server notion of real-world time as well as configuration changes to be applied on security engine <NUM>, e.g., changes in the error logging level and/or changes in the heartbeat period T, etc. In some embodiments, the protected message includes a "Revoke" command, which causes the client device to revert to the login state. In step <NUM>, the security headend <NUM> sends the protected message to the security engine <NUM>. In some embodiments, the protected message is protected by performing cryptographic operation(s) on the message, e.g., by encryption the message with the client public key or a shared key and/or by signing the message with the server private key of the security headend <NUM>.

In step <NUM>, the security engine <NUM> receives the message, applies configuration changes according to the message, and adjusts the client notion of real-world time based on the server notion in the message in accordance with some embodiments. In the case of a failure or having a revoke command in the message, the client device revokes its security configurations (e.g., by removing the client public and private key pair from the storage) and reverts to the login state as shown in <FIG>.

In some embodiments, in the security heartbeat state, the communications between the client device and the security headend <NUM> (e.g., steps <NUM> and <NUM>) are protected using secure protocols, e.g., TLS. Once the security heartbeat configuration is complete, the client notion of real-world time is aligned with the server notion. The alignment makes the client environment more resistant to attacks. In some embodiments, failures in completing the steps shown in <FIG> result in the client device reverting to the login state shown in <FIG>.

<FIG> is a flowchart illustrating a provisioning method <NUM> for server controlled client authorization proof of possession in accordance with some embodiments. In some embodiments, as represented by block <NUM>, the method <NUM> is performed at a first server (e.g., server <NUM><NUM>-<NUM>, <FIG>) that includes one or more processors and a non-transitory memory. In some embodiments, as represented by block <NUM>, the method <NUM> includes the first server provisioning for a client device (e.g., the client device <NUM>, <FIG>) a real-world time, a client public key, and a client private key (e.g., as shown in step <NUM> in <FIG>). As represented by block <NUM>, the method <NUM> further includes the first server generating one or more provisioning response messages that include one or more of the client public key, the client private key, the real-world time, and an assertion object, wherein the assertion object includes a reference to the client public key (e.g., as shown in steps <NUM> and <NUM> in <FIG>). Additionally, as represented by block <NUM>, the method <NUM> includes the first server sending the one or more provisioning response messages to the client device (e.g., as shown in step <NUM> in <FIG>).

<FIG> is a flowchart illustrating a method <NUM> for a client presenting a server provisioned authorization proof for authorization and access to resources in accordance with some embodiments. In some embodiments, as represented by block <NUM>, the method <NUM> is performed at a client device (e.g., the client device <NUM>, <FIG>) that includes one or more processors (e.g., the processor(s) <NUM>, <FIG>) and a non-transitory memory (e.g., the memory <NUM>, <FIG>). In some embodiments, as represented by block <NUM>, the method <NUM> includes the client device (e.g., the security engine <NUM>, <FIG>) obtaining an authorization proof token, where the authorization proof token is generated based on a client public key, a client private key, and a real-world time provisioned by a first server (e.g., server <NUM>-<NUM>, <FIG>). As represented by block <NUM>, the method <NUM> further includes the client device (e.g., the application(s) <NUM>, <FIG>) generating a request including the authorization proof token and an assertion object obtained from the first server that is signed by a server private key of the first server and includes an expiration time and a reference to the client public key. As represented by block <NUM>, the method <NUM> also includes the client device (e.g., the application(s) <NUM>, <FIG>) sending the request to a second server, e.g., as in step <NUM> or step <NUM> of the application authorization state in <FIG>).

<FIG> is a block diagram of a computing device <NUM> for server control of client authorization proof of possession in accordance with some embodiments. In some embodiments, the computing device <NUM> corresponds to server <NUM><NUM>-<NUM> in <FIG> and/or the security headend <NUM> in <FIG> and <FIG> and performs one or more of the functionalities described above with respect to server <NUM><NUM>-<NUM> and/or the security headend <NUM>. While certain specific features are illustrated, those skilled in the art will appreciate from the present disclosure that various other features have not been illustrated for the sake of brevity, and so as not to obscure more pertinent aspects of the embodiments disclosed herein. To that end, as a non-limiting example, in some embodiments the computing device <NUM> includes one or more processing units (CPUs) <NUM> (e.g., processors), one or more input/output interfaces <NUM> (e.g., input devices, sensors, a network interface, a display, etc.), a memory <NUM>, a programming interface <NUM>, and one or more communication buses <NUM> for interconnecting these and various other components.

In some embodiments, the communication buses <NUM> include circuitry that interconnects and controls communications between system components. The memory <NUM> includes high-speed random access memory, such as DRAM, SRAM, DDR RAM or other random access solid state memory devices; and, in some embodiments, include non-volatile memory, such as one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile solid state storage devices. The memory <NUM> optionally includes one or more storage devices remotely located from the CPU(s) <NUM>. The memory <NUM> comprises a non-transitory computer readable storage medium. Moreover, in some embodiments, the memory <NUM> or the non-transitory computer readable storage medium of the memory <NUM> stores the following programs, modules and data structures, or a subset thereof including an optional operating system <NUM>, a storage module <NUM>, a provisioning unit <NUM>, a provisioning message generator <NUM>, a validation unit <NUM>, and a time alignment unit <NUM>. In some embodiments, one or more instructions are included in a combination of logic and non-transitory memory. The operating system <NUM> includes procedures for handling various basic system services and for performing hardware dependent tasks.

In some embodiments, the storage module <NUM> stores keys <NUM> and/or other data to facilitate authentication and/or authorization. To that end, the storage module <NUM> includes a set of instructions 1439a and heuristics and metadata 1439b.

In some embodiments, the provisioning unit <NUM> is configured to provision keys <NUM> and/or real-world time for client devices to facilitate client authorization proof of possession. To that end, the provisioning unit <NUM> includes a set of instructions 1441a and heuristics and metadata 1441b.

In some embodiments, the provisioning message generator <NUM> is configured to package key(s) <NUM>, token(s), and/or code(s) provisioned for client devices in message(s). To that end, the provisioning message generator <NUM> includes a set of instructions 1443a and heuristics and metadata 1443b.

In some embodiments, the validation unit <NUM> is configured to validate the data to client authorization proof of possession using the key(s) <NUM>. To that end, the validation unit <NUM> includes a set of instructions 1445a and heuristics and metadata 1445b.

In some embodiments, the time alignment unit <NUM> is configured to provision real-world time and/or periodic refresh intervals for client devices. To that end, the time alignment unit <NUM> includes a set of instructions 1447a and heuristics and metadata 1447b.

Although the storage module <NUM>, the provisioning unit <NUM>, the provisioning message generator <NUM>, the validation unit <NUM>, and the time alignment unit <NUM> are illustrated as residing on a single computing device <NUM>, it should be understood that in other embodiments, any combination of the storage module <NUM>, the provisioning unit <NUM>, the provisioning message generator <NUM>, the validation unit <NUM>, and the time alignment unit <NUM> can reside in separate computing devices in various embodiments. For example, in some embodiments, each of the storage module <NUM>, the provisioning unit <NUM>, the provisioning message generator <NUM>, the validation unit <NUM>, and the time alignment unit <NUM> resides on a separate computing device.

Moreover, <FIG> is intended more as functional description of the various features which are present in a particular implementation as opposed to a structural schematic of the embodiments described herein. As recognized by those of ordinary skill in the art, items shown separately could be combined and some items could be separated. For example, some functional modules shown separately in <FIG> could be implemented in a single module and the various functions of single functional blocks could be implemented by one or more functional blocks in various embodiments. The actual number of modules and the division of particular functions and how features are allocated among them will vary from one embodiment to another, and may depend in part on the particular combination of hardware, software and/or firmware chosen for a particular embodiment.

It will also be understood that, although the terms "first," "second," etc. may be used herein to describe various elements, these elements should not be limited by these terms. For example, a first device could be termed a second device, and, similarly, a second device could be termed a first device, which changing the meaning of the description, so long as all occurrences of the "first device" are renamed consistently and all occurrences of the "second device" are renamed consistently. The first device and the second device are both devices, but they are not the same device.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the claims. As used in the description of the embodiments and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

Claim 1:
A method comprising:
at (<NUM>) a client device including one or more processors and a non-transitory memory:
obtaining from a first server a client public key generated by the first server, a client private key generated by the first server, an assertion object generated by the first server, and a server notion of real-world time provisioned by the first server, wherein the assertion object includes a reference to the client public key and an expiration time, and the assertion object is generated upon successful authentication of the client device by a second server, separate and distinct from the first server;
creating an authorization proof token by performing cryptographic operations using the client public key, the client private key, and a client notion of real-world time aligned with the server notion of real-world time;
generating (<NUM>) a request including the authorization proof token signed using the client private key and the assertion object obtained from the first server ; and
sending (<NUM>) the request to the second server to prove the identity of the client device, including triggering the second server to validate one or more of the authorization proof token and the assertion object.