WO2019161285A1

WO2019161285A1 - Devices and systems for industrial internet of things security

Info

Publication number: WO2019161285A1
Application number: PCT/US2019/018328
Authority: WO
Inventors: Stephen K. MANSFIELD
Original assignee: Webasto Ncharging Systems, Inc.
Priority date: 2018-02-15
Filing date: 2019-02-15
Publication date: 2019-08-22

Abstract

Systems and methods including: generating, by an edge device (110), a secure temporal token (STT) (500); sending, by the edge device, a request to an edge server (140), where the request includes the generated STT and a serial number (206) of the edge device; retrieving, by the edge server, an edge device secret key (208) from a pair cache (214), where the pair cache includes the edge device serial number and the corresponding edge device secret key; decrypting, by the edge server, the STT via the edge device secret key; verifying, by the edge server, the edge device; and providing, by the edge server, access to the edge server by the edge device if the edge device is verified.

Description

DEVICES AND SYSTEMS FOR INDUSTRIAL INTERNET OF THINGS SECURITY

CROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims the priority benefit of U.S. Provisional Patent Application Serial Number 62/631,443 filed February 15, 2018, incorporated herein by reference in its entirety.

FIELD OF ENDEAVOR

[0002] The present embodiments relate to supply chain management. In particular, the present embodiments relate to securing data in supply chains.

BACKGROUND

[0003] Corporations, governments, and utilities have embraced a more robust form of Internet of Things (IoT) called Industrial Internet of Things (IloT). IloT has seen dramatic growth in the last five years. Government agencies use IloT for traffic management, street light management, and public safety surveillance. Electric and water utilities use IloT for automated meter readers. The Manufacturing industry uses IloT to more efficiently manage production, supply chain, warehouse operations, and transportation.

[0004] IloT offers many benefits over existing technology solutions. Wireless connected IloT devices enable simple integration without the cost of new and expensive wired infrastructures. Cloud computing centric IloT management enables rapid scalability and reliability without software complexity. Integrated mobile wireless applications enable innovative solutions that make simultaneous management of hundreds, thousands, or even millions of devices quite simple from a mobile phone.

SUMMARY

[0005] The various embodiments of the present devices, methods, and systems have several features, no single one of which is solely responsible for their desirable attributes. Without limiting the scope of the present embodiments as expressed by the claims that follow, their more prominent features now will be discussed briefly. After considering this discussion, and particularly after reading the section entitled“Detailed Description,” one will understand how the features of the present embodiments provide the advantages described herein. [0006] One aspect of the present embodiments include a method for secure communication between a server and edge device comprising establishing a secure key at the edge device, and initiating a secure communication channel between the server and edge device where the communication channel utilizes the established secure key and a temporal token.

[0007] In another embodiment, the temporal token further comprises a tenant name, an edge serial number, an authorization role, an STT creation date and time, and a nonce.

[0008] A method embodiment may include: generating, by an edge device comprising a processor and addressable memory, a secure temporal token (STT); sending, by the edge device, a request to an edge server comprising a processor and addressable memory, where the request comprises the generated STT and a serial number of the edge device; retrieving, by the edge server, an edge device secret key from a pair cache, where the pair cache comprises the edge device serial number and the corresponding edge device secret key; decrypting, by the edge server, the STT via the edge device secret key; verifying, by the edge server, the edge device via at least one of: the edge serial number of the decrypted STT matching the edge device serial number, a timestamp of the decrypted STT matching a temporal period, and an authorization role of the decrypted STT matching a security role assigned to the edge device; and providing, by the edge server, access to the edge server by the edge device if the edge device is verified.

[0009] In additional method embodiments, the STT may include: a tenant name, the edge device serial number, the security role assigned to the edge device, the timestamp, and a nonce. In additional method embodiments, the tenant name may be an owner of the edge device. Additional method embodiments may further include: providing, by the edge server, access to a tenant database of the edge server corresponding to the owner of the edge device by the verified edge device. In additional method embodiments, the nonce may be at least one of: a 98-byte long hexadecimal string and a random 49-byte hexadecimal number. The STT length may be at least 256 bytes.

[0010] In additional method embodiments, verifying the authorization role of the decrypted STT may further include: storing, by the edge server, the security role assigned to the edge device; and verifying that the authorization role is equal to or less than the stored security role of the edge device. In additional method embodiments, the security role of the edge device may be at least one of: no edge server access allowed, write data access only to the edge server, read and write data access to the edge server, enable one or more features of the edge device at the edge server, disable one or more features of the edge device at the edge server, and update a profile of the edge device at the edge server.

[0011] In additional method embodiments, verifying the edge device may further include: matching the edge serial number of the decrypted STT to the edge device serial number; matching the timestamp of the decrypted STT to the temporal period; and matching the authorization role of the decrypted STT to the security role assigned to the edge device. Additional method embodiments may include: denying, by the edge server, access to the edge server by the edge device if the edge device verification fails.

[0012] Additional method embodiments may include, prior to retrieving the edge device secret key from the pair cache: requesting, by the edge server, the edge device secret key from a secure data edge manufacturer server comprising a processor and addressable memory, where the request comprises the edge device serial number; validating, by the secure data edge manufacturer server, an authority of the edge server to access the edge device secret key; receiving, by the edge server, the edge device secret key corresponding to the edge device serial number; and storing, by the edge server, the edge device serial number and the corresponding edge device secret key in the pair cache.

[0013] Additional method embodiments may include, prior to retrieving the edge device secret key from the pair cache: capturing, by a camera of a user device having a processor with addressable memory, an encrypted optical label disposed on the edge device, where the encrypted optical label may be encrypted by a public key of the edge server; sending, by the user device, the captured encrypted optical label to the edge server; decrypting, by the edge server, the encrypted optical label via a private key of the edge server, where the decrypted optical label may include the edge device serial number and the corresponding edge device secret key; and storing, by the edge server, the edge device serial number and the corresponding edge device secret key in the pair cache.

[0014] Additional method embodiments may include, prior to retrieving the edge device secret key from the pair cache: enabling, by the edge device, a secure learning mode; programming, by a user device having a processor with addressable memory in communication with the user device, the edge device secret key into the user device; sending, by the user device, the edge device serial number and the corresponding edge device secret key to the edge server; and storing, by the edge server, the edge device serial number and the corresponding edge device secret key in the pair cache.

[0015] Additional method embodiments may include: prior to retrieving the edge device secret key from the pair cache: enabling, by the edge device, a secure learning mode; programming, by a user device having a processor with addressable memory in communication with the user device, the edge device secret key into the user device; storing, by the user device, the edge device serial number and the corresponding edge device secret key in a secure cache of the user device; connecting the user device to the edge server; and uploading the edge device serial number and the corresponding edge device secret key stored in the secure cache of the user device to the pair cache of the edge server.

[0016] A system embodiment may include: an edge device (110) having a processor and addressable memory, where the edge device processor may be configured to: generate a secure temporal token (STT); and generate a request comprising the generated STT and a serial number of the edge device; an edge server having a processor and addressable memory, where the edge server processor may be configured to: receive the generated request from the edge device; retrieve an edge device secret key from a pair cache, where the pair cache may include the edge device serial number and the corresponding edge device secret key; decrypt the STT via the edge device secret key; verify the edge device via at least one of: the edge serial number of the decrypted STT matching the edge device serial number, a timestamp of the decrypted STT matching a temporal period, and an authorization role of the decrypted STT matching a security role assigned to the edge device; and provide access to the edge server by the edge device if the edge device is verified.

