2.1 Physical limitations of smart objects

Although smart, the devices considered here are still objects, i.e., physical entities with a clear function, unlike general-purpose computers such as laptops or smartphones. Their capabilities and user interfaces therefore are specifically tailored to their particular purpose, resulting in low cost and potentially small physical dimensions. To cover the needs of a specific user, a large number of smart objects may need to be deployed, leading to severe constraints on the cost of each one of them.

Tight cost constraints cause manufacturers of smart objects to restrict the hardware components on a device to the bare minimum that is needed to fulfill the desired functionality. These so-called constrained devices have significantly less processing power and storage than a common smartphone or modern notebook computer, and often lack a full-fledged user interface. While the limited processor speed just slows down program execution, the restricted memory sizes seriously affect the system design. For example, a basic Texas Instruments CC2538 chip is equipped with 128 KiB flash memory and 16 KiB RAM (Texas Instruments, Inc., 2013; this chip is one of the more modern ones available for Internet-connected smart objects). A simple UDP-based example application¹ built for this platform requires around 13,600 bytes of RAM, leaving less than 2800 bytes for security-related data. The security library tinydtls² needs around 1900 bytes in its smallest reasonable configuration for Contiki, not including any keying material. As the library requires another 750 bytes buffer space when public key cryptography using elliptic curves is enabled only 150 bytes—roughly the equivalent of two public keys—RAM are left.

Energy may be a limiting factor as well, especially when the device is powered from a primary battery, limiting the average power available over, say, a two-year battery lifetime to the order of hundreds of microwatts. Margi et al. (2010) show for a common embedded development board with an MSP430 microcontroller and a CC2420 radio transceiver that the transmission of a 12 byte block over a wireless interface costs more than 10 times the energy of encrypting it. This makes network operations one of the most energy-consuming tasks for smart objects besides calculations and powering dynamic memory. Power can also be saved by slowing down the system clock rate, and taking parts or the entire device into sleep mode for most of the time. Both methods lead to increased communication latency and thus reaction times.

The latter must be taken into consideration specifically for network protocols as it affects the time required for state convergence, i.e., the delay until all communication partners have received all the data needed. For security, this is particularly challenging as the receiver of a message must be able to tell whether or not it is fresh to prevent replay of intercepted messages. A common notion of elapsed time hence is crucial for the communicating parties but not all embedded devices are equipped with a sufficiently accurate battery-buffered real-time clock. In this case, sender and receiver must be able to synchronize their clocks over the network.

Besides these constraints on system resources, smart objects often have limited means of direct interaction with human users. Their user interfaces usually differ significantly from the displays and (virtual) keyboards or pointing devices we are familiar with from our mobile phones or laptop computers. For instance, a temperature sensor might have not more than a small LED light to indicate its operational status. The number of states that can be visualized in this way are very limited: on/off to indicate whether or not the device is active, and possibly flashing to signal that it is trying to establish a network connection. Actuators such as light switches or electronic locks may be restricted to a simple button to toggle their state, sometimes without any state indicator on the device itself.

2.2 Security objectives

An essential mechanism for enabling users to keep control over their data is authorization. This term refers to the process of giving permissions to an entity, such as a person, a device, or a piece of software. Authorization mechanisms enable users to decide who is authorized to access their data/devices, and how (e.g., read it, change it). For enforcing the authorization, it must be possible to distinguish authorized from unauthorized users. This is achieved by using an authentication mechanism.

Authentication is the process of validating that an entity actually has certain attributes it claims to have. In the physical world, examples for an attribute of a person are her name, her age, or her membership in an organization. Authentication attributes may be suitable to uniquely identify an individual entity, but this is not necessarily the case. To be authorized to buy a beer one only needs to be of age, an attribute shared with many other people. Users opening a bank account need to be uniquely identifiable as they are held responsible for it.

