原标题：Add a Secure Element to Build Edge-to-Cloud Security into an IoT Design

　　Cybersecurity remains a universal problem in the design and deployment of any system connected to the public Internet. In the Internet of Things (IoT), security problems are particularly acute as users begin to question the ability of connected devices to securely support applications in smart homes, smart factories, or smart cities. Yet, in facing tighter delivery schedules, IoT device developers often feel they cannot afford the device resources, much less the additional time needed in the past to implement the extensive set of capabilities required for an effective security solution.

　　Semiconductor vendors are helping to strike a balance by providing easier to deploy security solutions. This article will discuss the problem of security before introducing one such solution from NXP Semiconductors, namely the EdgeLock SE050 secure element (SE). It will then show developers how to use this single-chip device to rapidly implement edge-to-cloud security in their IoT devices.

　　The IoT security problem

　　Poorly secured IoT devices have unfortunately proven to be an attractive target for cyberattacks. Once compromised, devices can yield confidential user data as well as provide valuable information needed to build counterfeit copies of the devices. Hackers can also use these exposed devices to create greater havoc, penetrating more deeply into networks to reach other connected devices, systems, and enterprise resources. As a result, the effects of compromised IoT devices ripple through the multiple layers of the IoT hierarchy, even threatening public safety in emerging IoT applications like building automation, industrial systems, transportation, and medical devices.

　　For developers expected to deliver more efficient IoT designs, security can come as an unwelcome addition to a growing list of requirements already dominated by demand for higher performance and lower power consumption. In fact, effective security depends on a growing list of requirements needed to mitigate threats extending from the edge to the cloud.

　　Applied in isolation, even familiar techniques such as encryption and authentication are insufficient on their own. IoT security needs to be built on a root of trust designed to ensure that security mechanisms and protocols are protected from compromise. At the same time, security methods increasingly need to be applied at finer granularity to protect not only connections between IoT devices, but also connections between components of an individual IoT design.

　　The NXP EdgeLock SE050 SE is designed specifically to provide the range of security mechanisms and protocols needed to build edge-to-cloud security into IoT devices.

　　Robust security solution

　　Designed as a turnkey solution for IoT device security, the NXP SE050 builds upon NXP's extensive experience in smart card security to provide a hardware root of trust for IoT designs. The device combines a dedicated microcontroller and secure credential storage with a software stack built on the Java Card OpenPlatform (JCOP) smart card operating system (OS). Independently certified up to the OS level at the Common Criteria (CC) Evaluation Assurance Level (EAL) Level 6 augmented (EAL 6+), the SE050 operating platform offers a rare level of assurance for operation in high threat environments (Figure 1).

Figure 1: Among certified products, the SE050 platform offers a rare of level of assurance with its certification up to the OS level at CC EAL 6+. (Data source: Common Criteria)

　　Optimized to run on this robust security platform, a dedicated NXP IoT security applet uses a built-in crypto library to support a comprehensive set of cryptography algorithms including:

　　Symmetric cryptography using Advanced Encryption Standard (AES) and Data Encryption Standard (DES) algorithms

　　Asymmetric cryptography using Rivest–Shamir–Adleman (RSA) and Elliptic-Curve Cryptography (ECC) algorithms with support for a number of ECC curves including standard curves specified by the National Institute of Standards and Technology (NIST)

　　Multiple hash functions used in building message authentication codes (MACs)

　　Multiple Key Derivation Function (KDF) algorithms used for password hashing, key agreement, and key strengthening, among other methods

　　To speed performance, the SE050 device integrates hardware accelerators for Advanced Encryption Standard (AES), Data Encryption Standard (DES), and Fast Attribute-based Message Encryption (FAME) cryptography.

　　To protect credentials used during cryptographic operations, the device provides up to 50 kilobytes (Kbytes) of secure user flash memory and comes pre-provisioned with root keys designed to support typical IoT transactions. Developers creating high-volume designs can also take advantage of custom keys and credentials provisioned securely by NXP or authorized third party providers.

　　Along with its embedded flash memory, the device supports access to random access memory (RAM) to store public certificates, for example, while the associated private keys remain in secure flash memory. Going further, the SE050 IoT applet includes a secure import/export capability that lets developers securely store keys or arbitrary data in external memory. Still, the device uses a memory management unit that limits access to different parts of memory to only the IoT applet, preventing unauthorized access through the microcontroller. For further protection against tampering and sophisticated side-channel attacks, the device also incorporates multiple logical and physical barriers to unauthorized access.