[0017] Additional system embodiments may include: a secure data edge manufacturer server having a processor and addressable memory, where the secure data edge manufacturer server processor may be configured to: receive a request from the edge server for the edge device secret key, where the request may include the edge device serial number; validate an authority of the edge server to access the edge device secret key; and send the edge device secret key corresponding to the edge device serial number to the edge server.

[0018] Additional system embodiments may include: an encrypted optical label disposed on the edge device, where the encrypted optical label may be encrypted by a public key of the edge server; a user device having a processor with addressable memory; a camera in communication with the user device processor; where the user device processor may be configured to: receive an image of the encrypted optical label from the camera; and send the image of the encrypted optical label to the edge server; where the edge server processor may be further configured to: decrypt the encrypted optical label via a private key of the edge server, where the decrypted optical label may include the edge device serial number and the corresponding edge device secret key; and store the edge device serial number and the corresponding edge device secret key in the pair cache. [0019] Additional system embodiments may include: a user device having a processor with addressable memory, where the user device processor may be configured to: program the edge device secret key into the user device; and send the edge device serial number and the corresponding edge device secret key to the edge server.

[0020] Additional system embodiments may include: a user device having a processor with addressable memory, where the user device processor may be configured to: program the edge device secret key into the user device; store the edge device serial number and the corresponding edge device secret key in a secure cache of the user device; and upload the edge device serial number and the corresponding edge device secret key stored in the secure cache of the user device to the pair cache of the edge server.

[0021] Another method embodiment may include: generating, by an edge device having a processor and addressable memory, a client random number (CRN); sending, by the edge device, the CRN and an edge device encryption capability to an edge server having a processor and addressable memory; sending, by the edge server, a server random number and an edge server encryption ability to the edge device; sending, by the edge server a digital certificate and a public key of the edge server to the edge device; validating, by the edge device, a signature on the digital certificate via the public key of the edge server; sending, by the edge device, an encrypted hash of all messages to the edge server, where the encryption may be based on the public key of the edge server; verifying, by the edge server, the encrypted hash, where the encrypted hash is decrypted with a private key of the edge server; generating, by the edge device, a pre-message secret (PMS); sending, by the edge device, the PMS encrypted with the public key of the edge server to the edge server; generating, by the edge device, a master key session by multiplying the CRN, SRN, and PMS; generating, by the edge server, a master key session by multiplying the CRN, SRN, and PMS; sending, by the edge device, a message to change to an encrypted connected with the master key session to the edge server; generating, by the edge device, a secure temporal token (STT); sending, by the edge device, a request to the edge server, where the request may include the generated STT and a serial number of the edge device; retrieving, by the edge server, an edge device secret key from a pair cache, where the pair cache may include the edge device serial number and the corresponding edge device secret key; decrypting, by the edge server, the STT via the edge device secret key; verifying, by the edge server, the edge device via at least one of: the edge serial number of the decrypted STT matching the edge device serial number, a timestamp of the decrypted STT matching a temporal period, and an authorization role of the decrypted STT matching a security role assigned to the edge device; and providing, by the edge server, access to the edge server by the edge device if the edge device is verified.

BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The various embodiments of the present ultrasonic audio for device setup now will be discussed in detail with an emphasis on highlighting the advantageous features. These embodiments depict the novel and non-obvious ultrasonic audio for device setup shown in the accompanying drawings, which are for illustrative purposes only. These drawings include the following figures, in which like numerals indicate like parts:

[0023] FIG. 1 is a conceptual illustration of a fleet data edge topology in accordance with an embodiment of the invention;

[0024] FIG. 2 is a conceptual diagram of a fleet edge security architecture in accordance with an embodiment of the invention;

[0025] FIG. 3 is a conceptual timing diagram of an edge security sequence in accordance with an embodiment of the invention;

[0026] FIG. 4 is a conceptual timing diagram of a secure temporal template handshake in accordance with an embodiment of the invention;

[0027] FIG. 5 is a high-level diagram of a secure temporal token format in accordance with an embodiment of the invention;

[0028] FIG. 6 is an illustration of authorization access rules in accordance with an embodiment of the invention;

[0029] FIG. 7 depicts a high-level flowchart of a method embodiment of an edge security sequence in accordance with an embodiment of the invention;

[0030] FIG. 8 illustrates an example top-level functional block diagram of a computing device embodiment;

[0031] FIG. 9 shows a high-level block diagram and process of a computing system for implementing an embodiment of the system and process;

[0032] FIG. 10 shows a block diagram and process of an exemplary system in which an embodiment may be implemented; and

[0033] FIG. 11 depicts a cloud-computing environment for implementing an embodiment of the system and process disclosed herein. DETAILED DESCRIPTION

[0034] The following detailed description describes the present embodiments with reference to the drawings. In the drawings, reference numbers label elements of the present embodiments. These reference numbers are reproduced below in connection with the discussion of the corresponding drawing features.

[0035] IloT technology is often at the center of managing mission-critical process operations or data sensing. IloT devices are often found in less secure environments and may be wirelessly connected to a large cloud-based system. An example would be a wirelessly connected bar code scanner on an outside loading dock. Such environments make them very susceptible to hacking and security breaches. Mission-critical applications require strong security as one of the key system design objectives.

[0036] In many embodiments, the disclosed system and method can help companies better manage their Material Handling Equipment (MHE), Ground Support Equipment (GSE) and Material Support Robots (MSR). The disclosed system and method may help manufacturers better manage operations, material movement, fleet truck utilization, and/or optimal energy utilization. The disclosed system and method, in some embodiments, can be called the“Fleet Management Edge” where sensors may be installed directly on MHE, GSE, and/or MSR trucks. In a number of embodiments, sensors may collect information about material handling, loading, speed, location, safe operation, equipment health, and/or truck energy state. In a variety of embodiments, the sensors may be connected to a device, sometimes called a“Fleet Data Edge” device. The fleet data edge device may collect information from the sensors and may abstract the data into a standardized message format. In numerous embodiments, messages may be securely sent via wireless and/or cellular networks to the Internet and/or to a central data collection cloud server. In additional embodiments, the server may be called a“Fleet Edge Server”, and may collect information to a secure database. In still more embodiments, the database may be accessed by third-party software.

[0037] The present application describes a lightweight security architecture that can enable highly secure data exchanges between fleet edge servers and remote data edge devices. The pillars of a secure digital system are privacy, authentication, and authorization. In many embodiments, the disclosed architecture can fulfill each of these requirements through security protocols and private key management. In accordance with a number of embodiments of the invention, it may also balance the needs of low cost hardware with relatively low performance microprocessors and encryption facilities and security. The embodiments disclosed herein discuss security architecture that provides an excellent balance of security and encryption technology within the capabilities of most Edge, IloT, and/or IoT devices.

[0038] With reference to FIG. 1, the present embodiments depict a fleet data edge topology in accordance with an embodiment of the invention. In a number of embodiments, the fleet data edge system 100 can be a small, self-contained high-performance computing, communications, and sensor data collection platform. In a variety of embodiments, the fleet data edge system 100 may include a series of data edge devices 110 that are each in communication with a series of sensors 115. In certain embodiments, the data edge devices 110 may be a complete data capture device configured to be installed on a vehicle or other device where data is desired. The data edge devices 110 may be fixedly or detachably attached to the vehicle or other device where data is desired. In further embodiments, the vehicle may be a piece of material handling equipment (MHE) or a piece of ground support equipment (GSE). In still further embodiments, the fleet data edge system 100 may have a series of data edge devices 110 installed on forklifts 120, other warehouse devices, and/or chargers 125. In yet still further embodiments, the data edge device 110 may be installed on emerging technology warehouse robots that support a multitude of warehouse data sensors.

