BranchCache implements a secure-by-design approach that works seamlessly alongside your existing network security architectures, without the requirement for additional equipment or complex additional security configuration.
BranchCache is non-invasive and does not alter any Windows authentication or authorization processes. After you deploy BranchCache, authentication is still performed using domain credentials, and the way in which authorization with Access Control Lists (ACLs) functions is unchanged. In addition, other configurations continue to function just as they did before BranchCache deployment.
The BranchCache security model is based on the creation of metadata, which takes the form of a series of hashes. These hashes are also called content information.
After content information is created, it is used in BranchCache message exchanges rather than the actual data, and it is exchanged using the supported protocols (HTTP, HTTPS, and SMB).
Cached data is kept encrypted and cannot be accessed by clients that do not have permission to access content from the original source. Clients must be authenticated and authorized by the original content source before they can retrieve content metadata, and must possess content metadata to access the cache in the local office.
Security is central to all aspects of BranchCache. This section describes the security of data in transit (over the wire), and at rest (in the client cache or Hosted Cache).
A client requests data from the content server, and indicates that it is capable of understanding BranchCache.
The content server authenticates and authorizes the client in exactly the same way it would if BranchCache were not being used. That is, authentication and authorization of a client to access data are independent of BranchCache.
The content server recognizes that the client can utilize BranchCache, and checks to make sure that the stored metadata is up to date with the content.
The content server then sends the metadata on the same channel that data normally would have been sent. If an SSL connection were established between the client and the server, then the hashes are sent back over this encrypted SSL connection.
The client that is requesting content obtains the metadata and uses it to look up availability in the branch.
The 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 it wants.
The caching computer encrypts the blocks with an encryption key that is derived from the content metadata (using AES 128 by default) and sends it to the client.
The client decrypts the data by using the same encryption key that the caching computer. The 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.
After the client decrypts the data, it validates that the data is not corrupted or tampered. To do this, the 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 client discards the data.
The data in the cache is accessible. The data is stored in the clear in the Distributed Cache and the Hosted Cache, which is similar to other caches and data on the system (such as the IE cache, the SMB offline files cache, and file system).