　　However, security is as much about allowing access to authorized devices as it is about setting up barriers to unauthorized access.

　　Device authentication

　　In serving as a root of trust for IoT devices, the SE050 cryptography mechanisms and secure storage capabilities directly support secure connections expected for communications with authorized remote hosts such as cloud servers. In fact, those same capabilities enable developers to ensure the authenticity of connections at the lowest levels of the IoT hierarchy between separate IoT devices built with SE050 SEs.

　　Using a method similar to conventional Internet authentication, an intelligent IoT sensor can authenticate itself to an IoT control device, for example. This process begins with the sensing device sending the certificate stored in its SE050 secure storage to the control device. The control device in turn validates the received certificate using SE050 crypto features. Upon successful validation, the control device sends some random value, called the challenge, back to the sensor device. In turn, the sensor device uses its SE050 SE to sign the challenge with the private key associated with the same certificate it sent earlier to the control device. Because that signed challenge can only be validated using the associated public key, the control device is assured that the certificate originally sent by the sensor device is truly owned by that device. Consequently, the control device can reliably authenticate the sensor device.

　　By switching roles in the same process, the control device can conversely authenticate itself to the sensor.

　　This kind of mutual authentication process is essential for building trusted IoT networks, particularly with the emergence of more intermediate layers including edge computing devices. Although the mutual authentication process is straightforward, even simple implementation mistakes or different interpretations of the protocol can result in serious security flaws. In resource-constrained IoT designs, in particular, the need for secure storage and rapid execution of complex crypto algorithms can further complicate reliable implementation. By adding the SE050 to any IoT design, developers can implement critical security features such as mutual authentication without compromising overall design performance or security.

　　Simple, secure integration

　　Complementing the SE050’s advanced capabilities is ease of design-in. Developers can easily integrate the device into their IoT hardware designs with minimal impact on design complexity or footprint. Designed to serve as an add-on device, the 3 millimeter (mm) x 3 mm device provides a simple set of serial interfaces (Figure 2).>

Figure 2: The NXP SE050 SE provides multiple interfaces, allowing its use as an I2C slave for connections to host microcontrollers, as an I2C master for ISO 7816-based connections to digital sensors, and as an ISO 14443 near field communication (NFC) contactless interface. (Image source: NXP)

　　To communicate with the host microcontroller, the device serves as an I2C slave. The SE050 can also serve as an I2C master for ISO 7816-based connections to another serial device such as a digital sensor. The device also supports a third interface for ISO 14443 NFC contactless connectivity.

　　For its different connections, the SE050's IoT applet orchestrates secure keys and access control rules to set up and manage sessions for each connection.

　　For communicating with the host, the SE050 provides session-based authentication designed to prevent interception of I2C commands and data, and the use of man-in-the-middle attacks. To initiate a serial connection session, developers can authenticate with a user ID, which serves just like a password or personal identification number (PIN).

　　Basic password-based authentication between the microcontroller and SE050 might not always be sufficient for some applications. For critical applications, developers might need to ensure that communications between the host microcontroller and SE050 SE remain confidential to prevent attacks that replay sessions, send out-of-order session fragments, or substitute cryptographic algorithms with hacked versions intended to extract confidential data.

　　Secure bus transactions

　　With the SE050 SE, developers can use authentication methods to create a secure communications channel between the SE050 and host microcontroller. Here, developers can use the SE050 IC's support for the Secure Channel Protocol (SCP) SCP03 standard broadly used to secure bidirectional communications between a Java Card device and host.

　　For microcontroller-based designs built with the SE050 SE, use of the SCP03 protocol essentially binds the SE050 SE to the host microcontroller during I2C bus session authentication, further permitting use of encrypted messages during the session. For message encryption within the SCP03 protocol, the plain text message is first encrypted using the AES algorithm, and a MAC for the encrypted message is generated. By sending both the encrypted message and associated MAC, this method called "encrypt-then-MAC", protects the encrypted message and enables the receiver to detect alterations to the message.

　　The SE050 also extends a form of protection to sensor data. Here, developers can request the SE050 to augment responses to host commands with attestation metadata including a unique identifier, freshness data in the form of a random value for each instance, a timestamp, and a signature. Within the host, software can examine attestation data received from the SE050 to validate the source and timeliness of data from sensors connected to the SE050 I2C master interface.

　　As data from individual sensors combine in streams flowing up the IoT hierarchy, applications can use this attestation data to identify the source of unusual data patterns that might indicate impaired, failed, or compromised sensors. With SCP03 host sessions and sensor data attestation, developers can reliably and securely acquire essential sensor data for critical applications.