[0039] In additional embodiments, the data edge devices 110 communicate with a network including, but not limited to, the Internet 130. In still additional embodiments, this communication can include, but is not limited to, wirelessly via Wi-Fi 135, via Bluetooth, hard-wired via a hardware connection to another Internet-enabled device, and/or to another local edge device for later transmission. In yet additional embodiments, once the data has been transferred, it can then be transmitted to another Internet-enabled device via Wi-Fi 136, or to one or more cloud-based data management servers 140. In more additional embodiments, the cloud-based data management server 140 can communicate with one or more third-party applications 150 and/or one or more databases 145. The one or more third- party applications 150 may be a third-party server having a processor with addressable memory, an application programming interface (API), or the like. The database 145 may be stored internally on the cloud-based data management server 140 or externally on another server or through a third-party service. In still more additional embodiments, the cloud-based data management server 140 may be located on site with the data edge devices 110 or in the cloud at an external site. In further additional embodiments, the fleet data edge system 100 may provide a simple and standardized way to collect truck data, store it in the cloud and make it available to Warehouse Management Software (WMS) and Warehouse Analytics Software (WAS). WMS and WAS applications may be utilized to control, optimize and determine the most efficient operations of the fleet.

[0040] One of the key technology components of many of the embodiments of the fleet data edge system 100 is a new and innovative security solution. In a still further number of embodiments, the edge security technology may be integrated into the fleet data edge device 110 and provide a secure encrypted, authenticated, and authorized connection between the fleet data edge device 110 and fleet edge server 140. In various embodiments, the data edge security technology may utilize a number of IT technology standards. By way of example and not limitation, these may include HTTPS/TLS to support encryption, X.509 certificates to authenticate the server and an innovative Secure Temporal Token to assert secure authentication an authorization of the fleet data edge device 110. When integrated as a system, these security solutions create a very strong security not seen in IloT solutions. Although many embodiments are focused on fleet truck management, it should be understood by those skilled in the art that these embodiments can be integrated into any IoT/IIoT device.

[0041] While a variety of fleet data edge systems are described above with reference to FIG. 1, the specific configurations and communication channels of fleet data edge systems are largely dependent upon the requirements of specific applications. For example, it can be appreciated by those skilled in the art that an edge data device may utilize a number of methods to communicate with the network including transmitting signals on internal device buses or network streams. Additionally, the types of sensors 115 utilized by the data edge device 110 can be any suitable sensor that can transmit quantifiable and recordable data. A discussion of client/server security is below.

[0042] With reference to FIG. 2, the present embodiments depict a fleet edge security architecture in accordance with an embodiment of the invention. As highlighted earlier, most IloT devices lack adequate security or have virtually no security at all. The rapid introduction of IoT devices has in most cases outpaced important standards considerations including security. Many existing security standards require significant processing power, memory, and management of secure keys. All of these technologies tend to drive requirements that are orthogonal for small, low cost, and/or low powered existing IoT devices. Emerging security requirement must also assume physical, wireless, and internet- based surface attacks.

[0043] In many embodiments of this invention, security architecture proposals utilize several industry standard technologies for data encryption; including X.509, PKI, and TLS. X.509 describes digital certificates, the certificate content, creation, and the concept of trust and a Certificate Authority. X.509 also defines the management of certificates. Digital certificates are central to all modern encryption and authentication schemes and provide a public means of exchanging encryption keys and authentication. Public key infrastructure describes several algorithms that allow for public/private keys used in asymmetric encryption. PKI algorithms have two keys: a public and private key. Data is encrypted with the public key and decrypted with the private key. The private key is a secret key that is never exposed. The public key is publicly available in the form of Digital Certificates. The public/private keys allow for easy management of secure keys. The use of public/private asymmetric encryption keys is central to all modem encryption and authentication schemes and allow for secure transmission of encrypted data. TLS, or Transport Layer Security is an encryption standard that defines what encryption algorithms and how data packets in the IP frame are encrypted. TLS uses both symmetric and asymmetric encryption. Symmetric encryption is desirable over asymmetric encryption. Symmetric encryption is computationally simple and very fast. However, it does require special handling of the key to ensure secrecy. Asymmetric encryption requires significant computational resources and is slower. However, key management is simple and very secure. Most modem encryption methods use asynchronous encryption to first exchange a symmetric key. Thereafter, all encryption may be done use symmetric encryption. A new random symmetric key may be generated for each session providing even more robust security. Triple DES, AES, AES256, and RSA are common encryption algorithms for TLS. However, AES or AES256 and RSA are generally recommended. An older version of IP encryption called SSL (Secure Socket Layer) security is considered obsolete. SSL and TLS are often used interchangeably in publications but virtually all IP security is presently done with TLS.

[0044] In accordance with many embodiments of the invention, fleet edge IoT security architecture 200 is a combination of existing industry standard security technology integrated with a simple yet innovative and secure method for sharing and exchanging private keys. In further embodiments, the security architecture can enable low cost IoT/IIoT devices the capability to securely encrypt data, authenticate the IoT devices, and provide role-based authorization access to cloud-based services. Thus, the combination of technologies and methods can allow for very robust security for IloT devices.

[0045] In a number of embodiments, the data edge IloT security system and method uses a combination of TLS security and dynamic temporal secure tokens. TLS is used to establish a secure encrypted exchange of data. In certain embodiments, each data edge client may create a unique dynamic Secure Temporal Token (STT) to authenticate and authorize access to the fleet edge server. The STT is encrypted with a unique private key. In many embodiments, the information contained in each token enables the server to authenticate and authorize access to the edge server resources. The token may also have security measures to reduce or eliminate“Packet Insertion” and“Man in the Middle” hacking attacks. In certain embodiments, there may also be a special protocol for the handling of secret keys making the fleet data edge device very secure.

[0046] In further embodiments, the first phase of the data edge security architecture 200 is to utilize the unique edge serial number 206 and private AES key 208 of the fleet data edge 110 device. In still further embodiments, the serial number 206 is assigned at the time of edge device manufacture and is a 12 byte ASCII number, while the secret AES key 208 is also assigned by the manufacturer and is a random 256-bit key. In a large number of embodiments, all data edge devices 110 can have a private key 208 that is recognized by the edge server 140. In still more embodiments, the private AES key management is a unique feature of this security architecture 200. The fleet data edge serial number 206 can be used to uniquely identify each fleet edge device 110. In additional embodiments, the private AES key 208 is unique to each fleet edge device 110 and is used to encrypt secure tokens. In still additional embodiments, the public key is provided by the fleet edge server 140 and is common for all devices that communicate with the fleet edge server 140.

[0047] In still yet further embodiments, fleet data edge devices 110 are defined as clients in a client/server architecture, and the fleet edge server 140 has an Application Programming Interface (API) and is a portal for services. In further embodiments, the fleet edge device 110 can request services through this interface, and in fact, all fleet edge IloT data/services requests can pass through this API. In certain embodiments, each time the fleet edge device 110 requests a service it may use an internet protocol called TCP/IP to communicate to the server API. In certain additional embodiments, the fleet edge device 110 may make a request to access the server over the network, and a TCP/IP session is set up between the server 140 and fleet edge device 110 to handle the request. When the session is established the fleet edge device 110 and server 140 can exchange data. In more embodiments, once the request is completed, successfully or unsuccessfully, the session can be shut down and communication between the server and Edge device terminated.

