M2M. Machine-to-Machine Intelligence Corporation. M2M Intelligence. Architecture Overview

Transcription

1 M2M Machine-to-Machine Intelligence Corporation M2M Intelligence Architecture Overview M2M Intelligence - Essential platform for the M2M and IoT Economy Architecture Overview Revised styles and edits 6/3/ :00 PM Page 1

2 Table of Contents M2M Intelligence Platform...1 Table of Contents...2 M2M Intelligence Platform Value Proposition...4 M2Mi Intelligence Components...5 Device and Message Models...5 Lockbox Security...5 FlowChains In-Stream Analytics...5 Device Management and Connectivity...5 Architecture Overview...6 Overview...6 The Platform Core...6 The Node...6 Figure 1: Architecture Overview of a typical deployment...7 The Database...7 Application Programming Interface Overview...7 Security...8 Authentication...8 Authorization...8 User based Authorization:...8 Lockbox based Authorization:...9 Data in transit...9 Data at rest...9 Components... Error! Bookmark not defined. Identity Manager...9 Object Store...10 Company...10 Message Model...10 Record...11 Device model...11 Gateway...11 Architecture Overview Revised styles and edits 6/3/ :00 PM Page 2

3 Protocol...12 Channel...12 Device...12 Device Group...14 Node Image...14 Data Store...14 Node...14 FlowChains...15 FlowChain Image...16 Data...17 Management...17 Node Manager...18 Lockbox...18 Overview...18 Model...18 Resource lockbox...18 Lockbox Key...19 Policy...19 Lockbox Componentss...20 Profile Manager...21 Policy Engine...21 Key Manager...21 Architecture Overview Revised styles and edits 6/3/ :00 PM Page 3

4 M2M Intelligence Platform Value Proposition M2M and IoT, connecting devices and machines to the Internet with Intelligence, promise benefits from smarter cities to healthier citizens to autonomous manufacturing. For businesses this means new revenue, new business models, higher efficiencies and new modes of customer engagement. M2Mi simplifies the building and deployment of secure connected business with the M2M Intelligence platform. M2Mi provides the only integrated M2M and IoT platform to globally connect, secure and generate in-stream insight to quickly create value from your connected assets. Thus, new M2M and IoT opportunities are faster to revenue, cheaper to maintain, more transparent and responsive to business conditions. Architecture Overview Revised styles and edits 6/3/ :00 PM Page 4

5 M2Mi Intelligence Components The M2M Intelligence v5.6 platform includes the following components: Device and Message Models Device and Message models are templates for M2M and IoT devices that significantly reduce large scale deployment times. Each Model describes how a device connects to the internet, over which protocols data is transported, and the composition of the produced data. Models are quickly built with the help of automation tools that guide a model development. Share models with other members of your enterprise or extend their accessibility to other enterprises for even faster deployments. Lockbox Security Lockbox Security is a massively scalable and low cost solution for critical infrastructure protection and secure information exchange. It includes patented Lockbox technology with fine-grained and dynamic policies to control conditions for data flow and access. It intelligently understands current M2M and IoT ecosystem context and takes policy-driven actions to control the flow of information. FlowChains In-Stream Analytics FlowChains simplify the collection, manipulation, and distribution of in-stream data. FlowChains automate data handling processes allowing organizations to rapidly develop and deploy value added M2M and IoT solutions. FlowChains are versatile and impose no constraints on the nature of the collected data, operations and formatting, nor on the destination of the distributed data. Device Management and Connectivity Bundles global carrier bandwidth services (over 200+ countries and 250+ partners) with the M2M Intelligence platform and enables management of diverse and geographically distributed devices. Architecture Overview Revised styles and edits 6/3/ :00 PM Page 5