　　Functional interface

　　Attestation requests and responses, as with all interactions between the host microcontroller and SE050 SE, flow through a communication stack defined in ISO 7816 functional interface standards for smart card devices (Figure 3). This Application Protocol Data Unit (APDU) standard defines the format, content, and protocol for message exchange between a host device (HD) and an SE.

Figure 3: Communications between an NXP SE050 SE and a HD proceed through an ISO 7816 smart card standard stack comprising application-level requests and response using the ISO 7816 APDU standard, transmitted by a data link layer using the ISO 7816-3 T=1 half-duplex protocol over I2C. (Image source: NXP)

　　Building on the I2C physical layer, the data link layer decomposes requests and response from the application layer into a sequence of transactions that follow the ISO 7816-3 T=1 over I2C protocol for half-duplex communication. In this protocol, the data link layer on the HD and on the SE wait for acknowledgement following each transmission in a transaction sequence.

　　For example, for a read request issued by the host application, the host's data link layer first polls the SE and waits for an acknowledge (ACK) response, which indicates that the SE is ready to send (Figure 4).

Figure 4: The data link layer processes HD requests including the read request shown here as a series of transactions conforming to the T=1 over I2C protocol, starting with a polling loop that repeats the request until it receives an acknowledge (ACK) response indicating that the SE is ready to transmit data. (Image source: NXP)

　　Following its ACK ready response, the data link layer in the SE sends data to the host as a sequence of data block transfers, waiting for an acknowledgement from the host's data link layer for each block transfer (Figure 5). Finally, the complete response is delivered to the host application.

Figure 5: After indicating that it is ready to send data, the SE sends a data response as a sequence of data blocks, waiting for an acknowledgement from the HD before sending the next block in the sequence. (Image source: NXP)

　　Software implementation

　　At the application level, exchanges between the host microcontroller and SE050 SE are conducted using the ISO 7816 APDU standard. For the SE050, APDUs for commands and responses are based on the Tag, Length, Value (TLV) format defined in ISO 7816-4. At a minimum, each APDU comprises a class (CLA) byte (a fixed value for all SE050 operations), an instruction (INS) byte, and two parameter (P1, P2) bytes. Data requests and responses may also include additional fields for the number of bytes to be read (Le), the length of the data field (Lc), and the data field.

　　For example, a read request by the host application would use a pair of TLVs to configure the SE050 I2C interface and perform the read request (Listing 1). As noted earlier, the host data-link layer would then decompose this request into a series of I2C bus transactions in accordance with the T=1 protocol.

　　Copy

　　static smStatus_t i2cm_Read(

　　ex_sss_boot_ctx_t *pCtx, uint8_t *readbuf, uint32_t readLength)

　　{

　　smStatus_t status;

　　TLV[0].type = kSE05x_I2CM_Configure;

　　TLV[0].cmd.cfg.I2C_addr = I2C_SENSOR_BUS_ADDRESS;

　　TLV[0].cmd.cfg.I2C_baudRate = kSE05x_I2CM_Baud_Rate_400Khz;

　　TLV[1].type = kSE05x_I2CM_Read;

　　TLV[1].cmd.rd.readLength = readLength;

　　TLV[1].cmd.rd.rdBuf = readbuf;

　　status = Se05x_i2c_master_txn(&pCtx->session, &TLV[0], 3);

　　return status;

　　}

　　Listing 1: The NXP Plug & Trust middleware includes source code demonstrating the use of the ISO 7816-4 TLV format in host commands such as this basic read command to the NXP SE050 SE. (Code source: NXP)

　　As illustrated in Listing 1, the code uses a simple C structure to encode the TLVs for the configuration and read requests. Here, each TLV is instantiated using an SE05x_I2CM_cmd_t structure (Listing 2).

　　Copy

　　typedef struct _SE05x_I2CM_cmd

　　{

　　SE05x_I2CM_TLV_type_t type;

　　SE05x_I2CM_INS_type_t cmd;

　　} SE05x_I2CM_cmd_t;

　　typedef enum _SE05x_I2CM_TLV_type

　　{

　　kSE05x_I2CM_None = 0,

　　kSE05x_I2CM_Configure,

　　//kSE05x_I2CM_Security,

　　kSE05x_I2CM_Write = 3,

　　kSE05x_I2CM_Read,

　　kSE05x_I2CM_StructuralIssue = 0xFF

　　} SE05x_I2CM_TLV_type_t;