[0048] In a number of embodiments, data edge private AES key management is a central security component of the security architecture. All IloT devices must have at least one secret in order to create a secure token, as shown in FIG. 5. The difficulty with secret keys is that they cannot be accessed by any external means otherwise they would be easily compromised. Since the server 140 has no way of reading the secret key 208 there is no direct way to obtain the secret key 208 from the edge device 110. It is electronically and physically hidden. In accordance with various embodiments of the invention, the data edge secure architecture can describe four different methods that can be used by the IoT server 140 to obtain a secret AES key. These include, but are not limited to: secure AES key servers, encrypted secure key optical labels, IoT key injection, and/or cached IoT key injection.

[0049] In additional embodiments, the data edge security architecture 200 can define a secure data edge manufacturer server 210 made available by the data edge manufacturer. In certain additional embodiments, when the edge device 110 is installed it instantly tries to communicate with the edge server 140. In still additional embodiments, the first time a HTTPS packet is received the edge server 140 would check the serial number key/value pair. In yet additional embodiments, if there are no serial numbers cached, the edge server 140 may establish a secure, mutually authenticated session with the edge manufacturer’s server 210. In still yet additional embodiments, the manufacturer’s server 210 may validate that the edge server 140 has the authority to access the edge device key/value pair stored in a key/value pair database 212, which allows the edge server 140 to then use the serial number to obtain the secret AES key 208. In many additional embodiments, the edge server 140 can then cache 214 the serial number key/value AES key 208 in its secure storage. In many embodiments, the edge server 140 does not allow any external access of the secret key 208. In various embodiments at this point, the edge server 140 can now have the edge secret key 208 and can validate the secure token sent by the fleet data edge 110 device. In certain further embodiments, caching 214 the secret key 208 as a serial number/key pair may speed up authentication after the first attempt. The benefit of this method is that the secret key can easily be obtained from the manufacturer via the data edge manufacturer server 210. Bookkeeping may be required on the part of the manufacturer and the edge server owner. The manufacturer must keep records of the serial number/key value pair. The manufacturer and the edge server owner must also establish a secure server session, such as via using Oauth2 secure token exchange. Oauth2 is a very fast and secure way of letting two servers exchange data.

[0050] A potential bookkeeping-less alternative is to use an encrypted optical label 216, such as a matrix barcode, two-dimensional barcode, or a quick response (QR) Coded Optical Label. In additional embodiments, the manufacturer would create a QR coded optical label encrypted by the edge server’s 140 public key 218. In further additional embodiments, data encrypted in the optical label 216 may include the data edge serial number 206 and its secret AES key 208 as well as other information. In still further additional embodiments, the optical label 216 may be printed and/or laser etched directly on the data edge 110 device or shipping container. In a variety of embodiments, an installation technician using a user device 224 such as a smartphone, tablet, or the like and webpage and/or application 220 installed and/or running on the user device 224 could optically scan the encrypted optical label 216 and send it to the edge server 140. Finally, in numerous embodiments, the edge server 140 may then decrypt the optical label 216 with its x.509 private key and save the serial number/key value pair in its secure cache 214. This method does not require any bookkeeping by the manufacturer and is relatively simple to manage. The edge server’s public key 218 is public and is easily obtained. The manufacturer can use the public key 218 with easily obtained industry standard encryption algorithms to generate the optical label 216. The optical label 216 may be an industry standard with readily available open source optical scanning software. Additionally, the data edge development company can supply a smartphone application and/or web interface to capture the optical label 216 code and forward it to the edge server 140.

[0051] In further embodiments, during installation of the fleet data edge device 110 a user or technician could place the edge device 110 in a secure learning mode. In still further embodiments, the technician could then use a user device 224 such as a smartphone, tablet, or the like and an application 220 or web interface to program a random secure AES key 208 into the IoT device 110 using Bluetooth or another communication protocol as a communications tether. In yet further embodiments, the smart application 220 could then securely send the serial number/ AES key 208 to the edge server 140, which would then save the Serial Number/AES key 208 in a secure cache 214. In still yet further embodiments, the smart application 220 or web interface may be password protected and/or may be unique to the installer so no one could tamper with the device 110 before it is paired with the server 140. This method requires no additional security effort by the manufacturer. However, it does necessitate the installation technician to have a user device 224 such as smartphone, tablet, or the like with a smart application or web interface and a camera 222. In some embodiments, the user device 224 may have a sensor to read a non-optical secret key 208 of the data edge device 110. The technician may also need a user ID/password to access the edge server 140 to save the secret AES key 208.

[0052] Cached edge key injection is similar to edge key injection except the keys may be temporarily cached in the user device 224 application 220 or web interface. In additional embodiments, the edge serial number/key value pair may be later uploaded into the edge applications server for situations where there is no viable Internet service available for the user device 224. In a number of embodiments, the user device 224 may be a thumb drive, such as a USB drive, to deliver the serial number/key value pair to the edge server 140.

[0053] Each of these methods provides a secure way to program a secure and private AES key 208 into the edge device 140. Each however, requires some effort on the edge server 140, edge manufacturer server 210, or the edge installation team to secure the secret AES key 208. These methods disclosed herein provide a reasonable amount of security to get the AES key 208 into the edge device 140 and a serial number/key value pair to the edge server’s cache 214.

[0054] With reference to FIG. 3, the present embodiments depict a timing diagram of an edge security sequence in accordance with an embodiment of the invention. In many embodiments, during the initial TCP/IP session both the fleet data edge device and server use a standard TLS handshake protocol, setting up a unique one-time session key to enable secure symmetric encryption of data. The timing diagram 300 shows a sequence diagram of the TLS handshake between a fleet edge server 140 and a data edge client 110.

[0055] In additional embodiments, the fleet data edge 110 device first generates a client random number (CRN) 310 and sends it in the clear along with its encryption capability. In still additional embodiments, the fleet edge server 140 generates its own server random number (SRN) 320 and sends it in the clear to the client along with its encryption capabilities. In yet additional embodiments, the fleet edge server 140 may then send 330 the client 110 a digital certificate along with its public key. In still yet additional embodiments, the fleet edge client 110 can use the public key to validate 340 the signature on the server’s digital certificate. In more additional embodiments, the client 110 may then create a hash of all the messages, encrypt them with the server’s public key and send them to the fleet edge server 140. In still more additional embodiments, the fleet edge server 140 can decrypt the hash with its private key and verify the exchange and eliminate any“Man in the Middle” attacks. In yet more additional embodiments, the client 110 generates one more random number called the“pre-message secret” (PMS) 350, and encrypts it with the server’s public key before forwarding it to the server. In certain additional embodiments, both the client 110 and the server 140 multiply the CRN, SRN, and PMS and generate a master session key (MKey). In many embodiments, the client and server now have a valid session key and the TLS encryption handshake can be ended 360. From this point on both the fleet edge server and the fleet edge device may use this symmetric key to encrypt all data. [0056] With reference to FIG. 4, the present embodiments depict a timing diagram of a secure temporal template handshake 400 in accordance with an embodiment of the invention. In a number of embodiments, once the TLS handshake has been completed, the Secure Temporal Template handshake sequence can begin. This sequence is outside the TLS handshake procedure and is proprietary to the data edge security system disclosed herein. The SST handshake can leverage several secure methods for management of the secret AES key.