6 Architecture Overview Overview The central element of the M2M Intelligence Platform is the data produced by devices. This data can represent a device s measurement result, connectivity details, or health status. Data alone is meaningless without context. The M2M Intelligence Platform turns collected data into actionable information by placing the data into its context, i.e. answering questions such as what is the data, which device produced it, and what is the environment in which the data was produced? Once a data is acquired by the M2M Intelligence Platform and its context established, it can be securely transformed, analyzed, stored, shared, and forwarded. To achieve this, the M2M Intelligence Platform is divided into seven main architectural constituents: 1. THE IDENTITY MANAGER to manage and authenticate Users 2. THE OBJECT STORE to manage and store the objects of the model 3. THE DATA STORE to manage and store the data collected from devices 4. THE NODE to interact with devices and collect their data 5. THE NODE MANAGER to manage the Node(s) 6. THE LOCKBOX to control resource access based on policies 7. THE DATABASE to store and persist all objects Each constituent can be deployed as an independent application and can communicate with the other constituents over secure HTTP channels (HTTPS). The Platform Core With the exception of the Node and the Database, all constituents of the M2M Intelligence Platform (Object Store, Data Store, Identity Manager, Lockbox and Node Manager) are stateless and are typically bundled together in a single application. This application the Platform Core can be scaled horizontally by running a cluster in the cloud datacenter. The Node The Node on the other hand must run in its own application and can be deployed anywhere on the network. It can run on the edge devices, on a gateway at the edge of the network or in the data center with the other constituents. The Node has a state and embarks most of the intelligence of the M2M Intelligence Platform. Each instance of the Node interacts with its own fleet of devices and receives commands from a Node Manager of the Platform Core. Architecture Overview Revised styles and edits 6/3/ :00 PM Page 6

7 Figure 1: Architecture Overview of a typical deployment The Database In practice, the Database consists of several independent databases storing the objects of the different Platform Cores constituents. For example the IDENTITY MANAGER, the OBJECT STORE, the DATA STORE and the LOCKBOX all have their own databases for which only they have access. The Lockbox database stores security related objects such as cryptographic keys and will preferably be implemented by a storage system with high security capabilities such as a Hardware Security Module. Application Programming Interface Overview Users interact with the M2M Intelligence Platform through a secure REST API, and every interaction with the Platform must be done through the API. The Identity Manager, Object Store, Data Store, Node and Lockbox and all expose a set of REST web services whose input and output are expressed in JSON. Each architectural constituent has its own set of independent and User-friendly URL. Only valid Users can interact with the M2M Intelligence Platform and every call to the API is authenticated via HTTP Basic Authentication and authorized based on the User s identity and role. In addition, the API must be accessed over secure HTTP channels (HTTPS). Architecture Overview Revised styles and edits 6/3/ :00 PM Page 7

8 When a User operation requires one architectural constituent to interact with another one in the name of the User, the credentials of the calling User are propagated to ensure that authentication and authorization are propagated across the entire operation. Security Authentication Every operation on the M2M Intelligence Platform must be authenticated. This is true regardless of if the caller of the operation is a User or another component of the Platform acting on behalf of a User. To interact with the M2M Intelligence Platform a User must provide a valid pair of credentials consisting of an address together with a password. In practice, every call to the API is first intercepted and passed to the Identity Manager for authentication. If the credentials are valid, the Identity Manager forwards the request to the targeted API together with the caller s information (company, role, etc). Authorization Every operation on the M2M Intelligence Platform must be authorized. As with authentication, this is true regardless of whether the caller of the operation is a User or another component of the Platform acting on behalf of a User. The M2M Intelligence Platform implements two forms of authorization: User based Authorization: For most interactions with the Platform, authorization is granted based on the permissions of the calling User and the ownership of the targeted resource. Permission is evaluated based on the role of the User while ownership depends on the properties of the targeted object. Every managed object on the Platform has an owner, the User who created it, and a flag indicating if it can be shared. For example, to delete a managed object (MO) in the Object Store such as a Device, the User must: 1) Have a sufficiently high role to delete MO s and 2) Have access to the targeted MO; either the MO is public, the User owns it or it is owned by someone from the User s company. The Platform currently accepts 4 User roles. With decreasing order of permissions they are: 1. Infrastructure Admin 2. Infrastructure Operator 3. Customer Admin 4. Customer Operator Architecture Overview Revised styles and edits 6/3/ :00 PM Page 8

