As I posted earlier, my team at Microsoft (Windows Live Core) shipped the Tech Preview of the new online service – Live Mesh. I worked on the Account service that takes care of account management, and user/device authentication and authorization. There were many questions asked by early adopters about how their data is transmitted and stored in Live Mesh, and how access is controlled. In this post I’ll talk about Live Mesh security and authorization architecture, so that you understand its internals and feel better about trusting your data to the Mesh.
Here is the diagram that illustrates all communications between user devices and Live Mesh cloud services and encryption/security mechanisms used in these communication channels:
Live Mesh security is rooted at the authentication provider (Windows Live ID, aka Microsoft Passport, is our provider today) which is used for initial user and device authentication. Once a user or a device is authenticated and a corresponding authentication token is obtained, the Live Mesh client passes this token to the Live Mesh Account service to access the root of the user’s mesh and to get the initial set of Live Mesh tickets. These tickets are used for further Mesh operations on other resources that this root is pointing to. All communications with the Live Mesh cloud services are done via HTTPS / SSL, so 3rd parties cannot intercept and read client-server communication.
All user (or device) related resources in Live Mesh are organized in a RESTful manner, i.e. they form a graph where each node is identified by a unique URL and represents a given resource. Nodes contain resource metadata and links to other resources. Mesh operations are essentially CRUD operations on the nodes of the user tree or nodes of other user trees if those users shared any data. Live Mesh cloud services check access rights in each operation by inspecting passed tickets and authorizing access only if a correct set of tickets is passed. Tickets can be obtained from the Account service or from responses to previous cloud operations.
Live Mesh authorization tickets are standard SAML tickets. They are digitally signed with the Live Mesh private key to prevent spoofing and they expire after a limited lifetime. Some tickets are used to just authenticate users or devices, other tickets contain authorization information about user/device rights. Cloud services inspect each resource request and authorize access only if it contains valid tickets (correctly signed and not expired) and these tickets specify that the requestor indeed has access to the requested resource. For example, a device X can initiate P2P data synchronization with device Y only if it presents a ticket that is correctly signed by Live Mesh and contains a record saying that both device X and Y are claimed by the same user OR if it contains a record saying that X and Y have the same Live Mesh Folder mapped on them (in the case that the devices are claimed by different users that are members of this Live Mesh Folder). Tickets are passed to the cloud services in the Authorization header using HTTPS to prevent replay attacks.
Each device in Live Mesh (computers, PDAs, mobile phones) has a unique private key that is generated during Live Mesh installation and used to authenticate the device in P2P communications with other devices. When a P2P communication is being established between two devices, they first use asymmetric encryption (RSA algorithm) to exchange encryption keys and then use symmetric encryption (AES with 128 bit key) to transfer data/files over TCP/IP. The RSA exchange guards against leaking symmetric encryption keys. AES encryption protects actual data from prying eyes. Live Mesh also uses a keyed message authentication code (HMAC) to verify the integrity of the data exchanged on a P2P channel.
If there is no direct connection between two devices (for example, if one device is behind a firewall), then the cloud communication relay located in the Microsoft data center is used to forward data packets from one device to another. All the traffic is encrypted in the same way as in the case with direct P2P link, i.e. first keys are exchanged with RSA and then traffic is encrypted with AES. The cloud relay cannot decrypt/read user data, since encryption keys are exchanged with the use of asymmetric encryption (RSA).
Live Mesh cloud services help devices find each other and establish communications. They cannot read synchronized user data/files relayed through the cloud, except for the case when user files are synchronized with the cloud storage (i.e. Live Desktop). At the moment, the limited Tech Preview of Live Mesh synchronizes your files not only between your devices, but also with your cloud storage (which you can access via Live Desktop) until you reach your storage quota (5GB as of today). So your files and metadata that describes them are stored in the Microsoft datacenter. They are protected by strong access control mechanisms, but the data is not stored in encrypted form. After the storage quota has been reached, all files are synchronized only P2P and not stored in the cloud (only metadata is stored in the datacenter). In the future, Live Mesh will allow users to selectively choose which files or Live Mesh Folders they want to synchronize with the cloud. If you choose to synchronize your data/files between your devices only, Live Mesh will not store your files in the cloud and will only store metadata that lets the service to operate.
UPDATE: Some of Live Mesh services were later integrated into Microsoft’s SkyDrive, but it’s been awhile since I worked there, I am not sure which parts of this article are valid in case of SkyDrive. Read it as a historical post if you wish 🙂