## 3 Key Building Blocks
### M2M Security
Read/write access to this container will also be managed by the platform based upon authorization decisions made by the authorization server. The M2M service platform will enforce policy decisions made by the authorization server acting therefore as a Policy Enforcement point. In a first step and ahead of any data exchange, an initial enrolment procedure takes place. The owner of the device registers the device with the service platform and with the authorization server and also defines read/write access rights policies to this device. In this phase the owner of the device typically grants read access to the device to the M2M application. This enrolment phase results in the distribution of long term credentials (typical expressed in months or years) for the device and the M2M application making possible for them to authenticate with the authorization server. When opening a data session the long term credentials are used both by the device and the M2M application to create shorter lifetime credentials used to actually protect data communications during the session time which can typically extend from a few hours to a few weeks. The device, after authenticating with the Authorization server will obtain a digital access token bundling together two distinct credentials:  
* Session encryption keys for private consumption used to cipher/decipher sent/received data( in our scenario, the data sent);
* Signed authorization token for public usage to be presented to the M2M service platform along with a data write request. Figure 16: Achieving End-to-End security for M2M communications. The M2M application, after authenticating with the Authorization server will obtain a similar access token; It will use the Session encryption keys used to cipher/decipher the data sent/received from the device (in our scenario the data received), and will present the authorization token to the M2M service platform in order to gain read access to the container holding the data sent from the device. The flow of operations involved in a typical write/read operation is shown in Figure 17.  
The M2M Application first issues an initial unsuccessful read request to the M2M service platform and is subsequently redirected towards the authorization server to authenticate and obtain an access token. This token will contain the same data ciphering keys as the one delivered to the device. It will also contain an authorization token to present to the M2M service platform in order to gain read access to the device data. It should be noted that the ciphering keys are kept private both by the device and the M2M application. This opens the possibility to achieve end to end data protection between the device and the M2M service platform and to benefit from the data distribution services of the M2M service platform without having the data available in clear at the level of the platform. It may happen however that some of the services offered by the M2M service platform require access to the data in clear. Semantic analysis or context awareness is example of such services. In this case, the platform acting as an M2M application, will be registered as a valid data recipient by the device owner, and will obtain the session keys needed to cipher/decipher the device data. Now, M2M applications often involve the need for one to many communication schemes. For example, the data originating from one device may need to be transmitted to several receiving applications, possibly using a publish/subscribe mechanism. Figure 17: Flow of operations when transferring data from device to application. The security architecture described here is perfectly suited to support this type of communication. The ciphering/deciphering keys distributed by the Authorization server are in fact group keys to be distributed to all parties involved in the communication scheme.