9 Lockbox based Authorization: For operations related to sensitive information such as collecting data from devices, storing device data or accessing device data through the Data Store API, the M2M Intelligence Platform grants authorization using the proprietary Lockbox technology. The Lockbox uses whitelisting combined with the dynamic context of the requesting entity and its surrounding ecosystem to determine if, and under which constraints, access to a resource may be granted. The Lockbox is further described below in the Lockbox Componentss section. Data in transit All communications to and within the M2M Intelligence Platform are secured by SSL. This includes authentication through X.509 certificates, privacy of the transmitted data through encryption and integrity of the transmitted data through secure hashing. We note that the Platform uses one-way authentication SSL so it does not require a requesting User to provide a valid certificate. Data at rest The M2M Intelligence Platform stores all data the objects of the model as well as the data produced by devices - in the Database. The Platform is agnostic of the underlying database technology and the security of the Platform does not rely on the security of the chosen database implementation. This guarantees that the Platform remains independent and is not locked to a specific database technology or vendor. In particular, to secure data at rest it is not assumed that the entire database is encrypted, i.e. that encryption is performed at the database level. Instead, sensitive data is encrypted at the application level by the Object Store or the Data Store before it is sent to the database for storage. Objects on the Platform are represented and stored in JSON. A JSON string is a collection of attributevalue pairs hence the Platform encrypts an object by encrypting selected value fields of its JSON representation. This makes it possible to secure the data while not affecting the performances of the database operations such as querying, filtering etc. Architectural Constituents Identity Manager The Identity Manager is responsible for the management of Users across the M2M Intelligence Platform, as well as the authentication of User credentials. While the Identity Manager can be connected to a third-party application and leverage an existing infrastructure, it is typically connected to the database where the User objects are stored. A User represents an entity that interacts with the Platform. A User object contains several attributes such as: Architecture Overview Revised styles and edits 6/3/ :00 PM Page 9

10 A unique identifier (id) across the entire Platform A first name and last name An used for authentication A secret password A company A role User passwords are stored encrypted in the database. Upon creation of a new User the Identity Manager generates a unique random String of 32 bytes (salt). The password and the salt are hashed using AES-256, and both the hash and the salt are stored in the database. Object Store The M2M Intelligence Platform is supported by a set of managed objects (MOs) characterizing the underlying architecture model. MOs are managed by the Object Store and securely stored in the database. The managed objects can only be accessed and manipulated (Create, Read, Update, Delete) by Users through the REST API of the Object Store. All MOs share a common set of attributes such as: A unique identifier (id) across the entire Platform A User friendly name A short description An owner or creator A flag indicating if the MO is public Some metadata such as the time of creation Company Users are grouped into Companies. Every User of the Platform must be associated to a single Company. A User may have access to all the MOs created by the other Users of its company. Message Model A message model or data template - describes how a raw data generated by a device is structured and must be interpreted. It contains information about the format of the data (JSON, XML, CVS) and the information that the content of the data represents, for example, temperature measurement, battery level, connectivity status, etc. Architecture Overview Revised styles and edits 6/3/ :00 PM Page 10

11 When the profile of a raw data is known, the data can be safely manipulated and processed by the Platform. Record The different pieces of information contained in a data are called a Record. A single data can have multiple Records to represent the various pieces of information the device produces and/or measures hence a Message Model can contain multiple Records. For example, a sensor could measure temperature, pressure and humidity and publish that information in a single JSON string. The profile of the resulting sensor s data would be made of 3 Records; a temperature Record, a pressure Record and a humidity Record. A Record object contains 3 parameters: 1. THE IDENTIFIER of the record in the data 2. THE TYPE of the record 3. THE UNIT in which the record is expressed The available values for type are fixed and include TEMPERATURE, PRESSURE, HUMIDITY, SPEED, POWER, etc. Each type has an associated list of accepted unit values. For example, a Record of type temperature can only have a unit value of KELVIN, CELCIUS or FAHRENHEIT. When possible, a Unit enumeration contains information on how to convert a value to and from a reference unit. This enables the Platform to automatically convert a data between message models and apply intelligence coherently to a collection of data representing the same quantities but expressed in different units. Device model A device model or device template - contains all the characteristics of a device. It describes how the device connects to the network, what kind of data the device produces, and what protocols the device uses to communicate. A group of devices of the same brand and model will thus share the same device model. A device model is made of several objects that we list here. Gateway A Gateway object represents how a device connects to the network. We consider 5 types of gateways on the Platform corresponding to the 5 accepted values for the Gateway Enumeration: ETHERNET: The device can access the network via a built-in Ethernet port. WIFI: The device can access the network via a Wi-Fi connection. SIM: The device can access the network via a cellular connection. Architecture Overview Revised styles and edits 6/3/ :00 PM Page 11

