Secure Element Arrays in Internet of Things Systems

Abstract

To provide a method for transmitting data using a collision-tolerant full-duplex communication protocol via a half-duplex connection.SOLUTION: A method includes the steps of: terminating a data receiving mode of a first device that transmits data; the first device transmitting a data frame via a half-duplex connection for reception by a second device; the first device monitoring for an acknowledgment from the second device; determining that the acknowledgment includes a cyclic redundancy check value and that the data frame needs to be re-transmitted; identifying a device role of the first device; and retransmitting the data frame at a time corresponding to the identification of the device role.SELECTED DRAWING: Figure 6

Description

[Technical Field]

[0001] This specification relates generally, but not exclusively, to Internet-of-things (IoT) systems, and particularly, but not exclusively, to a transparent architecture for IoT systems. [Background technology]

[0002] Internet of Things (IoT) systems often include edge devices that contain various sensors or other methods of collecting and communicating data. Some of these edge devices may not have direct network connectivity or may otherwise be resource-constrained. In addition, these edge devices are often required to store key material and perform secure processing. However, edge devices in IoT systems often lack processing resources and security capabilities, and their physical locations may not be conducive to storing key material. These edge devices may also implement software that requires periodic updates. Due to limited network connectivity for some of these edge devices, this may require a technician to access each individual edge device each time a software update is needed. This can be time- and resource-consuming in systems with many edge devices. Summary of the Invention

[0003] The present invention provides a system and method for providing secure execution of system functions for edge devices, a non-transitory computer-readable medium, and a physical access control system, as recited in the claims. [Brief explanation of the drawings]

[0004] In the drawings, which are not necessarily drawn to scale, like reference numbers may describe like components in different views. Like reference numbers with different suffixes may represent different instances of like components. Some embodiments are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings. [Figure 1] FIG. 1 illustrates an exemplary physical access control system. [Figure 2] FIG. 1 is a block diagram illustrating an example Internet of Things (IoT) architecture including an array of secure elements. [Figure 3] FIG. 1 is a block diagram illustrating an exemplary secure IoT gateway. [Figure 4A] 1 illustrates an exemplary workflow for authenticating an array of secure elements by a controller. [Figure 4B] 10 illustrates an exemplary workflow for authenticating a policy and / or controller by a sister board of a secure element. [Figures 5A-5C] FIG. 2 illustrates an exemplary transmission frame for a full-duplex protocol for use in a half-duplex system. [Figure 6] 1 is a flowchart illustrating an exemplary method for transmitting messaging over a half-duplex communication line using a full-duplex protocol. [Figure 7] FIG. 1 is a block diagram illustrating an example of a machine in which one or more embodiments may be implemented. DETAILED DESCRIPTION OF THE INVENTION

[0005] Disclosed herein are systems and methods for implementing a transparent architecture for Internet of Things (IoT) systems using an array of secure elements. An exemplary IoT architecture includes a gateway equipped with a built-in or connectable array of secure elements. The secure elements include hardware and / or software for performing cryptographic functions or processes, such as encryption, decryption, signature generation, signature verification, and / or key generation. The secure elements are contained within an explicitly defined perimeter that establishes the physical boundary of the cryptographic module and includes any processors and / or other hardware components that store and protect any software and firmware components of the cryptographic module. The secure elements can take the form of (or include) a secure crypto processor, a smart card, a secure digital (SD) card, a microSD card, a SIM card, and / or any other cryptographic module.

[0006] A secure element (SE) is a tamper-resistant platform capable of securely hosting multiple applications and their secret and cryptographic data, in accordance with the rules and security requirements established by a set of duly identified trusted authorities. An SE can be thought of as a chip that provides a dynamic environment for securely storing data, securely processing data, and securely communicating with external entities.

[0007] Physical access control systems (PACS) include readers (edge ​​devices) and controllers (intermediate servers / devices). In traditional PACS systems, readers are smart devices that host and run software for securely communicating with cards or mobile phones that come within the reader's communication range. A successful PACS system focuses on both user experience and security. Therefore, reader devices must have sufficient processing power to address both latency issues and hardware- and software-based security primitives. Reader devices have support for authenticating and reading data from a wide range of card devices with different protocols (both at the transport and application levels) and with different data modalities. This results in a lot of software implemented by the reader device that must be updated to support new card modalities, bug fixes, and so on. Because reader devices often lack network connectivity, the reader device must be physically accessed by a technician to perform these updates. Furthermore, this results in a secure element physically located on the reader that stores secure software and key material. Some readers may be physically located, for example, in exterior portions of a building, which may raise security concerns for businesses, authentication entities, or other users of PACS systems that may desire or require that substantially all secure storage of keys be physically located within a secure perimeter, such as the perimeter of a building.

[0008] To improve the above situation, an array of secure elements separate from the reader may be used to run security and application software for the reader device. The array of secure elements may be integrated with or attached to the PACS controller and configured to handle multiple parallel requests and connections to multiple edge devices (readers). The PACS controller may have a network connection to one or more remote devices that can store and provide software or firmware updates for the secure elements. In this way, the secure elements can be updated without a technician having to access each individual edge device (reader). The PACS controller may also be physically located within a building or other secure perimeter, eliminating security concerns about having multiple secure elements located on several readers.

