[go: up one dir, main page]

WO2019161285A1 - Dispositifs et systèmes pour la sécurité de l'internet industriel des objets - Google Patents

Dispositifs et systèmes pour la sécurité de l'internet industriel des objets Download PDF

Info

Publication number
WO2019161285A1
WO2019161285A1 PCT/US2019/018328 US2019018328W WO2019161285A1 WO 2019161285 A1 WO2019161285 A1 WO 2019161285A1 US 2019018328 W US2019018328 W US 2019018328W WO 2019161285 A1 WO2019161285 A1 WO 2019161285A1
Authority
WO
WIPO (PCT)
Prior art keywords
edge
edge device
server
secret key
serial number
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/US2019/018328
Other languages
English (en)
Inventor
Stephen K. MANSFIELD
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ampure Charging Systems Inc
Original Assignee
Webasto Charging Systems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Webasto Charging Systems Inc filed Critical Webasto Charging Systems Inc
Publication of WO2019161285A1 publication Critical patent/WO2019161285A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/088—Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3297—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H04L2209/805—Lightweight hardware, e.g. radio-frequency identification [RFID] or sensor

Definitions

  • the present embodiments relate to supply chain management.
  • the present embodiments relate to securing data in supply chains.
  • IoT Internet of Things
  • IloT Industrial Internet of Things
  • 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.
  • 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.
  • 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.
  • the temporal token further comprises a tenant name, an edge serial number, an authorization role, an STT creation date and time, and a nonce.
  • 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.
  • STT secure temporal token
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • STT secure temporal token
  • 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.
  • 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.
  • 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.
  • 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.
  • 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, generating,
  • FIG. 1 is a conceptual illustration of a fleet data edge topology in accordance with an embodiment of the invention
  • FIG. 2 is a conceptual diagram of a fleet edge security architecture in accordance with an embodiment of the invention.
  • FIG. 3 is a conceptual timing diagram of an edge security sequence in accordance with an embodiment of the invention.
  • FIG. 4 is a conceptual timing diagram of a secure temporal template handshake in accordance with an embodiment of the invention.
  • FIG. 5 is a high-level diagram of a secure temporal token format in accordance with an embodiment of the invention.
  • FIG. 6 is an illustration of authorization access rules in accordance with an embodiment of the invention.
  • FIG. 7 depicts a high-level flowchart of a method embodiment of an edge security sequence in accordance with an embodiment of the invention
  • FIG. 8 illustrates an example top-level functional block diagram of a computing device embodiment
  • FIG. 9 shows a high-level block diagram and process of a computing system for implementing an embodiment of the system and process
  • FIG. 10 shows a block diagram and process of an exemplary system in which an embodiment may be implemented.
  • FIG. 11 depicts a cloud-computing environment for implementing an embodiment of the system and process disclosed herein.
  • 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.
  • the disclosed system and method can help companies better manage their Material Handling Equipment (MHE), Ground Support Equipment (GSE) and Material Support Robots (MSR).
  • MHE Material Handling Equipment
  • GSE Ground Support Equipment
  • MSR Material Support Robots
  • 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.
  • sensors may collect information about material handling, loading, speed, location, safe operation, equipment health, and/or truck energy state.
  • 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.
  • messages may be securely sent via wireless and/or cellular networks to the Internet and/or to a central data collection cloud server.
  • the server may be called a“Fleet Edge Server”, and may collect information to a secure database.
  • the database may be accessed by third-party software.
  • 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.
  • the disclosed architecture can fulfill each of these requirements through security protocols and private key management.
  • 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.
  • the present embodiments depict a fleet data edge topology in accordance with an embodiment of the invention.
  • the fleet data edge system 100 can be a small, self-contained high-performance computing, communications, and sensor data collection platform.
  • 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.
  • 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.
  • the vehicle may be a piece of material handling equipment (MHE) or a piece of ground support equipment (GSE).
  • 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.
  • the data edge device 110 may be installed on emerging technology warehouse robots that support a multitude of warehouse data sensors.
  • the data edge devices 110 communicate with a network including, but not limited to, the Internet 130.
  • 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.
  • Wi-Fi 136 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.
  • 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.
  • 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.
  • 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.
  • WMS Warehouse Management Software
  • WAS Warehouse Analytics Software
  • 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.
  • 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.
  • HTTPS/TLS to support encryption
  • X.509 certificates to authenticate the server
  • an innovative Secure Temporal Token to assert secure authentication an authorization of the fleet data edge device 110.
  • fleet data edge systems 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.
  • the present embodiments depict a fleet edge security architecture in accordance with an embodiment of the invention.
  • 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.
  • 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.
  • TLS Transport Layer Security
  • 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.
  • 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.
  • 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.
  • the combination of technologies and methods can allow for very robust security for IloT devices.
  • 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.
  • each data edge client may create a unique dynamic Secure Temporal Token (STT) to authenticate and authorize access to the fleet edge server.
  • STT Secure Temporal Token
  • the STT is encrypted with a unique private key.
  • 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.
  • 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.
  • 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.
  • all data edge devices 110 can have a private key 208 that is recognized by the edge server 140.
  • 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.
  • the private AES key 208 is unique to each fleet edge device 110 and is used to encrypt secure tokens.
  • 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.
  • 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.
  • API Application Programming Interface
  • 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.
  • 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.
  • 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.
  • TCP/IP session is set up between the server 140 and fleet edge device 110 to handle the request.
  • the session is established the fleet edge device 110 and server 140 can exchange data.
  • the session can be shut down and communication between the server and Edge device terminated.
  • 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.
  • 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.
  • the data edge security architecture 200 can define a secure data edge manufacturer server 210 made available by the data edge manufacturer.
  • the edge device 110 when installed it instantly tries to communicate with the edge server 140.
  • the first time a HTTPS packet is received the edge server 140 would check the serial number key/value pair.
  • the edge server 140 may establish a secure, mutually authenticated session with the edge manufacturer’s server 210.
  • 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.
  • the edge server 140 can then cache 214 the serial number key/value AES key 208 in its secure storage.
  • the edge server 140 does not allow any external access of the secret key 208.
  • 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.
  • caching 214 the secret key 208 as a serial number/key pair may speed up authentication after the first attempt.
  • 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.
  • 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.
  • the manufacturer would create a QR coded optical label encrypted by the edge server’s 140 public key 218.
  • 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.
  • the optical label 216 may be printed and/or laser etched directly on the data edge 110 device or shipping container.
  • 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.
  • 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.
  • 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.
  • a user or technician during installation of the fleet data edge device 110 a user or technician could place the edge device 110 in a secure learning mode.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the present embodiments depict a timing diagram of an edge security sequence in accordance with an embodiment of the invention.
  • 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.
  • 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.
  • 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.
  • the fleet edge server 140 may then send 330 the client 110 a digital certificate along with its public key.
  • the fleet edge client 110 can use the public key to validate 340 the signature on the server’s digital certificate.
  • 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.
  • 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.
  • 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.
  • PMS pre-message secret
  • both the client 110 and the server 140 multiply the CRN, SRN, and PMS and generate a master session key (MKey).
  • MKey master session key
  • 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.
  • the present embodiments depict a timing diagram of a secure temporal template handshake 400 in accordance with an embodiment of the invention.
  • 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.
  • 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.
  • the server 140 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.
  • the assignment can represent the authorization to access certain server services granted to the fleet edge device 110.
  • the data edge IloT device 110 may create a unique Secure Temporal Token (STT).
  • 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.
  • this information may be initialized by an installation technician when the fleet data edge device 110 is installed, such as on a truck.
  • the data can be initialized by using a Bluetooth connected smartphone with an edge installation application installed.
  • 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.
  • 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.
  • the server 140 may not allow server access and terminate the TCP/IP session.
  • 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.
  • 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”.
  • the injection of the nonce can help deter packet injection by “Man in the Middle” attacks.
  • security authorization can make sure that that specific fleet edge device is“authorized” to access the service and data it is requesting.
  • 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.
  • the format of the header can be in a JSON format.
  • 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.
  • the serial number 504 is a public number and can be made available in the IP header.
  • 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.
  • the tenant name 502 may be used to direct the edge data message to the correct secure tenant database.
  • the tenant name 502 can“assure” that the data is being directed to the correct database.
  • 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.
  • the server can add a temporal period to the Date/Time 508, a value that may be called an EPOC temporal period.
  • an EPOC temporal period When the server receives the secure token 500 in the header it also obtains the current EPOC time.
  • 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.
  • 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.
  • 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”.
  • 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.
  • 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.
  • 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.
  • 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.
  • device authorization establishes a set of policies or roles for each edge device.
  • 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.
  • 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.
  • the edge device requests services and the API allows or does not allow access based on its authorization role.
  • 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.
  • a much more important Edge device that controls load/tilt safety would have higher authorization.
  • 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.
  • this tampered edge device could no longer access any server resources until inspected and reset by a technician.
  • the edge device can be permanently taken off-line.
  • 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).
  • STT secure temporal token
  • 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).
  • STT secure temporal token
  • the method may then include retrieving the edge device secret key (steps 706, 708, 710, 712).
  • the edge device secret key may be retrieved prior to the edge device generating the STT (step 702).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • API application programming interface
  • the edge device secret key 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).
  • 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.
  • 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.
  • 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.
  • the processor 824 may be configured to execute steps of a process establishing a communication channel and processing according to the embodiments described above.
  • 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.
  • 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.
  • 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.
  • 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).
  • an electronic display device 904 e.g., for displaying graphics, text, and other data
  • main memory 906 e.g.,
  • 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.
  • a communications infrastructure 914 e.g., a communications bus, cross-over bar, or network
  • 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.
  • 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.
  • Computer programs 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.
  • 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.
  • ROM read only memory
  • 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.
  • 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 is coupled to the bus 1002 for communicating information and command selections to the processor 1004.
  • 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.
  • 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.
  • processors in a multi-processing arrangement may also be employed to execute the sequences of instructions contained in the main memory 1006.
  • 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.
  • 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 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.
  • 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
  • Such computer programs when executed, enable the computer system to perform the features of the embodiments as discussed herein.
  • 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.
  • the term "computer-readable medium" as used herein refers to any medium that participated in providing instructions to the processor 1004 for execution.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • interface 1018 is connected to a network 1022 via a communication link 1020.
  • 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.
  • ISDN integrated services digital network
  • the communication interface 1018 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN.
  • LAN local area network
  • Wireless links may also be implemented.
  • the communication interface 1018 sends and receives electrical electromagnetic or optical signals that carry digital data streams representing various types of information.
  • the network link 1020 typically provides data communication through one or more networks to other data devices.
  • 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).
  • ISP Internet Service Provider
  • 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.
  • 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.
  • 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.
  • 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.
  • the logical operations constituting said example versions of the embodiments are referred to for e.g., as operations, steps or modules.
  • 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.
  • a processor e.g., 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.
  • communication interface e.g., e-mail interface
  • 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.
  • computers e.g., personal computers, computing nodes
  • 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.
  • 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).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne des systèmes et des procédés comprenant : la génération, par un dispositif de bordure (110), d'un jeton temporel sécurisé (STT) (500 ) ; l'envoi, par le dispositif de bordure, d'une demande à un serveur de bordure (140), la demande comprenant le STT généré et un numéro de série (206) du dispositif de bordure ; la récupération, par le serveur de bordure, d'une clé secrète de dispositif de bordure (208) provenant d'une mémoire cache de paire (214), la mémoire cache de paire comprenant le numéro de série de dispositif de bordure et la clé secrète de dispositif de bordure correspondante ; le déchiffrement, par le serveur de bordure, du STT par l'intermédiaire de la clé secrète de dispositif de bordure ; la vérification, par le serveur de bordure, du dispositif de bordure ; et la fourniture, par le serveur de bordure, de l'accès au serveur de bordure par le dispositif de bordure si le dispositif de bordure est vérifié.