12 DEVICE: The device can access the network using another device acting has a gateway. SATTELITE: The device can access the network via a satellite link connection. Each Gateway has an associated list of configuration parameters that must be provided to the Platform when provisioning a device that contains it. For example, if a device has a cellular connection then the Platform needs to know the carrier and the IMSI of the device SIM to be able to leverage the partnerships M2Mi has with network operators such as Vodafone. A device can have more than one gateway. Protocol A Protocol object represents a (layer 7) protocol used by a device to send and receive data over the network. It also indicates how the Platform can access the data produced by the device. Currently the protocols accepted by the M2M Intelligence Platform are MQTT and HTTP. Each Protocol has an associated list of configuration parameters that must be provided to the Platform when provisioning a device that contains it. For example, if a device communicates over MQTT then the Platform needs to know the broker URI and the topics on which the device publishes data in order to collect the data properly. Channel A single device may have the ability to send and receive different types of data using different protocols. The M2M Intelligence Platform represents these different communications endpoints through the concept of channels. A Channel object represents a single communication channel allowing for the exchange of data between the device and the Platform. It contains information about the message profile exchanged over the channel, the protocol used in the communication, and the direction in which data is flowing. A channel over which data is collected from the device is said to be of type OUTPUT, while a channel over which data is sent to the device is of type INPUT. An input channel corresponds to commands sent to the device. A Device can have multiple Channels. Device The central object of the platform is the device. A Device represents a physical thing somewhere on the network that can produce data and/or receive commands. A Device object contains all the configuration parameters that make the physical device uniquely identifiable and different from other devices of the same brand and model, e.g. its IP address, its IMSI number, or the MQTT broker where it publishes data. To onboard a new physical device to the M2M Intelligence Platform, a User must create a new Device object based on an existing device model. If a device model does not exist, it must be created. The Platform uses the selected device model to determine what information is needed and must be Architecture Overview Revised styles and edits 6/3/ :00 PM Page 12

13 provided by the User to provision the device properly. Once the device object is configured properly the Platform can start collecting data and/or send commands to the corresponding physical device. We consider two types of devices on the platform: END-DEVICES and GATEWAYS. End-devices represent devices at the edge of the network that produce data, while gateways are devices used by end-devices to access the network. The type of a device is defined in its associated device model. The representation of a device object in the database is displayed on Fig. 2. Figure 2. JSON representation of a Device Managed Object. Architecture Overview Revised styles and edits 6/3/ :00 PM Page 13

14 Device Group A Device Group object represents a group of devices. Devices can be grouped for many different reasons such as ownership, functionalities, or location. Grouping devices in a Device Group facilitates their management. A Device Group does not contain any reference to the devices that belong to the group, rather, it is the devices that contain references to the groups to which they belong. Node Image A Node Image object represents a physical Node application running somewhere in the network. It is mostly used for management and only accessible to the administrators of the infrastructure. Data Store The Data Store manages the storage and retrieval of device data. It does not enforce a particular schema and stores the data in the database as a set of key/value pairs. The Data Store is protected by the Lockbox. Every call to the Data Store API is first transmitted to the Lockbox for authorization. In practice, the User calling the API must provide a lockbox authorization token with its request. Lockbox authorization tokens must be obtained from the Lockbox and allow a specific operation on a target resource for a limited period of time and under specific security and/or monitoring constraints. Upon receipt of an authorization token, the Data Store can verify its validity with the Lockbox and apply the appropriate constraints such as encrypting or decrypting the target data set. Node The Node is a distributed architectural constituents that connects a device or a network of devices to the core of the M2M Intelligence Platform located in the cloud datacenter. The Node is the remote arm of the Platform and it can be deployed anywhere in the network: on an individual edge device, on a gateway at the edge of the network or in the data center together with the Platform core. The Node is a flexible architectural constituent by nature, and it can take on different roles depending on the use case and the associated architecture. Some of the main functions/roles of the Node include: DATA COLLECTION: The node collects data from devices and is the point of entry to the M2M Intelligence Platform. DATA ROUTING: The Node can collect and route data from a network of devices to e.g. the cloud datacenter or another network of devices. DATA ANALYSIS: The Node can analyze the collected data and act according to some pre-defined business logic. Architecture Overview Revised styles and edits 6/3/ :00 PM Page 14