[0009] In one example, an array of secure elements may be located on a sister board that may connect to a host device using one or more buses having bus protocols such as serial peripheral interface (SPI), inter-integrated circuit (I2C), universal serial bus (USB), etc. The secure element may be used for several functions. For example, the secure element may operate as a crypto-processor that provides security algorithms and secure storage of sensitive key material. In another example, the secure element may be used as an application platform that runs application-specific software along with storing security algorithms and key material. For example, in a PACS system, the secure element may be used to perform authentication of users who present authentication credentials to a PACS reader. In this way, software functionality to perform user authentication is not required in the reader device itself.

[0010] Figure 1 illustrates an exemplary scenario 100 in which a PACS may be used. As shown in Figure 1, a wall 102 has a door 104 disposed therein. In the exemplary situation, a secured area is behind the door 104, and the door has a lockable handle 106 that allows access to the secured area when in an unlocked state and prevents access to the secured area when in a locked state.

[0011] The reader device 108 is positioned proximate to the handle 106 of the door 104. In one example, the handle 106 is locked by default. The reader system 108 is operable to selectively place the handle 106 in an unlocked state in response to presentation of approved authentication credentials contained in a credential device 112 capable of communicating with the reader device 108 via a wireless interface 110. In various examples, the credential device 112 may be a key card, a fob, a mobile device (e.g., a smartphone), or any other suitable credential device having communication capabilities and authentication credentials.

[0012] In conventional systems, application software for authenticating a user may be implemented on the reader device 108 itself. For example, a user presents a credential device 112 that communicates with the reader device 108 and provides authentication credentials to the reader device 108. The reader device 108 then uses the received authentication credentials to securely authenticate the user and unlock the handle 106. In other conventional examples, some of this functionality is included in the reader device 108 and some in a remotely located PACS controller. For example, the reader device may perform a secure transaction with the credential device 112 and then send the data to the PACS controller to authenticate the user. The controller may then communicate to unlock the handle 106.

[0013] Because the reader device 108 performs secure transactions and / or authentication, software or firmware updates may be required for the reader device 108. In some examples, the reader device 108 does not include a network connection and is only connected to the PACS controller via a single wired connection, such as an RS-485 or other connection. This requires a technician to physically travel to the reader device 108 to update the software or firmware of each reader device 108 in the PACS system. It may be desirable to move some of this functionality off the reader for ease of maintenance while still providing the user with the same or a better user experience as the reader device 108.

[0014] To accomplish this, an array of secure elements may be implemented in a PACS controller, with each secure element configured to implement secure software execution for an individual reader device 108. These PACS controllers often include one or more network connections to allow for remote updates of the software executed by the secure elements, eliminating the need for technicians to physically travel to each reader device 108. It should be understood that the present disclosure is applicable to many types of IoT systems in addition to PACS systems. The system 100 shown in FIG. 1 is presented merely as an example and not as a limitation.

[0015] FIG. 2 illustrates an IoT system 200. The system 200 includes multiple edge device clusters 210 and a secure IoT gateway (SIG) 220. Each of the multiple edge device clusters 210 may include one or more edge devices 230, such as the reader device 108 of FIG. 1 . The SIG 220 may communicate with a remote source 240 over a local area network or a wide area network 280, such as the Internet. The SIG 220 may include a controller 250 and a sister board 260 that includes multiple secure elements 270. In one example, the controller 250 may be a PACS controller. While illustrated as two clusters 210 of five edge devices 230 each and four secure elements 270, any number of clusters 210 with any number of edge devices 230 and any number of secure elements 270 may be implemented for the system 200. Although shown as separate controller 250 and sister board 260, in some examples, multiple secure elements 270 may be integrated with controller 250. Controller 250 may be connected to communicate with sister board 260 using any bus protocol, such as SPI, I2C, USB, etc.

[0016] The SIG 220 is connected via a network connection 280 to communicate with remote source(s) 240 and via individual connections 290 to communicate with individual edge devices 230. For example, the connection 280 may be a local area network connection or a wide area network connection such as an Internet connection. The individual connections 290 may be wired or wireless connections such as Ethernet, Wi-Fi, USB, RS-485, etc. Although illustrated as a single connection 290 for each cluster 210, a connection 290 may be provided for each individual edge device 230. The remote source 240 may be one or more servers or other computing devices and may store firmware files or other software updates for multiple secure elements 270. In some examples, the SIG 220 communicates with the remote source 240 to obtain firmware files or other software updates to update one or more secure elements 270 implemented by the SIG 220.

[0017] In a PACS system such as that shown in FIG. 1 , the reader device 108 may be an edge device 230 connected to communicate with a controller 250, such as a PACS controller. The connection 290 may be a wired full-duplex connection, a wired half-duplex connection such as an RS-485 connection, or any other connection. The secure element 270 may be configured to execute software that performs functions using application-specific hardware for the reader 108. For example, when a user approaches the reader device 108 and presents authentication credentials using the credential device 112, the secure element 270 may be assigned to the transaction to perform security algorithms, secure storage of confidential key material, and user authentication. In some examples, the reader device 108 may only obtain authentication credentials from the credential device 112 and provide the authentication credentials to the controller, and the secure element 270 performs all of the application-specific functions to authenticate the user and unlock the door handle 106. In other examples, some of the application-specific functions may be performed by the reader device 108 and some by the secure element 270.