[0057] In a variety of embodiments, the fleet edge server 140 may retrieve the fleet data edge client 110 serial number from the TCP/IP header and check to see if the address has been previously cached 410 via an edge manufacturer server 402. In further embodiments, when it has not been previously cached, the server requests 420 from the manufacturer 402 of the fleet edge device 110 the unique private AES key it programmed into the fleet edge device 110. In still further embodiments, if the fleet edge serial number does not exist in the manufacturer’s secure server 402, the fleet edge server 140 can reject the device 110 request and terminate the TCP/IP session. In yet further embodiments, once the server 140 successfully obtains the fleet edge serial number/private key pair from the manufacturer’s server 402 it caches 430 the key/value pair database as well as the device’s authorization role, which can be provided by the manufacturer or by fleet edge server security policy. In still yet further embodiments, the assignment can represent the authorization to access certain server services granted to the fleet edge device 110. In further embodiments, during the setup of the TCP/IP session the data edge IloT device 110 may create a unique Secure Temporal Token (STT). In still yet further embodiments, the token can include, but is not limited to, the tenant name, serial number, authorization role and nonce. An example embodiment of such a format of the STT is depicted in FIG. 4. In further additional embodiments, this information may be initialized by an installation technician when the fleet data edge device 110 is installed, such as on a truck. In still further additional embodiments, the data can be initialized by using a Bluetooth connected smartphone with an edge installation application installed. In certain additional embodiments, the edge device 110 can encrypt the token using its secret key and insert it into each TCP/IP header request as well as the serial number, which is unencrypted.

[0058] In numerous embodiments, when the TCP/IP Session is set up, the server 140 can retrieve the secret key of the fleet edge device 110 using the serial number from the header as the key. In certain embodiments, the server 140 may use the secret AES key from its cache and decrypt the token. In additional embodiments, the fleet edge server 140 can compare the STT serial number with the header serial number, and if they match then the first part of the authentication is completed. In more additional embodiments, the fleet edge server 140 can verify that the timestamp is within the proper temporal period 440. In a number of embodiments, the STT can be verified if it is within the proper temporal period, allowing the fleet data edge device to be authenticated by the fleet edge server. In still additional embodiments, if either of these steps fails, the server 140 may not allow server access and terminate the TCP/IP session. In yet additional embodiments, the server 140 may retrieve the device’s authorization role and determines if the services requested are within the security role assigned to the edge device 110. In still certain embodiments, the services requested are within the security role assigned to the fleet edge device 110, the device 110 can access the services and data of the edge server 450, and if not, the server 140 does not allow access and the TCP/IP session is terminated.

[0059] Validation of the token is a critical part of the overall security scheme. In a number of embodiments, each fleet edge device 110 can have a unique private AES key, and uses the key to encrypt the token. Since AES keys are unique, only a fleet edge authorized device 110 may be in possession of this unique key. Validation of the token serial number assures that the fleet edge device 110 is“authentic”. Validation of the temporal period assures that TCP/IP frame sent is not a“replay attack”. Likewise, the injection of the nonce can help deter packet injection by “Man in the Middle” attacks. Finally, security authorization can make sure that that specific fleet edge device is“authorized” to access the service and data it is requesting.

[0060] With reference to FIG. 5, the present embodiments depict a high-level diagram of a secure temporal token format in accordance with an embodiment of the invention. The token 500 can include, but is not limited to, five components: an edge serial number 504, a tenant name 502, a Date/Time 508, an authorization role 506, and a nonce 510. In many embodiments, the format of the header can be in a JSON format. In a variety of embodiments, the edge serial number 504 used in the token 500 may be a hexadecimal string formatted representation of the serial number assigned by the manufacturer. In certain varieties of embodiments, the serial number 504 is a public number and can be made available in the IP header. In additional embodiments, the serial number 504 can be used to validate the uniqueness of the token 500. Validation of the correct serial number may represent that the secure token 500 is truly“authentic”. The tenant name 502 is the name of the owner of the device. In certain additional embodiments, the tenant name 502 may be used to direct the edge data message to the correct secure tenant database. Thus, in many embodiments, the tenant name 502 can“assure” that the data is being directed to the correct database. In still additional embodiments, the Date/Time 508 can be a hexadecimal string format of Unix EPOC time (milliseconds), which may represent the value used, is the current EPOC time of the edge device the instant the token 500 is created. In more additional embodiments, the server can add a temporal period to the Date/Time 508, a value that may be called an EPOC temporal period. When the server receives the secure token 500 in the header it also obtains the current EPOC time. In further embodiments, if the edge server EPOC time is less than the EPOC temporal period, then the token 500 has not timed out and can still be considered valid. Validation of the EPOC temporal period can validate that “Packet Insertion” has not occurred. In still further embodiments, the authorization role 506 can be used to validate the correct data and services authorization of the fleet data edge device. In a number of embodiments, an authorization role 506 may also be saved in the server. In numerous embodiments, the STT authorization role 506 can only be equal to or less than the security role kept in the edge server. Likewise, in still many embodiments, if the authorization role 506 is greater, a security breach is suspected and the TCP/IP session may be terminated, providing for“strong secure authorization”. Finally, in yet further embodiments, a nonce 510 can be added to the end of the token 500. In certain further embodiments, the nonce 510 may be a hexadecimal string that is 98 bytes long. In still further embodiments, the nonce 510 string may be made up of a random 49-byte hexadecimal number. In other embodiments, the nonce 510 may be any random number. Ultimately, in a variety of embodiments, adding up all of the various string elements 502, 504, 506, 508, 510 yields a secure token 500 length of 256 bytes, which is long enough so that it will not be compromised by“random number injection” into the header. In some embodiments, the secure token 500 length may be at least 256 bytes and may be longer depending on the desired encryption level. The inclusion of a nonce 510 can provide for“strong encryption”. The length of the nonce 510 may be adjusted to a desired encryption level.

[0061] With reference to FIG. 6, the present embodiments depict authorization access rules in accordance with an embodiment of the invention. The final security component of the data edge is device authorization. In many embodiments, device authorization establishes a set of policies or roles for each edge device. In numerous embodiments, the role of the device can be set at the factory, by an installation technician or by the edge server. Authorization access rules hierarchies 600 can define what resources or data each device may have access to. [0062] In still many embodiments, when the device is installed in the network the role or authorization is set along with the serial number/key value pair. A typical authorization hierarchy 600 for a device can define what security roles the edge device has access to. It is proposed in still many embodiments of this architecture that the edge server API may manage the security access of each edge device. In further embodiments, the edge device requests services and the API allows or does not allow access based on its authorization role. By way of example and not limitation, devices with limited authorization would have very few services available to it, while other devices depending on their role could access more data or control devices. A further example would be an edge device that is only an Internet Access Point. It would have no access to the server resources. However, a much more important Edge device that controls load/tilt safety would have higher authorization. In a large number of embodiments, a key role for a device would be“No Server Access Allowed”, meaning that if a device has been tampered with it would instantly send out a“Tampered” alert to the server, which would then change the devices security role to“0” or no access. Thus, this tampered edge device could no longer access any server resources until inspected and reset by a technician. Alternatively, the edge device can be permanently taken off-line.

[0063] FIG. 7 depicts a high-level flowchart of a method embodiment 700 of an edge security sequence in accordance with an embodiment of the invention. The method 700 may include generating, by an edge device having a processor and addressable memory, a secure temporal token (STT) (step 702). The method may then include sending, by the edge device, a request to an edge server having a processor and addressable memory, where the request may include the generated STT and a serial number of the edge device (step 704).

[0064] The method may then include retrieving the edge device secret key (steps 706, 708, 710, 712). In some embodiments, the edge device secret key may be retrieved prior to the edge device generating the STT (step 702).