Authentication and authorization are closely related. The authorization mechanism must use the attributes provided by the authentication mechanism to determine whether a person is authorized: The authorization information that needs to be applied must be obtainable making use of the authentication attributes. We use the term Authenticated Authorization to refer to a synthesis of mechanisms for authentication and authorization. If one of the mechanisms or the interaction between them fails, the security they aim to provide is no longer assured.

Authenticated authorization is needed to achieve multiple security objectives. Security objectives specify how data need to be protected. The importance of a security objective depends on the use case where the mechanism is applied.

To illustrate the security objectives, we introduce the following use case: John has developed insulin-dependent diabetes and therefore has to check periodically the amount of blood glucose and administer a related charge of insulin whenever the glucose concentration exceeds a certain level. The insulin pump used for this can be placed on John’s body and controlled electronically. (Those devices are quite common today, cf. Zisser, 2010; Horsley, 2011.)

John’s latest acquisition is an automated blood glucose meter that can act autonomously and communicate its measurements to the insulin pump to relieve the device owner from manual checking of the sugar level, calculation of the correct insulin dose, and triggering the actual injection.³ Both devices use wireless communication to avoid cables hanging around the user’s body and to eliminate feedback loops between the glucose meter and the insulin injection.

Moreover, John wants to be able to monitor his health status and possibly change the device configuration from his smartphone or laptop computer whenever he likes to, and grant a medical practitioner access to his devices during consultation. Changing pricks and injection needles should be as easy as possible. For current systems where the sensor pads and infusion pumps are replaced, removal of old devices from John’s personal network, and integration of the exchange units should work without complex manual reconfiguration.

This scenario opens up a full range of important security-related questions as John not only wants his insulin-level to be properly controlled but also keep sensitive information hidden from others.

Measurements and control data should be kept confidential. For example, the blood sugar values must be accessible only by entities that John has authorized, such as his insulin pump, monitoring applications, and possibly John’s physician.

The data that is interchanged between the devices also must be integrity protected, i.e., they can only be manipulated by authorized entities. The autonomic insulin pump needs to make sure that the blood sugar values it uses to determine the amount of needed insulin stem from an authorized source, e.g., from John’s blood sugar measurement device or a replacement device that is used instead.

In some cases, it is important that the entity which is responsible for an action can be identified. The respective security objective is called accountability. If it is also necessary to prove this to a third party, non-repudiation is needed. For example, if the insulin pump is underdosing the insulin resulting in medical problems for John, it might be necessary to find out (and prove) who is responsible for this. Accountability and non-repudiation require the authentication mechanism to uniquely identify an entity.

Another security objective that needs to be considered is availability: Authorized entities must not be kept from accessing data. For example, the insulin pump must be able to access the measured values of the blood sugar measurement device to determine the amount of needed insulin. Thus, the availability of this data must be ensured.

2.3 Authentication-related tasks

To meet the security objectives, various tasks must be performed by different actors. As an example for authentication in the physical world, imagine buying an alcoholic drink: Here, the law mandates the seller to ask the customer to prove that she has the required age. The customer hence presents her identity card to the seller who needs to check the listed birth date and if the photo on the card matches the person in front of him. Moreover, it is in the responsibility of the seller to verify that the shown document is a proper identity card issued by the government.

This brief example illustrates the three important properties that an authentication token such as the identity card or an entrance ticket must provide:

1. The attribute(s) needed for the authentication purpose: This could be the age as in the previous example, or just the fact that a guest holds an entrance ticket. The only requirement on the attribute set is that it has to be meaningful for the purpose of the authentication and that the issuing party and the party that uses the authentication token for authentication have some common understanding of the meaning of the token. If the authentication is conducted for authorization, the attributes are required to determine the respective permissions.

2. A verifier: This is something to make the attributes attachable to the bearer such as the photo that is printed on the identity card.

3. An endorsement: The evidence that the issuer of the authentication token has validated the attributes listed therein and that the attached verifier is correct. For example, an identity card might have a stamp or holographical picture as endorsement. The essential feature is that only the government agency that has issued the card can generate this stamp or holography.