[0018] When a user approaches the reader device 108, or when the reader device 108 receives the user's authentication credentials, the controller 250 or other electronic circuitry may select and assign a secure element 270 for use with the reader device 108. This may be any secure element 270 that is currently available to the running software for the reader device 108.

[0019] In one example, each edge device 230 may dynamically receive a reference to a secure element 270 that the individual edge device 230 is assigned for an individual session. For example, when an edge device 230 requires a secure element 270, the controller 250 may identify an available secure element 270 that can provide the necessary functionality for the individual edge device 230. The controller 250 may also be implemented as a "dispatcher," responsible for dispatching messages or data to individual secure elements 270, shielding the array of secure elements from the individual edge devices 230. This allows for a high level of modularity in code development and management, while protecting against the crash or termination of the edge device 230 or other actors in the system.

[0020] Other devices or circuitry for monitoring the lifecycle of edge device 230 or secure element 270 and implementing policies, for example, to either regenerate an individual device or keep the device in a terminated state and notify a system administrator, may also be implemented in system 200. In other examples, one or more of edge device 230, controller 250, or secure element 270 may monitor the lifecycle of multiple devices in the system, which may be used in cleaning up or resetting the individual states of multiple devices in the system.

[0021] In some cases, it may be desirable to implement applications and key material on an edge device that is not accessible by the remote device 240 or other entities. For example, in a PACS system, an entity may want to program the controller 250 or the secure element 270 with a particular authentication code that is not accessible by other entities, such as via the remote device 240. To enable this, the secure element 270 may be configured so that the secure element 270 is programmable in a high-level language. In some examples, even if the secure element 270 is a resource-constrained device, a runtime capable of running a language runtime for the secure element 270 may be implemented. Thus, an entity can develop an application and install the application on the secure element 270.

[0022] In the above scenario, it may be desirable to restrict who can install these applications on the secure element 270. In one example, applications installed on the secure element 270 must be signed by an entity, and then a higher-level or other entity double-signs the application with a corresponding key. If the application is double-signed, one or more of the secure elements 270 or the embedded secure element of the controller 250 may allow the application to be installed on an individual secure element 270. This allows entities to independently develop applications and load them onto the secure element 270. In some examples, a virtual firewall may also be implemented by the secure element 270 to prevent applications installed by the secure element 270 from interfering with each other.

[0023] 3 is a block diagram illustrating an example implementation of SIG 220. Gateway 220 includes control circuitry 300, a processing element 310, and one or more secure elements 320, which may be secure element 270 of FIG. 2. In some cases, gateway 220 includes four secure elements 320. Each secure element 320 of gateway 220 may be configured to perform the same function. In some implementations, secure element 320 is implemented (in both hardware and software) to provide a higher level of security assurance than a typical general-purpose microprocessor. In some implementations, secure element 320 is implemented as a general-purpose microprocessor without providing a higher level of security assurance.

[0024] The control circuitry 300 and processing elements 310 may be configured to implement an allocation protocol for assigning secure elements 320 to individual edge devices 230. The control circuitry 300 and processing elements 310 may be implemented by the controller 250 and / or on a sister board 260. To enable the use of secure elements 320 with edge devices 230, the edge devices 230, secure elements 320, protocols, etc. may be implemented as actors that manage their own state and communicate only with other actors in the system using intra-process messaging. These actors maintain the configuration state of their individual devices and dynamically receive references to the secure elements 320 they have assigned to a given session. Similarly, actors may connect / register with actors with which they can communicate using the desired transport and application protocols.

[0025] The control circuitry 300 and / or processing elements 310 may execute software acting as a dispatcher actor responsible for dispatching messages / data to the appropriate associated secure elements 320, thereby shielding the entire array of secure elements 320 from, for example, an actor representing an edge device 230. The use of actors and inter-process messaging allows for a high level of modularity in code development and maintenance, superior performance due to zero overhead in inter-component interactions because the components are all part of the same process, and protection from malfunctioning of any component. Typically, a failure or bug in a software component of a process leads to a crash of the entire process. The actor model allows the system to contain failures within individual actors, thereby protecting the process from failure. This mechanism ultimately provides near-100% uptime and resilience from misbehaving components / actors in the process.

[0026] The remote source 240 may provide updates for the secure element 320 via the network connection 280. For example, the firmware of the first secure element 320 may be updated via a security enclave, such as a trusted execution environment, implemented by the processing element 310. In such cases, the security enclave may execute applications that utilize cryptographic support and provide isolation from the overall computing environment. In some implementations, the security enclave implemented by the processing element 310 contains symmetric or asymmetric key material used by the security enclave to communicate with another device. The cryptographic processes and techniques used by the security enclave to communicate with multiple devices differ from the cryptographic processes implemented by the multiple secure elements of the gateway 220.