[0065] The method 700 may include retrieving the edge device secret key from a secure data edge manufacturer server (step 706). The edge server may request the edge device secret key from a secure data edge manufacturer server having a processor and addressable memory. The request may include the edge device serial number. The secure data edge manufacturer server may then validate an authority of the edge server to access the edge device secret key. The edge server may then receive the edge device secret key corresponding to the edge device serial number.

[0066] The method 700 may include retrieving the edge device secret key from an encrypted optical label on the edge device (step 708). A camera of a user device having a processor with addressable memory may be used to capture an encrypted optical label disposed on the edge device. The encrypted optical label may be encrypted by a public key of the edge server. The user device may send the captured encrypted optical label to the edge server. The edge server may decrypt the encrypted optical label via a private key of the edge server. The decrypted optical label may include the edge device serial number and the corresponding edge device secret key.

[0067] The method 700 may include programming the edge device secret key and sending the edge device secret key to the edge server (step 710). The edge device may enable a secure learning mode. A user device having a processor with addressable memory in communication with the user device may program the edge device secret key into the user device. The user device may then send the edge device serial number and the corresponding edge device secret key to the edge server.

[0068] The method 700 may include programming the edge device secret key, storing the secret key in a secure cache of a user device, and uploading the secret key to the edge server (step 712). This approach (step 712) may be similar to the prior approach (step 710) except it may be used where an Internet connection is not available, additional security is required, or the like. In some embodiments, this approach (step 712) may be used with a portable drive, such as a USB drive that may be inserted into the user device to program a secret key of the user device and then be inserted into the edge server directly or via a wired connection. The edge device may enter a secure learning mode. The user device having a processor with addressable memory in communication with the user device may program the edge device secret key into the user device. The user device may store the edge device serial number and the corresponding edge device secret key in a secure cache of the user device. The user device may connect to the edge server, such as via a wired connection, an application programming interface (API), a Bluetooth connection, or the like.

[0069] Once the edge device secret key is retrieved, it may be stored in a pair cache of the edge server with the corresponding edge device serial number (step 714). The retrieving (steps 706, 708, 710, 712) and storing (step 714) steps of the method 700 may only need to be done one time for each new edge device added to the system and may be accomplished prior to generating the STT (step 702).

[0070] The method may then include the edge server retrieving the edge device secret key from the pair cache (step 716). The pair cache may include the edge device serial number and the corresponding edge device secret key. The method 700 may then include decrypting, by the edge server, the STT via the edge device secret key (step 718). The method 700 may then include verifying, by the edge server, the edge device (step 720). The verification may include verifying that the edge serial number of the decrypted STT matches the edge device serial number, verifying that a timestamp of the decrypted STT matches a temporal period, and/or verifying that an authorization role of the decrypted STT matches a security role assigned to the edge device. The method 700 may then include providing, by the edge server, access to the edge server by the edge device if the edge device is verified (step 722). If the edge device is not verified, then the edge server may deny access to the edge server and/or other resources.

[0071] FIG. 8 illustrates an example of a top-level functional block diagram of a computing device embodiment 800. The example operating environment is shown as a computing device 820 comprising a processor 824, such as a central processing unit (CPU), addressable memory 827, an external device interface 826, e.g., an optional universal serial bus port and related processing, and/or an Ethernet port and related processing, and an optional user interface 829, e.g., an array of status lights and one or more toggle switches, and/or a display, and/or a keyboard and/or a pointer-mouse system and/or a touch screen. Optionally, the addressable memory may, for example, be: flash memory, eprom, and/or a disk drive or other hard drive. These elements may be in communication with one another via a data bus 828. In some embodiments, via an operating system 825 such as one supporting a web browser 823 and applications 822, the processor 824 may be configured to execute steps of a process establishing a communication channel and processing according to the embodiments described above.

[0072] System embodiments include computing devices such as a server computing device, a buyer computing device, and a seller computing device, each comprising a processor and addressable memory and in electronic communication with each other. The embodiments provide a server computing device that may be configured to: register one or more buyer computing devices and associate each buyer computing device with a buyer profile; register one or more seller computing devices and associate each seller computing device with a seller profile; determine search results of one or more registered buyer computing devices matching one or more buyer criteria via a seller search component. The service computing device may then transmit a message from the registered seller computing device to a registered buyer computing device from the determined search results and provide access to the registered buyer computing device of a property from the one or more properties of the registered seller via a remote access component based on the transmitted message and the associated buyer computing device; and track movement of the registered buyer computing device in the accessed property via a viewer tracking component. Accordingly, the system may facilitate the tracking of buyers by the system and sellers once they are on the property and aid in the seller’s search for finding buyers for their property. The figures described below provide more details about the implementation of the devices and how they may interact with each other using the disclosed technology.

[0073] FIG. 9 is a high-level block diagram 900 showing a computing system comprising a computer system useful for implementing an embodiment of the system and process, disclosed herein. Embodiments of the system may be implemented in different computing environments. The computer system includes one or more processors 902, and can further include an electronic display device 904 (e.g., for displaying graphics, text, and other data), a main memory 906 (e.g., random access memory (RAM)), storage device 908, a removable storage device 910 (e.g., removable storage drive, a removable memory module, a magnetic tape drive, an optical disk drive, a computer readable medium having stored therein computer software and/or data), user interface device 911 (e.g., keyboard, touch screen, keypad, pointing device), and a communication interface 912 (e.g., modem, a network interface (such as an Ethernet card), a communications port, or a PCMCIA slot and card). The communication interface 912 allows software and data to be transferred between the computer system and external devices. The system further includes a communications infrastructure 914 (e.g., a communications bus, cross-over bar, or network) to which the aforementioned devices/modules are connected as shown.

[0074] Information transferred via communications interface 914 may be in the form of signals such as electronic, electromagnetic, optical, or other signals capable of being received by communications interface 914, via a communication link 916 that carries signals and may be implemented using wire or cable, fiber optics, a phone line, a cellular/mobile phone link, an radio frequency (RF) link, and/or other communication channels. Computer program instructions representing the block diagram and/or flowcharts herein may be loaded onto a computer, programmable data processing apparatus, or processing devices to cause a series of operations performed thereon to produce a computer implemented process.

[0075] Embodiments have been described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments. Each block of such illustrations/diagrams, or combinations thereof, can be implemented by computer program instructions. The computer program instructions when provided to a processor produce a machine, such that the instructions, which execute via the processor, create means for implementing the functions/operations specified in the flowchart and/or block diagram. Each block in the flowchart/block diagrams may represent a hardware and/or software module or logic, implementing embodiments. In alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures, concurrently, etc.

[0076] Computer programs (i.e., computer control logic) are stored in main memory and/or secondary memory. Computer programs may also be received via a communications interface 912. Such computer programs, when executed, enable the computer system to perform the features of the embodiments as discussed herein. In particular, the computer programs, when executed, enable the processor and/or multi-core processor to perform the features of the computer system. Such computer programs represent controllers of the computer system.

[0077] FIG. 10 shows a block diagram of an example system 1000 in which an embodiment may be implemented. The system 1000 includes one or more client devices 1001 such as consumer electronics devices, connected to one or more server computing systems 1030. A server 1030 includes a bus 1002 or other communication mechanism for communicating information, and a processor (CPU) 1004 coupled with the bus 1002 for processing information. The server 1030 also includes a main memory 1006, such as a random access memory (RAM) or other dynamic storage device, coupled to the bus 1002 for storing information and instructions to be executed by the processor 1004. The main memory 1006 also may be used for storing temporary variables or other intermediate information during execution or instructions to be executed by the processor 1004. The server computer system 1030 further includes a read only memory (ROM) 1008 or other static storage device coupled to the bus 1002 for storing static information and instructions for the processor 1004. A storage device 1010, such as a magnetic disk or optical disk, is provided and coupled to the bus 1002 for storing information and instructions. The bus 1002 may contain, for example, thirty -two address lines for addressing video memory or main memory 1006. The bus 1002 can also include, for example, a 32-bit data bus for transferring data between and among the components, such as the CPU 1004, the main memory 1006, video memory and the storage 1010. Alternatively, multiplex data/address lines may be used instead of separate data and address lines.