With this terminology, the steps performed by the seller and customer can be generalized as the following authentication-related tasks:

(1) Attribute binding: The attribute intended to be verifiable must be bound to a verifier, e.g., a cryptographic credential. To achieve this, an attribute binding authority checks if an entity actually has the attributes it claims to have and then binds it to a verifier. The authority must provide some kind of endorsement information which enables other entities to validate the binding.

(2) Verifier validation: The entity that wants to authenticate an entity checks the attribute-verifier-binding using the endorsement of the attribute binding authority.

(3) Authentication: The verifier is used for authenticating an entity or the source of a data item.

2.4 Authorization-related tasks

The process of not selling alcoholic drinks to minors is the implementation of a specific policy. The government has set this policy as well as the rules to enforce it: A customer is authorized to buy a beer if she has a certain age. Sellers must therefore validate the customer’s age by inspecting the identity card and make sure that the card holder is the same person that is about to buy the drink.

The latter is the aspect of authentication that has been discussed in Section 2.3. Defining and enforcing the policy requires the following authorization-related tasks:

(4) Configuration of authorization information: The authorization authority must configure the information that governs authorization. This can be achieved by uploading the access rules defined by the owner of a device to an authorization server in a network. For the liquor store example, configuration of authorization information is the enactment and publication of the law that prohibits selling alcohol to people below a certain age.

(5) Obtaining authorization information: Authorization information must be made available to the entity which enforces the authorization. A device may need to retrieve authorization information from the authorization server before it can validate incoming requests. Shop owners must keep track of legislation activities that may effect their business, and instruct their employees to enforce applicable laws.

(6) Authorization validation: The authorization of an entity with certain attributes must be checked by mapping the attributes (which must be validated by authentication) to the authorization information.

(7) Authorization enforcement: According to the result of the authorization validation the access to a resource is granted or denied.

2.5 Implications of device constraints for authenticated authorization

In our medical device use case, some of the tasks for authentication and authorization must be fulfilled by the constrained devices, i.e., the blood glucose meter and the insulin pump. One of the most obvious limitations is the basic user interface exposed by these devices: For instance, the glucose meter might have only a power button and a status LED.

For complex interactions between a human and the device, more powerful user interfaces are necessary. In previous decades, this was accomplished using a wired point-to-point connection between a computer and the device’s serial port or USB interface. Security in this case was achieved by physically restricting the access to the device or at least the respective socket. For smart objects, this is different by design as they use Internet protocols and thus communicate over a—potentially public—data network where it may traverse several insecure network segments, especially when transmitting data over the air through wireless links.

When applied properly, cryptography can be used to secure the communication of smart objects. Because of the devices’ constraints, care must be taken which cryptographic primitives are actually used. Otherwise, the overhead from employing security measures might outweigh the gains from using smart objects.

For constrained devices, the selection of a viable security mechanism needs to consider power consumption, code size, and memory footprint. All three have in common that resources must be set aside that will no longer be available for the actual application.

Memory constraints make it difficult to store the authentication keys of all potential communication partners on a device. Instead, the device must obtain the keying material on demand. Although this could in theory be done using public key cryptography and certificates that bind the public keys to certain attributes, the need to parse large data structures and to store root certificates locally to enable validation of entire certificate chains makes this approach less viable in practice.

In addition to the scarce memory for storing large numbers of keys or root certificates, more energy is consumed by a node when additional messages for certificate validation have to be transmitted. The code size will increase due to the need to parse complex data structures. Depending on the capabilities of the device, the energy expended in such a validation may be significant.

As an alternative to public key cryptography, mechanisms using symmetric keys offer an option for scalable lightweight security. While public key cryptography works with pairs of asymmetric keys where one part can (and must) be disclosed, a symmetric key represents a secret that is shared only between communication parties. The immediate benefit of using symmetric keys is the smaller code size for cryptographic operations, less memory required for key storage, and smaller messages. However, as symmetric keys are shared between the communicating peers, care must be taken to avoid disclosure to non-authorized parties.