　　typedef union _SE05x_I2CM_INS_type {

　　SE05x_I2CM_configData_t cfg;

　　SE05x_I2CM_securityData_t sec;

　　SE05x_I2CM_writeData_t w;

　　SE05x_I2CM_readData_t rd;

　　SE05x_I2CM_structuralIssue_t issue;

　　} SE05x_I2CM_INS_type_t;

　　typedef struct _SE05x_I2CM_readData

　　{

　　uint16_t readLength;

　　SE05x_I2CM_status_t rdStatus;

　　/* Output. rdBuf will point to Host buffer */

　　uint8_t *rdBuf;

　　} SE05x_I2CM_readData_t;

　　Listing 2: The NXP Plug & Trust software distribution provides structures for defining the request type (green highlight) and associated command parameters (blue highlight). (Code source: NXP)

　　Within that SE05x_I2CM_cmd_t structure, the type member is defined by a C enum, SE05x_I2CM_TLV_type_t, which lists the possible values including the standard value 4 for a read request ADPU (kSE05x_I2CM_Read). The cmd member of the SE05x_I2CM_cmd_t structure is defined in a union of structures. In this case, the cmd member is an rd structure, which in turn comprises members that specify the length of requested data (readLength) and target buffer pointer (rdBuf).

　　This set of definitions abstracts to a few lines of code to set the TLV[1] instance type member in Listing 1 to indicate a read request (kSE05x_I2CM_Read) and set the cmd member to the desired readLength and readBuf buffer pointer.

　　Development support

　　To simplify software development, NXP abstracts host interactions with the SE050 SE through its Plug & Trust middleware and associated library application programming interfaces (APIs) (Figure 6). The NXP Plug & Trust middleware distribution package combines middleware and APIs with a set of sample applications built on mbed TLS, OpenSSL, and other packages. In addition, a Python based command line interface (CLI) allows developers to use SE050 features in an interactive mode.

Figure 6: Along with sample software, the NXP Plug & Trust software package includes middleware and associated APIs that abstract the details of interactions with the SE050 through the ISO 7816-based stack, which comprises the APDU application layer, T=1 over I2C data link layer, and I2C physical layer. (Image source: NXP)

　　Along with the NXP Plug & Trust software, developers can quickly evaluate the SE050 using the OM-SE050ARD development kit, which combines an SE050 SE and simple support circuitry with multiple headers. Along with connectors for an external I2C interface and direct access to SE050 pins, the OM-SE050ARD board includes an Arduino-R3 header. Using the Arduino-R3 header, developers can easily attach the OM-SE050ARD board to a number of development boards, including the NXP I.MX 6ULTRALITE evaluation board and the NXP FRDM-K64F evaluation board.

　　Using the supported evaluation boards, developers can quickly explore specific use cases for security either programmatically through the Plug & Trust software samples or interactively through the Python-based CLI. Among the sample applications in the Plug & Trust software distribution, sample software illustrates the complete process for reading sensor data through the SE050 I2C master interface. Developers can quickly rebuild this sample application to replace conventional I2C reads with attestation reads. The use of attestation reads requires no changes to the TLV setup shown in Listing 1. In fact, the changes largely involve replacing the I2C read function, Se05x_i2c_master_txn(), shown in Listing 1 with the attested read version, Se05x_i2c_master_attst_txn(), along with its associated function parameters.

　　Other sample applications demonstrate the final step in edge-to-cloud security – authentication and secure communications with cloud services. Among the Plug & Trust software samples, developers can find step-by-step instructions for using the SE050 to provide authentication and secure connections to public cloud services including Microsoft Azure, IBM Watson, Amazon Web Services (AWS), and Google Cloud Platform (GCP). The majority of effort involved in these cloud connection samples lies in creating an account on the respective cloud service and uploading keys and certificates (also provided in the sample routines). The SE050 SE handles the heavy lifting that developers typically need to implement to ensure secure cloud connectivity.

　　Using the NXP Plug & Trust software stack in combination with NXP development boards, developers can quickly take full advantage of the SE050 SE’s comprehensive support for edge-to-cloud security for IoT devices.

　　Conclusion

　　Poorly secured IoT devices threaten to expose large volumes of confidential data and can become entry points to other attached resources. Developers need to build IoT designs on a secure foundation that extends from the device to the cloud and supports the complete IoT device lifecycle. As shown, this can be accomplished by augmenting designs with the SE050 from NXP. Using this SE, developers can meet emerging requirements for more effective security stretching from the edge to the cloud.