[0027] The number of secure elements 320 may be less than the number of edge devices 230 serviced by the secure element 320. This may be advantageous when not all edge devices 230 are expected to be active at the same time. Furthermore, this facilitates the ability to interleave requests to a single secure element. In some examples, a single secure element actor may be associated with two edge device actors. Even if the two edge device actors are active at the same time, the two edge device actors may be in different communication phases. Requests from each edge device actor may be interleaved to a single secure element actor. For example, a transaction may include several command-response pairs between an edge device and a secure element. By the time the secure element returns a response to a particular command from the first edge device, the controller may have received a different command from the second edge device. In this situation, interleaving communications from the two edge devices allows for efficient use of a single secure element.

[0028] In instances where the secure element 320 is located on a sister board that is physically separable from the controller 250, it may be desirable to authenticate the sister board when it is plugged into or otherwise connected to the controller 250. To accomplish this, the controller 250 may include an additional secure element that is embedded in the controller 250 and has the functionality to both authenticate the array of secure elements 320 and verify policy compatibility with individual controllers 250. In another embodiment, rather than including an embedded secure element on the controller 250, a secure enclave provided by a microprocessor may be used.

[0029] FIG. 4A shows an exemplary workflow for authenticating an array of secure elements 320 by the controller 250. In one example, the enclave or embedded secure element of the controller 250 includes an asymmetric key pair along with a signed root digital certificate. Having the signed digital certificate allows the enclave or embedded secure element in the controller 250 to send a random number to the secure array of secure elements. The secure elements 320 in the array then return the signed random number along with the certificate used by the secure elements 320. Note that each secure element in the array has a different certificate and key, but all certificates have the same parent (root) certificate. The enclave or embedded secure element in the controller 250 then verifies the signature of the random number and verifies the certificate of the secure element 320. This process, which is similar to a public key infrastructure (PKI), can be used by the controller 250 to authenticate the secure elements 320. This process may be performed when a sister board is connected to the controller and then performed again, or alternatively, at random intervals, for example to protect against vulnerabilities caused by man-in-the-middle attacks.

[0030] While the above process only verifies the authenticity of the sister board, it may also be desirable for the sister board to authenticate the controller 250 and / or system policy. FIG. 4B shows an example workflow for authenticating a policy and / or the controller 250 by a sister board of the secure element 320. The policy may be authenticated with the assistance of one or more remote devices 240. An enclave secure element or an embedded secure element in the controller 250 can authenticate with the remote device 240 and obtain a signed cryptogram unique to that controller 250. This signed cryptogram is then transmitted to the array of secure elements 320 in the sister board. Only if the signature is correct will the secure element 320 function. In some examples, the secure element may also include the functionality to parse the policy and only provide some functionality to the controller 250 based on the parsed policy.

[0031] Some PACS systems are connected using a full-duplex connection to communicate between the reader and the PACS controller. However, in some conventional systems, communication between the secure element 320 and the edge device 230 uses a half-duplex connection 290. In these systems, it is desirable to implement a full-duplex communication protocol over the legacy half-duplex connection to ensure a desired user experience. For example, some conventional PACS systems may include an RS-485 connection over the connection 290. In these conventional systems, one of the reader or controller acts as the primary communicator, and the other acts as the secondary communicator. To facilitate communication between the edge device 230 and the secure element 320, a full-duplex protocol may be implemented over the half-duplex connection so that all devices can act as primary communicators.

[0032] The full-duplex protocol can be designed to allow its use on common universal asynchronous receiver-transmitter (UART) hardware present in modern microcontrollers without requiring hardware modifications to existing devices. Along with resolving data collisions, this protocol helps mitigate data corruption that can occur due to noisy or otherwise poor-quality RS-485 lines. This protocol is intended to be used in conjunction with higher-level protocols without imposing significant restrictions on them. In the open systems interconnection (OSI) model, the protocol can be implemented at the data link layer. All data sent by the sender is acknowledged by the receiver. If the appropriate acknowledgement is not received in time by the sender, the protocol incorporates a collision resolution algorithm that results in successful data delivery, as described with respect to FIG. 6.

[0033] 5A-5C are diagrams illustrating exemplary data frame formats for a full-duplex protocol for use in a half-duplex system. FIG. 5A shows a data frame 500 used to communicate data over a half-duplex connection. Data frame 500 is shown as including 37 bytes, but may include any number of bytes. Data frame 500 includes an option byte (FIG. 5B), a data payload, and a 4-byte cyclic redundancy check (CRC). Although illustrated as 32 bytes, data frame 500 may be configured to have a data payload of any size. The CRC may be used to detect errors in the transmission of the data in data frame 500.

[0034] FIG. 5B shows an example options field 510 for a data frame 500. The options field 510 includes an error indicator bit, six reserved for future use (RFU) bits, and a toggle bit. The RFU bit may be assigned for any purpose. The error indicator is a single bit that indicates an error in the transmission protocol. If set to 0, the frame transfers data. If set to 1, the frame indicates that a critical error has occurred on a device, such as the edge device 230, and other devices, such as the controller 250, need to act accordingly. The error indication may be used in addition to error detection at a higher level than the protocol implementation. The toggle bit is used when transmitting a data frame and is toggled for each successive frame. The toggle bit is used to distinguish between two successive frames with the same data and a retransmission of a single frame.