When applied to the diabetes use case, these observations imply that only the glucose meter and the insulin pump should know the key that is used to secure their communication. As their user interfaces are too restricted to enter a shared secret manually, the devices must obtain the secret on demand over a secure channel. This process may be facilitated by a less-constrained device that is under the user’s control, e.g., a personal smartphone.

3.1 Constrained level

Actors on the constrained level may have only very limited system resources. They should be required to perform as little tasks as possible but must perform some security-related tasks to ensure the security of the data.

The constrained level comprises the Resource Server (RS) and the client (C). RS hosts a piece of information, a web resource (R). C requests access to R (Figure 1), e.g., to read a value stored in R or to write a new value into R. C and RS want to communicate directly with each other and thus need means for secure communication.

C and RS must perform the following tasks to enforce the security policies of their owners:

• Authentication of received information: A device that receives a message has to authenticate its source.

• Validation and enforcement of authorization as configured by the owner: A device in possession of the owner’s data has to enforce the owner’s authorization policies. Specifically, received information is only acted upon after validating that the message is authorized, that its contents was protected as required, and that any response can be properly protected.

3.2 Principal level

Actors on the principal level are the owners of the constrained level actors described above. They represent individuals or companies located in the physical world that own the devices and/or the data on them. The client owner (CO) is in charge of C and decides if RS is an authorized source for R. The resource owner (RO) owns RS and defines access policies for R. An actual device might host several RS’ from different resource owners. Figure 2 depicts the relationship between the constrained level actors and their principal.

Actors on the principal level must perform the following task:

• Configuration of authorization policies for their respective constrained level actors. This includes the authorization to perform tasks on the less-constrained level for them.

3.3 Less-constrained level

To reduce the requirements on the actors of the constrained level, they can delegate some security-related tasks to less-constrained devices, the Authorization Managers. These act as a link between the constrained level actors and their respective principals. In particular, less-constrained actors can obtain security policies from the principals, interprete them to generate simplified rules, bind them to a verifier, and provide them to the constrained level actors. Less-constrained devices may be able to use more elaborate user interfaces toward their principals than devices at the constrained level.

The relationship between the actors on all three levels is depicted in Figure 3. The Client Authorization Manager (CAM) is controlled by CO and acts as a less-constrained level actor for C, the Server Authorization Manager (SAM) poses as the link between RS and RO.

The tasks of the less-constrained level actors are the following:

• Obtain the authorization information provided by the principal.

• Potentially simplify it for use by the constrained level.

• Identify the authorization information that applies for the current request.

• Bind the authorization information to a verifier and thereby endorse that the entity in possession of the verifier is authorized as stated in the authorization information.

• Provide the verifier to the constrained devices.

3.4 Authorization to authorize: choosing the authorization managers

The model described above requires the Authorization Managers to be available whenever a client initiates communication with an unknown RS. This limits the choice of devices that can be used as less-constrained level actors.

An evident solution for this problem is to outsource the tasks CAM and SAM are performing to a service in the cloud which is always available and can be used by C and RS as long as those can connect to the Internet.

Users have only limited control over servers in the cloud. These are run by enterprises that pursue their own interests which may conflict with the user’s wishes (Chen et al., 2010). In particular, users do not control the access to data on cloud servers if they completely rely on the cloud providers for the protection of the data. Without precaution, access to data in the cloud is granted as the cloud provider sees fit. This is exacerbated by legal uncertainties and anomalies some jurisdictions exhibit with respect to the protection of data held in the cloud (Kerr and Nojeim, 2012; Mather et al., 2009, p. 33).

3.4.2 Delegated key management

To prevent the Authorization Managers from abusing their power, organizational regulations are not sufficient. To safeguard the owners’ control over their data, a technical solution must be used. A basic design principle for cryptographic mechanisms that continues to be valid today is Kerckhoffs’s principle. It states that the security of a cryptographic mechanism must only depend on the confidentiality of the key (Kerckhoffs, 1883, p. 12). As long as the cryptographic mechanism is not broken, owners can therefore control the access to their data by a careful usage of encryption and safeguarding the respective keying material.

