2.9 Security

This section documents system-wide security issues that are not otherwise described in the Technical Documents (TDs) for the member protocols. It does not duplicate what is already in the member protocol TDs unless there is some unique aspect that applies to the system as a whole.

The following figure shows how the content is encrypted by the system. For more details, see [MS-PCCRC] section 2.2

Content security

Figure 9: Content security

The following typical sequence of events describes the security of data during transportation and at rest (in the client cache or hosted cache):

  1. A content client requests data from a content server, and by requesting metadata, for which there are different mechanisms for SMB 2.1, 3.x, and HTTP, indicates that it supports content caching.

  2. The content server authenticates and authorizes the client in exactly the same way it would if caching were not being used. That is, authentication and authorization of a client to access data are independent of content caching.

  3. The content server recognizes that the content client can use content caching and checks to make sure that the stored metadata is up-to-date with the content.

  4. The content server then sends the metadata on the same channel that data normally would have been sent. If a secure SSL/TLS connection has been established between the client and the server, then the hashes are sent back over this encrypted connection.

  5. The content client that is requesting content obtains the metadata and uses it to discover local availability.

  6. The content client establishes a connection with the caching computer (a hosted cache server when hosted cache mode is used, or a peer caching computer when distributed cache mode is used) and requests the blocks that it requires.

  7. The caching computer encrypts the blocks with an encryption key that is derived from the content metadata that uses AES 128 by default and sends it to the content client. For more details about the encryption process for AES 128, see [FIPS197].

  8. The content client decrypts the data by using the same encryption key as the caching computer. The content client and the caching computer compute the same encryption key because they derive it from the same content metadata, which is sent by the content server.

  9. After the content client decrypts the data, it validates the data. To validate, the content client computes the block hashes on the blocks received, and then compares them to the block hashes received in the content metadata from the server. If the hashes do not match, the content client discards the data.

The data in the cache is accessible. The data is stored unencrypted in the distributed cache and the hosted cache, which is similar to other caches and data on the system.