15 CONTEXT SCANNING: The Node can scan the environment of edge devices, establish their context and leverage that information with the Lockbox. SECURITY: The Node interacts with the Lockbox to ensure end-to-end authorization and security from the collection of a data to its storage in the cloud datacenter. FLOW CONTROL: The Node can interact with the devices of a local network and control their flow. The spectrum of IoT and M2M applications as well as the range of existing connected devices is very broad and rapidly evolving. As a consequence, the M2M Intelligence Platform must have the ability to adapt rapidly to new use cases and ecosystems. The Node is the architectural constituent of the Platform that provides this versatility. Versatility is achieved through modularity and the concept of FlowChains. FlowChains The Node is the architectural constituent of the Platform that implements most of the Platform s intelligence by leveraging the concept of FlowChains. A FlowChain is a logical sequence of operations on a data. It starts with the collection of raw data from a device and completes with the forwarding of the processed data to e.g. the Data Store for storage. Between the collection and the forwarding of the data, the data can be manipulated and formatted in many different ways by constructing the desired sequence of operations. FlowChains are created and run by the Node. Users connect their devices to the Platform by creating FlowChains. FlowChains are created through the API of the Node, and a single FlowChain can connect many devices that may or may not have the same device models. In practice, a FlowChain is constructed as a sequence of unit operations called Data Handlers. Each Data Handler is designed to perform a specific operation on a data or its environment then pass the processed data and its associated information to the next Data Handler of the Flow. Existing data handlers include Collectors, Filters, Converters, Authorizers, Aggregator/Aggregators, Distributors/Splitters, Reporters and Forwarders. By default, every FlowChain is composed of at least 3 data handlers: 1. AN AGGREGATOR to aggregate the data collected from devices of different device models. By leveraging multiple Converters and an Aggregator, a single FlowChain can aggregate data of multiple devices producing data of different models and apply a single business rule to all the collected data. 2. A SECURE DISTRIBUTOR to forward the processed data to one or more endpoint. By leveraging a Distributor and multiple Forwarders it is possible to route the processed data to different endpoints based on some business conditions. Architecture Overview Revised styles and edits 6/3/ :00 PM Page 15

16 3. A FLOW MONITOR to report some basic information about the FlowChain to the Platform core for auditing and billing purpose. To make a FlowChain operational, a User must add to these default handlers at least one of the following two: 1. A COLLECTOR to collect data from a single device or a group of devices sharing the same device model. 2. A FORWARDER to send the collected data to an endpoint such as an application or the Data Store. Figure 3. Representation of a basic FlowChain collecting data from devices with 2 different profiles. All collected data is sent to the Data Store for storage and, depending on some predefined conditions, some data are routed to a remote MQTT broker. The Node is an integral constituent of the lockbox architecture and integrates to the Lockbox through the Secure Distributor of a FlowChain. Every data processed by a Secure Distributor must be authorized by the Lockbox to go from its collection point, e.g. the device, to its destination, e.g. the cloud datacenter. This authorization may be performed remotely by sending a request to the Lockbox in the Platform core, or locally by enforcing the appropriate policies in the Node. FlowChain Image When a User creates a new FlowChain through the Node API, the M2M Intelligence Platform creates an associated manage object (MO) that is used for management and persistence. The FlowChain Image object is created via the Object Store and stored in the database. It contains information about the status of the FlowChain, the Node on which it is running, or the devices from which the FlowChains collects data. Architecture Overview Revised styles and edits 6/3/ :00 PM Page 16