[0035] 5C shows an exemplary acknowledgment frame 520 provided by a receiver when a data frame is successfully received from a sender. In this example, the acknowledgment frame includes a CRC field that is a copy of the CRC field of data frame 500. While shown using a CRC for acknowledgment frame 520, any data may be used for the acknowledgment that allows the sender to verify with reasonable certainty that data frame 500 was received by the receiver. For example, any bit pattern that associates an acknowledgment with data frame 500 and that is large enough and random enough so that the probability of random noise or a corrupted frame being identified as a valid acknowledgment is very small.

[0036] When implementing a communication protocol, two different roles may be statically assigned to two devices as role "A" and role "B." For example, the controller 250 may be assigned role "A," and the edge device 230 may be assigned role "B." The baud rate, the number of stop bits used, and the bit order may be agreed upon in advance between the devices. An estimated time unit (ETU) value for the protocol may also be defined. The ETU value may generally be selected to be greater than the time required to transmit a data frame 500 and receive an acknowledgment frame 520 with some additional margin. For example, a value of 5 milliseconds may be used for a baud rate of 115,200 bits per second (bps).

[0037] FIG. 6 is a flowchart illustrating a method 600 for transmitting data according to a full-duplex protocol over a half-duplex connection. When transmitting a data frame 500, a device must wait until the line is idle. Once the line is idle, the data frame is transmitted with a specified number of bytes. When receiving a frame, the specified number of bytes is received, and then the device waits for a period of time until the line is idle. When idle, both nodes are in receive mode (step 602) and waiting to receive data. Once received, the CRC of the received data frame 500 is checked. If the CRC is incorrect, the node begins receiving another data frame. If the CRC is correct, the node sends a corresponding acknowledgement and begins receiving another data frame. When a new data frame is received, the CRC of the frame is checked to see if it is equal to the CRC of the last received frame. If they match, the frame is considered a duplicate and is not reported to upper layers. An acknowledgement is also sent for duplicate frames.

[0038] When transmitting the data frame 500, the device stops receive mode in step 604. In step 606, the data frame 500 is transmitted using the specified number of bytes. Following transmission of the data frame 500, the device waits until an acknowledgment is received (step 608) or the ETU expires (step 610). If the ETU expires before receiving an acknowledgment, the method 600 proceeds to step 614. If the acknowledgment is successfully received, the method 600 proceeds to step 612 and checks the CRC of the acknowledgment frame 520. If the CRC does not match that of the transmitted data frame 500, the method 600 proceeds to step 614. If the CRC matches, the data frame 500 is successfully transmitted, the method returns to step 602, and the device re-enters receive mode. In step 614, the role of the device is checked. If the device is a role "A" device, the method 600 proceeds to step 606 and retransmits the data frame 500. If the device is a role "B" device, the device proceeds to step 616 and enters receive mode for two ETUs to minimize collisions on the line, then returns to step 606 to retransmit data frame 500. Method 600 provides a full-duplex protocol with collision resolution for use on a half-duplex line.

[0039] FIG. 7 shows a block diagram of an example machine 700 on which any one or more of the techniques (e.g., methods) described herein may be executed. For example, the machine 700 may be any one or more of the edge device 230, the controller 250, or the secure element 270. Examples may include or operate by a logical component or components or mechanisms within the machine 700 as described herein. Circuitry (e.g., processing circuitry) is a collection of circuitry embodied in a tangible entity of the machine 700, including hardware (e.g., simple circuits, gates, logic, etc.). Elements of the circuitry may flexibly change over time. The circuitry includes components that, when operational, may perform specified operations, either alone or in combination. In one example, the hardware of the circuitry may be invariably designed (e.g., hardwired, etc.) to perform specific operations. In one example, the hardware of a circuit configuration may include variably connected physical components (e.g., execution units, transistors, simple circuits, etc.) that include machine-readable media that have been physically modified (e.g., magnetically, electrically, movable arrangements of immutable mass particles, etc.) to encode instructions for a particular operation. When connecting the physical components, the underlying electrical properties of the hardware configuration change, for example, from an insulator to a conductor (or vice versa). The instructions enable embedded hardware (e.g., execution units or loading mechanisms) to create elements of the circuit configuration within the hardware through the variable connections to perform some of the particular operations when in operation. Thus, in one example, the machine-readable media elements are part of the circuit configuration or are communicatively connected to other components of the circuit configuration when the device is operating. In one example, any of the physical components may be used in two or more elements of two or more circuit configurations. For example, during operation, an execution unit may be used in a first circuit of a first circuit configuration at one time and reused by a second circuit of the first circuit configuration or used by a third circuit of the second circuit configuration at a different time. Additional examples of these components for machine 700 are provided below.

[0040] In alternative embodiments, machine 700 may operate as a standalone device or may be connected (e.g., networked) to other machines. In a networked configuration, machine 700 may operate as a server machine, a client machine, or both in a server-client network environment. In one example, machine 700 may operate as a peer machine in a peer-to-peer (P2P) (or other distributed) network environment. Machine 700 may be a personal computer (PC), tablet PC, set-top box (STB), personal digital assistant (PDA), mobile phone, web appliance, network router, switch, or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify operations to be performed by that machine. Furthermore, while only a single machine is illustrated, the term “machine” should be interpreted to include any collection of machines individually or collectively executing a set (or sets) of instructions to perform any one or more of the methodologies described herein, such as cloud computing, software as a service (SaaS), other computer cluster configurations, etc.

