## 3 Key Building Blocks
### M2M Security  
The M2M service platform may be privately owned for operation in a closed ecosystem, but it may also be operated by a third party business entity: the \"M2M service provider\". Security in such a platform is quite an important issue and typically encompasses two phases: In the first initial secrets are exchanged during an enrolment (or security bootstrap) operation between parties needing to communicate privately. In the second phase, those secrets are actually used to control resource access and secure data communications. In the case of the ETSI M2M platform those two aspects are being considered and the ETSI M2M security framework addresses the definition of M2M service bootstrap and M2M service connection procedures. It supports mutual authentication, integrity protection, and confidentiality on M2M Device  
Figure 14: Central device connects to a sensor and discovers an embedded Internet services that was not advertised. The 6 LBR may accept connections from many 6 LNs. Figure 13: The topology of Bluetooth LE Pico net with roles. or M2M Gateway-to-Network Interface. Several security bootstrapping methods are supported by the specification, including PKI based methods and techniques relying on the presence of 3 GPP network elements typically deployed by Mobile network operators (MNO) such as GBA and SIM/AKA. However little support is provided for security bootstrap when using small and constrained M2M objects such as sensors. The security model currently proposed by ETSI M2M architecture is a piecewise security model: The data sent between a source device and a recipient application via the M2M service platform are protected from the device to the M2M platform and from the M2M service platform to the destination using different credentials controlled by the M2M service provider as shown on Figure 15. As a consequence, the data are always available in clear at the level of the M2M service platform. This may be a problem when the platform is operated by an M2M service provider which is not involved in dealing with the semantics of the data transmitted. For example, an M2M service provider may carry data originating from health body sensors and simply route this data to the processing center for interpretation. Trust may then be the issue for this type of confidential data. If the platform is privately operated, then having the data available in clear at the level of the platform may require putting in place security measures to minimize the risk of data compromising, thus increasing the operating cost. In both cases, an end-to-end data protection scheme would constitute a better solution. Our security contribution is related to the definition of security architecture suitable to achieve end to end data protection and compatible with the ETSI M2M platform architecture. The main concept of the novel architecture is to unbundle the functionality offered by the service platform and separate from it the trust related functions which will be implemented into a separate platform built around an Oauth authorization server, Figure 16.  
The architecture shown on Figure 16 involves 4 actors:  
* The device, exposed here as the \"resource\" is assumed in this discussion to act as a data generator, _i.e._, a sensor);
* The M2M application requiring access to the data sent by the device. The M2M application will act as a \"resource consumer\";
* The M2M service platform enabling the application to read data sent by the device, acts as a \"resource provider\";  
Figure 15: ETSI M2M Trust model. The authorization server implementing the Oauth authorization protocol holds the data access right policies for the device and implements the decision process based upon those policies. The authorization server is a Policy decision point. Sending data from the device to the M2M application via the service platform will be achieved via the use of a data container located in the platform.