17 Data FlowChains collect and manipulate device data. The Data object flowing through a FlowChain is an abstraction of the real data, the string of bytes collected from the device. This abstraction must be selfconsistent and allow for each operation or data handler - of the FlowChain to perform its operation without the need for external information. The abstracted Data object contains the following information: The raw data has it was collected The identified message profile A normalized representation of the data An identifier of the device who produced the data An identifier of the FlowChain processing the data A context associated to the data Some metadata containing e.g. a lockbox authorization token The information contained in a Data object is generally computed and updated as it flows through the FlowChain. For example, when a Collector collects a data from a device it uses the known message model to parse the raw data and create a normalized representation of the data as a set of key/value pairs. The next handlers of the flow can then easily update the normalized data, populate the context or add metadata attributes to the Data object. Management In contrary to the other architectural constituents of the Platform, the Node has a state defined by the FlowChains that it is running. This state must be persisted when the Node is shut down and restarted. This is important when the Node is running on a device that may be switched on and off during its natural course of life, but also when it is running on an application server somewhere in the network that may be switched off for e.g. maintenance. Finally, when the Node is deployed in clusters it might be desirable to have a mechanism to transfer the state i.e. the FlowChains from one Node to another. To achieve this goal, the Node API offers services to start and stop a Node, save the state of a Node or load a saved state to a running Node. The state of a Node is automatically saved when the Node is stopped. Persistence of the state of the Nodes, i.e. the FlowChains, is both centralized and distributed, via the Node Image managed object, and locally via Architecture Overview Revised styles and edits 6/3/ :00 PM Page 17

18 In practice, the state of a Node is saved and restored using a local file. Since the Node may interact with the other architectural constituents of the Platform on behalf of a User, its state or the FlowChains that it is running may contain sensitive information such as User credentials. To protect this information the file on which the state of a Node is saved must be encrypted. This encryption is implemented as follows: 1. Upon starting or saving the state of a Node, the User provides a secret key 2. This secret key is hashed using SHA1 and the first 16 bytes of the hash are kept 3. The 16 bytes long hash is used to encrypt the state of the Node with AES. Restoring the state of a Node, or initializing a Node from a known state, works similarly and the User must provide the secret key that was used to encrypt the state. Node Manager The Node Manager is responsible for managing the Node instances deployed in the network. It can locate and forward a FlowChain configuration requests (create a new data flow, add devices to an existing data flow, etc) to the appropriate Node. It makes the Node scalable and enables the seamless integration of a User Interface (UI) to the M2M Intelligence Platform. Lockbox Overview The Lockbox is the central constituent of the Lockbox architecture. It is a complete and independent product that may be used in various contexts. In the context of the M2M Intelligence Platform, the main mission of the Lockbox is to ensure trust and security for the data generated by devices across their entire life within the Platform; i.e. from collection to processing to storage and/or distribution to application and third parties. The Lockbox can be used as a secure data broker mechanism enabling a User to securely share the data of its devices with partner companies. Model The model underlying the Lockbox relies on the following objects: Resource lockbox A Resource Lockbox represents a resource that is protected by the Lockbox. Every resource controlled by the Lockbox must have an associated Lockbox Resource object. It contains information about the resource itself (owner, location, parent resources, etc) as well as the security configuration that must be applied to secure the access to the resource. The main security parameters of a Resource Lockbox are: Architecture Overview Revised styles and edits 6/3/ :00 PM Page 18