[0041] The machine (e.g., computer system) 700 may include a hardware processor 702 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), a main memory 704, a static memory 706 (e.g., memory or storage for firmware, microcode, basic input / output (BIOS), unified extensible firmware interface (UEFI), etc.), and mass storage 708 (e.g., a hard drive, tape drive, flash storage, or other block device), some or all of which may communicate with each other via an interlink (e.g., bus) 730. The machine 700 may further include a display unit 710, an alphanumeric input device 712 (e.g., a keyboard), and a user interface (UI) navigation device 714 (e.g., a mouse). In one example, the display unit 710, the input device 712, and the UI navigation device 714 may be touchscreen displays. The machine 700 may further include a storage device 708 (e.g., a drive unit), a signal generation device 718 (e.g., a speaker), a network interface device 720, one or more sensors 716, such as a global positioning system (GPS) sensor, a compass, an accelerometer, or other sensor. The machine 700 may include an output controller 728, such as a serial (e.g., universal serial bus (USB)), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection, for communicating with or controlling one or more peripheral devices (e.g., a printer, a card reader, etc.).

[0042] The registers of processor 702, main memory 704, static memory 706, or mass storage 708 may be or include machine-readable medium 722 on which one or more sets of data structures or instructions 724 (e.g., software) that embody or are utilized by any one or more of the techniques or functions described herein are stored. The instructions 724 may also reside, completely or at least partially, within any of the registers of processor 702, main memory 704, static memory 706, or mass storage 708 during their execution by machine 700. In one example, one or any combination of hardware processor 702, main memory 704, static memory 706, or mass storage 708 may constitute machine-readable medium 722. Although machine-readable medium 722 is illustrated as a single medium, the term “machine-readable medium” may include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) configured to store one or more instructions 724.

[0043] The term "machine-readable medium" may include any medium capable of storing, encoding, or carrying instructions for execution by machine 700 and causing machine 700 to perform any one or more of the techniques of this disclosure, or storing, encoding, or carrying data structures used by or associated with such instructions. Non-limiting examples of machine-readable media may include solid-state memory, optical media, magnetic media, and signals (e.g., radio frequency signals, other photon-based signals, audio signals, etc.). In one example, a non-transitory machine-readable medium includes a machine-readable medium having a plurality of particles with an unchanging (e.g., resting) mass and is thus a composition of matter. Thus, a non-transitory machine-readable medium is a machine-readable medium that does not include a transitory, propagating signal. Examples of non-transitory machine-readable media may include non-volatile memory such as semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)) and flash memory devices, magnetic disks such as internal hard disks and removable disks, magneto-optical disks, and CD-ROM and DVD-ROM disks.

[0044] The instructions 724 may further be transmitted or received over a communications network 726 using a transmission medium via a network interface device 720 utilizing any one of several transport protocols (e.g., frame relay, Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP), etc.). Exemplary communications networks may include local area networks (LANs), wide area networks (WANs), packet data networks (e.g., the Internet), mobile phone networks (e.g., cellular networks), plain old telephone (POTS) networks, and wireless data networks (e.g., the Institute of Electrical and Electronics Engineers (IEEE) 802.11 family of standards known as Wi-Fi), the IEEE 802.16.4 family of standards, peer-to-peer (P2P) networks, among others. In one example, the network interface device 720 may include one or more physical jacks (e.g., Ethernet, coaxial, or telephone jacks) or one or more antennas for connecting to the communications network 726. In one example, network interface device 720 may include multiple antennas for wireless communication using at least one of single-input multiple-output (SIMO), multiple-input multiple-output (MIMO), or multiple-input single-output (MISO) techniques. The term "transmission medium" is intended to include any intangible medium capable of storing, encoding, or carrying instructions for execution by machine 700, as well as digital or analog communication signals or other intangible media for enabling the communication of such software. Transmission media are machine-readable media.

[0045] The above description includes references to the accompanying drawings, which form a part of the detailed description. The drawings show, for illustrative purposes, specific embodiments in which the invention may be practiced. These embodiments are also referred to herein as "examples." Such examples may include elements in addition to those shown or described. However, the inventors also contemplate examples in which only the elements shown or described are provided. Furthermore, the inventors also contemplate examples that use any combination or permutation of the elements shown or described (or one or more aspects thereof) with respect to a particular example (or one or more aspects thereof), or with respect to other examples (or one or more aspects thereof) shown or described herein.

[0046] As used herein, the term "or" is used to mean non-exclusive unless otherwise indicated; or "A or B" includes "B but not A," "A but not B," and "A and B." The Abstract is provided to enable the reader to quickly ascertain the contents of the technical disclosure. It is provided with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Also, in the above Detailed Description, various features may be grouped together to streamline the disclosure. This should not be construed as intending that an unclaimed disclosed feature is essential to any claim. Rather, inventive subject matter may reside in fewer than all features of a particular disclosed embodiment. Accordingly, the appended aspects are incorporated into the Detailed Description herein as examples or embodiments, with each aspect standing on its own as a separate embodiment, and it is contemplated that such embodiments can be combined with each other in various combinations or permutations. The scope of the present invention should be determined with reference to the appended aspects, along with the full range of equivalents to which such aspects are entitled.