PCT/US2019/018328 2018-02-15 2019-02-15 Dispositifs et systèmes pour la sécurité de l'internet industriel des objets Ceased WO2019161285A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201862631443P 2018-02-15 2018-02-15
US62/631,443 2018-02-15

Publications (1)

Publication Number Publication Date
WO2019161285A1 true WO2019161285A1 (fr) 2019-08-22

Family

ID=67618866

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2019/018328 Ceased WO2019161285A1 (fr) 2018-02-15 2019-02-15 Dispositifs et systèmes pour la sécurité de l'internet industriel des objets

Country Status (1)

Country Link
WO (1) WO2019161285A1 (fr)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113407361A (zh) * 2021-05-27 2021-09-17 中国联合网络通信集团有限公司 桌面访问控制方法和系统
US20220006650A1 (en) * 2019-03-25 2022-01-06 Micron Technology, Inc. Secure device communication
CN113992379A (zh) * 2021-10-22 2022-01-28 中国电信股份有限公司 主动标识设备的通信方法、通信系统、介质及电子设备
US20220060455A1 (en) * 2020-08-21 2022-02-24 Microsoft Technology Licensing, Llc Secure computing device
CN114268490A (zh) * 2021-12-21 2022-04-01 杭州萤石软件有限公司 一种设备认证方法、物联网系统、服务器及存储介质
CN114900288A (zh) * 2022-05-23 2022-08-12 科大天工智能装备技术（天津）有限公司 一种基于边缘服务的工业环境认证方法
US11693994B2 (en) 2021-04-29 2023-07-04 Saudi Arabian Oil Company System and method for securing cache boards of an enterprise network data storage system
US20240214199A1 (en) * 2021-02-24 2024-06-27 Systemes Et Technologies Identification (Stid) Method for secure exchanges between an access control reader, iot hub and a data processing unit
CN118869200A (zh) * 2024-07-04 2024-10-29 广东电网有限责任公司中山供电局 一种电力系统的加密通信方法和安全加密通信系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110173684A1 (en) * 2010-01-12 2011-07-14 Simon Hurry Anytime validation for verification tokens
US8775810B1 (en) * 2009-09-30 2014-07-08 Amazon Technologies, Inc. Self-validating authentication token
US20160127454A1 (en) * 2014-10-30 2016-05-05 Equinix, Inc. Interconnection platform for real-time configuration and management of a cloud-based services exchange
US20170116427A1 (en) * 2015-10-27 2017-04-27 Blackberry Limited Token-based control of software installation and operation
US9887975B1 (en) * 2016-08-03 2018-02-06 KryptCo, Inc. Systems and methods for delegated cryptography

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8775810B1 (en) * 2009-09-30 2014-07-08 Amazon Technologies, Inc. Self-validating authentication token
US20110173684A1 (en) * 2010-01-12 2011-07-14 Simon Hurry Anytime validation for verification tokens
US20160127454A1 (en) * 2014-10-30 2016-05-05 Equinix, Inc. Interconnection platform for real-time configuration and management of a cloud-based services exchange
US20170116427A1 (en) * 2015-10-27 2017-04-27 Blackberry Limited Token-based control of software installation and operation
US9887975B1 (en) * 2016-08-03 2018-02-06 KryptCo, Inc. Systems and methods for delegated cryptography

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220006650A1 (en) * 2019-03-25 2022-01-06 Micron Technology, Inc. Secure device communication
US12166899B2 (en) * 2019-03-25 2024-12-10 Micron Technology, Inc. Secure device communication
US20220060455A1 (en) * 2020-08-21 2022-02-24 Microsoft Technology Licensing, Llc Secure computing device
US20240214199A1 (en) * 2021-02-24 2024-06-27 Systemes Et Technologies Identification (Stid) Method for secure exchanges between an access control reader, iot hub and a data processing unit
US11693994B2 (en) 2021-04-29 2023-07-04 Saudi Arabian Oil Company System and method for securing cache boards of an enterprise network data storage system
CN113407361A (zh) * 2021-05-27 2021-09-17 中国联合网络通信集团有限公司 桌面访问控制方法和系统
CN113407361B (zh) * 2021-05-27 2023-07-11 中国联合网络通信集团有限公司 桌面访问控制方法和系统
CN113992379A (zh) * 2021-10-22 2022-01-28 中国电信股份有限公司 主动标识设备的通信方法、通信系统、介质及电子设备
CN114268490B (zh) * 2021-12-21 2023-09-05 杭州萤石软件有限公司 一种设备认证方法、物联网系统、服务器及存储介质
CN114268490A (zh) * 2021-12-21 2022-04-01 杭州萤石软件有限公司 一种设备认证方法、物联网系统、服务器及存储介质
CN114900288A (zh) * 2022-05-23 2022-08-12 科大天工智能装备技术（天津）有限公司 一种基于边缘服务的工业环境认证方法
CN114900288B (zh) * 2022-05-23 2023-08-25 北京科技大学 一种基于边缘服务的工业环境认证方法
CN118869200A (zh) * 2024-07-04 2024-10-29 广东电网有限责任公司中山供电局 一种电力系统的加密通信方法和安全加密通信系统