[0078] The server 1030 may be coupled via the bus 1002 to a display 1012 for displaying information to a computer user. An input device 1014, including alphanumeric and other keys, is coupled to the bus 1002 for communicating information and command selections to the processor 1004. Another type or user input device comprises cursor control 1016, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to the processor 1004 and for controlling cursor movement on the display 1012.

[0079] According to one embodiment, the functions are performed by the processor 1004 executing one or more sequences of one or more instructions contained in the main memory 1006. Such instructions may be read into the main memory 1006 from another computer- readable medium, such as the storage device 1010. Execution of the sequences of instructions contained in the main memory 1006 causes the processor 1004 to perform the process steps described herein. One or more processors in a multi-processing arrangement may also be employed to execute the sequences of instructions contained in the main memory 1006. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the embodiments. Thus, embodiments are not limited to any specific combination of hardware circuitry and software.

[0080] The terms "computer program medium," "computer usable medium," "computer readable medium", and "computer program product," are used to generally refer to media such as main memory, secondary memory, removable storage drive, a hard disk installed in hard disk drive, and signals. These computer program products are means for providing software to the computer system. The computer readable medium allows the computer system to read data, instructions, messages or message packets, and other computer readable information from the computer readable medium. The computer readable medium, for example, may include non-volatile memory, such as a floppy disk, ROM, flash memory, disk drive memory, a CD-ROM, and other permanent storage. It is useful, for example, for transporting information, such as data and computer instructions, between computer systems. Furthermore, the computer readable medium may comprise computer readable information in a transitory state medium such as a network link and/or a network interface, including a wired network or a wireless network that allow a computer to read such computer readable information. Computer programs (also called computer control logic) are stored in main memory and/or secondary memory. Computer programs may also be received via a communications interface. Such computer programs, when executed, enable the computer system to perform the features of the embodiments as discussed herein. In particular, the computer programs, when executed, enable the processor multi-core processor to perform the features of the computer system. Accordingly, such computer programs represent controllers of the computer system. [0081] Generally, the term "computer-readable medium" as used herein refers to any medium that participated in providing instructions to the processor 1004 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks, such as the storage device 1010. Volatile media includes dynamic memory, such as the main memory 1006. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise the bus 1002. Transmission media can also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

[0082] Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, an EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.

[0083] Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to the processor 1004 for execution. For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to the server 1030 can receive the data on the telephone line and use an infrared transmitter to convert the data to an infrared signal. An infrared detector coupled to the bus 1002 can receive the data carried in the infrared signal and place the data on the bus 1002. The bus 1002 carries the data to the main memory 1006, from which the processor 1004 retrieves and executes the instructions. The instructions received from the main memory 1006 may optionally be stored on the storage device 1010 either before or after execution by the processor 1004.

[0084] The server 1030 also includes a communication interface 1018 coupled to the bus 1002. The communication interface 1018 provides a two-way data communication coupling to a network link 1020 that is connected to the worldwide packet data communication network now commonly referred to as the Internet 1028. The Internet 1028 uses electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on the network link 1020 and through the communication interface 1018, which carry the digital data to and from the server 1030, are exemplary forms or carrier waves transporting the information. [0085] In another embodiment of the server 1030, interface 1018 is connected to a network 1022 via a communication link 1020. For example, the communication interface 1018 may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line, which can comprise part of the network link 1020. As another example, the communication interface 1018 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, the communication interface 1018 sends and receives electrical electromagnetic or optical signals that carry digital data streams representing various types of information.

[0086] The network link 1020 typically provides data communication through one or more networks to other data devices. For example, the network link 1020 may provide a connection through the local network 1022 to a host computer 1024 or to data equipment operated by an Internet Service Provider (ISP). The ISP in turn provides data communication services through the Internet 1028. The local network 1022 and the Internet 1028 both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on the network link 1020 and through the communication interface 1018, which carry the digital data to and from the server 1030, are exemplary forms or carrier waves transporting the information.

[0087] The server 1030 can send/receive messages and data, including e-mail, program code, through the network, the network link 1020 and the communication interface 1018. Further, the communication interface 1018 can comprise a USB/Tuner and the network link 1020 may be an antenna or cable for connecting the server 1030 to a cable provider, satellite provider or other terrestrial transmission system for receiving messages, data and program code from another source.

[0088] The example versions of the embodiments described herein may be implemented as logical operations in a distributed processing system such as the system 1000 including the servers 1030. The logical operations of the embodiments may be implemented as a sequence of steps executing in the server 1030, and as interconnected machine modules within the system 1000. The implementation is a matter of choice and can depend on performance of the system 1000 implementing the embodiments. As such, the logical operations constituting said example versions of the embodiments are referred to for e.g., as operations, steps or modules.

[0089] Similar to a server 1030 described above, a client device 1001 can include a processor, memory, storage device, display, input device and communication interface (e.g., e-mail interface) for connecting the client device to the Internet 1028, the ISP, or LAN 1022, for communication with the servers 1030.

[0090] The system 1000 can further include computers (e.g., personal computers, computing nodes) 1005 operating in the same manner as client devices 1001, where a user can utilize one or more computers 1005 to manage data in the server 1030.

[0091] Referring now to FIG. 11, illustrative cloud computing environment 50 is depicted. As shown, cloud computing environment 50 comprises one or more cloud computing nodes 10 with which local computing devices used by cloud consumers, such as, for example, personal digital assistant (PDA), smartphone, smart watch, set-top box, video game system, tablet, mobile computing device, or cellular telephone 54A, desktop computer 54B, laptop computer 54C, and/or automobile computer system 54N may communicate. Nodes 10 may communicate with one another. They may be grouped (not shown) physically or virtually, in one or more networks, such as Private, Community, Public, or Hybrid clouds as described hereinabove, or a combination thereof. This allows cloud-computing environment 50 to offer infrastructure, platforms and/or software as services for which a cloud consumer does not need to maintain resources on a local computing device. It is understood that the types of computing devices 54A-N shown in FIG. 11 are intended to be illustrative only and that computing nodes 10 and cloud computing environment 50 can communicate with any type of computerized device over any type of network and/or network addressable connection (e.g., using a web browser).

[0092] The above description presents the best mode contemplated for carrying out the present embodiments, and of the manner and process of practicing them, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which they pertain to practice these embodiments. The present embodiments are, however, susceptible to modifications and alternate constructions from those discussed above that are fully equivalent. Consequently, the present invention is not limited to the particular embodiments disclosed. On the contrary, the present invention covers all modifications and alternate constructions coming within the spirit and scope of the present disclosure. For example, the steps in the processes described herein need not be performed in the same order as they have been presented, and may be performed in any order(s). Further, steps that have been presented as being performed separately may in alternative embodiments be performed concurrently. Likewise, steps that have been presented as being performed concurrently may in alternative embodiments be performed separately.

Claims

WHAT IS CLAIMED IS:

1. A method comprising:

generating, by an edge device (110) comprising a processor and addressable memory, a secure temporal token (STT) (500);

sending, by the edge device, a request to an edge server (140) comprising a processor and addressable memory, wherein the request comprises the generated STT and a serial number (206) of the edge device;