Claims

1. 1. A system for providing secure execution of system functions for an edge device, comprising: a controller configured to connect for communication with a plurality of edge devices, each edge device configured to obtain data for an application of the system, the controller being further configured to receive the data from each of the plurality of edge devices; an array of secure elements connectable to the controller, the array of secure elements configured to perform a function using the data received from the plurality of edge devices; the controller is configured to authenticate the array of secure elements and associate identified secure elements of the array of secure elements with the individual edge devices to perform the functions on the data received from the individual edge devices of the plurality of edge devices; the controller is configured to communicate results of the executed functions to the individual edge devices; The system, wherein the array of secure elements is configured to authenticate the controller by verifying a signed cryptogram received from the controller.

2. 10. The system of claim 1, wherein the controller is configured to connect for communication with each of the plurality of edge devices via a connection comprising Ethernet, Wi-Fi, RS-485, or Universal Serial Bus (USB).

3. The system of claim 2 , wherein the system is a physical access control system and the plurality of edge devices are readers physically co-located with physical access devices.

4. The system of claim 1 , wherein a total number of the plurality of edge devices is greater than a total number of the secure elements.

5. the controller is configured to associate at least two of the plurality of edge devices with a single secure element of the array of secure elements; The system of claim 4 , wherein the single secure element is configured to alternate communications from at least two of the plurality of edge devices.

6. 6. The system of claim 1, wherein the array of secure elements is located on a sister board, the sister board physically connecting to the controller and communicating with the controller via one or more bus protocols.

7. 7. The system of claim 6, wherein the controller is configured to verify the authenticity of the sister board using at least one certificate signed by each secure element in the array of secure elements.

8. The system of claim 6 , wherein the array of secure elements is configured to authenticate the controller when the sister board is connected to the controller.

9. 8. The system of claim 7, wherein the controller is further configured to authenticate the array of secure elements by sending a generated code to each secure element and receiving a signed generated code along with a certificate associated with each secure element.

10. The system of claim 7 , wherein a certificate associated with each secure element in the array of secure elements is unique to the secure element.

11. The system of claim 10 , wherein the certificate associated with each secure element shares a common parent certificate with other secure elements in the array of secure elements.

12. 10. The system of claim 1, wherein the secure element is programmable to perform a custom function, and wherein a plurality of secure elements of the array of secure elements are configured to verify the authenticity of the custom function to enable installation and execution of the custom function.

13. The system of claim 1 , further comprising the plurality of edge devices.

14. The system of claim 1 , wherein the controller is further configured to receive a signed cryptogram from a remote device that has authenticated the controller.

15. The system of claim 14 , wherein the controller is further configured to authenticate with the remote device via an embedded secure element within the controller.

16. 15. The system of claim 14, wherein the controller is further configured to authenticate with the remote device via a security enclave or trusted execution environment implemented by a processor within the controller.

17. 17. The system of claim 16, wherein the security enclave communicates with the remote device using different symmetric or asymmetric key material than that used by the array of secure elements.

18. 10. The system of claim 1, wherein the array of secure elements is further configured to authenticate the controller by verifying a cryptographic signature of a policy cryptogram received from the controller via one or more remote sources that manage policy.

19. 20. The system of claim 18, wherein the array of secure elements is further configured to parse the policy and enable a portion of functionality of the array of secure elements based on the parsed policy.

20. The system of claim 1 , wherein the controller is further configured to authenticate the array of secure elements at random intervals after connection.

21. 1. A method for providing secure execution of functions for a plurality of edge devices in an Internet of Things (IoT) system, comprising: a controller of the IoT system receiving data from each edge device of the plurality of edge devices of the IoT system; the controller authenticating an array of secure elements; the array of secure elements connected to the controller authenticating the controller by verifying a signed cryptogram received from the controller; associating an identified secure element of the array of secure elements connected to the controller with the respective edge device; providing the received data to the identified secure element, the secure element using the data to perform a function; and communicating via the controller to the respective edge device a result of the function performed by the identified secure element.

22. 22. The method of claim 21, wherein the IoT system is a physical access control system and the plurality of edge devices are readers physically co-located with physical access devices.

23. 22. The method of claim 21, wherein the controller is connected to communicate with the individual edge devices using an RS-485, Ethernet, Wi-Fi, or Universal Serial Bus (USB) connection.

24. the total number of the edge devices is greater than the total number of the secure elements, the controller is configured to associate at least two of the plurality of edge devices with a single secure element of the array of secure elements; 24. The method of any one of claims 21 to 23, wherein the single secure element is configured to alternate communications from at least two of the plurality of edge devices.

25. 22. The method of claim 21, wherein the array of secure elements is located on a sister board, the sister board physically connecting to the controller and communicating with the controller via one or more bus protocols.

26. 26. The method of claim 25, further comprising the controller verifying the authenticity of the sister board using at least one certificate signed by each secure element in the array of secure elements.