19 A 512 bit long cryptographic key to encrypt and decrypt the resource, The list of Lockbox Keys that give access to the resource. By default, every device on the M2M Intelligence Platform has an associated Resource Lockbox securing access to its stored data through integration of the Lockbox with the Data Store. Lockbox Key The Lockbox key is at the center of the data broker capability of the M2M Intelligence Platform. It makes the connection between Users, resources and policies. A Lockbox key gives its bearer access to a resource provided that the bearer satisfies a set of constraints. These constraints are defined by the policies associated to the Lockbox key. To access a resource secured by the Lockbox, a User has to present a valid Lockbox key, i.e. one that gives access to the resource. Before authorizing the request, the Lockbox will establish and analyze the context surrounding the request based on the policies associated to the matching Lockbox key. If one (or more) policy is satisfied, access is granted and the Lockbox may establish a secure connection between the key holder and the resource. While a Lockbox key has an owner the owner of the resource and creator of the key it can be shared and therefore used by any entity in possession of valid credentials such as Users, devices and applications. By sharing a Lockbox key with members of a partner company, the owner gives access to the associated resource, the limits of how the resource can be accessed is prescribed by the shared Lockbox key s policies. Policy A policy defines under which constraints a set of actions can take place. A policy defines a general set of conditions and is not attached to a particular Lockbox key. It can be used by many Lockbox keys thereby limiting the number of policies in use in the M2M Intelligence Platform. A policy object is composed of the following: A source to define from which IP or location a resource can be accessed, A set of actions to determine the accepted operations on the resource, A set of conditions describing the context under which the resource may be accessed, An (optional) set of configurations that must be applied to secure the access, A security level that determines the cryptographic suite to use to secure the resource. Architecture Overview Revised styles and edits 6/3/ :00 PM Page 19

20 Figure 4: Two different Users accessing the same shared resource under different constraints. Lockbox Components The Lockbox is made of 3 main components: 1. The Profile Manager 2. The Policy Engine 3. The Key Manager It must be completed by a set of additional components located on the same network. Depending on the specific Lockbox deployment, part or all of these components must be made available to the Lockbox. The main additional components include: An Identity Manager A Policy Manager A Key Generator A Secure Storage system A PKI Certificate Authority Architecture Overview Revised styles and edits 6/3/ :00 PM Page 20

21 A Single Sign-On platform Profile Manager The Profile Manager handles all incoming requests to the Lockbox. The requests are made through the Lockbox API. The main mission of the Profile Manager is to ensure that a received request is complete and valid, load the request specific information from other constituents of the architecture, and then dispatch all gathered information to the Policy Engine for authorization. For example, the Profile Manager may interact with the Object Store to obtain the profile of the requesting device, interact with the Key Manager to get the details of the Resource Lockbox and Lockbox Keys associated to the request, and with the Policy Manager to load the relevant polices. Once the Policy Engine has authorized access to a resource, the Profile Manager requests an authorization token from the Key Manager and sends it to the requestor. This authorization token can then be used by the requestor to access the resource and e.g. get device data from the Data Store. Policy Engine The Policy Engine is the central component of the Lockbox. Its mission is to decide if a requestor (User, device, application) is authorized to access a protected resource. Decisions are made based on the established context surrounding the request and the set of policies describing under which conditions the protected resource can be accessed by the requestor. If required by the enforced policies, the Policy Engine may provide a network orchestration engine with new network configuration instructions and have it establish a secure connection between the requestor and the accessed resource. Note: The Policy Engine can be made to run on the remote Node and enforce policies locally without the help of the Lockbox located in the cloud datacenter. Key Manager The main function of the Key Manager is to manage the security related objects of the Lockbox architecture such as the Lockbox keys and Resource Lockbox. In particular, the Key Manager is responsible for the creation, edition, storage and deletion of these two objects. The Key Manager must be connected to a secure storage system to store the sensitive Lockbox keys and Resource Lockbox as well as to a Key Generator for the generation of cryptographically secure key material (Lockbox key values, authorization token, RSA key pairs for the PKI, etc.). The Key Manager is also responsible for managing all cryptography related components of the architecture (PKI, SSO, etc.) and thus connects to any security/cryptography component that is part of the architecture such as the CA of a PKI, a SSO platform, etc. Architecture Overview Revised styles and edits 6/3/ :00 PM Page 21

22 Founded 2006 at NASA Research Park Trusted production solutions Fortune 500 customers Installed on thousands of network and compute cloud data center assets Intellectual property and trademarks Personal portal and secure information exchange. Patent US granted Global Trademark M2M Intelligence Industry leadership Founding member of OASIS MQTT Machine-to-Machine Intelligence (M2Mi) Corporation NASA Research Park Building 19, Suite 2063 Moffett Field, CA USA General Enquiries: 1-(650) phone 1-(650) fax Member of Smart Grid Interoperability Panel and Open Data Center Alliance Architecture Overview Revised styles and edits 6/3/ :00 PM Page 22

23 Architecture Overview Revised styles and edits 6/3/ :00 PM Page 23