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/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/3263—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
  • H04L9/3268—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
  • H04L63/0281—Proxies
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
  • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
  • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
  • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
  • H04L63/065—Network architectures or network communication protocols for network security for supporting key management in a packet data network for group communications
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
• • 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/083—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) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
  • H04L9/0833—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) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP] involving conference or group key
• • 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/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
• • 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/3218—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 using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
• • 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/3247—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 digital signatures

Definitions

• This disclosure relates to the field of cybersecurity and, more particularly, to a system and method for using device and application intelligence in artificial intelligence (Al) and machine learning (ML) models in Internet of Things (loT), Industrial loT (I loT), and Operational Technology (OT) environments.
• the disclosure provides methods to securely distribute authenticated and trusted data streams to Al systems.
• PKI public key infrastructure
• CA commercial certificate authority
• PSKs symmetric pre-shared keys
• headless (non-user) devices and communicating over insecure local and wide area networks with other devices in activities that include application data transfers, command and control messages, and telemetric data transfers.
• expiration and renewal of PSKs in use requires timely synchronization between tightly coupled applications to avoid service disruption in production environments.
• GDOI Group Domain of Interpretation
• RFC Request For Comments
• IPsec Internet Protocol Security
• unicast peer-to-peer and client-server communications require session key negotiation based on manually pre-configured PSKs and identity hints (e.g., the Transport Layer Security (TLS)-PSK standard as specified in RFC 4279).
• TLS Transport Layer Security
• Distribution of symmetric keys to a plurality of connected devices requires secure device authentication with a key distribution service, validation of devices based on domain membership, group membership, group based key management, distribution policies based on authorized application identifiers, and high availability to alleviate service disruptions during field operations.
• the presently fundamental security gap in implementing a zero-trust network architecture is the inability to orchestrate the generation and distribution of pre-shared symmetric keys, securely on-demand and at-scale, to connected applications executing on heterogeneous devices enrolled into domain-based groups with device identification and authentication based on enrolled domain validation.
• HSM Hardware Security Module
• KMS key management system
• a KMS may transmit (transfer) the symmetric keys over secure transport using a key encapsulation mechanism that requires use of a PKI based asymmetric public-private keypair by an authenticated receiver.
• Secure email protocols such as Secure/Multipurpose Internet Mail Extensions (S/MIME) use key encapsulation mechanisms for security.
• a major challenge for a KMS is the renewal rate of the symmetric keys and scalability as the volume of headless (nonuser) devices proliferates. While a KMS may securely generate, store, and transfer symmetric keys, the dynamic coordination of key exchanges across connected applications and devices that pre-share keys for client authentication and secure communications are beyond the scope of a KMS.
• Multi-signature schemes provide two sets of cryptographic subject public keys and associated issuer signatures within a single X.509 certificate.
• multi-signature schemes require computational and memory intensive operations with larger certificate sizes that are too heavy (too large) and not viable for use on resource constrained devices.
• Other approaches split an encryption key into fragments.
• split keys require multiple parties (actors) to submit their fragments to establish a quorum with a specified threshold of fragments to access and decrypt the data.
• the OASIS key management interoperability protocol (KMIP) specification describes message protocols for symmetric key operations (e.g., create, derive, rekey) using a unique identifier over HTTPS with various message formats (e.g., tag type length value (TTLV), JSON, XML).
• TTLV tag type length value
• JSON JSON
• XML XML
• the specification does not include group based pre-shared keys and enhanced key usage and authorization techniques (permissions) based on factors such as for example network domain, application identifiers, or tenant identifiers.
• the mechanism to authenticate the client to the server and the underlying transport for confidentiality and integrity are not specified and is external to the protocol.
• the specification does not address use of pre-shared key identity hints, between the initiators/clients and responders/servers in a connection, required for client authentication over secure transport protocols (e.g., TLS, IKE, SSH), insecure transport protocols (UDP, TCP) over IP, or non-IP communications protocols.
• secure transport protocols e.g., TLS, IKE, SSH
• UDP insecure transport protocols
• IP IP
• non-IP communications protocols e.g., IP
• One innovative system and method discloses quantum-safe networking and quantum-safe key exchange protocols using a quantum safe (QS) network, quantum distributed (QD) keys, generation of quantum reference (QREF) locators based on input data and user secrets (credentials), and a QREF access token. While this approach provides quantum safe protocols, in the context of quantum computing (QC) threats to key exchange protocols based on the hardness of integer factorization and discrete logarithm problem, it requires a quantum key distribution (QKD) system, over a proprietary protocol, for the distribution of the QD keys (e.g., satellites, fiber optic grids, terrestrial lines).
• establishing QS communication channels between the end-point devices requires quantum safe QD key provisioning with physical or direct connections to QS registration servers on QS networks from a manufacturer or retailer facility.
• the QD keys must be protected on a local secure element (such as for example a HSM, TPM, or secure memory enclave).
• the device identifiers and attributes, and the assigned QD key must be stored on a QS server of the QS system in a device account to identify the end-point device and retrieve the appropriate QD key to establish the QS communication channel.
• Such a device identification and verification method does not leverage the information technology (IT) device management services and onboarding workflows in Enterprise (controlled or airgapped), and operational technology (OT) field networks.
• IT information technology
• OTD operational technology
• the solution requires a local agent (QREF application) to be installed and executed on the end-point devices to use the QD key, QREF access token, and device identifier/credentials to establish a QS communication channel, and further for the QS network to locate the device account and identify the QREF locator from the QREF access token and use the correct (same) end-point QD key to establish the QS communication channel.
• QREF application a local agent
• Requiring a local agent on the end-point device poses challenges on resource constrained and real-time operating system (RTOS) platforms wherein monolithic production (application) images are managed and regulated by the original equipment manufacturers (OEMs).
• RTOS resource constrained and real-time operating system
• the approach may also require reengineering of the line of business applications and security protocol stacks on OT/loT/lloT devices to use QD keys.
• the manufacturing workflows at the manufacturer/retailer’s factory often do not permit access to the Internet, or the device owner/operator’s Enterprise or cloud based production systems.
• Provisioning devices with operational cryptographic key data is generally deferred to device onboarding workflows at the production facility, where customization becomes a cumbersome process for IT NOC/SOC operators.
• QKD quantum key distribution
• PSKs symmetric pre-shared keys
• a resource server or trust anchor, or trust manager, or collaboration service
• local key generators to locally derive a symmetric key, using a key derivation function and an application secret value (that is stored on a secure element on the device endpoint or on a network endpoint) associated with a device identifying key, to circumvent transmitting the PSK between devices.
• an application secret value that is stored on a secure element on the device endpoint or on a network endpoint
• such approaches require use of a secure transport channel over DTLS, TLS, or IPsec on resource constrained devices for device authentication, and further may require the first and second devices to pre-share device identifiers to request the pairing key (i.e., PSK) from the resource server based on identity hints.
• Other approaches use a first symmetric key to generate a second symmetric key that may require a first (shared) master public key and a (unique) private key per device.
• Other approaches use a session key associated with an inter-domain authorization token, issued by an authorization provider to a collaboration service, wherein the session key is provided by the collaboration service to a credential management service for the device domain, and further wherein the device must retrieve the session key from the credential management service for the device domain.
• These other methods thereby advocate a complicated workflow between distributed devices and multiple services configured across domains. Further, these other approaches may require an inbound connection from the resource server to the devices for key revocation and renewal.
• DTLS and TLS protocols provide for use of PSK based authentication and PSK identity hints during the handshake phase
• key provisioning, authorization, exchange, and management methods are outside the scope of the protocol specifications.
• headless (non-user) and resource constrained connected devices in OT/lloT/loT environments.
• support for the heterogeneous device classes i.e., device types
• APIs application programming interface
• Another major technology gap that remains is implementing device authentication and secure data transport between devices and services for data integrity (tamper resistance) and data confidentiality (privacy) without: (a) provisioning digital certificates on devices at the factory (by device manufacturers) or in the field (by device owners/operators); (b) integration with public/private cross-domain PKI systems in production and operational environments; and (c) cumbersome workflows for key and certificate lifecycle management in air-gapped and controlled production environments.
• HMAC keyed-hash message authentication code
• Yet another technology gap that remains is a mechanism to automate and scale secure software updates through the supply chain with zero trust principles for a multi-part content inspection-based approval workflow and multi-person digital signing rules, beyond mere role-based “blind” authorization, to mitigate insider threats and advanced cyber-attacks based on compromise of the golden signing key.
• Recent high-profile breaches in the upstream supply chain demonstrate the lack of a trustworthy automated and gated workflow across the producer, broker, consumer content distribution ecosystem for loT/lloT/OT device software updates.
• IETF Manufacturer Usage Description Specification https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-13 is not intended to address network authorization.
• IETF RFC-5280 defines use of an IP address or a domain name system (DNS) label in the subject alternate name (SAN) extension field in a certificate signing request (CSR).
• DNS domain name system
• CSR certificate signing request
• CA Certificate Authority
• CAB Certificates “Baseline Requirement Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates” imposes restrictions on the use of IP addresses in certificates.
• IP addresses may be dynamically assigned and are therefore mutable.
• Secure design includes mitigating attacks via control of published APIs, sanitizing data and inputs from sources, and verifying the supply chain provenance of training data.
• Secure development includes securing the supply chain of software components, identifying, tracking and protecting connected assets, and using cryptographic hashes or signatures for training data.
• Secure deployment includes controlling access with authenticated APIs, managing cryptographic keys to protect data, and computing and sharing cryptographic hashes and/or signatures of model files.
• Secure operation and maintenance include monitoring system behavior, securing modular update procedures and distribution, and detection of out-of- distribution and/or adversarial inputs.
• the proposed system and method provide a key distribution service (KDS) to generate, distribute, and manage symmetric pre-shared keys at scale for use by applications on authenticated and domain validated devices in a permissioned device group to establish secure communications with pre-shared symmetric keys for data protection (i.e., integrity, authentication, privacy, confidentiality) and PSK based TLS authentication.
• KDS key distribution service
• the proposed system and method provide device authentication using the KDS, or local KDS proxy installed on a server registered as a member device, to perform a secure and authenticated Domain Name System (DNS) server reverse lookup of the device’s IP address (based on a DNS A record) and match the resolved DNS hostname (based on a DNS PTR, ALIAS or CNAME resource record) with the member identifier in the digitally signed KDS request.
• DNS Domain Name System
• the present disclosure provides a cost-effective, automated, and scalable symmetric pre-shared key distribution service for private (Enterprise, Tactical) and public (Internet) networks; permissioned group membership for devices with DNS domain validation; simplifies key generation, distribution, and management; and eliminates complicated certificate provisioning, key renewal, and key/certificate lifecycle management workflows, depending on implementation.
• the present disclosure provides flexible deployment modes to host the key distribution service (KDS) onpremises or in the cloud as a multi-tenant software-as-a-service (SaaS).
• KDS proxy may be hosted on-premises to locally perform device authentication and domain validation and proxy the authenticated device’s requests for services to a cloud-hosted KDS SaaS.
• the tenant identifier configured for the KDS proxy server (device), and the local member devices must be the same.
• the KDS proxy installed on an on-premises server registers the server as a member device with the KDS (over UDP, TCP, or TLS) to retrieve the API token and API secret required for authenticated REST APIs to perform proxy transactions with the KDS on behalf of the local member devices.
• the KDS proxy retrieves the PSK for the group identifier (e.g., “KDS Proxy Servers”), and PSK identity hint (e.g., a UUID) configured in the server (device) configuration file to acquire the API secret and API token for authenticated REST APIs.
• the PSKs for the KDS proxy servers must be pre-configured on the KDS portal under the designated group identifier.
• the disclosed method provides significant security improvements and efficiencies to retrofit legacy brownfield devices for secure communications and data protection with on-demand, simplified, and automated pre-shared key lifecycle management.
• the disclosed system and method provide security for a plurality of inter-device and intra-device communications protocols including, at least, the connection-less User Datagram Protocol (UDP), connection-oriented Transmission Control Protocol (TCP), Internet Protocol (IP v4/v6), Controller Area Network Bus (CAN Bus), Modbus (over TCP/UDP), Highway Addressable Remote Transducer (HART), WirelessHART, and RS232 serial communications protocol.
• UDP connection-less User Datagram Protocol
• TCP connection-oriented Transmission Control Protocol
• IP v4/v6 Internet Protocol
• CAN Bus Controller Area Network Bus
• Modbus over TCP/UDP
• HART Highway Addressable Remote Transducer
• WirelessHART WirelessHART
• the CAN Bus, HART, Modbus networks may be bridged to an Ethernet (ETH) network using an intermediary device (CAN- ETH adapter, or HART-ETH adapter, or Modbus over TCP/UDP) that serves as a gateway between a software application program executing on an application server device on the Ethernet network and the CAN/HART devices on the respective CAN Bus and HART network.
• the security capabilities for the WirelessHART network may be enriched through integration of the WirelessHART security manager with the KDS.
• the WirelessHART security protocol and architecture uses pre-shared join keys between wireless devices, a network manager, and a security manager associated with a WirelessHART network. The security manager is responsible for the generation, storage, renewal, and revocation of the keys.
• the network manager authenticates devices using a device unique or shared pre-shared join key and distributes network, unicast and broadcast session keys.
• the WirelessHART protocol does not specify authentication, key management and distribution to wired or mobile devices, support for device groups, support for device domain enrollment (e.g., into DNS managed network domains), support for multicast communication, authorization and transactional accounting security services (for the non-IP addressable devices), cryptographic agility to configure key sizes and algorithms for quantum resistant ciphers (only specifies the AES-128 CBC-MAC and counter mode of encryption and keyed message integrity check), or integration of wireless and legacy HART devices. Further the pre-shared join keys must be configured on all the wireless devices and stored on the security manager.
• join key serves as an authentication method to assert that the devices (e.g., sensors, gateways) are listening to the advertisement broadcast on the network to request admission to join the network
• the scope of the device enrollment is restricted to the broadcast range, rather than to a domain level scope.
• the proposed system and method for headless (non-user) devices in OT, loT, and I loT ecosystems uses the Enterprise domain name system (DNS) service over TLS/HTTPS for domain based device enrollment, identification, and authentication based on digitally signed resource records retrieved using Domain Name System Security Extensions (DNSSEC);
• DNS Domain Name System Security Extensions
• DHCP Enterprise dynamic host configuration protocol
• device identification may be performed using a registered DNS hostname (via a PTR, ALIAS or CNAME DNS record) of a DNS domain enrolled device, or the SIM ICCID of a mobile device registered with a mobile service provider.
• the device DNS hostname may be configured manually or dynamically on the DNS server.
• domain enrolled resource slack devices e.g., general purpose operating system (GPOS) based edge gateways, greenfield downstream devices
• GPOS general purpose operating system
• the DNS may be configured dynamically with the device hostname.
• the DHCP server may be configured with an extensible custom attribute for the network domain part (e.g., acme.com) and the device initial DNS hostname may be inferred using the MAC address or serial number of the device as the prefix (e.g., 001 B44113AB7.acme.com or Y9831031.acme.com).
• the KDS may be configured to use the inferred device initial DNS hostname to automatically (extract and) configure the MAC address or serial number of the member device as the member IIUID.
• a DNS alias for the device may be configured manually later with an operator-friendly hostname (e.g., camera-lobby-west.acme.com).
• a contract manufacturer or OEM may provide a manifest (batch) of MAC addresses or serial numbers of the devices for Enterprise IT administrators to pre-configure the DNS server with address (A) and PTR records for the anticipated devices.
• device two-factor authentication may be performed using the group shared or device unique member key as the first factor and the device unique identifier (e.g., DNS hostname or SIM ICCID) as the second factor.
• the device unique identifier e.g., DNS hostname or SIM ICCID
• a common use case with headless operational technology devices is authentication with trusted non-repudiable identity prior to initiating a session key exchange for secure transactions with services or peer devices.
• a client application executes on device A
• a server application executes on device B.
• Both the devices are set-up with a device configuration that includes the basic set of parameters to rendezvous with the key distribution service (KDS) directly or through an on-premises KDS proxy.
• KDS key distribution service
• the proposed method is agent-less, may be deployed on brownfield, greenfield or mobile devices, and the applications may use the retrieved keys for data authentication or encryption with any protocol stack or crypto engine.
• the devices are enrolled into the network domain.
• Both address (A) and pointer (PTR) records are configured in DNS for IP address reverse lookup-based device domain verification.
• the device IMSI identifier is used for device verification with the mobile service provider with a challenge for proof of possession of the authentication key.
• the device may be configured automatically using the KDS interface APIs to retrieve vendor specific information from the DHCP server.
• the device is authenticated by the KDS proxy over a secure channel with a security challenge as the first factor of authentication and authenticated for device domain verification by the DNS server as the second factor of authentication.
• the application may use a pre-shared key identity hint to create or retrieve a key over the secure channel. All key operations for status verification, renewals, and deletion are performed over the secure channel with two-factor device authentication.
• the application may use the retrieved keys for client authentication over TLS-PSK, data authentication and data encryption over insecure UDP, TCP, or non-IP protocols.
• a method is executed for generating, distributing, and managing the lifecycle of a symmetric pre-shared key (PSK) for client authentication (C-PSK) between applications executing on distributed devices including a client application executing on a client device, a server application executing on a server device, a key distribution service (KDS), a KDS proxy, a KDS interface, a symmetric KDS member PSK (M-PSK), a M-PSK identity hint, a tenant identifier, a device group identifier associated with the tenant identifier, a member domain associated with the group identifier, an application identifier associated with the group identifier, a C-PSK identity hint, a key record, a dynamic host configuration protocol (DHCP) server, and a domain name system (DNS) server.
• KDS key distribution service
• KDS KDS proxy
• KDS interface KDS interface
• M-PSK symmetric KDS member PSK
• M-PSK symmetric KDS member PSK
• the method includes authenticating, with the KDS, by the client application executing on the client device, using the configured tenant identifier, symmetric KDS member PSK (M-PSK) and M-PSK identity hint, wherein the client device is registered by a DNS hostname on the DNS server configured with a KDS or KDS proxy, and configured as a member of a device group on the KDS.
• M-PSK symmetric KDS member PSK
• the method further includes acquiring, by the client application the C-PSK from the KDS, using at least the group identifier and C-PSK identity hint, for use as a shared symmetric key for client authentication over a secure transport protocol to communicate with the server application executing on the server device registered by a DNS hostname in the DNS server, wherein the server device is configured as a member of the device group on the KDS.
• the method further includes authenticating, with the KDS, by the server application executing on the server device, using the configured tenant identifier, symmetric KDS member PSK (M-PSK) and the M-PSK identity hint, wherein the server device is registered by a DNS hostname on the DNS server configured with a KDS or KDS proxy, and configured as a member of a device group on the KDS.
• M-PSK symmetric KDS member PSK
• the method further includes acquiring, by the server application the C-PSK from the KDS, using at least the group identifier and C-PSK identity hint, for use as a shared symmetric key for client authentication over a secure transport protocol to communicate with the client application executing on the client device registered by a DNS hostname in the DNS server, wherein the client device is configured as a member of the device group on the KDS.
• the method further includes initiating, by the client application a TLS-PSK session using the acquired C-PSK for the client device in the device group as the PSK for client authentication, to establish secure communications with the server application executing on the server device.
• the method further includes renewing, by the client and server applications, the C- PSK for client authentication upon expiry or for high velocity key rotation, programmatically and automatically using the KDS interface, without requiring human intervention, and without service disruption.
• the approach additionally includes methods wherein: the device member authentication handshake is performed by the KDS interface on the client and server devices using the tenant identifier, the device member PSK (M-PSK) and M-PSK identity hint for the first factor of device authentication, and further wherein the session key is generated using a key exchange handshake between the KDS interface and the KDS or KDS proxy, and further wherein the device member validation for the second factor of device authentication is performed by: performing, by the KDS or KDS proxy, a DNS reverse lookup of the device member IP address to query for the DNS hostname; retrieving, by the KDS or KDS proxy, the DNS hostname from the resource record in the DNS response; and comparing and matching, by the KDS or KDS proxy, the retrieved DNS hostname with the device member identifier in the KDS requests.
• the device member authentication handshake is performed by the KDS interface on the client and server devices using the tenant identifier, the device member PSK (M-PSK) and M-PSK identity hint for the first factor of device authentication
• the approach further includes methods wherein: the device authentication and key exchange handshakes may be performed over a connection-less UDP or connection-oriented TCP transport protocol, without requiring a security transport protocol such as DTLS, TLS or IPsec, and further wherein data authentication and/or data encryption may be performed with the retrieved pre-shared keys over any communications protocol such as LIDP/IP, TCP/IP, or non-IP protocols.
• the KDS interface provides the application programming interface (APIs) for the client and server applications to send requests and receive responses for key operations directly to/from the KDS, or indirectly through the KDS proxy.
• APIs application programming interface
• the client and server devices are registered by a unique DNS hostname in the domain on a local DNS server with an IP address (A) record and a PTR record for DNS hostname reverse lookup.
• the client and server devices are configured as members of the tenancy associated with the tenant identifier and the device group associated with the tenant identifier, and further wherein the device group is configured with a key record that includes a key instance (C-PSK) for client authentication.
• the key record configured for the device group on the KDS includes a key expiration timestamp and a key status to manage automatic key renewal, key rotation, and key revocation operations on the KDS.
• the key record configured for the device group on the KDS includes a key token for the client application to send an authenticated API request to the server application using the key instance as an API shared secret and the key token as an API shared token and further wherein the API request may be a REST API request.
• An authenticated member device’s request for any key operation, based on the group identifier and C-PSK identity hint, may be processed by the KDS and permitted based on a match of the member domain with the domain (i.e., domain name and toplevel domain suffix parts) derived from the resource records retrieved by the DNS reverse lookup for the member device DNS hostname.
• An authenticated member device requests for any key operation, based on the group identifier, C-PSK identity hint, and application identifier, may be processed by the KDS and permitted based on a match with an application identifier associated with the group identifier to allow or deny the key operation.
• the device specific information configured as extended custom attributes for a member device may be retrieved from the DHCP server using extended KDS interface APIs to automate local device configuration and export vendor specific member device information to the KDS.
• An authenticated member device requests for any key operation, based on the group identifier and C-PSK identity hint, may be processed by the KDS and permitted based on a match of the member device tenant identifier with the associated license owner identifier retrieved from the DHCP server as vendor specific member device information.
• a device unique C-PSK identity hint may be generated by the client application to create a device unique PSK for client authentication (C-PSK) using a device unique registration identifier and a derivation function (for example, a HMAC-SHA256 algorithm).
• C-PSK device unique PSK for client authentication
• a derivation function for example, a HMAC-SHA256 algorithm
• a method is executed for generating, distributing, and managing the lifecycle of a symmetric pre-shared key (PSK) for secure communications (S-PSK), for use between applications executing on distributed devices including an client application executing on an client device, a server application executing on a server device, a key distribution service (KDS), a KDS proxy, a KDS interface, a symmetric KDS member M-PSK, a M-PSK identity hint, a tenant identifier, a device group identifier associated with the tenant identifier, a member domain associated with the group identifier, an application identifier associated with the group identifier, a S-PSK identity hint, a derived device key (D- PSK) a key record, a dynamic host configuration protocol (DHCP) server, and a domain name system (DNS) server.
• PSK symmetric pre-shared key
• S-PSK secure communications
• the method includes authenticating, with the KDS, by the client application executing on the client device, using the configured tenant identifier, symmetric KDS member PSK (M-PSK) and M-PSK identity hint, wherein the client device is registered by a DNS hostname on the DNS server configured with a KDS or KDS proxy, and configured as a member of a device group on the KDS.
• the method further includes acquiring, by the client application the S- PSK from the KDS, using at least the group identifier and S-PSK identity hint, for use as a shared symmetric key to secure communications over an insecure transport protocol and communicate with a server application executing on the server device registered by a DNS hostname on the DNS server, wherein the server device is configured as a member of the device group.
• the method further includes authenticating, with the KDS, by the server application executing on the server device, using the configured tenant identifier, symmetric KDS member PSK (M-PSK) and M- PSK identity hint, wherein the server device is registered by a DNS hostname on the DNS server configured with a KDS or KDS proxy, and configured as a member of a device group on the KDS.
• the method further includes acquiring, by the server application the S-PSK from the KDS, using at least the group identifier and S-PSK identity hint, for use as a shared symmetric key to secure communications over an insecure transport protocol and communicate with the client application executing on the client device registered by a DNS hostname on the DNS server, wherein the client device is configured as a member of the device group.
• the method further includes protecting, by the client application executing on the client device, using the acquired S-PSK the authenticity and/or the confidentiality of data in communications with the server application executing on the server device over an insecure connection- oriented or connection-less transport protocol.
• the method further includes protecting, by the server application executing on the server device, using the acquired S-PSK the authenticity and/or the confidentiality of data in communications with the client application executing on the client device over an insecure connection-oriented or connection-less transport protocol.
• the method further includes renewing, by the client and server applications, the S-PSK for secure communications upon expiry, or for high velocity key rotation, programmatically and automatically using the KDS interface, without requiring human intervention, and without service disruption.
• the approach additionally includes methods wherein: the device member authentication handshake is performed by the KDS interface on the client and server devices using the tenant identifier, the device member PSK (M- PSK) and M-PSK identity hint for the first factor of device authentication, and further wherein the session key is generated using a key exchange handshake between the KDS interface and the KDS or KDS proxy, and further wherein the device member validation for the second factor of device authentication is performed by: performing, by the KDS or KDS proxy, a DNS reverse lookup of the device member IP address to query for the DNS hostname; and retrieving, by the KDS or KDS proxy, the DNS hostname from the resource record in the DNS response; and comparing and matching, by the KDS or KDS proxy, the retrieved DNS hostname with the device member identifier in the KDS requests.
• the approach further includes methods wherein: the device authentication and key exchange handshakes may be performed over a connection-less UDP or connection-oriented TCP transport protocol, without requiring a security transport protocol such as DTLS, TLS or IPsec, and further wherein data authentication and/or data encryption may be performed with the retrieved pre-shared keys over any communications protocol such as UDP/IP, TCP/IP, or non-IP protocols.
• the KDS interface provides the application programming interface (APIs) for the client and server applications to send requests and receive responses for key operations directly to/from the KDS, or indirectly through the KDS proxy.
• APIs application programming interface
• the client and server devices are registered by a unique DNS hostname in the domain on a local DNS server with an IP address (A) record and a PTR record for DNS hostname reverse lookup.
• the client and server devices are configured as members of the tenancy associated with the tenant identifier and the device group associated with the tenant identifier, and further wherein the device group is configured with a key record that includes a key instance (S-PSK) to secure communications between the client and server applications.
• the key record configured for the device group on the KDS includes a key expiration timestamp and a key status to manage automatic key renewal, key rotation, and key revocation operations on the KDS.
• the S-PSK Prior to acquiring the S-PSK from the KDS by the client application, the S-PSK is created on the KDS by the server application with the server member device as the key creator and with restricted key usage permissions, for example, for data authentication, data encryption, content (producer or broker) signing, broadcast signing, broadcast encryption, multicast signing, multicast encryption, token signing, or token encryption operations.
• restricted key usage permissions for example, for data authentication, data encryption, content (producer or broker) signing, broadcast signing, broadcast encryption, multicast signing, multicast encryption, token signing, or token encryption operations.
• the acquiring of the S-PSK from the KDS by the client application restricts key usage based on the permissions configured by the key creator.
• the key record configured for the device group on the KDS includes a key token for the client application to send an authenticated API request to the server application using the key instance as an API shared secret and the key token as an API shared token and further wherein the API request may be a REST API request.
• An authenticated member device’s request for any key operation, based on the group identifier and S-PSK identity hint, may be processed by the KDS and permitted based on a match of the member domain with the domain (i.e., domain name and toplevel domain suffix parts) derived from the resource records retrieved by the DNS reverse lookup for the member device DNS hostname.
• An authenticated member device requests for any key operation, based on the group identifier, S-PSK identity hint, and application identifier, may be processed by the KDS and permitted based on a match with an application identifier associated with the group identifier to allow or deny the key operation.
• the device specific information configured as extended custom attributes for a member device may be retrieved from the DHCP server using extended KDS interface APIs to automate local device configuration and export vendor specific member device information to the KDS.
• An authenticated member device requests for any key operation, based on the group identifier and S-PSK identity hint, may be processed by the KDS and permitted based on a match of the member device tenant identifier with the associated license owner identifier retrieved from the DHCP server as vendor specific member device information.
• a derived device key may be created locally, just-in-time on-demand and not stored locally, using the retrieved S-PSK and a device unique identifier as the registration identifier for the client and server applications to sign and/or encrypt messages or tokens for data authentication and/or privacy.
• a method is executed for certificate-less authentication and validation of mobile devices including an application executing on a mobile device, a key distribution service (KDS), a KDS interface, a SIM on the mobile device, a device directory service (DDS), and a mobile service provider (MSP) associated with the mobile device.
• KDS key distribution service
• DDS device directory service
• MSP mobile service provider
• the mobile device member authentication handshake is performed by the KDS interface on the client mobile device using the tenant identifier, the device member PSK (M-PSK) and M-PSK identity hint for the first factor of device authentication, and further wherein the session key is generated using a key exchange handshake between the KDS interface and the KDS or KDS proxy, and further wherein the device member validation for the second factor of device authentication is performed by: receiving, by the KDS from the mobile device, the integrated circuit card identifier (ICCID), international mobile equipment identity (IMEI), and International Mobile Subscriber Identity (I MSI) information of the mobile device; and sending, by the KDS to the mobile device, a nonce for signing by the SIM on the mobile device using the authentication key stored securely within the SIM, wherein the storage location may be in the card circuitry or on an applet on the SIM; and receiving, by the KDS from the mobile device, the signed nonce; and sending, by the KDS to the mobile services provider of the mobile device, the nonce and I MSI for signing using the associated authentication key of the
• the approach additionally includes methods wherein: an authenticated mobile member device’s request for any key operation, based on the group identifier and C- PSK or S-PSK identity hint, may be processed by the KDS and permitted based on a match of the member device tenant identifier with the associated license owner identifier retrieved from the DDS as vendor specific member device information.
• a method is executed for generating, distributing, and managing the lifecycle of a symmetric pre-shared key (PSK) for certificate- 1 ess selective encryption (S-PSK) of partial sections of messages over insecure transport, for use between applications executing on distributed devices including an client application executing on an client device, a server application executing on a server device, a key distribution service (KDS), a KDS proxy, a KDS interface, a symmetric KDS member M-PSK, a M-PSK identity hint, a tenant identifier, a device group identifier associated with the tenant identifier, a member domain associated with the group identifier, an application identifier associated with the group identifier, a S-PSK identity hint, a key record, a dynamic host configuration protocol (DHCP) server, and a domain name system (DNS) server.
• KDS key distribution service
• KDS key distribution service
• KDS KDS proxy
• KDS interface KDS interface
• the method includes retrieving, by an client application, the pre-shared key from the KDS using at least the group identifier and S-PSK identity hint; selectively encrypting with the received preshared key, by the client application, partial sections of messages transmitted over the network; retrieving, by a server application, the pre-shared key from the KDS using at least the group identifier and S-PSK identity hint; and selectively decrypting with the received pre-shared key, by the server application, the selectively encrypted partial sections of messages received over the network.
• the approach additionally includes methods wherein: an authenticated member device’s request for any key operation, based on the group identifier and S-PSK identity hint, may be processed by the KDS and permitted based on a match of the member domain with the domain (i.e. , domain name and top-level domain suffix parts) derived from the resource records retrieved by the DNS reverse lookup for the member device DNS hostname.
• an authenticated member device based on the group identifier and S-PSK identity hint
• An authenticated member device s request for any key operation, based on the group identifier, S-PSK identity hint, and application identifier, may be processed by the KDS and permitted based on a match with an application identifier associated with the group identifier to allow or deny the key operation.
• the device specific information configured as extended custom attributes for a member device may be retrieved from the DHCP server using extended KDS interface APIs to automate local device configuration and export vendor specific member device information to the KDS.
• An authenticated member device s request for any key operation, based on the group identifier and S-PSK identity hint, may be processed by the KDS and permitted based on a match of the member device tenant identifier with the associated license owner identifier retrieved from the DHCP server as vendor specific member device information.
• a method is executed for generating, distributing, and managing the lifecycle of a symmetric pre-shared key (PSK) for certificate- 1 ess selective encryption (S-PSK) of partial sections of messages over insecure transport, for use between applications executing on distributed mobile devices including an client application executing on an client mobile device, a server application executing on a server mobile device, a key distribution service (KDS), a KDS proxy, a KDS interface, a symmetric KDS member M-PSK, a M-PSK identity hint, a tenant identifier, a device group identifier associated with the tenant identifier, a member domain associated with the group identifier, an application identifier associated with the group identifier, a S-PSK identity hint, a key record, a device directory service (DDS), and a mobile service provider (MSP) server.
• PSK symmetric pre-shared key
• S-PSK selective encryption
• the approach additionally includes methods wherein: an authenticated member device’s request for any key operation, based on the group identifier, S-PSK identity hint, and application identifier, may be processed by the KDS and permitted based on a match with an application identifier associated with the group identifier to allow or deny the key operation.
• An authenticated member device s request for any key operation, based on the group identifier and S-PSK identity hint, may be processed by the KDS and permitted based on a match of the member device tenant identifier with the associated license owner identifier retrieved from the DDS as vendor specific member device information.
• a method is executed for generating, distributing, and managing the lifecycle of symmetric pre-shared keys (PSKs) for certificate-less document security with selective object encryption, for use between applications executing on distributed devices including a producer application executing on a producer device, a consumer application executing on a consumer device, a key distribution service (KDS), a KDS proxy, a KDS interface, a symmetric KDS member M-PSK, a M-PSK identity hint, a tenant identifier, a device group identifier associated with the tenant identifier, a member domain associated with the group identifier, an application identifier associated with the group identifier, a key record, a dynamic host configuration protocol (DHCP) server, a device directory service (DDS), and a domain name system (DNS) server.
• KDS key distribution service
• KDS KDS proxy
• KDS interface a symmetric KDS member M-PSK
• M-PSK identity hint a tenant identifier
• the method includes creating, by the producer application on the KDS, pre-shared keys with identity hints; encrypting embedded objects within a document, by the producer application, selectively using the retrieved pre-shared keys, wherein the producer application may be a word processing software or a document exchange program, and further wherein different embedded objects may be encrypted with different pre-shared keys, and further wherein the pre-shared key identity hint is tagged with the respective encrypted embedded object; sending, by the producer application to the consumer application, the document with the embedded encrypted objects and the tagged pre-shared key identity hints; retrieving, by the consumer application from the KDS, using at least the group identifier and pre-shared key identity hint, the pre-shared keys for the preshared key identity hints tagged with the respective encrypted embedded objects in the received document, for decryption; and restricting access privileges to the encrypted embedded objects within the document, by the consumer application, on devices authenticated and validated by the KDS, wherein the consumer application may be a word processing software or a document exchange
• the approach additionally includes methods wherein: an authenticated member device’s request for any key operation, based on the group identifier and preshared key (PSK) identity hint, may be processed by the KDS and permitted based on a match of the member domain with the domain (i.e. , domain name and top-level domain suffix parts) derived from the resource records retrieved by the DNS reverse lookup for the member device DNS hostname.
• PSK preshared key
• An authenticated member device requests for any key operation, based on the group identifier, pre-shared key (PSK) identity hint, and application identifier, may be processed by the KDS and permitted based on a match with an application identifier associated with the group identifier to allow or deny the key operation.
• the device specific information configured as extended custom attributes for a member device may be retrieved from the DHCP server using extended KDS interface APIs to automate local device configuration and export vendor specific member device information to the KDS.
• An authenticated member device s request for any key operation, based on the group identifier and pre-shared key identity hint, may be processed by the KDS and permitted based on a match of the member device tenant identifier with the associated license owner identifier retrieved from the DHCP server or DDS as vendor specific member device information.
• a method is executed for generating, distributing, and managing the lifecycle of a symmetric pre-shared key (PSK) for certificate-less keyed hash message authentication code (HMAC) based content signing for tamper resistance, for use between applications executing on distributed devices including a producer application executing on a producer device, a consumer application executing respectively on a consumer device, a key distribution service (KDS), a KDS proxy, a KDS interface, a symmetric KDS member M-PSK, a M-PSK identity hint, a tenant identifier, a device group identifier associated with the tenant identifier, a member domain associated with the group identifier, an application identifier associated with the group identifier, a key record, a dynamic host configuration protocol (DHCP) server, a device directory service (DDS), and a domain name system (DNS) server.
• PSK symmetric pre-shared key
• HMAC certificate-less keyed hash message authentication code
• the method includes creating, by a producer application on the KDS, a symmetric pre-shared key with an associated pre-shared key (PSK) identity hint; signing, by the producer application, digital content using the created preshared key; generating, by the producer application an associated signature manifest with the tenant identifier, group identifier, digital signature, and pre-shared key identity hint; sending, by the producer application to the consumer applications, the signed digital content and the associated signature manifest; receiving, by the consumer application, the signed digital content and the associated signature manifest with the tenant identifier, group identifier, digital signature, and the pre-shared key identity hint; retrieving, by the consumer application from the KDS, using at least the tenant identifier, group identifier, and pre-shared key identity hint, the pre-shared key for the pre-shared key identity hint in the received signature manifest; and verifying, by the consumer application, the received signed digital content using the retrieved preshared key to regenerate the digital signature and compare for match with the digital signature in the received signature manifest.
• the approach additionally includes methods wherein: an authenticated member device’s request for any key operation, based on the group identifier and preshared key (PSK) identity hint, may be processed by the KDS and permitted based on a match of the member domain with the domain (i.e. , domain name and top-level domain suffix parts) derived from the resource records retrieved by the DNS reverse lookup for the member device DNS hostname.
• PSK preshared key
• An authenticated member device requests for any key operation, based on the group identifier, pre-shared key (PSK) identity hint, and application identifier, may be processed by the KDS and permitted based on a match with an application identifier associated with the group identifier to allow or deny the key operation.
• the device specific information configured as extended custom attributes for a member device may be retrieved from the DHCP server using extended KDS interface APIs to automate local device configuration and export vendor specific member device information to the KDS.
• An authenticated member device s request for any key operation, based on the group identifier and pre-shared key identity hint, may be processed by the KDS and permitted based on a match of the member device tenant identifier with the associated license owner identifier retrieved from the DHCP server or DDS as vendor specific member device information.
• a method is executed for generating, distributing, and managing the lifecycle of symmetric pre-shared keys (PSKs) for certificate-less keyed hash message authentication code (HMAC) based content signing for supply chain tamper resistance, for use between applications executing on distributed devices including a broker application executing on a broker device, a consumer application executing respectively on a consumer device, a key distribution service (KDS), a KDS proxy, a KDS interface, a symmetric KDS member M-PSK, a M- PSK identity hint, a tenant identifier, a device group identifier associated with the tenant identifier, a member domain associated with the group identifier, an application identifier associated with the group identifier, a key record, , a dynamic host configuration protocol (DHCP) server, a device directory service (DDS), and a domain name system (DNS) server.
• PSKs symmetric pre-shared keys
• HMAC certificate-less keyed hash message authentication code
• the method includes receiving, by a broker application, signed digital content and an associated signature manifest; creating, by the broker application, an additional pre-shared key on the KDS; signing, by the broker application, the received signed digital content using the created pre-shared key to generate an extended signed digital content; appending, by the broker application, the tenant identifier, group identifier, additional digital signature, and additional associated pre-shared key identity hint to the received signature manifest to generate an extended signature manifest; sending, by the broker application to the consumer applications, the extended signed digital content and the associated extended signature manifest; receiving, by the consumer application, the extended signed digital content and the associated extended signature manifest with the tenant identifiers, group identifiers, digital signatures, and the pre-shared key identity hints; retrieving, by the consumer application from the KDS, using at least the tenant identifier, group identifier, and pre-shared key identity hint, the pre-shared keys for the identity hints in the received extended signature manifest; and verifying, by the consumer application, the received extended signed digital content using the retrieved
• the approach additionally includes methods wherein: an authenticated member device’s request for any key operation, based on the group identifier and preshared key (PSK) identity hint, may be processed by the KDS and permitted based on a match of the member domain with the domain (i.e., domain name and top-level domain suffix parts) derived from the resource records retrieved by the DNS reverse lookup for the member device DNS hostname.
• PSK preshared key
• An authenticated member device s request for any key operation, based on the group identifier, pre-shared key (PSK) identity hint, and application identifier, may be processed by the KDS and permitted based on a match with an application identifier associated with the group identifier to allow or deny the key operation.
• PSK pre-shared key
• the device specific information configured as extended custom attributes for a member device may be retrieved from the DHCP server using extended KDS interface APIs to automate local device configuration and export vendor specific member device information to the KDS.
• An authenticated member device s request for any key operation, based on the group identifier and pre-shared key identity hint, may be processed by the KDS and permitted based on a match of the member device tenant identifier with the associated license owner identifier retrieved from the DHCP server or DDS as vendor specific member device information.
• a method is executed for agent-less device risk monitoring including a machine learning model, a multi-dimensional feature matrix, harvested device intelligence, a threat intelligence provider, a device management system, and a network activity monitoring system.
• the method includes selecting an algorithm to build a machine learning model using a multi-dimensional feature matrix with harvested device intelligence as training datasets; building a multidimensional feature matrix that includes device tenancy, group memberships, key type and usage profile, volume of key usage, rate of key rotation, and application identifiers (e.g., file name, file hash); extending the feature matrix with imported application-based indicators of compromise from the external forensics-based threat intelligence provider that includes content integrity measurement and vulnerability assessments comprising of scores categorized by, for example, application reputation, static/dynamic analysis, runtime introspection analysis, domain generation algorithm (DGA) analysis, obfuscation level, unpacking level, IP address and domain reputation, geo-location, autonomous system numbers (ASNs), and IP address age; extending the feature matric by
• a common use case with wireless operational technology devices is secure provisioning at the factory on a manufacturer network, and onboarding in the field on a production network.
• a main or purpose-built onboarding application on a device A must connect to a secure wireless access point (WAP) in the production network.
• WAP secure wireless access point
• the manufacturer of the device is provided with the guest SSID and guest pre-shared key to connect the device to the guest wireless network.
• the device must be switched with zero-touch from the guest wireless network to the secure wireless network during device onboarding in the production network.
• the wireless access point is configured for multi-SSID mode of operation with different SSIDs and pre-shared keys for the guest and secure wireless networks.
• Device A is setup with a device configuration that includes the basic set of parameters to rendezvous with the KDS directly or through an on-premises KDS proxy, and the internal key identity hint to retrieve the internal pre-shared key for the internal SSID.
• the guest SSID and guest pre-shared key are configured in the main or onboarding application.
• Device A is enrolled into the network domain. Both address (A) and pointer (PTR) records are configured in DNS for IP address reverse lookup-based device domain verification.
• Device A authenticates with the wireless access point using the guest pre-shared key to connect to the guest wireless network.
• Device A may be configured automatically using KDS interface APIs to retrieve vendor specific information from the DHCP server.
• the internal SSID may be retrieved from DHCP attributes for the scope.
• Device A is authenticated by the KDS proxy over a secure channel with a security challenge as the first factor of authentication and authenticated for device domain verification by the DNS server as the second factor of authentication.
• the application uses the internal pre-shared key identity hint to retrieve the pre-shared key for the secure wireless network over the secure channel.
• the application uses the retrieved internal pre-shared key to authenticate with the wireless access point over the secure wireless network.
• a method for distributing a symmetric internal wireless access point (WAP) pre-shared key (IWAP-PSK) for secure wireless authentication by a device with a WAP in a production network including a supplicant program executing on the device, the WAP configured for multiSSID (service set identifier) mode of operation, a key distribution service (KDS), a KDS proxy, a KDS interface, a symmetric KDS member PSK (M-PSK), a M-PSK identity hint, a tenant identifier, a device group identifier associated with the tenant identifier, a member domain associated with the group identifier, an application identifier associated with the group identifier, the IWAP-PSK identity hint, an internal WAP SSID (IWAP-SSID), a guest WAP pre-shared key (GWAP-PSK), a guest WAP SSID (GWAP-SSID), a key record, a dynamic host configuration protocol (
• the method includes authenticating, by the supplicant program with the WAP, using the GWAP-SSID and GWAP-PSK to establish initial wireless access for the device over the production network.
• the method further includes authenticating, with the KDS, by the supplicant program executing on the device, using the configured tenant identifier, symmetric KDS member PSK (M-PSK) and M-PSK identity hint, wherein the client device is registered by a DNS hostname on the DNS server configured with a KDS or KDS proxy, and configured as a member of a device group on the KDS.
• M-PSK symmetric KDS member PSK
• the method further includes retrieving, by the supplicant program the IWAP-PSK from the KDS, using at least the group identifier and IWAP-PSK identity hint, for use as a shared symmetric key for authentication with the wireless access point.
• the method further includes authenticating, by the supplicant program with the WAP, using the IWAP-SSID and retrieved IWAP-PSK to establish secure wireless access for the device over the production network to perform a switch-over from the guest SSID to internal SSID wireless network.
• the approach additionally includes methods wherein: on the KDS the device is configured as a member of the tenancy associated with the tenant identifier and the device group associated with the tenant identifier, and further wherein the device group is configured with a key record that includes a key instance (IWAP-PSK) for secure wireless authentication.
• IWAP-PSK key instance
• An authenticated member device s request for any key operation, based on the group identifier and IWAP-PSK identity hint, may be processed by the KDS and permitted based on a match of the member domain with the domain (i.e., domain name and top-level domain suffix parts) derived from the resource records retrieved by the DNS reverse lookup for the member device DNS hostname.
• domain i.e., domain name and top-level domain suffix parts
• the GWAP-SSID, GWAP-PSK, IWAP-SSID, M-PSK, and M-PSK identity hint may be factory configured attributes on the executable application image or system firmware on a real time operating system (RTOS) platform or specified through a configuration file on a general purpose operating system (GPOS) platform.
• RTOS real time operating system
• GPOS general purpose operating system
• the primary and secondary KDS/KDS proxy URLs, the tenant identifier, and the group identifier and identity hints associated with the production WAP for secure access may be discovered using network characteristics based on custom attributes configured on a DHCP server, or a DNS server, associated with the member device LAN.
• An authenticated member device s request for any key operation, based on the group identifier, IWAP-PSK identity hint, and application identifier, may be processed by the KDS and permitted based on a match with an application identifier associated with the group identifier to allow or deny the key operation.
• the device specific information configured as extended custom attributes for a member device may be retrieved from the DHCP server using extended KDS interface APIs to automate local device configuration and export vendor specific member device information to the KDS.
• An authenticated member device s request for any key operation, based on the group identifier and IWAP-PSK identity hint, may be processed by the KDS and permitted based on a match of the member device tenant identifier with the associated license owner identifier retrieved from the DHCP server as vendor specific member device information.
• the supplicant program may detect a change in the IWAP-PSK based on failure to authenticate with the WAP using the IWAP-SSID and last retrieved and stored IWAP-PSK, and automatically switch-over to the guest wireless network using the GWAP-SSID and GWAP-PSK, authenticate with the KDS, retrieve a IWAP-PSK from the KDS, and authenticate with the WAP using the IWAP-SSID and retrieved IWAP-PSK to switch-over to the secure wireless network.
• the supplicant program for security reasons may not store the last retrieved IWAP-PSK locally on the device, and dynamically at power cycle or application restart, authenticate with the guest wireless network using the GWAP-SSID and GWAP-PSK, authenticate with the KDS, retrieve an IWAP-PSK from the KDS, and authenticate with the WAP using the IWAP-SSID and retrieved IWAP-PSK to switch-over to the secure wireless network.
• the supplicant program may be a Wi-Fi supplicant, or a Wi-Fi supplicant function implemented within a production application or system firmware.
• the member device DNS hostname on the local DNS server is equivalent to, and may also serve as, the local device identifier (LDevID) as described in the Institute of Electrical and Electronics Engineers (IEEE) 802.1 AR standard for device identification.
• LevID local device identifier
• the disclosed system and method provide for the automated management, on the KDS, of the status, renewal, and revocation (administratively or explicitly by the key creator) of the PSKs distributed to member devices by the KDS.
• This resolves major operational and administrative challenges commonly attributed in PKI based solutions to the additional cost of certificate revocation, the overheads associated with managing and distributing a large certificate revocation list (CRL) to resource constrained devices, querying the certificate status online or processing the CRL by real time applications that require low latencies at runtime, and the complexities associated with implementing a key renewal method for key lifecycle management on headless devices.
• CTL certificate revocation list
• the disclosed system and method provide for the just-in-time on-demand retrieval of symmetric pre-shared keys by embedded applications and embedded devices without requiring local persistence (storage) of the retrieved keys.
• Cloud based services and microservices may require pre-shared keys for digitally signed tokens, for example shared access signature (SAS) tokens, to provision devices and establish authenticated connections.
• Microservices (for example, authorization services) may require pre-shared keys to encrypt access tokens for secure distribution to requestors (e.g., client applications on devices).
• the key exchange ceremony with the cloud-based service may require securing retrieving and storing a nonce (i.e., a symmetric pre-shared key) on a local secure element (e.g., a trusted platform module or TPM) and using the secured nonce to sign and/or encrypt a service token in future transactions.
• a local secure element e.g., a trusted platform module or TPM
• a local hardware, firmware, or software based secure element may not be available on legacy/brownfield devices and a significant majority of resource slack low-cost greenfield devices.
• resource constrained devices lack writable storage space on non-volatile random-access memory (NVRAM), flash, or hard disk drive (HDD) to persist data objects.
• NVRAM non-volatile random-access memory
• HDD hard disk drive
• the key distribution service (KDS) interface provides the application programming interface (APIs) for the applications to send requests and receive responses for certificate operations directly to/from the KDS, or indirectly through the KDS proxy.
• the certificates may be imported (in single or batch mode), renewed, or rekeyed through the KDS portal.
• the trusted applications may retrieve trusted certificates, the leaf certificate and associated private key, and verify certificate status using the KDS APIs.
• the KDS enforces policy-based authorization with a pre-configured list of trusted applications.
• the applications may store the retrieved trusted certificates in a local trust store, and the retrieved leaf certificates and associated private keys in a local key store, for use at runtime.
• the applications may use a local secure element (such as a TPM or SIM) to protect the retrieved private keys.
• the applications may retrieve the leaf certificate and associated private key dynamically (i.e. , not persist the retrieved artifacts in a local key store such as a secure file system, secure element, or NVRAM).
• the key distribution service (KDS) interface provides the application programming interface (APIs) for the applications to send requests and receive responses for certificate operations directly to/from the KDS, or indirectly through the KDS proxy.
• the certificates may be imported (in single or batch mode), renewed, or rekeyed through the KDS portal.
• the trusted applications may retrieve trusted certificates, the leaf certificate and associated private key, and verify certificate status using the KDS APIs.
• the KDS enforces policy-based authorization with a pre-configured list of trusted applications.
• the applications may store the retrieved trusted certificates in a local trust store, and the retrieved leaf certificates and associated private keys in a local key store, for use at runtime.
• the applications may use a local secure element (such as a TPM or SIM) to protect the retrieved private keys.
• the applications may retrieve the leaf certificate and associated private key dynamically (i.e., not persist the retrieved artifacts in a local key store such as a secure file system, secure element, or NVRAM).
• the disclosed method configures and uses extended attributes as security extensions in the X.509 certificate subject alternate name (SAN) field to specify a host address, network address, and network mask for scope and address pool based network segmentation for authorization of a client device for managed access to a server device; wherein the vendor class identifier associated with the client device, the scope, and the address pool are configured on a DHCP server associated with the deployment infrastructure.
• the method provides for use of a public or private certificate authority (CA) issued X.509 certificate, or a self-signed certificate (i.e., issued by a null CA, such as, for example, OpenSSL utilities, wherein the certificate is signed with its own private key and not by a trusted CA).
• CA public or private certificate authority
• null CA such as, for example, OpenSSL utilities
• This method provides regulation of the self-signed certificate with device two-factor authentication in the local network and runtime validation of the extended host (IP) and network (subnet) address attributes in the certificate SAN for evidence of practical control over the host address, address pool, and network subnet.
• IP extended host
• subnet network address attributes
• the anti-spoofing security countermeasures (for IP addresses, DHCP, and DNS) must be implemented on the local network.
• I0T/II0T lack computing power, memory, and storage required for application logs and messaging protocols, such as MQTT or AMQP, to publish message to topics.
• the disclosed system and method provide an agent-less approach, for resource constrained and resource slack devices, with APIs in any modern programming language to send device metadata to a microservice hosted onpremises or on-cloud, and a method to relay device metadata through webhooks to service provider in real-time for data analytics by AI/ML engines.
• the method provides simplified APIs for security by design, with device two-factor authentication, a secure channel to manage and distribute quantum proof keys and quantum resistant certificates for authenticated access, authenticated APIs, and data signatures to establish supply chain provenance, trusted data with tamper-proof signatures to train AI/ L models, and protection from the factory floor to field environments with a technology that is applicable to multiple industries from retail, to manufacturing, energy, healthcare, automotive, and beyond.
• FIG. 1A is a schematic diagram illustrating an example distributed intelligent network and key distribution service in accordance with various exemplary embodiments of the disclosed system.
• FIG. 1 B is a schematic diagram illustrating an example device label scan based device discovery and provisioning system in accordance with various exemplary embodiments of the disclosed system.
• FIG. 1C is a schematic diagram illustrating an example device label scan based device onboarding workflow in accordance with various exemplary embodiments of the disclosed system.
• FIG. 1 D is a schematic diagram illustrating an example supply chain tamper resistant content distribution service in accordance with various exemplary embodiments of the disclosed system.
• FIG. 1 E is a schematic diagram illustrating an example multi-party, multiperson, and multi-part content inspection and approval workflow in accordance with various exemplary embodiments of the disclosed system.
• FIG. 2A is a schematic diagram illustrating a common method to establish a connection between devices over secure transport with server certificate verification illustrating the absence of device authentication.
• FIG. 2B is a schematic diagram illustrating a common method to establish a connection between devices over secure transport with client certificate and server certificate verification illustrating the absence of device key protection without requiring a secure element on the device.
• FIG. 3A is a schematic diagram illustrating a method to establish a connection between devices over secure transport with pre-shared key (PSK) based client (and device) authentication, and server certificate verification, in accordance with various exemplary embodiments of the disclosed system.
• PSK pre-shared key
• FIG. 3B is a transaction state machine illustrating a method to authenticate a member device with a key distribution service (KDS) or KDS proxy using a configured KDS member pre-shared key (M-PSK) and M-PSK identity hint, and generate a session key using a secure key exchange method, to perform device validation using a domain name system (DNS) server and securely communicate with the KDS or KDS proxy to perform transactions, in accordance with various exemplary embodiments of the disclosed system.
• KDS key distribution service
• M-PSK KDS member pre-shared key
• DNS domain name system
• FIG. 3C is a transaction state machine illustrating a method to authenticate a mobile member device with a key distribution service (KDS) or KDS proxy using a configured KDS member pre-shared key (M-PSK) and M-PSK identity hint to perform device authentication and validation using a mobile service provider (MSP), and generate a session key using a secure key exchange method to securely communicate with the KDS or KDS proxy to perform transactions, in accordance with various exemplary embodiments of the disclosed system.
• KDS key distribution service
• M-PSK configured KDS member pre-shared key
• MSP mobile service provider
• FIG. 3D is a diagram of an exemplary computer system in which embodiments of the method of retrieving a pre-shared key to initiate client authentication over TLS using TLS-PSK can be implemented.
• FIG. 3E is a diagram of an exemplary computer system in which embodiments of the method of retrieving pre-shared keys to accept client authentication over TLS using TLS-PSK can be implemented.
• FIG. 3F is a diagram of an exemplary computer system in which embodiments of the method of device unique pre-shared keys for client authentication (C-PSK) over TLS-PSK between a client and server application can be implemented. [0125] FIG.
• 3G is a transaction state machine illustrating a method to authenticate a mobile member device with a key distribution service (KDS) or KDS proxy using a configured KDS member pre-shared key (M-PSK) and M-PSK identity hint to perform device authentication and validation using the mobile device identifiers (e.g., I MEI , ICCID), and generate a session key using a secure key exchange method to securely communicate with the KDS or KDS proxy to perform transactions, in accordance with various exemplary embodiments of the disclosed system.
• KDS key distribution service
• M-PSK configured KDS member pre-shared key
• M-PSK identity hint to perform device authentication and validation using the mobile device identifiers (e.g., I MEI , ICCID)
• FIG. 3H is a diagram of an exemplary computer system in which embodiments of the method of device two-factor authentication, retrieval of trusted intermediate and root certificates, leaf certificates and the associated private keys, using the KDS interface APIs, KDS, and certificate authority (CA) can be implemented.
• FIG. 4 is a schematic diagram illustrating a common method to establish an insecure connection between devices over a connection-oriented or connection-less transport protocol.
• FIG. 5A is a schematic diagram illustrating a method to establish a secure connection between devices over a connection-oriented or connection-less transport protocol using a pre-shared key (PSK) for mutual device authentication and data protection in accordance with various exemplary embodiments of the disclosed system.
• PSK pre-shared key
• FIG. 5B is a diagram of an exemplary computer system in which embodiments of the method of retrieving, using, verifying, and renewing a pre-shared key to initiate secure communication over an insecure transport protocol can be implemented.
• FIG. 5C is a diagram of an exemplary computer system in which embodiments of the method of retrieving, using, verifying, and renewing a pre-shared key to accept secure communication over an insecure transport protocol can be implemented.
• FIG. 5D is a diagram of an exemplary computer system in which other embodiments of the method of creating, using, and deleting a pre-shared key to accept secure communication over an insecure transport protocol can be implemented.
• FIG. 5E is a diagram of an exemplary computer system in which embodiments of the method of device unique pre-shared keys for authenticated secure communications (D-PSK), derived using a group key (S-PSK) and device unique registration ID, between a client and server application can be implemented.
• FIG. 6 is a schematic diagram illustrating a method to perform authentication and domain validation of a device using a key distribution service proxy for the device internet protocol (IP) address based reverse lookup to retrieve the authoritative device DNS hostname from a configured local DNS server over the local area network in accordance with various exemplary embodiments of the disclosed system.
• IP internet protocol
• FIG. 7 A is a schematic diagram illustrating entity relationships between components of the model in accordance with various exemplary embodiments of the disclosed system.
• FIG. 7B is a schematic diagram illustrating further entity relationships between components of the model in accordance with various exemplary embodiments of the disclosed system.
• FIG. 8A is a diagram of an exemplary computer system in which embodiments of the method of pre-shared key based selective encryption/decryption of partial sections of messages transmitted/received between client/server applications over a local area network can be implemented.
• FIG. 8B is a diagram of an exemplary computer system in which embodiments of the method of pre-shared key based selective encryption/decryption of objects embedded within documents exchanged between producer/consumer applications can be implemented.
• FIG. 8C is a diagram of an exemplary computer system in which embodiments of the method of pre-shared key based content signing by a producer application and pre-shared key based content verification by a consumer application for tamper resistance can be implemented.
• FIG. 8D is a diagram of an exemplary computer system in which embodiments of the method of additional pre-shared key based content signing by a broker application and multiple pre-shared keys based content verification by a consumer application for supply chain tamper resistance can be implemented.
• FIG. 8E is a diagram of an exemplary computer system in which embodiments of the method of dynamically and securely retrieving an internal wireless access point (WAP) pre-shared key (PSK) over a guest wireless network for device authentication with a multi-SSID (service set identifier) mode WAP for switch-over to a secure wireless network can be implemented.
• WAP wireless access point
• PSK pre-shared key
• FIG. 9A is a diagram of an exemplary computer system in which embodiments of the method predicting the device risk score and classifying a security event by building a machine learning model using a multi-dimensional feature matrix with device intelligence as training and test datasets can be implemented.
• FIG. 9B is a diagram of an exemplary computer system in which embodiments of the method of securely harvesting, processing, and distributing trusted device metadata to webhooks can be implemented.
• FIG. 10 is a diagram of an exemplary computer system in which embodiments of the method of certificateless device security and data protection can be implemented.
• applications executing on a first device can connect to an authorized key distribution service (KDS) to request symmetric keys (generated by the KDS, or created by service applications) to communicate with applications executing on a second device; applications on authenticated member devices may retrieve symmetric keys from an authorized KDS to communicate with other authenticated member devices of the group; symmetric keys may to set to expire based on a time-to-live (TTL) interval that triggers an automatic rekey; applications may use the retrieved symmetric key as a pre-shared key for direct message exchange (e.g., over UDP or TCP transport protocols) or over the TLS-PSK secure transport protocol; the communications between the applications and the authorized KDS occur over a secure channel (for example, on resource constrained devices over UDP or TCP with M-PSK based authentication and ephemeral Diffie-Hellman (DH) or Elliptic-Curve DH (ECDH) key exchange for session key
• KDS authorized key distribution service
• DH ephemeral Dif
• a KDS proxy securely proxies the KDS Interface Application Programming Interface (API) requests from authenticated and validated devices to the externally hosted (e.g., cloud) KDS using an API access token and an API access secret to digitally sign the mapped Representational State Transfer (REST) API requests to the KDS.
• the KDS proxy appends the proxy’s group identifier and PSK identity hint (for the KDS proxy listener to retrieve the corresponding API token and API secret to authenticate the REST API request) and, at least, the authenticated member identifier and member DNS hostname retrieved from the local DNS server in the proxied API requests to the externally hosted KDS.
• a secondary KDS may be configured for data synchronization and service level failover.
• the KDS Interface library that initiates transactions with the KDS switches over to the secondary KDS on a timeout on the primary KDS. An automatic switch back to the primary KDS may be attempted during subsequent transactions.
• a shared device group type comprises of a list of devices identified by the DNS hostname; a private device group type (e.g., for local storage encryption, or intra-device communications) comprises of a single device; and a tenant comprises for a plurality of device groups.
• Other device group types may be defined for specific purposes (e.g., shared, private, onboarding, authenticator, anonymous, community, any suitable device groups).
• the client and server applications engaged in an Internet Key Exchange (IKE) protocol handshake may retrieve pre-shared keys (PSKs) from the KDS for PSK-based client authentication over IKE.
• IKE Internet Key Exchange
• a device may be a member of multiple device groups; the applications may retrieve keys to access multiple device members (or groups); the applications may use the retrieved symmetric pre-shared key over any transport protocol (e.g., User Datagram Protocol or UDP, Transmission Control Protocol or TCP, Internet Protocol or IP, non-IP); the applications may use the retrieved symmetric key for PSK-based client authentication over a TLS-PSK session, or for PSK-based client authentication over an IKE session; and the applications may use the retrieved key with any open-source or third-party secure transport or crypto library.
• transport protocol e.g., User Datagram Protocol or UDP, Transmission Control Protocol or TCP, Internet Protocol or IP, non-IP
• the applications may use the retrieved symmetric key for PSK-based client authentication over a TLS-PSK session, or for PSK-based client authentication over an IKE session
• the applications may use the retrieved key with any open-source or third-party secure transport or crypto library.
• LOB line of business
• brownfield or greenfield applications (e.g., client, server) executing on in-field devices for application security by design
• KDS key distribution service
• the KDS Interface library provides application developers with a simple set of APIs and transparently manages all the authentication ceremonies, application identifiers, and secure communications (request-response handshake) with the KDS on behalf of the application.
• the connected applications may use the retrieved PSK with any third-party cryptographic library to perform local key operations and use any underlying protocol stack for communications. This level of compatibility and simplicity is essential to minimize the coding effort required by application developers to quickly and easily harden applications for enhanced security.
• the KDS Interface application programming interface may include at least the following set of operations:
• KDS device configuration e.g., as a JSON file, which may optionally, for security reasons, be digitally signed and include the signer’s certificate or public key for signature verification
• KDS device configuration e.g., as a JSON file, which may optionally, for security reasons, be digitally signed and include the signer’s certificate or public key for signature verification
• key exchange method e.g., DH, ECDH, CRYSTALS-Kyber
• KDS member PSK M-PSK
• M-PSK identity hint tenant identifier
• tenant identifier e.g., M-PSK-based device authentication with the KDS.
• the Uniform Resource Locator (URL) for the KDS and KDS proxy specify the respective service endpoint addresses.
• the tenant identifier identifies a tenant in a multitenant “software as a service (SaaS)” KDS subscription model.
• the member identifier identifies the tenant member device to the KDS.
• These generic KDS configuration settings may be loaded from a KDS configuration file provided to the applications executing on the member device.
• the device may be a member of multiple device groups, and a device group may be assigned multiple key records (i.e. , identity hints), therefore the group identifier and identity hint must be provided explicitly during a KDS query operation.
• the group identifiers associated with the member device, and identity hints associated with a group identifier may be included in an application-specific configuration settings file loaded by the application for cross-validation at runtime.
• the key limit specifies the maximum number of active retrieved keys for storage in the KDS context’s internal key cache.
• a static public authentication key and secret authentication key may be generated based on the configured key exchange method wherein each party knows the other party’s static public authentication key.
• KDS Handle Returns a handle to the KDS context (KDS Handle).
• the context caches the retrieved key records.
• CreateKey KDS Handle, Group Identifier, Identity Hint, Key Template
• the key template may specify at least the key algorithm, key size, key usage, and key expiration.
• the key sizes may be specified, for example, as 56, 80, 112, 128, 192, 256, or higher bits.
• the key algorithm may be specified as, for example, as AES, DES, 3DES, Blowfish, CAST, RC4, RC5, RC6, or ChaCha20.
• the cipher types for the specified key algorithms may be further specified, for example, as GCM, CCM, ECB, CBC, CTR, OFNB, CFNB, EAX, XTS, CBC-MAC.
• the key usage may be specified, for example, as client authentication, data authentication, data encryption, content (producer or broker) signing, broadcast signing, broadcast encryption, multicast signing, multicast encryption, token signing, or token encryption.
• the key template specified may include extended attributes provided by the application including, for example, description of activity, network type (e.g., wired, wireless), network protocol (e.g., IP, CAN Bus, Modbus, HART, WirelessHART), and transport protocol (e.g., UDP, TCP, TLS, DTLS, IPsec) for KDS based key related activity audit logs.
• network type e.g., wired, wireless
• network protocol e.g., IP, CAN Bus, Modbus, HART, WirelessHART
• transport protocol e.g., UDP, TCP, TLS, DTLS, IPsec
• LKID Local Key Identifier
• key record (wherein the key expiration period may be specified as a timestamp, and 0 may imply that an explicit release by the key creator is required).
• the keys may also be pregenerated using the KDS administration portal.
• the key creator is set to the member identifier or KDS administrator accordingly in the key record.
• the LKID is a local fast lookup index stored within the KDS context wherein the retrieved key records may be cached in the process space (execution context).
• the key record may be returned as a read-only reference to the application. If a key already exists for the specified group identifier, identity hint, and key template, the KDS returns an error code.
• the KDS may be configured to generate a security event notification on key creation errors, as a security countermeasure against brute-force attacks to guess the group identifier and identity hint to retrieve keys.
• RetrieveKey KDS Handle, Group Identifier, Identity Hint
• ⁇ Returns a LKID and key record.
• the key record may be returned as a read-only reference to the application.
• the KDS may be configured to generate a security event notification as a security countermeasure against brute-force attacks to guess the group identifier and identity hint to retrieve keys.
• retrieveCommunityKey KDS Handle, Community Identifier, Cotenant Identifier, Group Identifier, Identity Hint
• ⁇ retrieves a key record based on the group identifier and identity hint associated with a different tenant (cotenant identifier) within a community (community identifier) of tenants.
• ⁇ Returns a LKID and key record.
• the key record may be returned as a read-only reference to the application.
• the KDS may be configured to generate a security event notification as a security countermeasure against brute-force attacks to guess the group identifier and identity hint to retrieve keys.
• retrieveKeys KDS Handle, Group Identifier
• ⁇ Returns a list of key records (to pre-populate PSKs and identity hints for TLS- PSK based client authentication, or cache M-PSKs for the first factor of authentication by the KDS proxy).
• the KDS may be configured to generate a security event notification as a security countermeasure against brute-force attacks to guess the group identifier to retrieve key records.
• VerifyKey KDS Handle, Group Identifier, Identity Hint
• KDS key status (e.g., ACTIVE, SUSPENDED, EXPIRED, DELETED, REVOKED, or INVALID).
• a key status other than ACTIVE or SUSPENDED may be considered by applications as a DEACTIVATED status for previously retrieved keys.
• the KDS may be configured to generate a security event notification as a security countermeasure against brute-force attacks to guess the group identifier and identity hint to retrieve keys.
• the applications may setup a timer based on the calculated key expiration time and renew the key explicitly in the registered callback handler using the key identity hint as context to cross-reference the associated expired key.
• RenewKey KDS Handle, Group Identifier, Identity Hint
• Renews i.e. , re-keys
• a key record (due to key expiration or for on-demand renewal) created (owned) by the member identifier for use as a PSK for client authentication or secure communications.
• a renewed key record is retrieved (due to expiration).
• the KDS may be configured to generate a security event notification as a security countermeasure against brute-force attacks to guess the group identifier and identity hint to retrieve keys.
• DeleteKey KDS Handle, Group Identifier, Identity Hint, Delete Type
• the type of deletion may be specified as LOCAL or SERVICE.
• the key record is cleared (freed) from the local cache of the KDS I context.
• the key record is deleted on the KDS.
• a key record may be deleted programmatically by the creator (owner) member identifier or by an authorized KDS portal administrator for keys created (owned) by the KDS service.
• the delete operation on the KDS may be configured and implemented either as a purge (permanent delete) of the key record or as an adjustment of key status to preserve key history.
• the KDS may be configured to generate a security event notification as a security countermeasure against brute-force attacks to guess the group identifier and identity hint to retrieve keys.
• the KDS Interface application programming interface may be extended to automate local device configuration, export vendor specific member device information to the KDS, integrate with ecosystem services (e.g., DHCP services, cloud based device provisioning and hub services), and to verify content signing, and include at least the following set of operations:
• DeriveDeviceKey KDS Handle, Group Identifier, Identity Hint
• cloud services e.g., microservices for device registration, device provisioning, hub attached business applications for telemetry, data analytics, digital twins.
• the vendor specific information for a member device configured on the DHCP service may include, for example, the KDS server primary address, KDS server secondary address, tenant identifier, group identifier, SPSK identity hint, internal WAP SSID, internal WAP PSK identity hint, network domain, device type, country of manufacture, model identifier, serial number, supported network types, supported network protocols, and license owner identifier.
• the DHCP standard option code 43 for encapsulated vendor specific information including the custom option code available for private use may be configured for the defined vendor class identifier, scope, and address pool by policy on the DHCP service.
• VerifySignatureManifest (KDS Handle, Content File, Signature Manifest File) to verify content signing and supply chain tamper resistance using a signature manifest file.
• KDS Handle, Group Identifier QueryUpdate (KDS Handle, Group Identifier) to check for updates.
• the KDS verifies whether update pending for member ID based on the last content retrieved-on date and pending published content associated with the device type and group.
• the KDS interface application programming interface includes helper utilities (or convenience APIs) for the applications executing on the member device to optionally perform local key operations using the KDS context.
• the Local Key Identifier is a local fast lookup index stored within the KDS context wherein the retrieved key records may be cached in the process space (execution context).
• HMAC keyed-hash message authentication code
• S-PSK secret preshared key associated with the specified local key identifier
• This helper API may be utilized by applications during signing (as the producer) and verification (as the consumer) operations.
• ⁇ Encrypts the specified plaintext message using the secret pre-shared key (S- PSK) associated with the specified local key identifier (LKID).
• ⁇ Decrypts the specified ciphertext message using the secret pre-shared key (S- PSK) associated with the specified local key identifier (LKID).
• S- PSK secret pre-shared key
• LKID local key identifier
• the KDS interface application programming interface may include application identifiers comprising of, for example, a file path (e.g., file directory), a file name, and a file hash in all requests to the KDS or KDS proxy.
• the KDS may store the application identifiers in activity records of device transactions (e.g., member identifier, tenant identifier, group identifier, identity hint, request type, transaction status, request timestamp) for device risk monitoring.
• the KDS interface may determine the application identifiers based on the process identifier (PID) and operating system specific lookup to retrieve the associated application module load path and application name.
• PID process identifier
• the application identifiers provide threat intelligence to track unauthorized (or malicious) applications on the device that attempt to access the KDS.
• the KDS may be configured with security policies to inspect the application identifiers received as part of the KDS interface request against externally sourced threat intelligence, namely application image/binary reputation/deny lists, deny the key request, and block unauthorized or malware applications from retrieving the pre-shared keys.
• externally sourced threat intelligence namely application image/binary reputation/deny lists
• deny the key request and block unauthorized or malware applications from retrieving the pre-shared keys.
• the operational pre-shared keys may be protected by authorized applications from abuse/exploit by co-resident unauthorized or malware applications.
• a pre-shared key PSK
• M-PSK KDS member PSK
• the preconfigured M-PSK for member devices is associated with a pre-configured M-PSK identity hint for use during the device authentication handshake.
• the KDS may be preconfigured with a plurality of M-PSKs and associated M-PSK identity hints for each configured tenant in a multi-tenancy and shared (and synchronized) with the KDS proxy associated with the tenant.
• the M-PSK identity hint and associated M-PSK may be pre-configured on the KDS and member devices.
• the M-PSK identity hint and associated M-PSK may be unique for each member device to establish a first factor of authentication for enhanced security or may be shared between member devices within a tenancy or device group.
• the DNS reverse lookup using the member device IP address for the member device hostname through the configured authoritative DNS server for member device domain validation establishes the second factor of authentication. In this manner, multi-factor authentication of a member device is performed by a KDS (or KDS proxy).
• the member devices may be pre-configured at the factory (by initializing program variables in the application image on RTOS platforms) or in the field (by loading a configuration file on GPOS platforms) during onboarding with a default and shared M-PSK identity hint and M-PSK for initial (day-zero) pre-authentication with the KDS.
• a member device may generate a device unique private M-PSK identity hint and create an associated M-PSK (using the KDS interface API) with the reserved group identifier of “preauthentication” (and associated group type of “onboarding”) for subsequent preauthentication with the KDS.
• the PSK distributed to a client or server application, executing respectively on a member client or server device, for the client application to authenticate with the server application is referred to as the client authentication PSK (C-PSK).
• C-PSK client authentication PSK
• S-PSK PSK for secure communications
• the C-PSKs and S-PSKs are generated, or may optionally be pre-configured on the KDS, and distributed to authenticated and domain validated member devices based on group membership and tenancy association, to post-configure the member devices.
• applications executing on a member device may acquire and use a plurality of PSKs (C-PSKs, S-PSKs) based on different group identifiers and identity hints.
• server applications executing on a member device may acquire and use a plurality of PSKs (C-PSKs) based on different identity hints for a group identifier, because a group identifier may be associated to a plurality of key records as illustrated in FIG. 7A.
• C-PSKs PSKs
• the M-PSK, the device member domain validation by an authoritative DNS server, the securely distributed C-PSK or S-PSK, and the negotiated session key for TLS/DTLS based connections together establish a three- factor authentication of a member device, and four-fold increase in security, for high assurance of trust in a member device.
• the purpose of the device authentication handshake using the pre-configured M-PSK and associated PSK identity hint between a member device and a KDS is to pre-authenticate the member device prior to initiating any DNS reverse lookup requests with the configured DNS servers.
• This provides a safeguard mechanism against rogue devices attempting to connect with a KDS using a stolen M-PSK or a dictionary attack to guess the M-PSK.
• a sophisticated attacker could still use a compromised M-PSK and associated PSK identity hint from a cloned rogue device to perform a device authentication handshake.
• the subsequent member device DNS hostname validation through the authorized DNS server(s), based on the pre-requisite security countermeasure that the LAN is protected against IP address spoofing (by the network fabric of access, distribution, and core switches and routers in the path) would detect the rogue device as an unauthorized device and generate an alert to block subsequent accesses from the rogue device through a midstream network firewall or intrusion detection system security countermeasure (rule).
• the M-PSK and associated PSK identity hint may optionally be protected using a node-locked configuration file and a PUP as a security countermeasure.
• the ability to configure a plurality of M-PSKs and associated PSK identity hints on the KDS provides for timely remediation, with M-PSK renewal, should a M-PSK be compromised.
• the member device may be assigned an IP address (IPv4 or IPv6) using either a statically configured IP address or a dynamically assigned IP address by a Dynamic Host Configuration Protocol (DHCP) server configured for the LAN.
• the DNS server must be configured with the assigned member device IP address (A) record entry either manually or automatically (e.g., with Dynamic DNS).
• the allocated (leased) IP address may be reserved by the DHCP server for the member device with the associated Media Access Control (MAC) address, thereby ensuring an immutable IP address for the member device in the network domain of device enrollment.
• MAC Media Access Control
• an application or service 165 executing on a first device 160 may establish an authenticated and secure communication with an application or service on a second device 180 over a local or wide area network (LAN/WAN) 125.
• the first device 160 and the second device 180 use a respective (and identical) client KDS interface 303 or server KDS interface 310, a respective (and identical) preshared symmetric key data 163, a respective communications protocols stacks comprising of standard security protocols (e.g., TLS, DTLS), standard transport protocols (e.g., TCP, UDP), standard networking protocols (e.g., IPv4, IPv6), and nonIP protocols (e.g., CAN Bus, HART, WirelessHART, RS232 serial) 161.
• standard security protocols e.g., TLS, DTLS
• standard transport protocols e.g., TCP, UDP
• standard networking protocols e.g., IPv4, IPv6
• nonIP protocols e.g., CAN Bus, HART, WirelessHART
• the first device and the second device connect to a respective DHCP service 172 for device configuration and attributes including vendor specific information configured with extensible custom options, a respective DNS service 173a for device domain authentication, and a respective key distribution service (KDS) proxy 602 for key operations over a local or wide area network (LAN/WAN) 125.
• a mobile device may be authenticated by a mobile service provider (MSP) 322 service over a wide area network (WAN) 125.
• MSP mobile service provider
• WAN wide area network
• the key distribution service proxy (proxies) 602 connect over the LAN/WAN 125 to a key distribution service (KDS) 305 hosted on-premises or in the cloud.
• KDS 305 may connect over the WAN 125 to a cloud service 197 comprising of, for example, device registration services or hub services.
• application or service 165 may initially use the client KDS interface 303 or server KDS interface 310 APIs to retrieve (auto discover) device information (e.g., configuration and attributes).
• the application or service 165 may also load the device specific primary/secondary KDS server addresses and tenant identifier from a device configuration file.
• the application or service 165 may also load the application specific group identifiers and pre-shared identity hints from an application specific configuration file.
• the client KDS interface 303 or server KDS interface 310 queries the DHCP service 172 for the requested device information.
• step 166 application or service 165 may use the client KDS interface 303 or server KDS interface 310 APIs to send key requests (for key operations such as, for example, create, retrieve, verify, renew, delete) to a KDS proxy 602, wherein the key request comprises of at least the tenant identifier and group identifier, and for singular keys the per-shared key identity hint.
• key requests for key operations such as, for example, create, retrieve, verify, renew, delete
• the key request comprises of at least the tenant identifier and group identifier, and for singular keys the per-shared key identity hint.
• the client KDS interface 303 or server KDS interface 310 initiates device authentication, session key exchange, and sends key requests over a secure channel to the KDS proxy 602.
• step 194a the KDS proxy 602 authenticates the device DNS hostname using the DNS service 173a to perform a reverse lookup for the device DNS hostname by device IP address.
• the KDS proxy 602 authenticates the mobile device using the MSP 322 service to match nonces signed by the SIM on the device and by the MSP based on the device I MSI.
• Post device authentication at step 194 the KDS proxy 602 sends the key request to the KDS 305.
• Retrieved pre- shared symmetric key data 163 is provided to the application or service 165.
• the application or service 165 uses the retrieved pre-shared symmetric key data 163 to perform cryptographic operations based on the designated key type and usage constraints.
• client authentication, data authentication, or data encryption is performed accordingly to establish an authenticated and secure communication at step 174 with a second device 180, wherein on the second device 180 identical sequence of steps are executed to retrieve the pre-shared symmetric key data 163 and perform cryptographic operations at step 164.
• an application or service 165 may request a plurality of keys from the KDS proxy 602.
• the KDS proxy 602 uses security, transport, and network protocols 191 on the key distribution server 190 for communications with the KDS 305, the first device 160, and the second device 180 over the LAN/WAN 125.
• References 171 a-171f in FIG. 1A depict communications routed over the LAN/WAN 125 network fabric between devices 160/180 and services 172/305/321/323/602.
• a client application 101 executing on device 100 establishes a connection 129 over a local or wide area network (LAN/WAN) 125 with a server application 151 executing on device 150.
• the client application 101 uses a security protocol stack 102, such as for example connection-oriented Transport Layer Security (TLS) or connection-less Datagram TLS (DTLS) to establish a secure session 127 with the server application 151.
• the security protocol stack 102 uses a transport protocol stack 103, such as for example the connection-oriented Transmission Control Protocol (TCP) or connection-less User Datagram Protocol (UDP).
• TLS connection-oriented Transport Layer Security
• UDP connection-less User Datagram Protocol
• the transport protocol stack 103 uses a network protocol stack 104, such as for example the Internet Protocol (IP) version 4 (IPv4) or version 6 (IPv6) to establish a network connection 126 over a local or wide area network (LAN/WAN) 125.
• IP Internet Protocol
• IPv4 Internet Protocol version 4
• IPv6 version 6
• the server application 151 uses a security protocol stack 152, such as for example connection-oriented T ransport Layer Security (TLS) or connection-less Datagram TLS (DTLS) to establish a secure session 127 with the client application 101 .
• TLS connection-oriented T ransport Layer Security
• DTLS connection-less Datagram TLS
• the security protocol stack 152 uses a transport protocol stack 153, such as for example the connection-oriented Transmission Control Protocol (TCP) or connection-less User Datagram Protocol (UDP).
• TLS connection-oriented Transmission Control Protocol
• UDP connection-less User Datagram Protocol
• the transport protocol stack 153 uses a network protocol stack 154, such as for example the Internet Protocol (IP) version 4 (IPv4) or version 6 (IPv6) to establish a network connection 126 over a local or wide area network (LAN/WAN) 125.
• IP Internet Protocol
• IPv4 Internet Protocol version 4
• IPv6 version 6
• LAN/WAN local or wide area network
• the client application 101 executing on device 100 establishes a secure connection over a local or wide area network (LAN/WAN) 125 with a server application 151 executing on device 150.
• LAN/WAN local or wide area network
• establishing a secure session includes sending a client certificate 201 to the server application 151 for authentication of the client application 101 executing on the device 100 by the server application 151 executing on device 150.
• an administrator 318 uses the KDS portal 317 to configure entities and relationships in the KDS 305.
• the configuration includes at least the creation of tenants by tenant identifier 735; groups by group identifier 705, group type 707, and a plurality of key records 709; and member devices 701 by member identifier 703.
• a list of authorized local Domain Name Servers (DNS) 321 may be explicitly configured on the KDS portal 317, in addition to system level configuration of settings for a DNS connector.
• DNS local Domain Name Servers
• an administrator 318 may use the KDS portal 317 to create key records, create key instances, and renew expired key instances. This simplifies the retrieval and usage of pre-shared keys using a group identifier 705 and identity hint 711 by applications executing on the member devices.
• a list of online (i.e., Internet, cloud) authorized mobile service provider (MSP) 322 servers may be explicitly configured on the KDS portal 317 to authenticate devices with a local SIM (e.g., mobile devices, smartphones) configured by an MSP.
• MSP authorized mobile service provider
• the client application 101 executing on device 100 uses the key distribution service (KDS) interface 303 to authenticate the member device 100 with the KDS 305 over the local or wide area network (LAN/WAN) 125.
• KDS interface uses APIs to communicate with the KDS 305 to retrieve, create and retrieve, verify, renew, or delete a symmetric key instance 714, depicted as PSK 312, based at least the tenant identifier 735, member identifier 703, group identifier 705, and identity hint 711.
• the entire key record 709 is retrieved.
• the KDS 305 uses a configured local Domain Name Server (DNS) 321 , with communications at steps 300 and 320 routed over the LAN/WAN 125 network fabric, to reverse lookup the requestor member device IP address (of device 100) and retrieve the registered member DNS hostname 722. The retrieved member DNS hostname 722 is then matched with the received member identifier 703 in the API request at step 304 to authenticate the member device 100.
• the client application 101 uses the retrieved PSK 313 and associated identity hint 711 to initiate a TLS-PSK based client authentication at step 307.
• step 304 includes a device authentication handshake using the configured KDS member PSK (M-PSK) and M- PSK identity hint with the KDS 305 (or KDS proxy 602) and the configured DNS server 321 .
• the client KDS interface 303 sends a device hello to the KDS 305, wherein the message comprises of at least the configured tenant identifier 735 encrypted with the configured M-PSK and the configured M-PSK identity hint 711 .
• the KDS 305 creates (establishes) a session context and at step 352 sends a server challenge to the client KDS interface 303 comprising of at least a unique and random nonce value and a hash function specification, wherein the service challenge is encrypted with the M-PSK associated with the received M-PSK identity hint 711 .
• the client KDS interface 303 generates and sends a device response to the KDS 305 comprising of a hash output corresponding to the service challenge 352, wherein the device response is encrypted with the M-PSK.
• the KDS 305 verifies the received hash output and on match with an expected hash output authenticates the device and at step 355 sends a server hello to the client KDS interface 303 to commence key exchange.
• the server hello message includes a list of supported key exchange protocols encrypted with the M-PSK.
• the KDS interface commences a secure key exchange protocol handshake using one of the supported key exchange protocols, for example, the ephemeral Diffie-Hellman (DH) or Elliptic-Curve DH (ECDH) key exchange method, or using NIST approved quantum resistant cryptographic algorithms (NISTIR 8309 htps://doi org/ 0.6028/NIST.IR.8309) for general encryption (such as for example CRYSTALS-Kyber) over an insecure channel (e.g., UDP or TCP) to generate a session key at the client KDS interface 303 and KDS 305.
• the session key is never transmitted over the insecure channel.
• the client KDS interface 303 sends a KDS request encrypted with the session key.
• the KDS 305 the device is validated using the device IP address and a DNS reverse lookup to match with the device member DNS hostname 722.
• the KDS 305 sends a KDS response encrypted with the session key to the client KDS interface 303.
• subsequent key operations may be initiated repeating steps 357, 358 and 359.
• the client KDS interface 303 sends a device finish to the KDS 305 to free (release) the context at step 362.
• a subsequent session may be established repeating the sequence beginning with step 350.
• the described message sequence for device authentication handshake using the configured device member PSK is identical between the client KDS interface 303 and KDS proxy 602.
• the described message sequence for device authentication handshake using the configured device member PSK (M-PSK) and M- PSK identity hint may be performed using a connection-less (e.g., UDP) or connection-oriented (e.g., TCP) transport protocol on resource constrained devices wherein use of a secure transport protocol (e.g., DTLS, TLS, IPsec) is not feasible.
• a secure transport protocol e.g., DTLS, TLS, IPsec
• the server application 151 executing on device 150 uses the key distribution service (KDS) interface 310 to authenticate the member device 150 with the KDS 305 over the local or wide area network (LAN/WAN) 125.
• KDS interface uses APIs to communicate with the KDS 305 to retrieve, create and retrieve, verify, renew, or delete a symmetric key instance 714, depicted as PSK 312, based at least the tenant identifier 735, member identifier 703, group identifier 705, and identity hint 711.
• the entire key record 709 is retrieved.
• the KDS 305 uses a configured local Domain Name Server (DNS) 321 to reverse lookup the requestor member device IP address (of device 150) and retrieve the registered member DNS hostname 722. The retrieved member DNS hostname 722 is then matched with the received member identifier 703 in the API request at step 311 to authenticate the member device 150.
• the server application 151 uses the retrieved PSK 312 to verify a TLS-PSK based client authentication at step 308.
• a PSK-based client authentication and a server certificatebased server authentication are accomplished to establish a secure session between the client application 101 and the server application 151.
• the server application 151 executing on device 150 authenticates the client application 101 executing on device 100.
• the server application 151 may use different identity hints 711 and key instances 715, and therefore different symmetric PSKs 506, to authenticate client applications 101 on different devices 100.
• a server application 151 may use the server KDS interface 310 to retrieve at step 311 a list of key records 709 by group identifier 705 to cache key instances 715 by identity hints 711 for quick look up during TLS-PSK based handshake for session establishment.
• step 304 includes a device authentication handshake for mobile member devices using the configured KDS member PSK (M-PSK) and M-PSK identity hint with the KDS 305 (or KDS proxy 602) and the configured MSP 322 server.
• M-PSK configured KDS member PSK
• KDS proxy 602 KDS proxy 602
• the client KDS interface 303 sends a device hello to the KDS 305, wherein the message comprises of at least the configured tenant identifier 735, the device ICCID as the member identifier 703, the device IMEI as the member (universally unique identifier) UUID 731 , and the device IMSI all encrypted with the configured M-PSK and the configured M-PSK identity hint 711 .
• the KDS 305 creates (establishes) a session context and at step 365 sends a server challenge to the client KDS interface 303 comprising of a random nonce value, wherein the service challenge is encrypted with the M-PSK associated with the received M-PSK identity hint 711 .
• the client KDS interface 303 generates and sends a device response to the KDS 305 comprising of a nonce signed with the SIM’s authentication key (stored in the SIM card circuitry or as an applet on the SIM) corresponding to the service challenge 352, wherein the device response is encrypted with the M-PSK.
• the KDS 305 first sends the nonce corresponding to the service challenge 365 and the device IMSI of the mobile member device to the mobile service provider (MSP) 322 corresponding to the mobile member device, then receives the signed nonce from the MSP 322, and finally compares and matches the signed nonces received from the client KDS interface 303 and the MSP 322 to authenticate and validate the mobile member device.
• MSP mobile service provider
• the device hello may include a static public authentication key, generated by the client KDS interface 303 for the application on the member device, encrypted with the M-PSK.
• the server hello may include a static public authentication key, generated on the KDS 305 or KDS proxy 602, encrypted with the M-PSK.
• the client application 101 loads distinct device and application specific configuration files comprising of configuration settings required to access the KDS 305 or KDS proxy 602.
• the client application 101 uses the OpenContextKDS API to initialize the client KDS interface 303 for transactions with the KDS 305 or KDS proxy 602, using the KDS URLs, connection type, M-PSK, M-PSK identity hint, tenant identifier, and member identifier loaded from the device specific configuration file.
• the client application 101 uses the group identifier and C-PSK identity key loaded from the application specific configuration file.
• the client application 101 uses the RetrieveKey API to retrieve the pre-shared key (C-PSK) associated with the group identifier and C-PSK identity hint.
• C-PSK pre-shared key
• the client application 101 uses the retrieved C-PSK for PSK based client authentication with the server application over TLS (i.e., TLS-PSK).
• TLS-PSK TLS-PSK
• the client application 101 securely sends/receives data to/from the server application over the TLS session using the negotiated session key.
• the client application 101 uses the CloseContextKDS API to free the KDS context, thereby deleting the local C-PSK (i.e., the C-PSK is not persisted locally and re-acquired from the KDS 305 or KDS proxy 602 over client application restart).
• the server application 151 loads distinct device and application specific configuration files comprising of configuration settings required to access the KDS 305 or KDS proxy 602.
• the server application 151 uses the OpenContextKDS API to initialize the client KDS interface 303 for transactions with the KDS 305 or KDS proxy 602, using the KDS URLs, connection type, M-PSK, M-PSK identity hint, tenant identifier, and member identifier loaded from the device specific configuration file.
• the server application 151 uses the group identifier loaded from the application specific configuration file.
• the server application 151 uses the RetrieveKeys API to retrieve the pre-shared keys (C-PSKs) associated with the group identifier (i.e., preload C-PSKs required to accept connections from the client applications 101).
• the server application 151 uses the C-PSK identity hint received from a client application 101 to reference the associated pre-loaded C-PSK for PSK based authentication of the client application 101 over TLS (i.e., TLS-PSK).
• TLS-PSK i.e., TLS-PSK
• the server application 151 securely receives/sends data from/to the client application over the TLS session using the negotiated session key.
• the server application 151 uses the CloseContextKDS API to free the KDS context, thereby deleting the local pre-loaded C-PSKs (i.e., the C-PSKs are not persisted locally and re-acquired from the KDS 305 or KDS proxy 602 over server application restart).
• the client and server applications may use the VerifyKey API to verify the status of the C-PSK with the client KDS interface 303.
• the client KDS interface 303 examines the C-PSK expiration timestamp, and for nonexpired keys verifies the activation status of the C-PSK with the KDS 305 or KDS proxy 602.
• the client and server applications may use the RenewKey API to retrieve a renewed C-PSK.
• an application executing on a device may use TLS-PSK, or UDP/TCP over IP, TLS without client authentication, or non-IP communications protocols.
• the server trusted certificates root, intermediate, leaf
• the server trusted certificates may be installed on the device and updated using standard device update methods.
• an application executing on a device may be dynamically configured with a device unique pre-shared key for client authentication (C-PSK) over TLS-PSK.
• C-PSK device unique pre-shared key for client authentication
• the main application on RTOS platforms
• client application on GPOS platforms
• the device unique C-PSK identity hint may be generated using the device unique registration ID (e.g., MAC address, serial number.
• the device unique C-PSK may be dynamically created on the KDS using the KDSI APIs.
• the server application on the TLS server may dynamically retrieve the client’s device unique C- PSK using the KDSI APIs during the connection setup phase.
• the TLS client and server application may implement callbacks to validate the received PSK identity hint and fetch the pre-shared key during connection setup.
• the client application 101 executing on a member device generates a device unique C-PSK identity hint using the device unique registration ID (e.g., MAC address, serial number).
• the derivation function may be, for example, a HMAC-SHA256 algorithm.
• the client application 101 uses the client KDS interface 303 to create a device unique C-PSK using the generated C-PSK identity hint.
• the client KDS interface 303 communicates with the KDS 305 to create at step 387 a device unique C-PSK.
• the device unique C-PSK is retrieved by the client application 101 .
• the client application 101 initiates a TLS connection with the server application 151 using the C- PSK identity hint for client authentication using the TLS-PSK protocol specification.
• the server application 151 retrieves the C-PSK associated with the received C-PSK identity hint from the client application 101 using the server KDS interface 310 to communicate at step 391 with the KDS 305.
• the associated C-PSK is retrieved by the server application 151 to perform client authentication.
• the client KDS interface (303) and server KDS interface (310) application programming interface may include at least the following set of operations: 1) RetrieveTrustedCertificates (KDS Handle)
• ⁇ retrieves trusted certificates in PKCS#8 PEM format (e.g., intermediate and root certificates concatenated with a new line character as the separator) for the device based on the tenant identifier.
• trusted certificates in PKCS#8 PEM format e.g., intermediate and root certificates concatenated with a new line character as the separator
• a method is executed for an agentless solution on registered member devices authenticated with two-factor device authentication to retrieve trusted intermediate and root certificates, and leaf certificates and associated private keys, and verify status of the retrieved certificates, with a key distribution service (KDS) 305 using client KDS interface 303 APIs in any modern programming language.
• KDS key distribution service
• the public or private PKI based trusted certificates, and the leaf certificates and private keys, may be issued by a certificate authority (CA) 398 hosted on-cloud or on-premises.
• CA certificate authority
• the KDS 305 interfaces with the CA 398 to import (in single or batch mode), renew, or rekey certificates over an authenticated REST API connector, and query status of a certificate on request by the client application executing on the authenticated member device.
• the KDS 305 enforces policy-based authorization to restrict retrieval of the leaf certificate and associated private key by trusted applications configured on the KDS 305.
• the client application 101 e.g., TLS client, IKE client, SSH client, or command line utilities
• OCSP Online Certificate Status Protocol
• the KDS proxy 602 and KDS 305 enforce device two-factor authentication on API requests for leaf certificate and associated private key retrievals.
• a method is executed for importing, creating, renewing, rekeying, retrieving, or acquiring a leaf certificate for a public key and an associated private key of an asymmetric key pair, used in client authentication between applications executing on distributed devices, in data signing with digital signatures, in key unwrapping, including a client application executing on a first device, a server application executing on a second device, trusted intermediate certificates and trusted root certificates issued by a certificate authority (CA) 398, a key distribution service (KDS) 305, a KDS portal 317, a KDS administrator 318, a KDS proxy 602, a client KDS interface 303, a symmetric KDS member M-PSK, a M-PSK identity hint, a tenant identifier, an application identifier, a dynamic host configuration protocol (DHCP) service 172, and a domain name system (DNS) service
• the approach additionally includes methods wherein:
• the approach additionally includes methods wherein:
• the device member authentication handshake is performed by the client KDS interface 303 on the first device 160 using the tenant identifier, the device member PSK (M-PSK), and the M-PSK identity hint as a first factor of a device authentication, and further wherein a session key is generated using a key exchange handshake between the client KDS interface 303 and the KDS 305 or the KDS proxy 602, and further wherein a device member validation is performed as a second factor of the device authentication, by: performing, by the KDS 305 or the KDS proxy 602, a DNS reverse lookup of a device member IP address to query for the first DNS hostname; and retrieving, by the KDS 305 or the KDS proxy 602, the first DNS hostname from a resource record in a DNS response; and comparing and matching, by the KDS 305 or the KDS proxy 602, the retrieved first DNS hostname with a device member identifier in a plurality of KDS requests.
• M-PSK device member PSK
• M-PSK identity hint as a
• the approach additionally includes methods wherein:
• the device authentication and a plurality of key exchange handshakes are performed over a connection-less UDP or connection-oriented TCP transport protocol, without requiring a security transport protocol, and further wherein a data authentication and/or a data encryption is performed with the retrieved pre-shared keys using any communications protocol.
• the client KDS interface 303 provides a plurality of application programming interfaces (APIs), wherein the client application sends a plurality of requests for key and certificate operations directly to the KDS 305 and receive a plurality of responses for key and certificate operations directly from the KDS 305, or wherein the client application sends a plurality of requests for key and certificate operations indirectly through the KDS proxy 602 and receive a plurality of responses for key and certificate operations indirectly through the KDS proxy 602.
• APIs application programming interfaces
• the first device 160 is registered by a unique DNS hostname in a domain on a local DNS server with an IP address (A) record and a PTR record used in a DNS hostname reverse lookup.
• A IP address
• PTR record used in a DNS hostname reverse lookup.
• the first device 160 is configured as a member of a tenancy associated with the tenant identifier.
• the client application 101 uses the acquired leaf certificate and associated private key for data signing with a digital signature.
• the client application 101 uses the acquired leaf certificate for key unwrapping (i.e., to decrypt a wrapped key).
• the certificate authority 398 On request by the KDS administrator 318 at the KDS portal 317 the certificate authority 398 generates the asymmetric key pair and the leaf certificate for the generated public key and sends the generated leaf certificate and the associated generated private key file to the KDS portal 317.
• a method is executed for importing, creating, renewing, rekeying, retrieving, or acquiring a leaf certificate for a public key and an associated private key of an asymmetric key pair, used in server authentication with applications executing on distributed devices, in data signing with digital signatures, in key unwrapping, including a client application 101 executing on a first device 160, a server application 151 executing on a second device 180, trusted intermediate certificates and trusted root certificates issued by a certificate authority (GA) 398, a key distribution service (KDS) 305, a KDS portal 317, a KDS administrator 318, a KDS proxy 602, a server KDS interface 310, a symmetric KDS member M-PSK, a M-PSK identity hint, a tenant identifier, an application identifier, a dynamic host configuration protocol (DHCP) service 172, and a domain name system
• DHCP dynamic host configuration protocol
• the approach additionally includes methods wherein:
• the approach additionally includes methods wherein: a device member authentication handshake is performed by the server KDS interface 310 on the second device 180 using the tenant identifier, the device member PSK (M-PSK), and the M-PSK identity hint as a first factor of a device authentication, and further wherein a session key is generated using a key exchange handshake between the server KDS interface 310 and the KDS 305 or the KDS proxy 602, and further wherein a device member validation is performed as a second factor of the device authentication, by: performing, by the KDS 305 or the KDS proxy 602, a DNS reverse lookup of a device member IP address to query for the first DNS hostname; and retrieving, by the KDS 305 or the KDS proxy 602, the first DNS hostname from a resource record in a DNS response; and comparing and matching, by the KDS 305 or the KDS proxy 602, the retrieved first DNS hostname with a device member identifier in a plurality of KDS requests.
• M-PSK device member PSK
• the approach additionally includes methods wherein:
• the device authentication and a plurality of key exchange handshakes are performed over a connection-less UDP or connection-oriented TCP transport protocol, without requiring a security transport protocol, and further wherein a data authentication and/or a data encryption is performed with the retrieved pre-shared keys using any communications protocol.
• the server KDS interface 310 provides a plurality of application programming interfaces (APIs), wherein the server application 151 sends a plurality of requests for key and certificate operations directly to the KDS 305 and receive a plurality of responses for key and certificate operations directly from the KDS 305, or wherein the server application 151 sends a plurality of requests for key and certificate operations indirectly through the KDS proxy 602 and receive a plurality of responses for key and certificate operations indirectly through the KDS proxy 602.
• APIs application programming interfaces
• the second device 180 is registered by a unique DNS hostname in a domain on a local DNS service 321 with an IP address (A) record and a PTR record used in a DNS hostname reverse lookup.
• A IP address
• PTR record used in a DNS hostname reverse lookup.
• the second device 180 is configured as a member of a tenancy associated with the tenant identifier.
• the server application 151 uses the acquired leaf certificate and associated private key for data signing with a digital signature.
• the server application 151 uses the acquired leaf certificate key unwrapping (i.e., to decrypt a wrapped key).
• the certificate authority 398 On request by the KDS administrator 318 at the KDS portal 317 the certificate authority 398 generates the asymmetric key pair and the leaf certificate for the generated public key and sends the generated leaf certificate and the associated generated private key file to the KDS portal 317.
• a method is executed for assigning a leaf certificate and the associated private key to a member device from the imported or retrieved batch of leaf certificates and associated private keys, wherein a lookup is performed for a match of the member UIIID, or member identifier, or member DNS hostname with the subject name in the leaf certificate and the matched certificate and associated private key, for retrieval by the member device using the client KDS interface 303 or server KDS interface 394 retrieveCertificateWithKey API.
• the lookup and match of the leaf certificate and associated private key may be performed automatically by the KDS 305 or a collaborative service of the KDS 305, during device discovery and onboarding.
• a client application 101 loads a device specific configuration file comprising of configuration settings required to access the KDS 305 or KDS proxy 602.
• the client application 101 uses the OpenContextKDS API to initialize the client KDS interface 303 for transactions with the KDS 305 or KDS proxy 602, using the KDS URLs, connection type, M-PSK, M-PSK identity hint, tenant identifier, and member identifier loaded from the device specific configuration file.
• the client application 101 retrieves and stores trusted certificates (i.e., intermediate and root CA certificates) in a local trust store by retrieving the trusted certificates at step 394 using the retrieveTrustedCertificates API.
• the client application 101 retrieves and stores the leaf certificate and associated private key in the local key store by retrieving the leaf certificate and associated private key at step 396a using the RetrieveCertificateWithKey API, encrypted using the device M-PSK for security.
• the client application 101 uses the retrieved leaf certificates and private keys for client authentication, data signing with digital signatures, and key unwrapping.
• the client application 101 verifies the status of the retrieved leaf certificate (e.g., active, revoked, or expired) using the VerifyCertificate API.
• the client application 101 uses the CloseContextKDS API to free the KDS context and close the KDS session.
• administrator 318 uses the KDS portal 317 to import a leaf certificate file and the associated private key file.
• administrator 318 uses the KDS portal 317 to create an asymmetric public and private key pair, and send a request to create or rekey a leaf certificate for the public key to the configured certificate authority (CA) 398.
• CA configured certificate authority
• step 398a administrator 318 uses the KDS portal 317 to send a renew or revoke leaf certificate request to the configured certificate authority (CA) 398.
• the client KDS interface 303 interfaces with the KDS 305 to retrieve the trusted certificates, or the leaf certificates and associated private keys, based on API requests from the client application 101 .
• the administrator 318 uses the KDS portal 317 to (locally) import trusted (intermediate and root CA) certificates and store them locally for use by the KDS 305 to send to the devices based on API requests from the client application 101 through the client KDS interface 303.
• the identical sequence of steps may be performed by a server application 151 using the server KDS interface 310 for use in server authentication, data signing with digital signatures, and key unwrapping.
• the administrator 318 on the KDS portal 317, or at step 398a the certificate authority 398 dynamically generate a asymmetric key pair (i.e., associated public and private keys) using a specified key algorithm and key size such as, for example, Rivest-Shamir-Adleman (RSA) with key size, for example, of 512, 1024, 2048, or 4096 bits, Digital Signature Algorithm (DSA) with key size , for example, of 1024 bits, Elliptic curve cryptography (ECC) based on NIST specifications with key size, for example, of 224, 256, 384, or 521 bits), ECC based on the X.92 specification with key size, for example, of 192 or 256 bits), ECC based on the Standards for Efficiency Cryptography (SEC) specification with key size, for example, of 224, 384, or 521 bits, ECC based on the Brainpool specification with key size, for example, of 160,
• RSA Rivest-Shamir-Adleman
• the administrator 318 on the KDS portal 317 requests the certificate authority 398 for generation of a plurality (i.e., a batch associated with a universally unique batch identifier) of asymmetric key pairs, and leaf certificates with associated generated public keys, and associated private keys wherein the certificates and keys are sent to the KDS portal 317 in Privacy Enhanced Mail (PEM) file format or in the PFX (or PKCS#12) combined file format that holds the leaf certificate and the associated private key.
• PEM Privacy Enhanced Mail
• the generated batch associated with the universally unique batch identifier may be retrieved subsequently at step 398a by the administrator 318 on the KDS portal 317 by sending a request to the certificate authority (398) for retrieval of a plurality of leaf certificates and associated private keys in batch mode.
• the batch of leaf certificates and associated private keys may be generated autonomously and associated with a universally unique batch identifier by the certificate authority 398 for subsequent retrieval by the administrator 318 on the KDS portal 317 using the universally unique batch identifier.
• the administrator 318 on the KDS portal 317 initiates a lookup for a leaf certificate and the associated private key in the imported (at step 316) or retrieved (at step 398a) batch of leaf certificates and associated private keys, wherein the member IIUID 731 , or member identifier 703, or member DNS hostname 722 is matched with the subject name in the leaf certificate and the matched certificate and associated private key are assigned to the member device 701 for retrieval at step 396a by the first device 160 or second device 180 through the client KDS interface 303 or server KDS interface 310 respectively.
• the lookup and match of the leaf certificate and associated private key may be performed automatically by the KDS 305 or a collaborative service of the KDS 305, during device discovery and onboarding.
• a client application 101 executing on device 100 establishes a connection session over a local or wide area network (LAN/WAN) 125 with a server application 151 executing on device 150.
• the client application 101 uses a transport protocol stack 102, such as for example connection- oriented TCP or connection-less UDP, to establish a session with the server application 151.
• the transport protocol stack 103 uses a network protocol stack 104, such as for example the IPv4 or IPv6 to establish a network connection 126 over a local or wide area network (LAN/WAN) 125.
• the server application 151 uses a transport protocol stack 153, such as for example connection-oriented TCP or connection-less UDP, to establish a session with the client application 101.
• the transport protocol stack 153 uses a network protocol stack 154, such as for example the IPv4 or IPv6 to establish a network connection 126 over a local or wide area network (LAN/WAN) 125.
• the client application 101 executing on device 100 may send or receive plaintext or encoded (but not encrypted) data 404 over the established connection session over a local or wide area network (LAN/WAN) 125 to or from the server application 151 executing on device 150.
• the mode of data transmission herein is insecure without session key-based network traffic encryption.
• the client application 101 executing on device 100 uses the key distribution service (KDS) interface 303 to authenticate the member device 100 with the KDS 305 over the local or wide area network (LAN/WAN) 125.
• KDS key distribution service
• the KDS interface uses APIs to communicate with the KDS 305 to retrieve, or to create and retrieve, a symmetric key instance 714, depicted as PSK 501 , based at least the tenant identifier 735, member identifier 703, group identifier 705, and identity hint 711.
• the key record 709 is retrieved.
• the KDS 305 uses a configured local Domain Name Server (DNS) 321 to reverse lookup the requestor member device IP address (of device 100) and retrieve the registered member DNS hostname 722.
• DNS Domain Name Server
• the client application 101 uses the retrieved PSK 501 and associated identity hint 711 for authenticating and/or encrypting messages 504 sent to the server application 151 executing on device 150, and for verifying and/or decrypting messages 504 received from the server application 151 executing on device 150.
• the server application 151 executing on device 100 uses the key distribution service (KDS) interface 310 to authenticate the member device 150 with the KDS 305 over the local or wide area network (LAN/WAN) 125.
• KDS key distribution service
• the KDS interface uses APIs to communicate with the KDS 305 to retrieve, or to create and retrieve, a symmetric key instance 714, depicted as PSK 506, based at least the tenant identifier 735, member identifier 703, group identifier 705, and identity hint 711.
• the key record 709 is retrieved.
• the KDS 305 uses a configured local Domain Name Server (DNS) 321 to reverse lookup the requestor member device IP address (of device 150) and retrieve the registered member DNS hostname 722.
• DNS Domain Name Server
• the server application 151 uses the retrieved PSK 506 and associated identity hint 711 for authenticating and/or encrypting messages 504 sent to the client application 101 executing on device 150, and for verifying and/or decrypting messages 504 received from the client application 101 executing on device 150.
• the shared symmetric keys depicted as 501 and 506, the client application 101 executing on device 100 and server application 151 executing on device 150 establish secure communications with network traffic protection for data exchange.
• the client application 101 loads distinct device and application specific configuration files comprising of configuration settings required to access the KDS 305 or KDS proxy 602.
• the client application 101 uses the OpenContextKDS API to initialize the client KDS interface 303 for transactions with the KDS 305 or KDS proxy 602, using the KDS URLs, connection type, M-PSK, M-PSK identity hint, tenant identifier, and member identifier loaded from the device specific configuration file.
• the client application 101 uses the group identifier and S-PSK identity key loaded from the application specific configuration file.
• the client application 101 uses the RetrieveKey API to retrieve the pre-shared key (S-PSK) associated with the group identifier and S-PSK identity hint.
• the client application 101 uses the retrieved S-PSK to securely send/receive data to/from the server application 151.
• the client application uses the VerifyKey API to verify the status of the S-PSK with the client KDS interface 303.
• the client KDS interface 303 examines the S-PSK expiration timestamp, and for non-expired keys verifies the activation status of the S-PSK with the KDS 305 or KDS proxy 602.
• the client application 101 uses the RenewKey API to retrieve a renewed S-PSK.
• the client application 101 uses the retrieved S-PSK to securely send/receive data to/from the server application 151.
• the client application 101 uses the CloseContextKDS API to free the KDS context, thereby deleting the local S-PSK (i.e., the S-PSK is not persisted locally and re-acquired from the KDS 305 or KDS proxy 602 over client application restart).
• the server application 151 loads distinct device and application specific configuration files comprising of configuration settings required to access the KDS 305 or KDS proxy 602.
• the server application 151 uses the OpenContextKDS API to initialize the client KDS interface 303 for transactions with the KDS 305 or KDS proxy 602, using the KDS URLs, connection type, M-PSK, M-PSK identity hint, tenant identifier, and member identifier loaded from the device specific configuration file.
• the server application 151 uses the group identifier and S-PSK identity key loaded from the application specific configuration file.
• the server application 151 uses the RetrieveKey API to retrieve the pre-shared key (S-PSK) associated with the group identifier and S-PSK identity hint.
• the server application 151 uses the retrieved S-PSK to securely receive/send data from/to the client application 101 .
• the server application uses the VerifyKey API to verify the status of the S- PSK with the client KDS interface 303.
• the client KDS interface 303 examines the S- PSK expiration timestamp, and for non-expired keys verifies the activation status of the S-PSK with the KDS 305 or KDS proxy 602.
• the server application 151 uses the RenewKey API to retrieve a renewed S-PSK.
• the server application 151 uses the retrieved S-PSK to securely receive/send data from/to the client application 101 .
• the server application 151 uses the CloseContextKDS API to free the KDS context, thereby deleting the local S-PSK (i.e. , the S-PSK is not persisted locally and re-acquired from the KDS 305 or KDS proxy 602 over server application restart).
• the server application 151 may use the RetrieveKeys API to retrieve the pre-shared keys (S-PSKs) associated with the group identifier (i.e., pre-load S-PSKs required to accept connections from the client applications 101).
• S-PSKs pre-shared keys
• the server application 151 loads distinct device and application specific configuration files comprising of configuration settings required to access the KDS 305 or KDS proxy 602.
• the server application 151 uses the OpenContextKDS API to initialize the client KDS interface 303 for transactions with the KDS 305 or KDS proxy 602, using the KDS URLs, connection type, M-PSK, M-PSK identity hint, tenant identifier, and member identifier loaded from the device specific configuration file.
• the server application 151 uses the group identifier and S-PSK identity key loaded from the application specific configuration file.
• the server application 151 uses the CreateKey API to create and retrieve pre-shared keys (S-PSKs) associated with the group identifier and associated S-PSK identity hint.
• the server application 151 uses the retrieved S-PSKs to securely receive/send data from/to the client applications 101 .
• the server application uses the DeleteKey API to delete the S-PSKs on the KDS 305.
• the server application 151 uses the CloseContextKDS API to free the KDS context, thereby deleting the local S-PSKs (i.e., the S-PSKs are not persisted locally).
• an application executing on a device may be dynamically configured with a device unique pre-shared key for authenticated secure communications (S-PSK) over any transport protocol (e.g., UDP, TCP, TLS).
• S-PSK authenticated secure communications
• the main application (on RTOS platforms) or client application (on GPOS platforms) may use the group key (S-PSK) identity hint embedded (on RTOS platforms) or loaded from a configuration file (on GPOS platforms) to retrieve the group key (S-PSK) from the KDS.
• a unique device key may be derived with a HMAC-SHA256 of the retrieved group key (S-PSK) and the device unique registration ID pre-shared with the server (e.g., Azure DPS/Hub).
• S-PSK group key
• Azure DPS/Hub the server
• a device group may be defined on the KDS with the client and server device as members, or the client application may dynamically create a S-PSK and send the S-PSK identity hint to the server application to retrieve the S- PSK from the KDS.
• the client application 101 executing on a member device uses a configured group key (S-PSK) identity hint (that may be embedded within the application or discovered through network characteristics based on DHCP or DNS based custom attributes or loaded from a configuration file) required to retrieve the group key (S-PSK).
• S-PSK configured group key
• the client application 101 uses the client KDS interface 303 to retrieve the group key (S-PSK) using the S-PSK identity hint.
• the client KDS interface 303 communicates with the KDS 305 to retrieve the requested group key (S-PSK).
• the device group key (S-PSK) is retrieved by the client application 101 .
• the client application 101 derives a unique device key (D-PSK) using the group key (S-PSK) and the device unique registration ID (e.g., MAC address, serial number).
• the derivation function may be, for example, a HMAC-SHA256 algorithm.
• the client application 101 connects using the device registration ID with the server application 151 .
• the server application 151 retrieves the group key (S-PSK) using the server KDS interface 310, which at step 526 communicates with the KDS 305 and at step 527 returns the requested group key (S-PSK) to the server application 151 .
• the device group key (S-PSK) is retrieved by the client application 101.
• the server application 151 derives the unique device key (D-PSK) using the device registration ID.
• the client application 101 and server application 151 use the unique device key (D-PSK) for authenticated secure communications.
• a KDS proxy 602 provides authentication and validation of the member device 703 in the DNS domain.
• the member devices on local area networks (LAN) 125 may connect to a KDS 305 over a wide area network (WAN) through the KDS proxy 602.
• WAN wide area network
• NAT network address translation
• the member device IP address on the LAN is not retrievable by the KDS 305 over the WAN 606. Therefore, a DNS reverse lookup by member device IP address for the member device DNS hostname is not feasible.
• the KDS interfaces 303 and 309 connect the KDS proxy 602.
• the KDS proxy uses the configured DNS servers 321 in the LAN 125 to perform the DNS reverse lookup by member device IP address for the member device DNS hostname 722 and matches the resolved DNS hostname with the member identifier 703 in the API request
• the KDS proxy 602 establishes a secure connection, for example over a web connection using certificate-based mutual authentication and Hypertext Transfer Protocol Secure (HTTPS), with the KDS 305 to perform the requested API operation on behalf of the member device on the LAN using, for example, Representational State Transfer (REST) APIs.
• HTTPS certificate-based mutual authentication and Hypertext Transfer Protocol Secure
• REST Representational State Transfer
• the KDS proxy 602 and KDS 305 may be configured for security using API access tokens and API access secrets for authenticated API requests and permission-based access controls.
• the KDS proxy 602 may append, at least, the authenticated member identifier 703 and member DNS hostname 722 retrieved from the local DNS server in the proxied API requests to the externally hosted KDS
• the on-premises KDS proxy performs the first factor of device authentication for the local member devices.
• the devices are assigned to the group identifier “Factory Default” and configured with an associated shared or private M-PSK identity hint and M-PSK.
• the (RTOS) main or (GPOS) onboarding application on the device should create a device unique M-PSK identity hint and M-PSK under the “Registered Members” group for advanced security for subsequent first-factor device authentication (using the KDS interface CreateKey API).
• a member device 701 is associated with a member identifier 703.
• a member identifier 703 is associated with a member DNS hostname 722 registered with a local DNS server.
• the member DNS hostname 722 may be mapped to an alias (ALIAS) or canonical name (CNAME) resource record on the DNS server and therefore be different from the member identifier 703.
• ALIAS alias
• CNAME canonical name
• a group identifier 705 is associated with a group type 707 (e.g., shared, private, onboarding, authenticator, anonymous, community, any suitable group type).
• a group identifier 705 is associated with one or more key records 709.
• identity hints 711 key templates 713, key instances 715, key creators 724, key statuses 726, and key expirations 721 are respectively associated with key records 709.
• key algorithms 717, key sizes 719, and key usages 728 are respectively associated with key templates 713.
• the key status 726 is managed by the KDS and may be set to ACTIVE, SUSPENDED, EXPIRED, or DELETED on persisted key records 709.
• the key usage 728 may be set by the key creator 724 to, for example, client authentication, data authentication, data encryption, content (producer or broker) signing (e.g., code file, data file, image file, Java archive (JAR) file, compressed zip/tar format file), broadcast signing, broadcast encryption, multicast signing, multicast encryption, token signing, or token encryption.
• the key usage 728 may be defined as a bitmask or multi-value data type to grant multiple permissions (for example, to grant data authentication and data encryption permissions).
• a key token 734 is associated with a key record 709, effectively associating the key instance 715 with the key token 734.
• a hash algorithm 738 is associated with the key template 713 for digital signing (for example, with HMAC authentication).
• one or more member domains 740 are associated with one or more group identifiers 705.
• an authenticated member device’s 701 request for a key instance 715 (or any key operation) based on the specified group identifier 705 and identity hint 711 may be processed by the KDS and permitted based on a match of the member domain 740 with the domain (i.e., domain name and top-level domain suffix parts) derived from the resource records retrieved by the DNS reverse lookup for the member device DNS hostname 722.
• the domain i.e., domain name and top-level domain suffix parts
• a member domain of “my-domain.com” associated with the group identifier 705 qualifies the member device 701 for associated key records 709 based on the specified identity hint 711 for the specified group identifier 705.
• one or more application identifiers 742 represented as a hyphenated alphanumeric character string or a universally unique identifier (UUID), may be associated with the group identifier 705.
• the UUID may be specified as the MAC address, serial number, or IMEI of the member device 701 .
• an image name 744 may be associated with the application identifier 742.
• an image hash 746 e.g., SHA-256 of the application image may be associated with the application identifier 742.
• an authenticated member device’s 701 request for a key instance 715 (or any key operation) based on the specified group identifier 705 and identity hint 711 may be processed by the KDS and permitted based on the application identifier transmitted by the KDS interface (303, 310) in KDS requests (304, 311) matching with the application identifiers associated with the specified group identifier 705 and identity hint 711 on the KDS.
• a key nonce 748 may be associated with the key template 713 as a nonce (i.e., a unique, random, or pseudorandom value) for use as, for example, an initialization vector (an input into a cryptographic primitive).
• the size of the key nonce 748 (e.g., 192, 128, 96, 56 bits) may depend on the cipher type (e.g., block size for a block cipher) or mode of operation of the cipher algorithm (e.g., may be zero or a fixed value for deterministic algorithms).
• a key handle 750 may be associated with the key template 713.
• the key handle 750 may be used to configure a locality identifier on a local secure element (e.g., TPM handle, NVRAM index, HSM slot) for the application to optionally store the retrieved per-shared key securely on the device.
• a message authentication code (MAC) hash algorithm 752 may be associated with the key template 713.
• a MAC hash prime 754 may be associated with the key template 713. Additional entities, such as for example, the member device manufacturer (e.g., vendor class identifier configured on the DHCP service 172) and model may be associated with the member device, explicitly through the KDS portal or retrieved from external services (e.g., DHCP extended attributes associated with the device MAC address).
• the member device manufacturer e.g., vendor class identifier configured on the DHCP service 172
• model may be associated with the member device, explicitly through the KDS portal or retrieved from external services (e.g., DHCP extended attributes associated with the device MAC address).
• a community identifier 756 may be associated with one or more tenant identifiers 735.
• group types 707 provide rules based access controls to regulate access to key records (associated with the group identifier) by KDS member devices.
• the “private” group type restricts access to the key creator only.
• the “shared” group type grants access to all members of the group.
• the “anonymous” group type also grants access to authenticated non-members of the group.
• the “community” group type grants retrieve access to members of co-tenants within a community (i.e. , tenant identifiers associated with a community identifier).
• the member of tenant A-Corporation may access key records 709 by identity hint 711 associated with a community group identifier 705 (with group type set to “community”) of tenant B- Corporation provided tenants A-Corporation and B-Corporation are co-tenants of the referenced community (by community identifier 756) in the key retrieve operation initiated by the member of tenant A-Corporation.
• the use case of community based key access is of relevance for content signing and supply chain tamper resistance with signature manifests (FIG. 8C) and extended signature manifests (FIG. 8D) wherein the said signature manifests may include the tenant identifier and group identifier in the entry records for transactions between cross-tenant producer, broker, and consumer applications.
• a device may be configured as follows:
• ⁇ member device “OT Device”.
• ⁇ member identifier “A2Z029” as the local device identifier (LDevID).
• ⁇ member DNS hostname “A2Z029.dba.com”.
• the DNS PTR-record (stored under the IP address reversed, with “.in-addr.arpa” appended at the end for IPv4 or converted into 4-bit sections with “,ip6.arpa” appended at the end for IPv6) pointed to A2Z029.dba.com for the A-record pointed to the assigned IP address. For example, stored as “45.34.23.12. in-addr.arpa” for IPv4 address “12.23.34.45”, and as “f.e.d.c.b.a.0.9.8.7.6.5.4.3.2.1 .
• CNAME records may be created to assign multiple identities (i.e., aliases) to a member device (e.g., a server grade device may function as a web server, a file server, and a mail server).
• the ALIAS-record may be created with a short (subset) name (e.g., dba.com) and the CNAM E-record may prefix the short name (e.g., A2Z029.dba.com).
• the digital signatures generated using the retrieved preshared keys for data authentication may use the hash algorithm 738 associated with the key template 713 for the key record 709 associated with the identity hint 711.
• a message authentication code generated using the hash algorithm 738 may be mapped to a lesser number of bytes (for example, a 2-byte CRC equivalent) using the hash function specified by the MAC hash algorithm 752 and optionally the prime number specified by the MAC hash prime 754.
• a digital signature of the message may be generated using the hash algorithm 738 (for example, HMAC-MD5- 128), and then the cyclic redundancy check (CRC) checksum field in the CAN message may be replaced with a hash of the generated digital signature of the message using the MAC hash algorithm 752 and MAC hash prime 754 specified in the key template 713.
• the specified MAC hash algorithm 752 may be implemented on the devices using, for example, the MAC hash prime 754, multiplication, bitwise exclusive OR (XOR), bitwise AND, and left/right bit shifting operators.
• the KDS 305 uses a configured local Domain Name Server (DNS) 321 to reverse lookup the requestor member device IP address of the member device 701 and retrieve the registered member DNS hostname 722.
• DNS Domain Name Server
• the retrieved member DNS hostname 722 is then verified with the received member identifier 703 in the API request to authenticate the member device 701 , wherein the verification uses a received DNS ALIAS or CNAME record configured on the DNS server to validate the received member identifier 703 (instead of an exact match).
• the key instance 715 is equivalent to an API shared secret and the key token 734 is equivalent to an API shared token in a REST API request authentication mechanism.
• REST API requests are digitally signed by the client/client application for the server/server application to verify that the API requests were issued by authorized sources and were not tampered in-transit.
• the API shared secret and the API shared token are used to digitally sign and verify the request URL that comprises of the API method, the API request timestamp, and the API token (a universally unique identifier or UUID).
• the API service accounts are typically configured manually through a services portal, or automatically generated during service account creation by the service.
• the associated API shared credentials (i.e. , the token and the secret) must be stored securely by the service and application administrators. If the API shared credentials are lost, a new set of credentials must be generated for the server/server applications and synchronized with the associated client applications.
• the KDS 305 provides an automated and scalable mechanism to distribute and synchronize API shared credentials between applications on authenticated and domain validated member devices.
• the key instance 715 and key token 734 may be generated externally and imported into the KDS 305.
• a scheduled task on the KDS 305 periodically and automatically renews key instances 715 within the time window configured on the KDS 305 before the respective key expirations 721 for PSKs created (and owned) by the KDS administrator as set in the key record 709 key creator 724 field.
• the key instances 715 for PSKs created (and owned) by applications executing on member devices 701 may be renewed programmatically and automatically through the client KDS interface 303 APIs.
• applications 101 and 151 may establish connection-oriented or connection-less secure communications using any transport protocol stack 103 and network protocol stack 104 using the client KDS interface 303, KDS 305 and KDS proxy 602.
• standards-based communications protocols may include the Controller Area Network Bus (CAN Bus), Modbus (over TCP/UDP), Highway Addressable Remote Transducer (HART), WirelessHART, and the RS232 serial communications protocol.
• the key size 719 may be selected to optimize the encrypted message length to reduce latency in real time applications. Based on the message types and maximum frame length permitted in the communications standards, the key size 719 for the optimal message signature length may be selected.
• the keyed-hash message authentication code may optionally be truncated before sending alongside the message to be authenticated due to message length constraints.
• the member device 701 may be registered as a computer object on a directory service 730.
• a member universally unique identifier (UUID) 731 (representing for example the device unique MAC address, serial number, or mobile device IMEI) may be configured for the member device 701 .
• the tenant identifier 735 may be configured with directory service 730, such as for example a Microsoft® Active Directory.
• the member device 701 may be enrolled into the directory services 730 managed domain and assigned a universally unique identifier (UUID) by the directory service 730.
• UUID universally unique identifier
• the member UUID 731 may be configured accordingly from the KDS portal 317 to match with the retrieved UUID of the associated computer object on the directory service 730 for member device validation by the KDS 305.
• the group identifiers 706 for the member device 701 may be retrieved from groups and group memberships configured on the directory service 730 during KDS 305 configuration from the KDS portal 317.
• the client KDS interface 303 provides a simplified set of APIs as a library for static or dynamic linking by polyglot applications (e.g., C, C++, C#/.Net, Java).
• the client KDS interface 303 includes built-in functions for KDS session management, KDS request and response handling, and an operating system (OS) abstraction layer (OSAL) for integration with the device platform.
• OS operating system
• the OSAL provides OS agnostic interfaces to the client KDS interface 303 for multiplatform portability.
• the OS specific hooks for memory, filesystem, network, timer, mutex, and thread management may be implemented as underlying plugins (i.e., operators) to the OSAL based on the target OS platform (e.g., Windows, Linus, FreeRTOS, Azure RTOS, VxWorks, QNX, uCOS).
• the target OS platform e.g., Windows, Linus, FreeRTOS, Azure RTOS, VxWorks, QNX, uCOS.
• a server application operating as a service to a plurality of client (or initiator) applications may use the KDS 305 to configure a key instance 715 with an identity hint 711 for content signing purposes.
• the server application may sign the content using a PSK and send the associated PSK identity hint and digital signature along with (and separately from) the digitally signed content using, for example, a key-hashed message authentication code (HMAC).
• HMAC key-hashed message authentication code
• the client (or initiator) application may retrieve the key instance 715 from the KDS 305 using the identity hint 711 , regenerate the digital signature for the received content, and cross-verity the computed digital signature with the digital signature received along with the content.
• the content signing mechanism may be extended to include multiple signatories for supply chain tamper resistance using a chain of PSKs, wherein a configuration file comprising of a list of PSK identity hints and digital signatures may be sent, over a secure channel, along with (and separately from) the digitally signed content for regeneration and cross-verification.
• the client (or initiator) application may retrieve key instances 715 from the KDS 305 using the identity hints 711 , regenerate the digital signatures for the received content, and cross-verify the computed digital signatures with the digital signatures received along with the content.
• the ability of the KDS to manage and distribute purpose-built PSKs to authenticated member devices for content signing enables use of separate PSKs for client authentication, secure communications, and content signing.
• the applications executing on member devices can provide digital attestation of data (e.g., indicators of runtime operational integrity, loaded configuration, telemetric measurements) to track and trace data objects to the data source.
• the receivers can tag the cross-verified data object to the authenticated data source for data provenance.
• OT/lloT/loT device platforms e.g., memory, storage, file system on flash
• EEPROM electrically erasable programmable read-only memory
• flash-based file systems may be read-only (not writable, or writable overlays that are volatile over a power cycle) and therefore updating PKI based keys and certificates may not be possible.
• the common approach of storing long-lived (no expiry) private keys, seed phrases (nonces), and certificates in NVRAM poses security risks.
• the PSKs in the disclosed system need not be persisted on the device and may be dynamically retrieved from the KDS by the applications executing on the device at runtime (e.g., at application launch) and erased from memory at application termination.
• the length of X.509 certificates may vary based on the size of the parameters and keys and are typically in the order of kilobytes (e.g., 1 KB, 2KB, 5 KB), whereas symmetric key sizes are typically in the order of bytes (e.g., 56, 80, 112, 128, 192, 256 bits).
• the PSKs 501 and 506 for data authentication and data encryption may be used by a real time and mission critical client application 101 and server application 151 to secure selective sections of messages 504 in application (user) space.
• This provides application developers with a simplified method that is agnostic to the underlying transport and network protocol stacks in user or kernel space. For real-time and mission critical applications that require low latency, messaging integrity and confidentiality, partial payload protection is an effective solution.
• Some examples include operational technology (OT) applications in (a) industrial control systems that must comply with the Generic Object-Oriented Substation Event (GOOSE) and IEC- 61850 (International Electrotechnical Commission) and NERC-CIP (North American Electric Reliability Corporation Critical Infrastructure Protection) standards; (b) applications in transportation systems (e.g., smart vehicles); (c) applications in aviation systems (e.g., commercial and military aircrafts, unmanned aerial vehicles or drones); (d) applications in space systems (e.g., satellites and spacecrafts); and (e) applications in healthcare systems (e.g., medical equipment, bedside equipment, surgical equipment, nurse station equipment, on-patient devices, and palliative or hospice care equipment).
• GOOSE Generic Object-Oriented Substation Event
• IEC- 61850 International Electrotechnical Commission
• NERC-CIP North American Electric Reliability Corporation Critical Infrastructure Protection
• inter-system messaging between the components e.g., electronic control units, telemetric control units, on-board diagnostics units, navigation systems, display units, multi-service loT edge gateways, sensors, actuators, controllers
• components e.g., electronic control units, telemetric control units, on-board diagnostics units, navigation systems, display units, multi-service loT edge gateways, sensors, actuators, controllers
• the PSKs 501 and 506 may be used for data encryption wherein selective sections (or embedded component objects) within a document to redact/obfuscate content based on the member device identifier 703.
• This capability allows restricted documents retrieved by authenticated and authorized users based on roles, permissions, and privileges to be rendered by applications (e.g., word processing software, PDF readers, slideware software) with selective content redacted/obfuscated based on the member device identifier 703.
• the application generating the secure document uses a PSK to encrypt selective sections of the document and embeds the associated PSK identity hint 711 within the section as metadata.
• Different sections within the document may be encrypted with different PSKs using the respective PSK identity hints 711.
• the application rendering the secure document uses the embedded PSK identity hints to retrieve the associated PSKs and decrypt the respective sections.
• the rendering application may be a web browser, thereby enabling web applications and services to deliver dynamically generated secure web content (web pages) to authenticated and authorized users with redacted/obfuscated content based on the member device identifier 703.
• blockchain applications may retrieve PSKs from the KDS 305 with device authentication and device domain validation for (a) secure communications without requiring PKI issued certificate-based device and/or client authentication, and (b) digital signing of transactions without requiring PKI issued certificates and asymmetric keys.
• the KDS provides scalability with simplified key lifecycle management to blockchain applications. Managing distributed private keys and associated certificates using a centralized PKI system (as the root of trust, or trust anchor) is against the decentralized first principle of blockchain philosophy.
• SDN software defined network
• the client application 101 uses client KDS interface 303 to retrieve a pre-shared key (S-PSK) 501 from the KDS 305.
• the client application 101 uses the retrieved S-PSK 501 to selectively encrypt partial sections of messages 801 transmitted over the local or wide area network (LAN/WAN) 125.
• the server application 151 uses the Server KDS interface 310 to retrieve the pre-shared key (S-PSK) 506 from the KDS 305.
• the server application 151 uses the S-PSK 506 to selectively decrypt the selectively encrypted partial sections of messages 801 received over the local or wide area network (LAN/WAN) 125.
• the producer application 802 on device 899 uses client KDS interface 303 to create pre-shared keys (PSKs) 805 on the KDS 305.
• the producer application 802 uses the created and retrieved PSKs 805 to selectively encrypt embedded objects and tag each encrypted embedded object with the respective pre-shared identity hint within the document 803.
• the consumer application 807 on device 898 uses the server KDS interface 310 to retrieve the pre-shared keys (PSKs) 809 for the pre-shared key identity hints tagged with the respective encrypted embedded objects from the KDS 305, on member devices authenticated and validated by the KDS.
• the server application 151 uses the retrieved PSKs 809 to selectively decrypt the encrypted embedded objects within the document.
• the structure of the document is illustrated with examples of encrypted embedded objects and the associated PSK identity hint tagged to each of the respective encrypted object within the secured document.
• the producer application 811 on device 897 receives content 813.
• the producer application 811 uses client KDS interface 303 to create a pre-shared key (PSK) 815 on the KDS 305 for content signing.
• PSK pre-shared key
• the producer application 811 uses the retrieved PSK 815 to digitally sign the received content 813 and generate a digitally signed content 817.
• the producer application 811 generates a signature manifest with the tenant identifier, group identifier, digital signature for the digitally signed content 817, the associated PSK identity hint for the PSK 815, and the named object 820 for the digitally signed content 817.
• the consumer application 823 on device 896 receives the digitally signed content 817.
• the consumer application 823 receives the associated signature manifest 819.
• the consumer application 823 uses client KDS interface 303 to retrieve the pre-shared key (PSK) 826 from KDS 305 for the tenant identifier, group identifier, and PSK identity hint 822 in the received signature manifest 819.
• the consumer application 823 regenerates a digital signature for the received digitally signed content 817 using the retrieved PSK 826 and compares for match with the digital signature 821a in the received signature manifest 819.
• PSK pre-shared key
• the broker application 832 on device 895 receives content 813.
• the broker application 832 uses client KDS interface 303 to create a pre-shared key (PSK) 836 on the KDS 305 for content signing.
• PSK pre-shared key
• the broker application 832 uses the retrieved PSK 836 to digitally sign the received digitally signed content 828 and generate an extended digitally signed content 830.
• the broker application 832 receives a signature manifest 819, and at step 834 generates an extended signature manifest with the tenant identifier, group identifier, additional digital signature for the extended digitally signed content 830, the additional associated PSK identity hint for the PSK 836, and the named object 820 for the extended digitally signed content 830.
• the consumer application 823 on device 896 receives the extended digitally signed content 830.
• the consumer application 823 receives the associated extended signature manifest 819.
• the consumer application 823 uses client KDS interface 303 to retrieve the pre-shared keys (PSKs) 837 from KDS 305 for the tenant identifiers, group identifiers, and PSK identity hints 822 in the received extended signature manifest 831.
• the consumer application 823 regenerates the digital signatures for the received extended digitally signed content 830 using the retrieved PSKs 837 and compares for match with the digital signatures 821b in the received extended signature manifest 831.
• content signing for supply chain tamper resistance may be implemented as a set of utilities (or tools) comprising of a signing utility (kdssign) and a verifier utility (kdsverify) on a GPOS platform (e.g., Windows, Linux, or Mac OS) that may be executed on registered KDS member devices.
• a signing utility kdssign
• a verifier utility kdsverify
• GPOS platform e.g., Windows, Linux, or Mac OS
• ⁇ extend Adds (appends) an entry record to the specified signature manifest file (JSON).
• two-factor split channel verification of device updates may be performed, wherein the steps comprise of downloading, by a update program executing on the device, a device update (package or module) from a configured update server (e.g., a web service hosted onpremises or in the cloud), verifying by the update program the digital code signing of the downloaded device update by the content publisher using a configured asymmetric public key or signing certificate as the first factor of verification, and verifying a signature manifest (or extended signature manifest) file provided along with the device update using the extended KDS interface VerifySignatureManifest API as the second factor of verification.
• a signature manifest or extended signature manifest
• the signature manifest or extended signature manifest file may be generated for the device update by the provider or broker applications respectively for content signing and supply chain tamper resistance using the extended KDS interface GenerateSignatureManifest API.
• the workflow for the signature manifest based second factor protection may operate independent of (or concurrently with) the continuous integration (Cl) and content distribution (CD) workflow for the first factor of verification, with separation of duties based permissions to mitigate insider threats and advanced persistent supply chain exploits by sophisticated attackers.
• the signature manifest or extended signature manifest file for the device update package may be generated by the providers or brokers using the kdssign signing utility, and the signature manifest or extended signature manifest file verification may be performed by the consumers using the kdsverify verifier utility.
• the KDS interface may retrieve (automatically discover) the primary and secondary KDS/KDS proxy URLs, the tenant identifier, the group identifier, and identity hints associated with a production wireless access point (WAP) for secure access based on network characteristics using custom attributes configured on a DHCP server, or a DNS server, associated with the member device LAN.
• WAP production wireless access point
• An original equipment manufacturer may pre-configure, embedded within the production application image on realtime operating system (RTOS) platforms or through a factory default configuration file on general purpose operating system (GPOS) platforms, the KDS member pre-shared key (M-PSK) and M-PSK identity hint required for device authentication on the KDS, and the guest WAP service set identifier (SSIDs) and associated guest (Wi-Fi Protected Access) WPA2 PSKs for the manufacturing and deployment network environments.
• RTOS realtime operating system
• GPOS general purpose operating system
• M-PSK KDS member pre-shared key
• M-PSK identity hint required for device authentication on the KDS
• SSIDs guest WAP service set identifier
• Wi-Fi Protected Access Wi-Fi Protected Access
• a supplicant program e.g., Wi-Fi supplicant, Wi-Fi supplicant function implemented within a production application or system firmware
• GWAP-PSK GWAP-SSID and associated guest WAP pre-shared key
• IWAP-PSK production WAP specific secure internal WAP pre-shared key
• a group may be configured that comprises of the production WAP device and member devices or member domain with the associated IWAP-PSK and IWAP-PSK identity hint.
• the KDS administrator portal 317 may be configured for single-sign-on (SSO) and federated identity based authentication using authentication methods (e.g., OpenlD Connect or OlDC, Security Assertion Markup Language or SAML, OAuth) with an identity provider (IdP) to authenticate portal users, and grant permissions based on group membership to create IWAP-PSKs for the member domains 740 associated with a group identifier 705.
• SSO single-sign-on
• OAuth Security Assertion Markup Language
• IdP identity provider
• a supplicant program 850 executing on a device 893 uses factory configured attributes 857 that includes a guest WAP SSID (GWAP-SSID) 851 and a guest WAP pre-shared key (GWAP-PSK) 852 to authenticate with a WAP 894 in the production network to access the guest wireless network.
• factory configured attributes 857 that includes a guest WAP SSID (GWAP-SSID) 851 and a guest WAP pre-shared key (GWAP-PSK) 852 to authenticate with a WAP 894 in the production network to access the guest wireless network.
• GWAP-SSID guest WAP SSID
• GWAP-PSK guest WAP pre-shared key
• the supplicant program 850 uses the client KDS interface 303, with a tenant identifier, group identifier, and internal WAP pre-shared key (IWAP-PSK) identify hint, discovered at step 858 using network characteristics based on custom DHCP attributes 859 configured on a DHCP (or DNS) server, or retrieved from a configuration file on the device, and the member identifier to at step 304 authenticate with the KDS 305 and retrieve an internal WAP pre-shared key (IWAP-PSK) 862.
• IWAP-PSK internal WAP pre-shared key
• the supplicant program 850 uses the retrieved IWAP-PSK 862 and internal WAP SSID (IWAP SSID) pre-configured within the supplicant program image or retrieved from a configuration file on the device to authenticate with the WAP 894 in the production network to access the secure wireless network.
• IWAP SSID internal WAP SSID
• steps 902, 904, 906, 908, 910, and 912 indicate the ordered sequence of actions performed at blocks 901 , 903, 905, 907, 909, 911 , and 913 respectively.
• an algorithm is selected to build a machine learning model using a multi-dimensional feature matrix with device intelligence as training datasets.
• a multi-dimensional feature matrix is built that includes device tenancy, group memberships, key type and usage profile, volume of key usage, rate of key rotation, and application identifiers (e.g., file name, file hash).
• the feature matrix is extended with imported application-based indicators of compromise from external forensics-based threat intelligence that includes content integrity measurement and vulnerability assessments comprising of scores categorized by, for example, application reputation, static/dynamic analysis, runtime introspection analysis, domain generation algorithm (DGA) analysis, obfuscation level, unpacking level, IP address and domain reputation, geo-location, autonomous system numbers (ASNs), and IP address age.
• the feature matrix is further extended by retrieving device properties (e.g., model, manufacturer, identifiers, attributes, update history) from device management systems, and network management services (e.g., Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP) servers).
• DNS Domain Name System
• DHCP Dynamic Host Configuration Protocol
• the feature matrix is further extended by retrieving flow records for connection history of inter-device communications from network activity monitoring systems.
• the device risk score may be predicted using the multidimensional feature matrix for linear regression.
• a security event may be classified as a true positive, false positive, true negative, or false negative using an unsupervised model, multi-layer deep learning network networks, and the multidimensional feature matrix for logistic regression.
• steps 921 , 923, 925, 927, and 929 indicate the ordered sequence of actions performed at blocks 920, 922, 924, 926, 928, and 930 respectively.
• metadata connectors comprising of at least a service provider, filter type, filter name, webhook specified as a URL, API token, API secret, and filter criteria specified as a list of metadata types and metadata identifiers are configured, wherein the filter type is specified as a device type or device group.
• the KDS service 305 or KDS proxy 602 authenticates a client device 100 with two-factor authentication.
• a client application 101 on the client device 100 uses the KDS client interface 303 (for example with the ExportDeviceMetadata API) to send device metadata comprising of a metadata identifier, metadata type, and metadata value to the KDS service 305, wherein the metadata type may be, but not limited to, plain text, formatted text, integer number, decimal number, image, video, or audio.
• the text may be any application defined telemetry, status, or log message.
• the KDS service 305 receives the device metadata, processes the received device metadata against the configured metadata connectors to apply the specified filters and sends, to the webhook URL, the received device metadata along with filter and device identifiers, for example as a JSON payload, with a HTTP request (for example as a POST).
• the webhook of the service provider processes the received device metadata as feature vectors to train AI/ML models, and further applying methods, including but not limited to, linear or logistic regression, neural networks, decision trees for assessments, predictions, or analysis of cyber risks, threats to the device, or application security by design respectively.
• the KDS service 305 processes the response from the webhook and stores the received response in the device metadata repository. Further, the response from the webhook may be forwarded by the KDS service 305 to a collaboration service, specified in the payload of the response, to trigger or execute remediation actions on the client device 100.
• the tenant identifiers and group identifiers for pre-shared keys designated for specific purposes, such as for document security or content signing, may be defined for extended scope (e.g., any tenant, any group).
• the key records on the source KDS may be configured as exportable, and importable on a destination KDS using password-protected keys, encryption, and key encapsulation for secure exchange.
• the preshared key retrieved from the KDS may be used to generate a derived device key in association with a set of local device unique identifiers.
• One use case may be to register the device with a cloud based device provisioning service.
• Yet another use case may be to sign or encrypt messages and/or authentication tokens to cloud based hub services.
• the cloud based device management platforms and services require an on-device local secure element (e.g., TPM, HSM, SIM) to protect pre-shared group keys and derived device keys.
• a local secure element may not be available on legacy, brownfield, or greenfield devices.
• the proposed innovation protects the pre-shared group keys and derived device keys by not requiring these keys to be stored locally and instead providing for dynamic on-demand retrieval of the pre-shared group key and just-in-time generation of the derived device key based on local device identifiers (e.g., a device registration identifier configured with the cloud service).
• the client application 101 and server application 151 may use a publish-subscribe messaging protocol (e.g., Message Queue Telemetry Protocol or MQTT, Advanced Message Queuing Protocol or AMQP) that may require use of such derived device keys from pre-shared group keys and unique device registration identifiers on devices wherein there is no local secure element.
• Representative cloud services may be Microsoft Azure Device Provisioning Service (DPS) and loT Hub, Amazon Web Services, or Google Cloud device provisioning and hub services.
• the secure shell (SSH) protocol may be enhanced to use a pre-shared key (PSK) for client authentication.
• PSK pre-shared key
• a SSH client may use either a password, a keypair (e.g., RSA/DSA private-public keys), or a X.509 certificate for data encryption/authentication with a remote SSH server.
• the SSH servers may be configured with user accounts, authorized keys, or trusted (root, intermediate, issuer) certificates for all the remote users or device clients. Storing and managing authorized keys on distributed SSH servers is cumbersome and costly.
• the SSH client may dynamically create a PSK on the KDS for client authentication and send the PSK identity hint to the SSH server to initiate a PSK based authentication.
• the SSH server may retrieve the PSK from the KDS using the received PSK identity hint.
• a plurality of PSKs for client authentication may be retrieved from the KDS just- in-time by the SSH server and not persisted/stored locally on the server.
• the SSH client may create a PSK for one-time use or renew the PSK (key rotation) based on the configured key duration for security purposes.
• a SSH server may be configured to store only the authorized PSK identity hints and retrieve associated PSKs from the KDS just-in-time during connection establishment and optionally cache the retrieved PSKs locally in memory until key expiration.
• This approach eliminates cumbersome and costly SSH server management, key pair generation on remote client devices, transfer of the public keys to the SSH servers, and automates key rotation with cryptographic agility orchestrated through the KDS.
• the RSA private keys are typically stored unprotected on the SSH client devices in the absence of a local secure element.
• the SSH client may be configured to retrieve the PSK dynamically from the KDS and not store the PSK locally unprotected on a device in the absence of a local secure element.
• a requestor may send a pre-shared key identity hint in the secure authorization request (e.g., over a TLS session) to the authorization server and receive an encrypted access token from the authorization server during a subsequent authorization grant request, wherein the authorization server retrieves the pre-shared key associated with the received pre-shared key identity hint to perform the said encryption.
• a pre-shared key identity hint in the secure authorization request (e.g., over a TLS session) to the authorization server and receive an encrypted access token from the authorization server during a subsequent authorization grant request, wherein the authorization server retrieves the pre-shared key associated with the received pre-shared key identity hint to perform the said encryption.
• the received pre-shared identity hint may further be included in the access token by the authorization server, for access token signing by the requestor using the associated pre-shared key in requests to a service provider, wherein the service provider retrieves the pre-shared key associated with the preshared key identity hint in the received access token to perform token verification.
• additional attributes may be discovered for an authenticated member device, wherein the system comprises of a mobile application (a purpose-built device label scanner) on a mobile device, a device discovery service (DDS), a DHCP service, an OEM service, a KDS, and a member device with a device unique label.
• a field operator may, pre or post onboarding of the member device onto the production (operations) network, use the mobile application on the mobile device to scan the device label comprising of, one or more of, a printed MAC address, a printed serial number (S/N), one or more printed bar codes, and a printed quick response (QR) code.
• the mobile application may send one or more of the scan codes to the DDS or DHCP service.
• the DDS or DHCP service may receive, from the OEM service, through an outbound query or an inbound notification, device information corresponding to the scan codes.
• the member device may send key requests to the KDS.
• the KDS may query the DDS for device information based on the member UUID (e.g., MAC address or serial number), or query the DHCP service for custom vendor specific options, and persist the retrieved device information for reference in subsequent key requests from the member device.
• the device information may include the device type, manufacturer identifier, country of manufacture, model, MAC address, serial number, supported network types, supported network protocols, and license owner identifier.
• the KDS may use the retrieved device information for policy based authorization of the key requests from the member device, by comparing and matching the associated member device tenant identifier with the license owner identifier retrieved from the DDS or DHCP service.
• a technician at the factory may scan the device using the mobile application and send one or more of the scan codes to the DDS shared with the licensed device owner/operator prior to device shipment.
• the DDS may be hosted on-premises or in the cloud (on the Internet).
• the DHCP server may be hosted in the same network or in a different subnet with relay agents for forwarding.
• the mobile application may connect to the DDS or DHCP service over a wired or wireless network.
• the DDS and DHCP service may connect to a plurality of OEM services.
• a method is executed for device label scan based zero-touch device onboarding at first-time power cycle including a device onboarder (DOB) mobile application executing on a mobile device, a field technician, field devices, a device directory service (DDS), a key distribution service (KDS), a KDS portal, a KDS application programming interface, a KDS administrator, a preconfigured member pre-shared key (M-PSK) and a M-PSK identity hint associated with the mobile device, a pre-configured API key and API token associated with the mobile device, a pre-configured factory default member pre-shared key (M-PSK) and a M-PSK identity hint associated with the field device, a bootstrap application on the field device, a tenant identifier associated with the mobile and field devices, a device type identifier associated with the field device, a printed device label with device unique immutable initial identifiers on the field device issued by the original equipment manufacturer (OEM), an asset metadata data
• DOB device onboarder
• the approach additionally includes methods wherein:
• the device label template comprises of at least a location ordinal, a prefix, and a regular expression for each device identifier on the printed device label.
• the scanning methods include optical character recognition (OCR) for textbased device identifiers, bar code scanning, and QR code scanning.
• OCR optical character recognition
• Inspecting the scan report includes manually configuring extended device information comprising of at least a device type, tenant identifier, and network domain for the field device.
• the scan report includes at least the MAC address, serial number, model, manufacture location, device geolocation, and the scanned image of the printed device label on the field device.
• the DHCP query based on the vendor class identifier for vendor specific information may include the manufacturer identification, country of manufacture, model, network types, network protocols, and license owner information associated with the field device type.
• the creation of address (A) and pointer (PTR) records on the DNS server for the initial device identifier may be performed manually by the DHCP server administrator, or dynamically using the dynamic DNS (DDNS) protocol to interface with the DNS server.
• DDNS dynamic DNS
• the zero-touch device onboarding at first-time power cycle is achieved with field device two-factor authentication using the pre-configured factory default member pre-shared key (M-PSK), M-PSK identity hint, and the member initial identifier, where the member initial identifier matches with the pre-configured DNS hostname based on the A and CNA E records.
• M-PSK factory default member pre-shared key
• M-PSK identity hint M-PSK identity hint
• the member initial identifier matches with the pre-configured DNS hostname based on the A and CNA E records.
• the device onboarding mobile application performs two-factor user authentication of the field technician in the tenant domain.
• the device onboarding mobile application performs two-factor device authentication in the tenant domain.
• the device onboarding mobile application uses authenticated REST APIs with the API key and API token to communicate with the device directory service (DDS).
• DDS device directory service
• the API key and API token may be pre-configured for the device onboarding mobile application (DOB) on the mobile device.
• DOB device onboarding mobile application
• the API key and API token may be dynamically retrieved by the device onboarding mobile application (DOB) from the KDS using the KDS application programming interface and device two-factor authentication.
• DOB device onboarding mobile application
• the device onboarding mobile application (DOB) on the mobile device may generate device label templates for printed device labels based on the scanned label image and artificial intelligence (Al) based on inference algorithms for the ordinals, prefixes, and regular expressions.
• DOB device onboarding mobile application
• Al artificial intelligence
• the QR code may be a manufacturer configured URL for the device type that may be included as extended device information in the scan report for upstream processing at the DDS.
• zero touch device onboarding is performed at first-time power cycle of a device in operational environments with device two-factor authentication to configure and manage the lifecycle of device and application-level quantum-safe keys for secure communications with client authentication, data authentication, and data encryption over secure and insecure transport protocols.
• a Device Onboarder a mobile application, executing on a mobile device (such as, for example, an Android or iOS smartphone or tablet) uses label templates to scan and process text, bar codes, and QR codes to identify device unique immutable initial identifiers on printed device labels issued by the original equipment manufacturer (OEM), discover devices, harvest, and store device information as asset metadata in the DDS.
• OEM original equipment manufacturer
• the mobile device must be configured on the KDS as a member device by IMEI and ICCID required in the device hello for two-factor authentication by the KDS.
• the DOB signs- in with user two-factor authentication (for example, using the Azure AD B2C single sign on (SSO) user flow for tenant based on user policy and first-time enrollment ceremony).
• the DOB communicates securely with the DDS, executing on the KDS, over authenticated REST APIs using an API key (a.k.a. API secret) and API token to receive device types and send device scan information.
• API key a.k.a. API secret
• API token to receive device types and send device scan information.
• the key record for each mobile device must be configured on KDS under a “Device Label Scanners” device group (private group type) with a member unique identity hint.
• the API key and API token may be manually configured on the DOB, for the mobile device under the “Device Label Scanners” device group.
• the DOB may authenticate with device two- factor authentication using KDSI APIs (with M-PSK and KDS authentication) and dynamically retrieve the API key and API token for the member unique identity hint manually configured on the DOB, for mobile device under the “Device Label Scanners” device group.
• Label templates describe how specific identifiers appear on the printed device label.
• the template files e.g., JSON
• Example of label templates are:
• the KDS interface 303 sends a device hello to the KDS 305, wherein the message comprises of at least the configured tenant identifier 735 and the device IMEI as the member identifier 703, all encrypted with the configured M-PSK and the configured M-PSK identity hint 711 .
• the KDS interface 303 sends a server challenge to the KDS interface 303 comprising of at least a unique and random nonce value and a hash function specification, wherein the service challenge is encrypted with the M-PSK associated with the received M-PSK identity hint 711 .
• the KDS interface 303 generates and sends a device response to the KDS 305 comprising of a hash output corresponding to the nonce and hash function specified in the service challenge 352 and the member device ICCID, wherein the device response is encrypted with the M-PSK.
• the KDS 305 compares and matches the hash received from the KDS interface 303 with the hash computed locally for the nonce and hash function specified in the service challenge 352 and the ICCID (manually pre-configured through the KDS portal for the member device) corresponding to the IMEI in the device hello 363C, to validate the mobile member device.
• a technician 119 scans a printed device label 108 on a device 108 using a mobile device 120 (e.g., an Android or iOS phone or tablet).
• a mobile device 120 e.g., an Android or iOS phone or tablet.
• DOB mobile application
• the technician 119 manually specifies the tenant identifier, network domain, and device type information for the device under scan 108.
• the device label is scanned and processed using a device label template (for the device 108) selected by the technician 119 in the DOB 135.
• the scan report comprising of at least the scanned and processed codes (text, bar codes, QR codes), the geolocation, and the manually configured device information at step 132, is sent to the device directory service (DDS) configured in the DOB 135 settings.
• the scanning method uses optical character recognition (OCR), bar code analysis, and QR code analysis algorithms.
• the label template for devices 108 comprise of at least the ordinal (for location), prefix, and regular expression required for each device identifier type (e.g., MAC address, serial number, manufacturer, manufactory location, model, etc.).
• the technician may inspect the processed scan codes and edit the report to overcome any errors due to damaged or obscured printed device labels or provide missing identifiers on the printed labels.
• the DDS receives device type, MAC address, serial number, model, geolocation, manufacturer, manufacture location (etc.) from the DOB 135 over authenticated REST APIs to securely discover and onboard devices at scale in the field.
• the DDS 112 interfaces with the KDS 195 using local or remote procedure calls (LPC/RPC) or via REST APIs to access the KDS database to retrieve, for example, the configuration settings and label templates, and store the label scan reports and device (asset) metadata.
• the DDS 121 may query the DHCP server 121 for vendor specific custom options that may be configured on the DHCP server by the tenant, wherein the information may comprise of manufacturer, country of manufacture, model, network types, network protocols, and license ownership information for the device.
• the DHCP server 121 may use dynamic DNS (DDNS) to create DNS A/PTR records for the device IP address and initial member identifier (e.g., in MAC-Address.Network-Domain.com format).
• DDNS dynamic DNS
• the administrator 116 of the DNS server 122 creates DNS A/PTR/CNAME records for the device IP address and local member DNS hostname configuration on the DNS, wherein the CNAME points a device local identifier to a device initial identifier.
• applications e.g., a bootstrap client or a line of business embedded main application
• executing on the device 108 may issue key requests to the KDS 195 during device onboarding for device registration and during operations for operational keys.
• the initial device identifier issued by the OEM may be mapped in DNS to an initial device IP address (e.g., in a guest wireless network), and the local device identifier issued by the device end user mapped in DNS to a local device IP address (e.g., in a secure wireless or wired network).
• a device assigned multiple IP addresses is configured accordingly in DNS with multiple A and PTR records.
• the DHCP server uses DDNS to update the DNS A/PTR records for the initial device identifier.
• the tenant administrator or operator 130 imports device label templates (e.g., JSON files) and configures device label templates on the KDS Portal 317 for the device type.
• a technician 119 downloads and installs the mobile application (i.e., DOB) 135 from the designated Enterprise App Store (133).
• the technician 119 configures settings for the DOB 135, wherein the settings may comprise of at least the KDS 195 server addresses, an API key and API token or a key identity hint assigned exclusively to the DOB instance 135 on the mobile device 120 for authenticated REST APIs, and the mobile device 120 I MEI and ICCID.
• the DDS 112 may execute alongside the KDS 195 on a single server.
• the DOB 135 synchronizes the device label templates and device types by retrieving the tenant metadata configured on the KDS 195 from the DDS 112.
• the technician 119 scans the printed device label on the device 108 applying the appropriate retrieved device label template for the device type.
• the scan report is securely uploaded to the DDS 112 over authenticated REST APIs.
• the device information from the scan report is stored in the asset metadata datastore 142 on the KDS server.
• a method is executed for symmetric keybased digital signing for content creation, content verification, content inspection, content approval, and gated workflow sequence for supply chain tamper resistance, from a device original equipment manufacturer (OEM) to a device owner (end-user facility), including a content creator at the OEM, a content loader at the end-user facility, a plurality of content approvers at the end-user facility, a policy manager at the end-user facility, a field manager at the end-user facility, a key distribution service (KDS), a KDS portal for users, a KDS application programming interface for applications executing on the user or field devices, a first secure channel for two- factor user and device authentication-based creation and retrieval of a plurality of digital signing symmetric keys, a second secure channel for content distribution, a dynamic host configuration protocol (DHCP) server, a domain name system (DNS) server, a content identifier, a content file associated with the content identifier, a signature manifest file associated with the
• DHCP dynamic host configuration protocol
• the approach additionally includes methods wherein:
• the content file may be, but is not limited to, a software update, configuration update, or an operating system (OS) update.
• OS operating system
• the signing key for the digital signing is a symmetric key created and/or retrieved by a KDS portal user with two-factor authentication, further wherein the key operation using a tenant identifier, a group identifier and a key identity hint is performed using a KDS local procedure call (LPC), a remote procedure call (RPC), or an authenticated REST API.
• LPC KDS local procedure call
• RPC remote procedure call
• authenticated REST API authenticated REST API
• the signing key for the digital signing is a symmetric key created and/or retrieved by an application on a registered member device of the KDS with two-factor device authentication, and further wherein the key operation using a tenant identifier, a group identifier and a key identity hint is performed using the KDS application programming interface.
• the digital signing keys are created and/or retrieved by the KDS portal users and applications on member devices over the first secure channel (e.g., a HTTPS, or TLS session).
• the first secure channel e.g., a HTTPS, or TLS session.
• the content file is downloaded from the retrieved URL or URI by the OEM application on the consumer field device over the second secure channel (e.g., a HTTPS, or TLS session).
• the second secure channel e.g., a HTTPS, or TLS session.
• the content file is inspected using external third-party content inspection methods that include, but are not limited to, static analysis, dynamic analysis, sandboxing, anomaly detection, and reputation lists based on the content approver’s security profile and threat model assessments.
• the content loader configures on the KDS portal the received content and signature manifest files along with at least a content identifier (universally unique identifier), content timestamp, content version, content type, and content description.
• the update policy configured by the policy manager may include at least a publish-on (not before) date and time, days of the week, and from/to time of day to schedule content download.
• the OEM application on the field device uses the KDS application programming interface (APIs) to query for updates, retrieve download URL/URIs, verify the retrieved signature manifest file, and notify update status to the KDS for state synchronization.
• APIs application programming interface
• the OEM application on the device installs the retrieved content file using OEM specific update methods that include, but are not limited to, streaming the HTTPS download to a flash memory partition on the device without buffering, or storing on a file system on a flash data partition.
• Verifying the content file, by the content loaders, content approvers, and OEM applications on the content consumer field devices comprises of retrieving the digital signing key records from the KDS for the tenant identifiers, group identifiers, and key identity hints in the associated extended signature manifest file, computing the hash and signature for the content file based on the key record specification for each of the digital signing keys, and comparing the computed signatures for the content file with the corresponding signatures in the extended signature manifest file.
• Each digital signer, at the OEM and end-user facility, of the content file may use a different key algorithm and key size for the digital signing key to extend the signature manifest file.
• the technique uses a symmetric key based multi-party content signing by the producer and one or more brokers and multiperson digital signing.
• the digital signing (symmetric) keys are retrieved out-of-band over a secure channel (in split mode, wherein the keys are not transmitted along-side signed content).
• the technique uses a split mode that comprises of a first secure channel for authentication-based creation and retrieval of a plurality of digital signing (symmetric) keys, and a second secure channel for content distribution (e.g., content file, signature manifest file).
• the technique further uses device two-factor authentication for content retrieval (without requiring PKI or device certificates) and gated workflow sequence based multi-part content inspection, notification-based approval, and notification-based publishing with role-based separation of duties and multi-person signing rule (with at least 4-person digital signing recommended).
• the content approval is content inspection-based (and not merely based on the user’s role and privileges).
• the external third-party content inspection method e.g., static analysis, dynamic analysis, sandboxing, anomaly detection, reputation lists
• the authorized download URL/URIs are retrieved by the OEM application with device two-factor authentication from the KDS (i.e., not embedded at factory in the OEM’s application) and may be hosted in the controlled environment of the device owner/operator.
• a content distribution service executes on the KDS server, as a companion service alongside the KDS.
• the CDS On receiving a QueryUpdate device request, the CDS returns UPDATEPENDING when the latest associated content timestamp/version is higher than the current content timestamp/version for member device.
• the CDS On receiving a retrieveUpdate device request, the CDS sends the download URL/URIs for the published content (with API secret and API token) for the updater application on the device to initiate an authenticated REST API based download over HTTPS to retrieve the content file and extended signature manifest, verify the signatures, and apply OEM specific update methods.
• the CDS sets the update status for the member device to “-1 : Retrieved” in the KDS database.
• the CDS sets the update status for the member device (0: Complete, non-zero-integer: Error (Code)) in the KDS database.
• the operations may be performed by authorized applications or utilities executing on authenticated member devices or by authenticated KDS portal (317) users (318), with two-factor device or user authentication in the tenant domain respectively.
• authorized applications e.g., line of business applications or utilities
• the devices must be direct members of the device group associated with the key record (709) or be members of trusted groups configured through the KDS portal (317) for the device group associated with the respective key record (709), or must qualify based on the configured inter-tenant community trust policies.
• the users For authenticated users to perform key operations directly from the KDS portal (317) the users must be members of the designated role-based user group (for example, in the identity provider’s authentication directory service). Further, named groups such as for example “Content Creators”, “Content Loaders”, and “Content Approvers” may be configured by the tenant administrator or operator (318), with the group type specified as “any”.
• the group type “any” provides a policy and role-based mechanism for authenticated devices and users to use pre-shared keys for intra-tenant and inter-tenant (community based) content signing and verification of signatures in the manifest or extended manifest files associated with the content file.
• the authenticated users (318) of a tenancy may access keys for content signing and verification purposes through the KDS portal (317) to execute the content creating, loading, inspecting, and approving tasks in the proposed content distribution system workflow.
• a producer 143 creates a signing key, and at step 143b generates and sends a content file and signature manifest to a device owner (broker) 144.
• the key creation at step 143a for content file signing and generation of the signature manifest file may be accomplished with utilities, executing on an authenticated device, that use the KDS interface (167) APIs or through the KDS Portal (317) by authenticated users.
• the producers (OEMs) 143 serve as content creators (role).
• the content file and signature manifest are shipped together (i.e., made available for import) to the device owner (broker) 144.
• the broker 144 receives and verifies the content file using the signature manifest file, and at step 144c retrieves the key from the KDS 195 using the key identity hint in the signature manifest for the associated content file. After verification, the broker 144 at step 144c creates a signing key for co-signing and extends the signature manifest.
• the content loader assigns a content identifier (UUID), content timestamp, content version, content type, and content description from the KDS portal (317).
• the key creation at step 144c for content file signing and generation of the extended signature manifest file may be accomplished with utilities, executing on an authenticated device, that use the KDS interface (167) APIs or through the KDS Portal (317) by authenticated users.
• the brokers 144 serves as content loaders (role).
• the broker 144 finally notifies a first approver.
• the first approver inspects the content file using one or more external third-party content inspection methods, such as, for example, static analysis, dynamic analysis, sandboxing, anomaly detection, reputation lists) based on the approver’s security profile and threat model assessments.
• the approver may further extend the extended signature manifest using the KDS 195 to create a signing key.
• the approver notifies the next approver where additional content inspection methods may be warranted by another approver.
• the last approver in the chain notifies the policy manager to configure an update policy to associate the content file to qualified consumers (devices) 145 managed by field managers).
• the policy manager notifies the field manager to publish the content to the devices 145.
• the OEM application 145a executing on the consumer (device) 145 queries the KDS 195 to check for content updates, and at step 145c retrieves the download URL and URIs (for the content file and extended manifest file items) from the KDS 195 using KDS interface (167) APIs for any pending content updates.
• the OEM application 145a downloads the content file and extended signature manifest from the retrieved URL/URIs, verifies the signatures by retrieving the keys from the KDS 195 at step 145e with the key identity hints in the extended signature manifest file 831 , and installs the verified content file using OEM specific update methods (e.g., streaming the HTTPS download to a flash memory partition on the device without buffering, storing on a file system on a flash data partition), executing proprietary shell scripts, helper applications, or OS loaders).
• OEM specific update methods e.g., streaming the HTTPS download to a flash memory partition on the device without buffering, storing on a file system on a flash data partition
• the OEM application 145a notifies update status (for the content identifier associated with the content update) to the KDS 195 for state synchronization.
• the user notifications at the broker 144 are generated and sent from the KDS Portal 317 (e.g., as email or SMS to the recipients).
• the users at the broker 144 are content loaders, content approvers, policy managers, and field managers.
• the DDS 146 interfaces with the KDS 195 using local or remote procedure calls (LPC/RPC) or via REST APIs for workflow coordination and content (content file and manifests) management.
• LPC/RPC local or remote procedure calls
• REST APIs for workflow coordination and content (content file and manifests) management.
• a content creator i.e., a producer, such as an OEM
• a content file e.g., a software update, configuration update, or OS update to be installed on a field device
• an associated signature manifest file with a creator digital signing
• sends the generated content and signature manifest files to a content loader 176 i.e., a broker, such as an end-user of the device.
• the content loader 176 imports the received content and signature manifest files, verifies the producer digital signing, extends the manifest file with a content loader co-signature, and notifies a first content approver 177.
• the first content approver (in the chain of one or more content approvers) inspects the content file with one or more external third-party content inspection methods and extends the manifest file with an approver digital signing.
• the final content approver notifies a policy manager 178.
• the policy manager 178 associates the content file with update policies, device types, and (optionally) device groups, and notifies a field manager 179.
• the field manager 179 publishes the inspected and approved content and completes the managed content distribution workflow.
• a member device 701 is associated with a device type 760.
• a content file 762 and signature manifest file 819 also the extended signature manifest file 831 received from a content creator 175 is imported by a content loader 176 on the KDS portal 317.
• the content loader 176 generates and associates a content identifier 761 with the content file 762, the extended signature manifest file 831 , a generated API key 763, and a generated API token 764.
• the generated API key 763 and API token 764 are unique per content identifier and sent to the content consumer field device 145 during Retrievellpdate device request processing by the CDS 146.
• a content timestamp, content version, content type, and content description are transitively assigned to the content identifier 761 (associated with the content file 762).
• a download URL 771 is associated with the content identifier 761 .
• a content URI 772 is associated with the content file 762.
• a manifest URI 773 is associated with the extended signature manifest file 831 .
• a content identifier, a content timestamp, a content version, a retrieved-on date/time, an update status, and an update history is associated with the member device 701 by the CDS 146.
• a list sequence of content identifiers e.g., UUlDs
• the device type 760 based on the update policy configured (at step 178a) by the policy manager 178.
• the next content identifier UUID
• the update history for the member device 701 is updated by the CDS 146 on receiving a NotifyUpdateStatus device request (which includes the content identifier) from the member device 701 .
• secure connectivity and data communications may be implemented for a zero-trust networking architecture using the KDS.
• a third-party aftermarket service application executing on a technician device (e.g., a desktop/laptop computer or mobile device) uses the KDS interface API and retrieves (or creates) a pre-shared key (PSK) with a statically or dynamically generated PSK identity hint from the KDS.
• PSK pre-shared key
• the service application then sends the PSK identity hint to the secure gateway (SGW) service on the service device (e.g., a vehicle, controller, actuator, sensor).
• SGW secure gateway
• the SGW service uses the KDS interface API and retrieves the corresponding PSK from the KDS using the received PSK identity hint.
• the SGW service sends a challenge nonce to the service application.
• the service application replies with the received nonce signed using the PSK for authentication.
• the SGW service then verifies the received signed nonce and on match grants access to the service application.
• the SGW service and service application may then communicate (e.g., for telematics, maintenance, diagnostics) with data authentication and encryption over any security (e.g., DTLS, TLS), transport (UDP, TCP), or network protocol (e.g., Ethernet, Wi-Fi, Bluetooth) using the pre-shared keys.
• the PSK is automatically rotated by the KDS based on the configured expiration timestamp.
• the KDS may be implemented as a microservices based highly available, vertically and horizontally scalable, architecture with local caching of the retrieved key and DNS records for low latency key operations, key distribution, and two-factor device authentication.
• FIG. 10 Although exemplary embodiments have been described in terms of a computing device or instrumented platform, it is contemplated that it may be implemented in software on microprocessors/general purpose computers, such as the computer system 1000 illustrated in FIG. 10. In various embodiments, one or more of the functions of the various components may be implemented in software that controls a computing device, such as computer system 800, which is described below with reference to FIG. 10.
• FIGS. 1-9 Aspects of the present disclosure shown in FIGS. 1-9, or any part(s) or function(s) thereof, may be implemented using hardware, software modules, firmware, non-transitory computer readable media having instructions stored thereon, or a combination thereof, and may be implemented in one or more computer systems or other processing systems.
• FIG. 10 illustrates an example computer system 1000 in which embodiments of the present disclosure, or portions thereof, may be implemented as computer- readable code.
• the network systems and architectures disclosed here can be implemented in computer system 800 using hardware, software, firmware, non-transitory computer readable media having instructions stored thereon, or a combination thereof and may be implemented in one or more computer systems or other processing systems.
• Hardware, software, or any combination of such may embody any of the modules and components used to implement the architectures and systems disclosed herein.
• programmable logic may execute on a commercially available processing platform or a special purpose device.
• programmable logic may execute on a commercially available processing platform or a special purpose device.
• One of ordinary skill in the art may appreciate that embodiments of the disclosed subject matter can be practiced with various computer system configurations, including multi-core multiprocessor systems, minicomputers, mainframe computers, computers linked or clustered with distributed functions, as well as pervasive or miniature computers that may be embedded into virtually any device.
• processor devices may be used to implement the above-described embodiments.
• a processor device may be a single processor, a plurality of processors, or combinations thereof.
• Processor devices may have one or more processor “cores”.
• Processor device 1002 may be a special purpose or a general-purpose processor device. As will be appreciated by persons skilled in the relevant art, processor device 1002 may also be a single processor in a multi-core/multiprocessor system, such system operating alone, or in a cluster of computing devices operating in a cluster or server farm. Processor device 1002 is connected to a communication infrastructure 1026, for example, a bus, message queue, network, or multi-core message-passing scheme.
• a communication infrastructure 1026 for example, a bus, message queue, network, or multi-core message-passing scheme.
• the computer system 1000 also includes a main memory 1004, for example, random access memory (RAM), and may also include a secondary memory 1006.
• main memory 1004 for example, random access memory (RAM)
• secondary memory 1006 for example, random access memory (RAM)
• Secondary memory 1006 may include, for example, a hard disk drive 1008, removable storage drive 1010.
• Removable storage drive 1010 may comprise a floppy disk drive, a magnetic tape drive, an optical disk drive, a flash memory, or the like.
• removable storage drive 1010 reads from and/or writes to a removable storage unit 1012 in a well-known manner.
• Removable storage unit 1012 may comprise a floppy disk, magnetic tape, optical disk, etc. which is read by and written to by removable storage drive 1010.
• removable storage unit 1012 includes a non-transitory computer usable storage medium having stored therein computer software and/or data.
• secondary memory 1006 may include other similar means for allowing computer programs or other instructions to be loaded into computer system 1000.
• Such means may include, for example, a removable storage unit 1016 and an interface 1014.
• Examples of such means may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM, or PROM) and associated socket, and other removable storage units 1016 and interfaces 1014 which allow software and data to be transferred from the removable storage unit 1012 to computer system 1000.
• the computer system 1000 may also include a communications interface 1018.
• Communications interface 1018 allows software and data to be transferred between computer system 1000 and external devices.
• Communications interface 1018 may include a modem, a network interface (such as an Ethernet card), a communications port, a PCMCIA slot and card, or the like.
• Software and data transferred via communications interface 1018 may be in the form of signals, which may be electronic, electromagnetic, optical, or other signals capable of being received by communications interface 1018. These signals may be provided to communications interface 1018 via a communications path 1020.
• Communications path 1020 carries signals and may be implemented using wire or cable, fiber optics, a phone line, a cellular phone link, an RF link or other communications channels.
• the computer system 1000 may also include a computer display 1024 and a display interface 1022.
• the display used to display the GUIs and dashboards for entities and relationships shown in FIG. 7A described above may be the computer display 1024, and the console interface may be display interface 1022.
• the terms “computer program medium,” “non-transitory computer readable medium,” and “computer usable medium” are used to generally refer to media such as removable storage unit 1012, removable storage unit 1016, and a hard disk installed in hard disk drive 1008. Signals carried over communications path 1020 can also embody the logic described herein.
• Computer program medium and computer usable medium can also refer to memories, such as main memory 1004 and secondary memory 1006, which can be memory semiconductors (e.g., DRAMs, etc.). These computer program products are means for providing software to computer system 1000.
• Computer programs are stored in main memory 1004 and/or secondary memory 1006. Computer programs may also be received via communications interface 1018. Such computer programs, when executed, enable computer system 1000 to implement the present invention as discussed herein. In particular, the computer programs, when executed, enable processor device 1002 to implement the processes of the present invention, such as the stages in the methods illustrated by the flowcharts in FIGs. 3A-3E, 5A-5D, 6, 7, 8A-8D, and 9 discussed above. Accordingly, such computer programs represent controllers of the computer system 1000. Where the invention is implemented using software, the software may be stored in a computer program product and loaded into computer system 1000 using removable storage drive 1010, interface 1014, and hard disk drive 1008, or communications interface 1018.
• Embodiments of the invention also may be directed to computer program products comprising software stored on any computer useable medium. Such software, when executed in one or more data processing device, causes a data processing device(s) to operate as described herein.
• Embodiments of the invention employ any computer useable or readable medium. Examples of computer useable mediums include, but are not limited to, primary storage devices (e.g., any type of random access memory), secondary storage devices (e.g., hard drives, floppy disks, CD ROMS, ZIP disks, tapes, magnetic storage devices, and optical storage devices, MEMS, nanotechnological storage device, etc.), and communication mediums (e.g., wired and wireless communications networks, local area networks, wide area networks, intranets, etc.).
• a group account number may be assigned to a business unit of an enterprise for role-based controls for members of the group.
• the service sign-in ceremony may be accomplished without requiring a service agent (by the service provider), through a plugin loaded by the client application (e.g., web browser) wherein the accessed service is qualified based on a server certificate and the encrypted password retrieved from the user token is used by the client application plugin to complete the authentication ceremony.
• the digitally signed service identifier in the user token request is optional.
• a method is executed for configuring, generating, issuing, sending, and verifying a client certificate to a first device 100, used in client authentication between applications executing on distributed devices, including a client application 101 executing on the first device 100, a server application 151 executing on a second device 150, a client certificate issued by a certificate authority (CA) 398, a key distribution service (KDS) 305, a KDS portal 317, a KDS administrator 318, a KDS proxy 602, a client KDS interface 303, a member identifier 703, a member universally unique identifier (UUID) 731 , a member domain name system (DNS) hostname 722, a symmetric KDS member (M-PSK) 715, a M- PSK identity hint 711 , a tenant identifier 735, an application identifier 742, a dynamic host configuration protocol (DHCP) service 172, and a domain name system (DNS) service
• CA certificate authority
• KDS key distribution service
• the approach additionally includes methods wherein: the device member authentication handshake is performed by the client KDS interface 303 on the first device 100 using the tenant identifier 735, the device member PSK (M-PSK) 715, and the M-PSK identity hint 711 as a first factor of a device authentication, and further wherein a session key is generated using a key exchange handshake between the client KDS interface 303 and the KDS 305 or the KDS proxy 602, and further wherein a device member validation is performed as a second factor of the device authentication, by: performing, by the KDS 305 or the KDS proxy 602, a DNS reverse lookup of a device member IP address to query for the first DNS hostname; and retrieving, by the KDS 305 or the KDS proxy 602, the first DNS hostname from a resource record in a DNS response; and comparing and matching, by the KDS 305 or the KDS proxy 602, the retrieved first DNS hostname with a device member identifier in a plurality of KDS requests.
• M-PSK
• the device authentication and a plurality of certificate and key exchange handshakes are performed over a connection-less UDP or connection-oriented TCP transport protocol, without requiring a security transport protocol.
• the validation of the first device 100 IP address is performed by the KDS proxy 602 based on the scope and address pool for the vendor class identifier configured on the DHCP service 172.
• the verification by the server application on the second device may be performed by the presence of multiple pairs of X.509 extended attributes, wherein each pair specifies a network address and network mask, to match with the host address and subnet address of the first device 100 in the protocol authentication handshake.
• the match by subnet address of the first device 100 in the protocol authentication handshake is performed using a logical AND operation between the host (IP) address of the first device 100 and the network mask in the received client certificate and then comparing the computed value of the logical AND operation with the network address in the received client certificate.
• the device metadata is defined as a name-value pair.
• the metadata type is tagged to the metadata name.
• Metadata-Identifier :: Metadata-Name : Metadata-Type
• Metadata-Type Text (Plain)
• the default metadata type is implicitly Text (Plain).
• a method is executed for configuring, on the KDS portal 317, a plurality of metadata connectors.
• the method includes authenticating, by the KDS service 305 or KDS proxy 602, a client device with two- factor authentication.
• the method further includes sending by a client application 101 on the client device 100 using the client KDS interface 303 (for example, with the ExportDeviceMetadata API) the device metadata comprising of a metadata identifier, metadata type, and metadata value to the KDS service 305.
• the method further includes receiving by the KDS service 305 the device metadata and processing the received device metadata against the configured metadata connectors.
• the method further includes sending to the webhook URL the received device metadata; and processing, by the webhook of the service provider, the received device metadata.
• the metadata connector comprises of at least a service provider name, filter type, filter name, webhook specified as a universal resource locator (URL), API token, API secret, and filter criteria specified as a list of metadata types and metadata identifiers, wherein the filter type is specified as a device type or device group 705.
• the metadata connector comprises of at least a service provider name, filter type, filter name, webhook specified as a universal resource locator (URL), API token, API secret, and filter criteria specified as a list of metadata types and metadata identifiers, wherein the filter type is specified as a device type or device group 705.
• the exported device metadata comprises of a metadata identifier, metadata type, and metadata value, wherein the metadata type may be, but not limited to, plain text, formatted text, integer number, decimal number, image, video, or audio.
• the metadata type of plain text or formatted text may be any application defined telemetry, status, or log message.
• the filters configured for the metadata connectors are applied by the KDS service 305, and the received device metadata along with the filter type and filter name matched based on the filter criteria, and associated device member identifiers (member UUID 731 , member identifier 703, member DNS hostname 722) for the client device 100 is sent to the webhook URL (for example as a JSON payload) with a HTTP request (for example, as a POST).
• the webhook URL for example as a JSON payload
• HTTP request for example, as a POST
• the received device metadata is processed by the webhook of the service provider as feature vectors to train AI/ML models, and further by applying methods, including but not limited to, linear or logistic regression, neural networks, decision trees for assessments, predictions, or analysis of cyber risks, threats to the device, or application security by design respectively.
• the response from the webhook is processed by the KDS service and stored in the device metadata repository.
• the response from the webhook may be, for example, a facial recognition based on the reported image, determination of the authenticity of the reported image, video, or audio (e.g., authentic, deep-fake), or a suggested mitigation action based on the reported status or log text message from the client device 100.
• the response from the webhook may be forwarded by the KDS service 305 to a collaboration service, specified in the payload of the response, to trigger or execute remediation actions on the client device 100.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Computer Hardware Design (AREA)
• Computing Systems (AREA)
• General Engineering & Computer Science (AREA)
• Telephonic Communication Services (AREA)
• Computer And Data Communications (AREA)
• Data Exchanges In Wide-Area Networks (AREA)

Applications Claiming Priority (14)

Publications (1)

Family

ID=96545976

Family Applications (1)

Country Status (3)

Families Citing this family (1)

Family Cites Families (17)

• 2024
  • 2024-03-22 EP EP24920503.0A patent/EP4690664A2/de active Pending
  • 2024-03-22 WO PCT/US2024/021119 patent/WO2025159775A2/en not_active Ceased
• 2025
  • 2025-09-25 IL IL323568A patent/IL323568A/en unknown

Also Published As

Similar Documents

Legal Events