Similar Documents

Publication Publication Date Title
WO2019161285A1 (fr) Dispositifs et systèmes pour la sécurité de l'internet industriel des objets
US11902445B2 (en) System and method for enabling secure service-based communications via 5G proxies
US11936772B1 (en) System and method for supply chain tamper resistant content verification, inspection, and approval
EP3090520B1 (fr) Système et procédé pour sécuriser des communications machine-machine
CN110493261B (zh) 基于区块链的验证码获取方法、客户端、服务器及存储介质
US20230421394A1 (en) Secure authentication of remote equipment
US10135826B2 (en) Leveraging security as a service for cloud-based file sharing
JP6382272B2 (ja) ある装置を使用して別の装置をアンロックする方法
US9338164B1 (en) Two-way authentication using two-dimensional codes
CN103517273B (zh) 认证方法、管理平台和物联网设备
EP4231680A1 (fr) Système, procédé et appareil d'authentification d'identité, dispositif et support de stockage lisible par ordinateur
US9979725B1 (en) Two-way authentication using two-dimensional codes
CN113572728B (zh) 认证物联网设备的方法、装置、设备及介质
WO2018227685A1 (fr) Système et procédé destinés à un accès sécurisé d'un dispositif terminal à l'internet des objets
CN113411187A (zh) 身份认证方法和系统、存储介质及处理器
KR20210121805A (ko) 블록체인 기반의 pki 도메인에 속하는 전자 장치, 인증 기관 기반의 pki 도메인에 속하는 전자 장치, 및 이들을 포함하는 암호화 통신 시스템
KR101835640B1 (ko) 통신 연결 인증 방법, 그에 따른 게이트웨이 장치, 및 그에 따른 통신 시스템
CN111414647A (zh) 一种基于区块链技术防篡改的数据共享系统及方法
CN116074028B (zh) 加密流量的访问控制方法、装置及系统
CN107409043B (zh) 基于中央加密的存储数据对产品的分布式处理
CN103560881A (zh) 一种射频识别系统安全认证与密钥协商方法
KR102322605B1 (ko) 사물인터넷 환경에서의 비밀키 설정 및 상호 기기 인증 방법
KR101745482B1 (ko) 스마트홈 시스템에서의 통신 방법 및 그 장치
CN108566367B (zh) 一种终端的认证方法和装置
CN106487838B (zh) 使用物联网建立产品生产履历的系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19754619

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19754619

Country of ref document: EP

Kind code of ref document: A1