Each Authorization Manager shares a separate key with its respective constrained device. To restrict the authorization to authorize, the respective permissions are bound to the key. Because of the low storage capabilities of constrained devices, only a small number of keys can be held simultaneously. Therefore, the number of less-constrained devices that can act as an Authorization Manager for a single constrained device must be restricted.

The Authorization Managers and their keys can be put into a hierarchical order. On the lowest level, CAM and SAM can only grant very basic access permissions. We call the corresponding key External Key (EK), the SAM in possession of an EK External Server Authorization Manager (ESAM) and the corresponding CAM External Client Authorization Manager (ECAM). With an EK, no new permissions can be configured but the freshness of existing permissions can be validated and mapped to an access request. ECAM and ESAM must only be able to grant permissions they have themselves and they are not able to assign new Authorization Managers to a constrained device.

The Owner Key (OK) has all permissions EK has. Moreover, with an OK new access permissions can be created. Additionally, a device in possession of that key can assign a new Authorization Manager to their constrained device. These Authorization Managers are called Owner Client Authorization Manager (OCAM) and Owner Server Authorization Manager (OSAM), respectively.

Figure 4 depicts the relationship between the actors and the keys they are sharing.

As described above, the owner has different amounts of control over different types of devices. Therefore, the OK should be stored on a device the owner has a high amount of control over, e.g., a server in the user’s home. Servers in the cloud should not know the OK. For more flexibility, the OK can be encrypted and stored in the cloud. The owner downloads the encrypted key to a more controllable device such as a smartphone when needed and decrypts it using a passphrase. The EK can be given to devices the owner has only very little control over, such as servers in the cloud. Thus, cloud servers can make simple authorization decisions on their own without further user interaction.

3.4.3 Implementation

The two types of keys described above are used in different ways. The OK is the only key that needs to be preconfigured on the device. The owner configures sets of access permissions that an Authorization Manager is allowed to grant. The EK is generated and added to the access permissions. To ensure the confidentiality of the EK, it is encrypted making use of the OK. The owner endorses the binding of these permission sets to the EK using the OK, thus creating an Authorization Granting Ticket (AGT) (see Figure 5). This enables the constrained device to validate if the Authorization Manager is allowed to grant the permission. The owner must transmit the EK securely to the respective ECAM or ESAM.

The AGT is encrypted and transmitted securely to the respective External Authorization Manager (EAM), i.e., ECAM or ESAM. The EAM can grant access to the respective constrained device within the limits of these permissions. The owner can create various different AGTs for an EAM. Moreover, AGTs for other devices can be stored in the cloud and downloaded when needed. Only the entity that has the EK specified in the AGT is able to grant the associated permissions.

If C wants to communicate with RS, it will ask its ECAM for permission. Likewise, RS will ask its ESAM if the access request is to be granted. ECAM and ESAM can grant access as long as the requested permissions are covered by one of the AGTs. ECAM and ESAM negotiate a verifier that will be used as a shared secret by C and RS and validate their permissions. ECAM and ESAM each encrypt the verifier using their respective EK, add some freshness information, and endorse the resulting Authorization Ticket with the EK. After that, they send the ticket to their constrained device. It can confirm that the owner authorized the authorization using the OK that is attached to the access permissions. The freshness of the information is validated using the EK. The structure of the Authorization Ticket is depicted in Figure 6.

If more sensitive data is involved, data owners might not want servers in the cloud to make authorization decisions. To keep the control over their data and devices, owners can use a more controllable device to provide these permissions, e.g., the owner’s smartphone that is present at the time of the access. To achieve this, the sensitive permissions can also be stored in the cloud, but the respective EK is not made available to the cloud servers. Instead, the key is additionally stored in the cloud after being encrypted. The EK and associated permissions can be downloaded to the smartphone when needed. The owner types a passphrase to unlock the EK which is then used to provide endorsement information for the set of permissions.