A trust management model for sensor enabled mobile devices in IoT

CBSTM-IoT: Context-based social trust model for the Internet of Things Challenge-response trust assessment model for personal space IoT
Dr.MohitBansal Profile Pic
Dr.MohitBansal,Canada,Teacher
Published Date:26-10-2017
Your Website URL(Optional)
Comment
Trust and Trust Models for the IoT10.1 Introduction The aim of this chapter is to investigate frameworks that ensure trust as well as communication security between nodes in an IoT deployment. The former captures trust in the identity and in the credentials or privileges of a communica- tion peer, therefore dealing with authentication and authorization, while the latter provides some guarantee about the privacy and integrity of the data exchanged between peers. Trust does not refer to the trust in the validity of the data itself; for example, the question of whether a sensor or other data source provides correct readings or not. This relates to the problem of sensor and device reputation, as, for example, discussed by Ganeriwal et al. 1. Trust and security are based on tokens or credentials, provided by a trust man- agement infrastructure, which are embedded in and potentially shared between devices (note that this chapter will use the terms peers, devices, and (end) entities to describe IoT nodes). The integrity and robustness of these tokens (which can, for example, be symmetric keys or digital certificates) are the cornerstone of trust and security. They are useful in deflecting external attacks initiated by entitiesTrust and Trust Models for the IoT  239 that are not in possession of credentials, but fail to deflect internal attacks, where credentials or nodes that own credentials have been compromised. 10.1.1 Trust and security from a device perspective IoT devices are vulnerable in many aspects, so providing and maintaining trust and security (e.g., providing token integrity over time) is a difficult endeavor. Once token integrity is compromised, for example, by recovering a secret net- work key from a device and using it to fabricate malicious nodes, the entire net- work is vulnerable to internal attacks. On the physical level, device enclosures are often not tamperproof; devices can be opened and their hardware can be accessed via probes and pin head- ers. Device central processing units (CPUs) are low-cost components that often have no sophisticated means to protect their code, data, and tokens from external access, that is, via its Joint Test Action Group (JTAG). This allows an attacker to clone entire devices or manipulate software and data; for example, to manipulate a glucometer so that it will provide incorrect readings. If the device is deployed in an unsupervised environment, it may be accessed and manipulated by a mali- cious third party without notice. Furthermore, IoT devices are often based on low-power hardware and may only be able to process tokens with a low complexity. This can have an impli- cation on the robustness of a token, as it can be reengineered or recovered via a brute-force attack. As a result of this, any trust management system for IoT deployments must have the ability to dynamically withdraw trust of individual devices. Likewise, individual devices must be dynamically able to validate the trustworthiness of other nodes they engage with. When trust and security credentials are distributed at the time of manufactur- ing or deployment, a device is seen as initially trustworthy. This trustworthiness, which might degrade over time, is based on many assumptions and prerequisites, including  The device’s hardware, as well as all stages of its manufacturing/ integration, is trustworthy and sound. For example, it must not have JTAG pin headers that allow the extraction of program code and data.  Likewise, the firmware and its development process (from specification to test) is trustworthy and follows best practices. For example, devices must not have undocumented software back doors that have been deliberately left by developers.  The generation, management, and deployment of tokens is trustwor- thy and sound. For example, pseudorandom number generators must240  Security and Privacy in Internet of Things (IoTs) have sufficient entropy to avoid the generation of weak and predictable keys. A general problem in the context of trustworthy firmware is that many embed- ded processors (even if they operate under a modern multitasking operating sys- tem) do not provide process encapsulation via memory virtualization. As a result, malicious code in a firmware image can access and manipulate credentials used by other system processes to initiate an internal attack. Therefore, it is not suffi- cient to determine the trustworthiness of firmware components individually, but the firmware image as a whole must be validated. Devices with a static (“factory-flashed”) firmware image can maintain a higher degree of trustworthiness over time than devices that can be updated dynamically in the field (i.e., via firmware download), if the upload mechanism itself poses a potential back door for attacks. If such a mechanism allows the upgrade of individual firmware components, the number of image variations can increase exponentially, which makes the validation of all firmware images vari- ations a very cumbersome task. Nonetheless, a secure device firmware updating or patching mechanism, as, for example, found in embedded Linux systems, is an integral component to maintain security, as otherwise a single vulnerability can compromise a number of systems. A network-wide update mechanism will preferably incorporate a smooth and effective patching process, which includes robust integrity and authenticity checks, minimizes service outages, and allows for a version rollback if needed. 10.1.2 Secure key storage Secure storage facilities (also known as keystores) increase the robustness of trust tokens used both within an IoT system and its trust management infrastructure (like a certificate authority or a trust center). Passive keystores provide a means to securely save and retrieve credentials; cryptographic operations are executed outside these stores by the device’s CPU. Active keystores in contrast allow the internal execution of cryptographic operations via an application program inter- face (API), so the credentials are never exposed. The following sections will describe various types of key stores. 10.1.2.1 Hardware stores The high-end representatives of this category are hardware security modules (HSM). HSMs have a place in trust management infrastructures with extensive cryptographic requirements. General-purpose HSMs provide a thoroughly secure, generally configurable administration; a security level that can be somewhat adjusted to needs; and tools that cover the whole life cycle of the HSM (such as secure key backup).Trust and Trust Models for the IoT  241 Their main disadvantage is their lack of flexibility if uncommon token for- mats or algorithms are used. Cryptographic smart cards (embedded or otherwise) and cryptographic uni- versal serial bus (USB) dongles are low-cost HSMs. They are particularly ade- quate for resource-constrained nodes or low-cost trust management infrastruc- tures. On the downside, smart cards and dongles may not have as high-security certifications as HSMs; their default administrative options are generally limited and their security-level settings are not as flexible. 10.1.2.2 Trusted platform modules Trusted platform modules (TPMs) are dedicated processors that offer both an interesting complement and an alternative to the options presented above. They are meant to protect hardware (by authenticating devices, or possibly attesting a certain hardware is present), booting processes, and so on, and can also be used in a more general way to store and retrieve credentials after booting has taken place. Their interfaces, however, are different from the ones found in the above HSMs and, in the case of devices that comply with TPM 1.1b, are vendor specific. 10.1.2.3 Software stores The natural place for software stores is in devices with low security require- ments or low-cost embedded systems that have no provisions to physically con- nect hardware modules. There is a plethora of both active and passive software stores that can be used in IoT systems. PKCS12 stores are based on the homonymous public key cryptography standard (PKCS), initially defined by RSA Security (now part of EMC Corporation) and later expanded and corrected by several request- for-comments documents (RFCs), such as RFC 7292 2. The standard defines a data structure syntax that can contain cryptographic objects (keys, certificates, etc.) and, optionally, arbitrary data, encrypted and signed. In principle, PKCS12 defines two types of integrity/privacy modes, the asymmetric cryptography and the password-based modes. Privacy-enhanced electronic mail (PEM) stores are files that contain Base 64 versions of ASN.1 formatted certificates and (encrypted) keys, enclosed by human-readable headers for convenience. Java stores are part of a much larger programming framework, the Java cryptography architecture/Java cryptography extension (JCA/JCE). This frame- work defines a provider-based, pluggable architecture that includes, among many other things, keystore implementations. One such implementation is provided by the Sun provider and included in all distributions since the early versions of Java. It implements keystores as proprietary password-protected Java KeyStore (JKS) files.242  Security and Privacy in Internet of Things (IoTs) Information Information source destination Normal flow (a) Interruption Interception (b) (c) Modification Fabrication (d) (e) Figure 10.1: Principal attack vectors in IoT device communication. 10.1.3 Trust and security from a network perspective During the operation of a network, devices set up static or dynamic (e.g., short- lived) communication links with other peers. These links can be either point-to- point or incorporate a group of nodes. From a device’s perspective, the challenge is to validate the authenticity and authority of the other peer(s) and to set up a secure communication link to avoid attack scenarios, as shown in Figure 10.1. For this purpose, trust tokens are exchanged and validated, or new session tokens are created (i.e., session keys derived from a master key). Overall the following requirements must be fulfilled:  Data: confidentiality  Data: integrity  Peer: authenticity  Peer: Proof of authorizationTrust and Trust Models for the IoT  243  Communication: service and system availability  Communication: nonrepudiation The assurance of data integrity, optionally in combination with data confidential- ity via encryption, provides trustworthiness in the data a node sends or receives. For example, in a body area network, a wireless glucometer sends glucose read- ings to an integrated insulin pump. This information must be protected from accidental or deliberate tampering, while patient privacy considerations require the data to be encrypted. Data integrity and confidentiality provide a foundation (complementary to additional protocol-specific features like sequence numbers or timestamps) to deal with the principal attack vectors of interception, interrup- tion, and modification. Data confidentiality is usually provided via symmetric encryption (with the Advanced Encryption Standard AES algorithm as a de facto industry standard) often implemented directly in hardware, while data integrity is provided via mes- sage authentication codes or cryptographic hashes that are attached to the data payload. Peer authenticity relates to the problem of how a peer can validate another peer’s identity before a communication link is established; that is, an insulin pump must be able to validate that it actually connects to a trusted glu- cometer (and subsequently receives data from it) and not from a malicious device. Peer authenticity can go hand in hand with system availability. For example, denial-of-service (DoS)-style attacks are typically external attacks (e.g., they are launched by external nodes outside the jurisdiction of an IoT deployment), so the ability to qualify and if necessary to discard data or connection requests (i.e., SYN flood attack for transmission control protocol TCP connections) at an early stage can help to alleviate such attacks. Proof of authorization provides assurance that a peer has the authority to (a) communicate with another peer and (b) conduct a certain action; for example,  A glucometer will only accept data requests from an insulin pump (and not from the blood pressure monitor). Furthermore, both glucometer and pump must be from the same manufacturer.  A reset command sent to the glucometer sensor by the insulin pump (after a sensor reconfiguration) should only be executed if the insulin pump has the required authorization level. Therefore, proof of authorization is a viable mechanism to protect against fabrication. Nonrepudiation—for example, the ability to ensure that communicating peers cannot deny the authenticity of their action—is linked back to peer tokens.244  Security and Privacy in Internet of Things (IoTs) Data integrity and data confidentiality are based on credentials only known to the communicating peers (i.e., shared secret keys). If these credentials are created dynamically on the fly, they must be mutually authenticatable during the key generation phase (to avoid man-in-the-middle MitM style attacks, as possible in Diffie–Hellman key exchanges). Likewise, peer authentication and authenticity are provided via additional device descriptors that are mutually available and can be mutually validated. 10.2 Trust Model Concepts The following section will present three trust models. They provide the concep- tual basis for a trust management infrastructure. 10.2.1 Direct trust model In a direct trust model, a peer obtains credentials of other peers in such a way that it is immediately convincing to them. A common approach is the predistri- bution of peer credentials before the network is deployed. Two approaches will be described here, if only briefly: one based on symmetric keys and another one that makes use of static whitelists. The first option uses as credentials pairwise shared symmetric keys (installed during manufacturing or system integration), which provide data confidentiality and integrity as well as implicit peer authenticity and proof of authorization—the latter can be expanded via additional peer descriptor tables in each device that associate further attributes with each peer. A direct trust model, which is based on pairwise shared symmetric keys for ∗ n nodes, requires a total of n (n− 1)/2 keys, with (n− 1) keys stored in every node, making it unsuitable for large-scale deployments. Also, the revocation or renewal of tokens is very tedious, as every node has to be notified. The second option, discussed in 3, uses asymmetric keys and whitelists con- taining references to certificates (as further discussed below). Here, each device is equipped with its own certificate (entailing its identity, a public key, and fur- ther device attributes) signed by an authority, and a complementary whitelist that contains unforgeable certificate identifiers of all peers with which it is allowed to communicate. An identifier can be a certificate’s hash value, its public key, or its serial number. While this solution substantially reduces the number of credentials dis- tributed in a network (each device would have exactly one certificate contain- ing one key pair), the management of the whitelists is impractical for large or nonstatic developments. Likewise, the revocation or renewal of tokens is very tedious. Overall, a direct trust model approach is only feasible in small and static networks because of its management constraints and memory requirements.Trust and Trust Models for the IoT  245 10.2.2 Web-of-trust model In a web-of-trust model, a peer accepts the credentials of another peer if these credentials have been validated (e.g., signed) by another, already trusted peer 4; that is, in a body area network, a glucometer will accept the credentials of an external programming device (and subsequently establish a connection to it) if these credentials were signed by a trusted insulin pump. The web-of-trust model is implemented in Pretty Good Privacy (PGP), where individual users maintain a list of credentials (e.g., public keys) in a key ring. When a key from another peer is inserted, the user assigns the key legitimacy which can hold the value as complete (e.g., complete confidence that the credential is owned by the other peer), marginally, or not trusted. However, in an IoT environment, a web-of-trust model is not feasible for nonstatic networks, as it does not enable new previously unknown nodes to join a network. Unmanaged key servers, as used in PGP, for example, are vulnerable to identity spoofing and do not solve this problem. Furthermore, the withdrawal of trust is tedious, as it has to be propagated across the network to reach all nodes. Also, IoT devices may operate in very regimented environments (i.e., medical or critical infrastructure), where a web-of-trust model is simply not acceptable and a tight, centralized trust management, as discussed in the next section, is required. 10.2.3 Hierarchical trust model Here, trust is managed by one or more trust anchors, whereby multiple anchors form a hierarchical infrastructure. 10.2.3.1 Trust center infrastructures In a trust center infrastructure (TCI) one or more dedicated trust anchors manage on-the-fly connection requests between network nodes. The network authentica- tion system Kerberos 5 is based on this approach, whereby individual clients receive tickets (with a certain life span) that allow them to authenticate and autho- rize themselves to other nodes. Figure 10.2 shows an example for a TCI based on a single dedicated trust anchor (TA). The TA has a unique shared token (a symmetric key Kx) with each node x in the network. It also optionally maintains a descriptor table Dx for each device. Whenever two nodes NI and ND set up a network connection, the initiating peer NI refers first to the TA (Step 1) (i) to validate NDs identity IDND, (ii) to obtain ND’s descriptor table DND (to resolve authentication and authorization issues), and (iii) to obtain a randomly generated session key SNI-ND to be shared later with ND. The same information about NI is provided for ND, but encoded using the key KND shared between TA and ND. Both components form a response which is encoded using KNI before transmission (Step 2).246  Security and Privacy in Internet of Things (IoTs) DNI TA DND 1 E (IDND) KNI 2 E (IDND, DND, SNI-ND, E (IDNI, DNI, SNI-ND)) KNI KND 1 2 3 E (IDNI, DNI, SNI-ND) KND 3 NI ND Figure 10.2: Node authentication in a trust center infrastructure. NI receives and decodes the response, validates ND’s identity and authorization level, and sends the second (still encoded) component to ND (Step 3), which in turn will validate NI’s identity and authorization level. Finally, both peers use SNI-ND to set up a secure communication link. The revocation of nodes (in the sense of marking them as untrusted) is straightforward when a TA is used. Also, each node only requires a single key Kx and the TA’s identity (i.e., its media access control MAC or Internet pro- tocol IP address), making it a very resource-efficient approach from a device’s perspective. The downside is that the TA poses a single point of failure; for example, a compromised trust anchor (which, for example, is a victim of a DoS attack) will compromise the integrity and availability of the entire network. The inability to revoke the TA complicates things further. Since the TA holds information about all devices managed by the TCI, this approach is only suitable for static networks or environments where an operator can add and remove device details on the fly. 10.2.3.2 Public key infrastructures Public key infrastructures (PKIs) are another implementation of the hierarchical trust concept. PKIs are less susceptible to attacks on availability, as they provide network nodes with verifiable credentials (also known as public key certificates) prior to deployment, which can be validated without accessing a TA. In contrast to TCIs they also demonstrate better scalability and manageability. According to the Internet Engineering Task Force (IETF) PKIX working group, a PKI is “the set of hardware, software, people, policies and proce- dures needed to create, manage, store, distribute, and revoke Public Key Cer- tificates.” 6.Trust and Trust Models for the IoT  247 A PKI, therefore, does not limit its scope to strictly technical elements such as hardware, software, networking infrastructures, protocols, or algorithms. It permeates into organizations that manage and use them by requiring the partici- pation of other agents and resources: people, policies, and procedures. Public key certificates (also called digital certificates or identity certificates), the public key cryptography procedures and technologies that substantiate them, and trust relations form the basis of a PKI. Trust relations based on the issuance of certificates, which in turn rely on public key cryptography, are what differ- entiates PKIs over other forms of security constructs, and what determines their properties. The life cycle of certificates is at the core of PKIs. Typically, an entity called the certification authority (CA) issues identity certificates by digitally signing a set of (identity-related and other) attributes including a public key (of a public– private key pair in the context of public key cryptography). The act of issuing such a certificate constitutes a proof of the linkage between the attributes and possession of the public key. By signing the certificate with his own private key of a public–private-key pair, a CA states that the attributes are tied to the entity that owns the public key pair. Issuing certificates that, in turn, issue other certificates is common practice, in what are called multilevel PKI hierarchies. PKIs also allow for the issuance and management of other types of certificates, such as attribute certificates. The issuance of certificates is the germinal event that constitutes a PKI, and is often present in successive steps throughout its existence. Other events give shape to the life cycle of a PKI as well. Overall, the life cycle of a certificate includes the following events:  End-entity registration  Issuance  Publication  Revocation of certificates  Generation of revocation state data  Archival and recovery of certificates and key material Trust plays a crucial role in PKIs. The key concept in this case is transitiv- ity of trust. Due to the mathematical properties of the algorithms that under- pin PKI technologies, a well-formed certificate directly or indirectly (through intermediate certificates, that form an unbroken chain of issuances) issued by a trusted certificate can in turn be trusted. In the simplest scenario, a sin- gle initial trusted certificate is all that has to be interchanged through fully verifiable channels. These channels can vary, but have to meet these two conditions:248  Security and Privacy in Internet of Things (IoTs)  The authenticity of the data must be assured by already established and particularly trustworthy methods, in proportion with the importance of the hierarchy that is to be established.  The mechanism must not rely on the trust of any component of the hier- archy it is meant to establish. As a result of all the above, previously unknown entities can communicate securely. In fact, there is no theoretical limit to the number of previously unknown entities that could securely communicate, hence the excellent scala- bility properties of a PKI. But, of course, as trust can be transmitted down trust chains with relative ease, the initial source of trust, or root trust anchor, has to be protected at all costs. 10.3 PKI Architecture Components The following components are usually found in PKIs:  Certification authorities  Registration authorities  Validation authorities  Central directories Optionally, PKIs can also incorporate timestamping authorities and certificate revocation authorities. In addition, but on an entirely different level, a PKI comprises a series of policies (of which certificate/certification policies are the most salient example), procedures, and personnel. 10.3.1 Certification authorities CAs form the backbone and the trust anchors of a PKI. They issue certificates and, in many cases, revocation status data (for instance, certificate revocation lists, CRLs) regarding the certificates they issue, and publish both types of prod- ucts. Certification authorities are typically structured in levels, thus forming a hierarchical PKI. 10.3.2 Registration authorities Registration authorities (RAs) act as the front end of certification authorities, in that they are responsible for identifying and authenticating entities that request certificates, and then dispatching certificate requests to CAs and routing back the certificate(s) to the requesting entity. In some cases, RAs are just a specialized component of CAs.Trust and Trust Models for the IoT  249 10.3.3 Validation authorities Validation authorities (VAs) allow for the validation of certificates. Validating a certificate actually comprises several steps (verifying signatures, possibly obtain- ing certificates, checking revocation status). It is generally assumed that VAs only provide services in relation to checking revocation status, typically via online certificate status protocol (OCSP) services. VAs are, therefore, usually OCSP servers. 10.3.4 Central directories Central directories make certificates available to other entities. Since other data, such as policies, or CRLs need to be published as well, central directories store and make all these data available. They are often implemented as lightweight directory access protocol (LDAP) servers. 10.3.5 Timestamping authorities Timestamping authorities (TSAs) are characterized by their ability to issue PKI- based trusted timestamps. Trusted timestamps can prove that data existed prior to the issuance of the timestamp; as a result, “time-aware” validation mechanisms (i.e., those that take into account the moment timestamped signatures were gen- erated) can be used. That property makes it possible for timestamps to form an important part of certain advanced signature mechanisms, such as CAdES-T/ CAdES-X or XAdES-T/XAdES-X 7. 10.3.6 Certificate revocation authorities Certificate revocation authorities (CRAs) are specific authorities that allow for the revocation of certificates. Normally, revocation duties are carried out by a dedicated service that belongs to each CA. However, whenever either the num- ber of issued certificates is high, or the complexity of revocation procedures increases, or so does the number and variety of CAs, specialized authorities, CRAs, come to play, whereby a single, centralized CRA can substitute equiva- lent revocation services on multiple CAs. CRAs provide a number of benefits:  CRAs decouple certificate issuance from revocation, thus easing the use of resources. They can contribute to overall system availability, as they provide revocation information about already issued certificates, even if certification authorities are not available. Providing revocation informa- tion within a certain time frame is critical for the correct functioning of many PKIs. What is more, policies generally set specific time frames for the renewal of that information, so the consequences of a failure to pro- vide can go beyond system unavailability.250  Security and Privacy in Internet of Things (IoTs)  CRAs make the end of life of CAs easier, by continuing to revoke certifi- cates after the CA has been effectively been decommissioned. A revoca- tion authority can even revoke every single certificate a CA has issued, if necessary, thus emulating the revocation of the certificate issuance CA certificate.  PKIs which contain multiple active CAs based on different products or technologies can find the use of CRAs especially beneficial. A CRA can provide services for all certificates, without the burden of having to revoke them using a specific CA.  Separating CRA services from CA services improves system security, by preventing unnecessary exposure of CA services to entities that only require revocation services or data. Protecting CAs is particularly critical as compared to protecting CRAs, as attacks to the former could lead to unwanted issuance of certificates, whereas attacks to a CRA would, at the most, mean an unwanted retrieval of certificates. 10.4 Public Key Certificate Formats 10.4.1 X.509 certificates X.509 identity certificates are specified in the X.509 recommendation of the telecommunication standardization sector of the International Telecommunica- tion Union (ITU-T) 8. They are self-descriptive entities that use Abstract Syn- tax Notation One (ASN.1) as the specification language. Its high-level structural representation (in ASN.1) is as follows: Certificate ::= SEQUENCE tbsCertificate TBSCertificate, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING TBSCertificate further defines (in ASN.1 notation) the data fields represen- ted in a certificate (Figure 10.3), while Algorithm Identifier is described via an object identifier (OID); that is, for example, “1.2.840.113549.1.1.4” for “MD5withRSA,” a combination of the MD5 hash algorithm encoded using the CA’s private RSA key. The signature (a signed hash value) is itself stored as a bit string. X.509 certificates are encoded using Distinguished Encoding Rules (DER) 9 (see Figure 10.4) and stored as an ASCII string. The X.509 standard distinguishes between three identity certificate versions (see Figure 10.5), with version 3 certificates being the most common and versa- tile ones. In relation to IoT devices, a digital certificate must contain the following information at a minimum:Trust and Trust Models for the IoT  251 Identity certificate Attribute certificate Subject Entity associated Holder Entity associated, (e.g., certificate 12345) Validity Period of validity Validity Period of validity Serial number 12345 Serial number 67890 Subject public key Attributes Set of attributes (e.g., roles) Issuer Name of the trust center Issuer Name of the trust center Signature Signature of trust center Signature Signature of trust center Certificate has one corresponding private key, which has to be protected separately Figure 10.3: Identity certificates and attribute certificates.252  Security and Privacy in Internet of Things (IoTs) 0000 : 30 82 03 05 ; SEQUENCE (305 Bytes) 0004 : 30 82 01 f1 ; SEQUENCE (1f1 Bytes) 0008 : a0 03 ; OPTIONAL 0 (3 Bytes) 000a : 02 01 ; INTEGER (1 Bytes) 000c : 02 000d : 02 10 ; INTEGER (10 Bytes) 000f : 6e 92 35 46 0e db b5 94 4d 59 f9 f1 a8 f1 cf e6 001f : 30 09 ; SEQUENCE (9 Bytes) 06 05 ; OBJECT_ID (5 Bytes) 0021 : 2b 0e 03 02 1d 0023 : ; 1.3.14.3.2.29 sha1RSA (shaRSA) 0028 : 05 00 ; NULL (0 Bytes) 002a : 30 1a ; SEQUENCE (1a Bytes) 002c : 31 18 ; SET (18 Bytes) 002e : 30 16 ; SEQUENCE (16 Bytes) ; OBJECT_ID (3 Bytes) 0030 : 06 03 0032 : 55 04 03 ; 2.5.4.3 Common Name (CN) ; PRINTABLE_STRING (f Bytes) 0035 : 13 0f 72 67 61 6e 20 53 69 6d 6f 6e 73 65 6e 0037 : 4d 6f ; “Morgan Simonsen” (3 Bytes) ; SEQUENCE (1e Bytes) 0046 : 30 1e ; UTC_TIME (d Bytes) 0048 : 17 0d 004a : 31 33 30 34 31 36 30 38 35 37 31 37 5a ; 16.04.2013 10:57 0057 : 17 0d ; UTC_TIME (d Bytes) Figure 10.4: ASN.1 DER encoded certificate 10. (From: Morgan Simonsen’s Blog. https://morgansimonsen.wordpress.com/2013/04/16/understanding-x-509- digital-certificate-thumbprints/.)  The name of the subject—for example, the identity of the device—to which the public key in the certificate is bound. Note that there is a con- ceptual difference between a typical server-side certificate (in which the entity is identified by its domain name system DNS name), and a device certificate, which can also be identified by a uniform resource identifier (URI), a MAC address, or an IP address.  Its public key and the cryptographic algorithm it relates to.  The certificate’s serial number (for revocation purposes) and validity.  The name of the issuer (e.g., the CA).  The purpose and restrictions of the public key in the certificate.Trust and Trust Models for the IoT  253 Version Serial number Signature algorithm indentifier Issuer name Validity period Subject name Public key information Issuer unique ID Subject unique ID Extensions Figure 10.5: X.509 Identity certificate versions 1, 2, and 3. X.509 certificates are rather large (∼2 Kbyte), have a complex structure (as shown in Figure 10.4), and require a complex parser; resource-constrained IoT devices may have difficulty handling them, in terms of both memory and com- putational requirements. Therefore, alternative formats are discussed in the fol- lowing two sections. 10.4.2 Self-descriptive card verifiable certificates Self-descriptive card verifiable certificates (CVCs) are very compact public key certificates suitable for resource-constrained devices like smart cards. While CVCs are still DER encoded (and are therefore self-descriptive), they only con- tain a subset of the fields of an identity certificate 11: cvcBody ::= SEQUENCE profileId UNSIGNED INTEGER, issuer CHARACTER STRING, pubKey CHARACTER STRING, subject CHARACTER STRING, notBefore DATE, notAfter DATE 10.4.3 Non-self-descriptive card verifiable certificates These certificates are not DER encoded and therefore do not have type tags. Information about their internal structure is provided via header fields that are kept separate from the certificate itself. Non-self-descriptive CVCs can be Version 1 Version 2 Version 3254  Security and Privacy in Internet of Things (IoTs) represented in their simplest form by a static abstract data type; for example, a structure in the programming language C: typedef struct simpleNonSelfDescriptiveCVC char version; char owner20; char issuer20; char alg; // Note that OIDs are omitted here ... tSimpleNonSelfDescriptiveCVC; A memory-efficient format that incorporates dynamic length fields, but requires a simple parser for processing (as it cannot be mapped onto a fixed-length data structure any more), appears as follows: typedef struct dynamicNonSelfDescriptiveCVC char version; char ownerLength; char ownerownerLength; char issuerLength; char issuerissuerLength; char alg; // Note that OIDs are omitted here ... tDynamicNonSelfDescriptiveCVC; 10.4.4 Attribute certificates An attribute certificate only assigns—in contrast to a conventional public key or identity certificate—privileges to end entities. X.509 attribute certificates are specified in 12. They have the following ASN.1 structure: AttributeCertificateInfo ::= SEQUENCE version AttCertVersion version is v2, holder Holder, issuer AttCertIssuer, signature AlgorithmIdentifier, serialNumber CertificateSerialNumber, attrCertValidityPeriod AttCertValidityPeriod, attributes SEQUENCE OF Attribute, issuerUniqueID UniqueIdentifier OPTIONAL, extensions Extensions OPTIONAL An attribute certificate is issued and signed by an attribute authority; it has a certain life span and binds an authorization (of whatever nature) to the end entity.Trust and Trust Models for the IoT  255 It has also optional extension fields. However, as can be seen in the listing, it does not contain a public key. Instead, it is tied to an identity certificate, as shown in Figure 10.3. This separation allows identity and attribute certificates to have different life spans, which is, for example, extensively used in digital rights management. Here, a consumer acquires the right to access certain digital content over a poten- tially limited period of time via an attribute certificate. The consumer himself is identified via his identity certificate. 10.5 Design Considerations for Digital Certificates 10.5.1 Device identifiers In a digital identity certificate, both its owner and the CA that signed the certificate must be uniquely identified. While there will be a relatively small number of CAs (with each CA being able to potentially manage millions of certificates), there is a need for a scalable naming scheme suitable for billions of nodes. Device identifier construction schemes can be based on various methods. These methods incorporate either (i) random data, (ii) a hierarchy identifier, (iii) the encoding of additional information (e.g., the manufacturer), or (iv) the use of cryptographic operations (e.g., hash of public key) 16. One scheme can apply several methods at the same time, as shown in Table 10.1 15. In today’s Internet, the URI is the de facto naming scheme to identify the name of a web resource. At the network level, a device is identified via its static or dynamic (v4 or v6) IP address. The DNS translates the hostname into a URI into an IP address. However, while this approach is suitable for a hierarchy of certificate author- ities, it does not necessarily scale for IoT networks, as (i) such networks can be isolated without having access to a DNS service and (ii) the anticipated number of IoT devices makes a classical URI approach unworkable. Further- more, machine-to-machine (M2M) communication does not necessarily require human-readable URIs. An alternative solution is the use of a device’s IPv6 address as its unique device identifier. Such an address consists of 16 octets; the overall address space 38 is in the order of 10 possible addresses 13. The underlying IPv6 network communication protocol is already widely embraced by standard (IEEE 802.3 Ethernet and IEEE 802.11 Wi-Fi based) net- works and has found its way into the IoT via the low-power wireless personal area networks (6LoWPAN) communication standard, so it is a potential candi- date for an IoT naming scheme.256  Security and Privacy in Internet of Things (IoTs) Table 10.1 Device identifier construction schemes and their underlying methods Project or Naming Scheme Method Applied Architecture IPv6 URI Hierarchy identifier; encoding additional information IPv6 IPv6 Hierarchy identifier Glowbal IP AAID Encoding additional information Protocol GS1 GS1 identification Random data; encoding additional keys information SWE Sensor UID Encoding additional information IoTWork Name of a node Hierarchy identifier; encoding additional within a namespace information NDN Name of the data Hierarchy identifier; encoding additional information; cryptographic operations Mobility GUID Encoding additional information; First cryptographic operations RFID RFID Random data 802.15.4 MAC address Random data An IPv6 address is ideally broken into two 64-bit segments, with the first segment being the network’s subnet address. In most IoT networks, this address will be assigned during deployment, so it cannot be anticipated when a certifi- cate is generated during manufacturing. Furthermore, the address can potentially change over time. The second 64-bit segment, however, is the device’s MAC address, which is in fact unique and available for certificate generation during manufacturing. Table 10.1 lists other naming schemes that could be potentially considered. These include:  The radiofrequency identification (RFID) naming scheme, which is based on a unique 64–92-bit identifier 13  GS1 identification keys 14  Sensor web enablement and sensor UID 15  IoTWork naming scheme 16  Mobility First 17

Advise: Why You Wasting Money in Costly SEO Tools, Use World's Best Free SEO Tool Ubersuggest.