retrieving, by the edge server, an edge device secret key (208) from a pair cache (214), wherein the pair cache comprises the edge device serial number and the

corresponding edge device secret key;

decrypting, by the edge server, the STT via the edge device secret key;

verifying, by the edge server, the edge device via at least one of: the edge serial number of the decrypted STT matching the edge device serial number, a timestamp (508) of the decrypted STT matching a temporal period, and an authorization role (506) of the decrypted STT matching a security role assigned to the edge device; and

providing, by the edge server, access to the edge server by the edge device if the edge device is verified.

2. The method of claim 1, wherein the STT comprises: a tenant name (502), the edge device serial number, the security role assigned to the edge device, the timestamp, and a nonce (510).

3. The method of claim 2, wherein the tenant name is an owner of the edge device.

4. The method of claim 3, further comprising:

providing, by the edge server, access to a tenant database of the edge server

corresponding to the owner of the edge device by the verified edge device.

5. The method of claim 2, wherein the nonce is at least one of: a 98-byte long

hexadecimal string and a random 49-byte hexadecimal number.

6. The method of claim 2, wherein the STT length is at least 256 bytes.

7. The method of claim 1, wherein verifying the authorization role of the decrypted STT further comprises:

storing, by the edge server, the security role assigned to the edge device; and

verifying that the authorization role is equal to or less than the stored security role of the edge device.

8. The method of claim 7, wherein the security role of the edge device is at least one of: no edge server access allowed, write data access only to the edge server, read and write data access to the edge server, enable one or more features of the edge device at the edge server, disable one or more features of the edge device at the edge server, and update a profile of the edge device at the edge server.

9. The method of claim 1, wherein verifying the edge device further comprises:

matching the edge serial number of the decrypted STT to the edge device serial number; matching the timestamp of the decrypted STT to the temporal period; and

matching the authorization role of the decrypted STT to the security role assigned to the edge device.

10. The method of claim 9, further comprising:

denying, by the edge server, access to the edge server by the edge device if the edge device verification fails.

11. The method of claim 1, further comprising, prior to retrieving the edge device secret key from the pair cache:

requesting (420), by the edge server, the edge device secret key from a secure data edge manufacturer server (210) comprising a processor and addressable memory, wherein the request comprises the edge device serial number;

validating, by the secure data edge manufacturer server, an authority of the edge server to access the edge device secret key;

receiving, by the edge server, the edge device secret key corresponding to the edge device serial number; and

storing, by the edge server, the edge device serial number and the corresponding edge device secret key in the pair cache.

12. The method of claim 1, further comprising, prior to retrieving the edge device secret key from the pair cache:

capturing, by a camera (222) of a user device (224) comprising a processor with

addressable memory, an encrypted optical label (216) disposed on the edge device, wherein the encrypted optical label is encrypted by a public key (218) of the edge server;

sending, by the user device, the captured encrypted optical label to the edge server; decrypting, by the edge server, the encrypted optical label via a private key of the edge server, wherein the decrypted optical label comprises the edge device serial number and the corresponding edge device secret key; and

13. The method of claim 1, further comprising, prior to retrieving the edge device secret key from the pair cache:

enabling, by the edge device, a secure learning mode;

programming, by a user device (224) comprising a processor with addressable memory in communication with the user device, the edge device secret key into the user device; sending, by the user device, the edge device serial number and the corresponding edge device secret key to the edge server; and

14. The method of claim 1, further comprising, prior to retrieving the edge device secret key from the pair cache:

enabling, by the edge device, a secure learning mode;

programming, by a user device (224) comprising a processor with addressable memory in communication with the user device, the edge device secret key into the user device; storing, by the user device, the edge device serial number and the corresponding edge device secret key in a secure cache of the user device;

connecting the user device to the edge server; and

uploading the edge device serial number and the corresponding edge device secret key stored in the secure cache of the user device to the pair cache of the edge server.

15. A system comprising:

an edge device (110) comprising a processor and addressable memory, wherein the edge device processor is configured to:

generate a secure temporal token (STT) (500); and

generate a request comprising the generated STT and a serial number (206) of the edge device;

an edge server (140) comprising a processor and addressable memory, wherein the edge server processor is configured to:

receive the generated request from the edge device;

retrieve an edge device secret key from a pair cache (214), wherein the pair cache comprises the edge device serial number and the corresponding edge device secret key;

decrypt the STT via the edge device secret key;

verify the edge device via at least one of: the edge serial number of the decrypted STT matching the edge device serial number, a timestamp (508) of the decrypted STT matching a temporal period, and an authorization role (506) of the decrypted STT matching a security role assigned to the edge device; and provide access to the edge server by the edge device if the edge device is verified.

16. The system of claim 15 further comprising:

a secure data edge manufacturer server (210) comprising a processor and addressable memory, wherein the secure data edge manufacturer server processor is configured to: receive a request (420) from the edge server for the edge device secret key,

wherein the request comprises the edge device serial number;

validate an authority of the edge server to access the edge device secret key; and send the edge device secret key corresponding to the edge device serial number to the edge server.

17. The system of claim 15 further comprising:

an encrypted optical label (216) disposed on the edge device, wherein the encrypted

optical label is encrypted by a public key (218) of the edge server;

a user device (224) comprising a processor with addressable memory;

a camera (222) in communication with the user device processor;

wherein the user device processor is configured to: receive an image of the encrypted optical label from the camera; and

send the image of the encrypted optical label to the edge server;

wherein the edge server processor is further configured to:

decrypt the encrypted optical label via a private key of the edge server, wherein the decrypted optical label comprises the edge device serial number and the corresponding edge device secret key; and

store the edge device serial number and the corresponding edge device secret key in the pair cache.

18. The system of claim 15 further comprising:

a user device (224) comprising a processor with addressable memory, wherein the user device processor is configured to:

program the edge device secret key into the user device; and

send the edge device serial number and the corresponding edge device secret key to the edge server.

19. The system of claim 15 further comprising:

program the edge device secret key into the user device;

store the edge device serial number and the corresponding edge device secret key in a secure cache of the user device; and

upload the edge device serial number and the corresponding edge device secret key stored in the secure cache of the user device to the pair cache of the edge server.

20. A method comprising:

generating, by an edge device (110) comprising a processor and addressable memory, a client random number (CRN) (310);

sending, by the edge device, the CRN and an edge device encryption capability to an edge server (140) comprising a processor and addressable memory;

sending, by the edge server, a server random number (320) and an edge server encryption ability to the edge device; sending, by the edge server a digital certificate and a public key (218) of the edge server to the edge device (330);

validating, by the edge device, a signature on the digital certificate via the public key of the edge server (340);

sending, by the edge device, an encrypted hash of all messages to the edge server,

wherein the encryption is based on the public key of the edge server;

verifying, by the edge server, the encrypted hash, wherein the encrypted hash is decrypted with a private key of the edge server;

generating, by the edge device, a pre-message secret (PMS) (350);

sending, by the edge device, the PMS encrypted with the public key of the edge server to the edge server;

generating, by the edge device, a master key session by multiplying the CRN, SRN, and PMS;

generating, by the edge server, a master key session by multiplying the CRN, SRN, and PMS;

sending, by the edge device, a message to change to an encrypted connected with the master key session to the edge server;

generating, by the edge device, a secure temporal token (STT) (500);

sending, by the edge device, a request to the edge server, wherein the request comprises the generated STT and a serial number (206) of the edge device;

corresponding edge device secret key;

decrypting, by the edge server, the STT via the edge device secret key;