Device Authentication and Secure Key Exchange

1. Overview

SSP provides a service called Device Authentication Service (DAS) and related client SDKs. This service enables operators to:

• Authenticate a device from the operator backend. This authentication is based whenever possible on secure platform-level elements like hardware root of trust or TEE, whether shared or not with the DRM platform.

• Secure the delivery of symmetric keys provided by the operator and intended to be used by the application running on the device. These keys can then be used by applications to encrypt/decrypt or sign/validate data sent or received to/from either a server in a client-server protocol or other devices in a peer-to-peer protocol.

2. Deployment Architecture

NAGRA provides the DAS only as a SaaS from AWS. It can be interfaced from any operator services either running on their premises or in the cloud. These operator services need to be authenticated using SSP credentials when interacting with the DAS.

NAGRA also provides three kinds of client SDKs depending on the nature of the targeted device.

Details about the different SDKs, demo applications, and documentation can be found here.

3. Supported Algorithms and Features

Persistence and multi-session details:

• Connect scheme always persists keys provided by DAS and always replaces old keys with new keys after new keys have been provided.

• Widevine scheme does not support persistence but allows importing several set of keys and using them all while the sessions are opened on the client.

• Web scheme does not support persistence but allows importing several set of keys and using them all while the sessions are opened on the client.

• TVKeyCloud scheme does not support the secure key exchange operation.

4. Using the DAS to Secure Access Tokens

Operators can use DAS in combination with their user management service to first authenticate a client application that is connecting and then strongly bind any kind of access tokens to these authorized application instances.

The following sequence diagrams detail a proposed flow :

The strong binding of the sessionToken to the application instance is realized by interfacing the sessionKey keyId (step 14) in each request using the sessionToken (step 16). Previously, the sessionKey keyValue was securely delivered to the authorized application instance using the DAS in step 9. In detail:

1. The application requests the Authentication SDK for authentication data.

2. The Authentication SDK returns the authentication data (dasMessage1) associated to a session object so that keys can be imported later (step 12) protected for this session. It is also important to provide the crypto scheme to the server side – it can either be hardcoded in the application or exported from the Authentication SDK depending on the type of SDK.

3. The application performs a sign-in request to the server API Gateway by providing user credentials, the authentication data, and the crypto scheme.

4. The API Gateway calls the DAS to authenticate the device by providing the scheme and the authentication data.

5. The DAS returns the deviceId and optionally the model. This deviceId may be a DRM deviceId or not depending on the scheme used.

6. The API Gateway requests the operator portal to authorize the user on that instance of the device of this model.

7. The portal validates the user credentials on this device and then returns a status and the accountId.

8. The API Gateway now creates a session token for this accountId on the deviceId running this application. The API Gateway will later enforce that each time the token is used in a request, the keyValue associated with the token is used to sign the request data. To enable this functionality, the API Gateway needs to maintain the link between the keyId and keyValue and the session token.

9. The API Gateway requests the DAS service to protect the keyId and keyValue for the device by providing the dasMessage1 coming from the Authentication SDK and both fields in the sessionKey input structure of the secureKeyExchange operation.

10. The DAS protects the keyId and keyValue for the device and returns a dasMessage2.

11. The API Gateway now returns the sessionToken, the dasMessage2, and the keyId to the application.

12. The application imports the dasMessage2 into the Authentication SDK.

13. Now, for each request that uses the sessionToken and that needs to be authenticated, the application first starts to create the request with all its arguments and payload.

14. Then the application requests the Authentication SDK to sign the request using the keyId that was delivered in step 11.

15. The Authentication SDK securely computes the signature of the requests by using the keyValue referred by the keyId.

16. The application now sends the request to the API Gateway with its signature.

17. The API Gateway first validates the sessionToken and retrieves the keyValue and all other parameters associated to the sessionToken.

18. The API Gateway then validates the request signature with the keyValue.

19. The API Gateway finally calls the portal to process the authenticated request by provided parameters retrieved from the sessionToken.

20. The portal returns the answer to the API Gateway.

21. The API Gateway returns the answer to the application.

In the previous diagram and description, the DAS APIs are simplified – the details are available here. Similarly, the AuthSDK API depends on the SDK flavors, but each AuthSDK is provided with reference source code to help to realize steps 1, 2, 12, 14 and 15.

5. Examples of device identifiers and models exposed by DAS server