27. 27. The method of claim 26, wherein the array of secure elements is authenticated by the controller by sending a generated code from the controller to each secure element, and the controller receiving the signed generated code along with a certificate associated with each secure element.

28. 27. The method of claim 26, wherein a certificate associated with each secure element in the array of secure elements is unique to the secure element.

29. 30. The method of claim 28, wherein the certificate associated with each secure element shares a common parent certificate with other secure elements in the array of secure elements.

30. 22. The method of claim 21, further comprising a remote device authenticating the controller, wherein the signed cryptogram is transmitted from the remote device to the controller.

31. The method of claim 30, wherein the controller authenticates with the remote device via an embedded secure element within the controller.

32. 31. The method of claim 30, wherein the controller authenticates with the remote device via a security enclave or trusted execution environment implemented by a processor within the controller.

33. 33. The method of claim 32, wherein the security enclave communicates with the remote device using different symmetric or asymmetric key material than that used by the array of secure elements.

34. 22. The method of claim 21, wherein the array of secure elements authenticates the controller by verifying a cryptographic signature of a policy cryptogram received from the controller via one or more remote sources that manage policy.

35. 35. The method of claim 34, further comprising the step of the array of secure elements analyzing the policy and enabling a portion of functionality of the array of secure elements based on the analyzed policy.

36. 22. The method of claim 21, wherein the controller authenticates the array of secure elements at random intervals after connection.

37. 1. A computer-readable storage medium comprising executable program code that, when executed by one or more processors, causes the one or more processors to: authenticating to a remote device to receive a signed cryptogram; authenticating to an array of secure elements by transmitting the signed ciphertext to the array of secure elements; authenticating the array of secure elements by transmitting a generated code to the array of secure elements and receiving the signed generated code together with a certificate associated with each secure element; receiving data from an individual edge device of a plurality of edge devices of an IoT system; associating an identified secure element of the array of secure elements with the respective edge device; providing the received data to the identified secure element, the secure element using the data to perform a function; and communicating to the respective edge device a result of the function performed by the identified secure element.

38. the executable program code further causes the one or more processors to associate at least two of the plurality of edge devices with a single secure element of the array of secure elements; 38. The computer-readable storage medium of claim 37, wherein the single secure element is configured to alternate communications from at least two of the plurality of edge devices.

39. 1. A physical access control system comprising: a controller configured to connect to each of a plurality of readers and receive authentication credentials from each of the plurality of readers, each of the plurality of readers being arranged to communicate with and receive individual authentication credentials from a credential device to control access to individual secured areas using the individual authentication credentials; an array of secure elements configured to perform user authentication using the authentication credentials received from the plurality of readers; the controller is configured to authenticate the array of secure elements and associate identified secure elements of the array of secure elements with individual readers of the plurality of readers to perform user authentication using the authentication credentials received from the individual readers; the controller is connected to communicate the result of the user authentication to the individual reader; 1. A physical access control system, wherein the array of secure elements is configured to authenticate the controller by verifying a signed cryptogram received from the controller.

40. 40. The physical access control system of claim 39, further comprising said plurality of readers.

41. 40. The physical access control system of claim 39, wherein the controller is configured to connect for communication with each of the plurality of readers via a connection comprising Ethernet, Wi-Fi, RS-485, or Universal Serial Bus (USB).

42. 42. A physical access control system according to any one of claims 39 to 41, wherein the total number of the plurality of readers is greater than the total number of the secure elements.

43. the controller is configured to associate at least two of the plurality of readers with a single secure element of the array of secure elements; 43. The physical access control system of claim 42, wherein the single secure element is configured to alternate communications from at least two of the multiple readers.

44. 40. The physical access control system of claim 39, wherein the controller is further configured to authenticate the array of secure elements by sending a generated code to each secure element and receiving a signed generated code along with a certificate associated with each secure element.

45. 45. The physical access control system of claim 44, wherein a certificate associated with each secure element in the array of secure elements may be unique to the secure element.

46. 46. ​​The physical access control system of claim 45, wherein the certificate associated with each secure element shares a common parent certificate with other secure elements in the array of secure elements.

47. 40. The physical access control system of claim 39, wherein the controller is further configured to receive signed cryptograms from a remote device that has authenticated the controller.

48. 48. The physical access control system of claim 47, wherein the controller is further configured to authenticate with the remote device via an embedded secure element within the controller.

49. 48. The physical access control system of claim 47, wherein the controller is further configured to authenticate with the remote device via a security enclave or trusted execution environment implemented by a processor within the controller.

50. 50. The physical access control system of claim 49, wherein the security enclave communicates with the remote device using different symmetric or asymmetric key material than that used by the array of secure elements.

51. 40. The physical access control system of claim 39, wherein the array of secure elements is further configured to authenticate the controller by verifying a cryptographic signature of a policy cryptogram received from the controller via one or more remote sources that manage policy.

52. 52. The physical access control system of claim 51, wherein the array of secure elements is further configured to analyze the policy and enable a portion of functionality of the array of secure elements based on the analyzed policy.

53. 53. The physical access control system of claim 52, wherein the controller is further configured to authenticate the array of secure elements upon connection and at random intervals thereafter.

Images