A system and method for securely distributing authenticated and trusted data streams to AI systems.

Abstract

The method provides a secure way to obtain and distribute trusted metadata from a device to an artificial intelligence (AI) system. The method enables the use of cryptographic hashes and signatures on data about its origin in the supply chain. The method is an agentless method for enhancing application security, as well as data protection with data authenticity and confidentiality on devices for upstream service communications and data sharing. The method helps to securely obtain, filter, and forward device metadata to webhooks for AI / ML-driven data analysis.

Description

Technical Field

[0001] The present disclosure relates to the field of cybersecurity, and more particularly, to systems and methods for using device and application intelligence in artificial intelligence (AI) and machine learning (ML) models in the Internet of Things (IoT), Industrial IoT (IIoT), and Operational Technology (OT) environments. The present disclosure provides a method for securely distributing an authenticated and reliable data stream to an AI system.

Background Art

[0002] Device manufacturers, owners, and operators face production, operation, and economic challenges due to workflow dependencies on heterogeneous cross-domain public key infrastructure (PKI) systems, high reissuance costs of short-lived certificates issued by commercial certificate authorities (CAs), emerging post-quantum threats to asymmetric keys and PKI systems, and the complexity of on-site device key and certificate lifecycle management. Providing a manufacturer-issued birth certificate for devices during manufacturing in an air-gap and controlled environment poses extensibility and workflow challenges in the factory. Providing an owner-issued operation certificate for devices during the onboarding process poses extensibility and workflow challenges in the field. The nature of the split and / or heterogeneous hybrid PKI systems between original equipment manufacturer (OEM) and device owner / operator partners poses cross-PKI interoperability issues.

[0003] The sheer volume of heterogeneous devices in IoT, IIoT, and OT environments—billions of devices—makes private key protection, key renewal / rotation, and key / certificate lifecycle management in PKI-based environments extremely cumbersome and expensive for network operations centers (NOCs), security operations centers (SOCs), and application / device management service (AMS / DMS) operators in centralized information technology (IT) and operations technology (OT) environments. Performing certificate chain verification and processing certificate revocation lists is computationally and bandwidth-intensive for real-time applications on resource-constrained devices. Local asymmetric key pair generation and periodic renewal for enhanced cybersecurity requires high entropy and computing power. On-device secure local storage for protecting long-lived private keys at rest is unavailable for low-cost OT devices (e.g., sensors, actuators, controllers) with read-on reflash-based partitions and file systems.

[0004] Existing symmetric key generation and distribution methods run on headless (non-user) devices and manage symmetric pre-shared keys (PSKs) without adequately addressing the complex workflows associated with such PSK usage by applications communicating over insecure local and wide-area networks with other active devices, including application data transfers, command and control messages, and telemetric data transfers. Furthermore, the expiration and renewal of PSKs in use require timely synchronization between tightly coupled applications to avoid service interruptions in production environments.

[0005] Public standards such as the Group Domain of Interpretation (GDOI) specified in Request for Comments (RFC) 6407 describe methods for managing and distributing group security policies, key material, and group security associations based on group membership for authenticated and encrypted multicast and broadcast communications between group members over the Internet Protocol Security (IPsec) protocol. However, unicast peer-to-peer and client-server communications still require session key negotiation based on manually pre-configured PSKs and identity hints (e.g., Transport Layer Security (TLS)-PSK standards as specified in RFC 4279). Furthermore, managing security associations and security policies over IPsec requires per-member device allow / reject rules that are technically difficult to manage and scale in centralized IT / OT networks where the network fabric is already too complex to secure and protect.

[0006] Managing pre-shared keys for real-time use by multiple applications and services running on distributed devices across local and wide-area networks remains a major challenge.

[0007] Distributing symmetric keys to multiple connected devices requires secure device authentication by a key distribution service, device validation based on domain membership, group membership, and group-based key management, distribution policies based on authorized application identifiers, and high availability to mitigate service disruptions during field operations.

[0008] A fundamental security gap in implementing zero-trust network architectures is the lack of ability for connected applications running on heterogeneous devices listed in domain-based groups with device identification and authentication based on listed domain validation to securely orchestrate the generation and distribution of pre-shared symmetric keys on demand and at scale.

[0009] Current approaches to generating, distributing, and using symmetric keys require a network-based hardware security module (HSM) or key management system (KMS) that acts as a secure element and / or key escrow / vault for key storage, protection, and use. While an HSM does not transmit protected symmetric keys, a KMS can transmit (transport) symmetric keys via secure transport using key encapsulation mechanisms that require the use of PKI-based asymmetric public-private key pairs by authenticated receivers. Secure email protocols such as Secure / Multipurpose Internet Mail Extension (S / MIME) use key encapsulation mechanisms for security. A major challenge for KMS is the update rate and scalability of symmetric keys as the volume of headless (non-user) devices increases. While a KMS can securely generate, store, and transport symmetric keys, the dynamic coordination of key exchange across connected applications and devices pre-sharing keys for client authentication and secure communication goes beyond the scope of a KMS.

[0010] Traditional PKI systems are designed to use a single cryptographic algorithm that requires duplication of the PKI system to support different algorithms to mitigate post-quantum threats to long-lived devices using X.509 certificates. Multi-signature schemes provide two sets of cryptographic subject public keys and associated issuer signatures within a single X.509 certificate. However, multi-signature schemes require computationally and memory-intensive operations with larger certificate sizes, making them too heavy (too large) and impractical for use on resource-constrained devices. Other approaches involve splitting the cryptographic key into fragments. However, a split key still requires multiple parties (actors) to submit their fragments to establish a quorum with a specified threshold for the fragments, and to access and decrypt the data.

[0011] The OASIS Key Management Interoperability Protocol (KMIP) specification describes a message protocol for symmetric key operations (e.g., creation, derivation, key regeneration) using unique identifiers over HTTPS in various message formats (e.g., Tag Type Length Value (TTLV), JSON, XML). However, the specification does not include group-based pre-shared key and extended key usage and authorization techniques (permissions) based on factors such as network domain, application identifier, or tenant identifier. Mechanisms for authenticating clients to servers, as well as the transport underlying confidentiality and integrity, are not specified and are outside the protocol. Furthermore, the specification does not address the use of pre-shared key identity hints between the initiator / client and responder / server during connection, which is required for client authentication over secure transport protocols (e.g., TLS, IKE, SSH), insecure transport protocols over IP (UDP, TCP), or non-IP communication protocols.

[0012] One innovative system and method discloses a quantum-safe (QS) network, a quantum-distributed (QD) key, the generation of a quantum reference (QREF) locator based on input data and user secrets (credentials), and a quantum-safe networking and quantum-safe key exchange protocol using QREF access tokens. This approach provides a quantum-safe protocol in the context of quantum computing (QC) threats to key exchange protocols based on the difficulty of integer factorization and discrete logarithm problems, but requires a quantum key distribution (QKD) system via a proprietary protocol for the distribution of QD keys (e.g., satellite, fiber optic grid, telescopic line). Furthermore, establishing a QS communication channel between endpoint devices requires a quantum-safe QD key that provides a physical or direct connection from the manufacturer's or retailer's equipment to a QS registration server on the QS network. The QD key must be protected on a local secure element (e.g., HSM, TPM, or secure memory enclave). Device identifiers and attributes, as well as assigned QD keys, must be stored in the QS server of the QS system within the device account to identify the endpoint device, retrieve the appropriate QD key, and establish a QS communication channel. Such device identification and verification methods do not leverage (controlled or air-gapped) enterprise information technology (IT) device management services and onboard workflows, nor operational technology (OT) field networks. Apart from manual installation or upload processes via physical channels, the solution requires a local agent (QREF application) to be installed and run on the endpoint device, to establish a QS communication channel using the QD key, QREF access token, and device identifier / credentials, and further requires the QS network to locate the device account, identify the QREF locator from the QREF access token, and establish a QS communication channel using the correct (same) endpoint QD key.Requiring a local agent on endpoint devices presents challenges to resource limitations and real-time operating system (RTOS) platforms where monolithic production (application) images are managed and regulated by original equipment manufacturers (OEMs). The approach may also require re-engineering the line of business applications and security protocol stacks on OT / IoT / IIoT devices to utilize QD keys. Manufacturing workflows in manufacturers' / retailers' factories often do not allow access to the internet or the device owner's / operator's corporate or cloud-based production systems. Providing operational cryptographic key data to devices typically extends to device onboard workflows in production facilities, and customization becomes a cumbersome process for IT NOC / SOC operators.

[0013] Other quantum key distribution (QKD) approaches use the physical entanglement properties of optical particles exchanged through ordinary optical fibers to generate a symmetric cryptographic key between two locations without sending a key between sites.

[0014] Other proposed approaches based on symmetric pre-shared keys (PSKs) describe a resource server (or trust anchor, or trust manager, or collaboration service), a local key generator for locally deriving the symmetric key using a key derivation function, and the use of an application secret (stored in a secure element of a device endpoint or network endpoint) associated with a device identification key to bypass the transmission of the PSK between devices. However, such approaches still require the use of a secure transport channel over DTLS, TLS, or IPsec on resource-constrained devices for device authentication and may further require the first and second devices to pre-share device identifiers in order to request a pairing key (i.e., PSK) from the resource server based on identity hints. Other approaches use the first symmetric key to generate a second symmetric key, which may require a first (shared) master public key and a per-device (unique) secret key. Another approach uses session keys associated with cross-domain authorization tokens issued to the collaboration service by the authorization provider, the session keys are provided by the collaboration service to the credential management service for the device domain, and the device must then retrieve the session keys from the credential management service for the device domain. These alternative methods thus propose complex workflows between distributed devices and numerous services configured across domains. Furthermore, these alternative approaches may require inbound connections from resource servers to devices for key revocation and renewal.These other proposed approaches fundamentally fail to address the device authentication challenges imposed on devices that lack a secure element as a local root of trust (e.g., Subscriber Identification Module i. SIM, Trusted Platform Module i. TPM, Hardware Security Module i. HSM, or Physically Clonable Function i. PUF), and lack the local compute and memory resources required to establish a secure transport channel over DTLS, TLS, or IPsec, and may further involve multiple applications running on a local (client or initiator) device that require the use of a unique PSK per remote (server or responder) device. Furthermore, without automated PSK lifecycle management, manual intervention is required to pre-provide or re-provide PSKs, imposing scalability issues. While the DTLS and TLS protocols provide PSK-based authentication and the use of PSK identity hints during the handshake phase, the methods of key provisioning, authorization, exchange, and management are outside the scope of the protocol specifications. This presents a major challenge for headless (non-user) and resource-constrained connected devices in OT / IIoT / IoT environments. Furthermore, support for heterogeneous device classes (i.e., device types) requires a feasible and lightweight underlying transport and network protocol stack, along with a multilingual application programming interface (API) for application developers and programming languages ​​(e.g., C, C++, C#, Java, Objective-C, Swift, Rust).

[0015] In the emerging trend toward the centralization of information technology (IT) and operational technology (OT) workflows, operators face challenges due to the complexity of device discovery and inventory management, particularly with brownfield and greenfield devices in OT. The need and benefits of registering devices with the Domain Name System (DNS) during onboarding using immutable local device identifiers (LDevIDs) issued by the device owner / operator are increasingly becoming a requirement in standards such as IEEE 802.AR. Using LDevIDs as common names in X.509 certificates necessitates the expansion of expensive public and private PKI systems, the recurring cost of per-device certificates, and the use of cumbersome key and certificate lifecycle management protocols for manufacturing utility and line-of-business applications. This exposes a major technological gap in pre- and post-delivery of devices in factory and device onboarding within the operational domain.

[0016] Another major remaining technological gap is (a) providing digital certificates to devices at the factory (by the device manufacturer) or on-site (by the device owner / operator), (b) integrating with public / private cross-domain PKI systems in production and operational environments, and (c) implementing device authentication and secure data transport between devices and services for data integrity (tamper resistance) and data confidentiality (privacy) without air gaps and cumbersome workflows for key and certificate lifecycle management in controlled production environments.

[0017] Another remaining technical gap is the mechanism for trusted and extensible key exchange between applications required for the use of keyed-hash message authentication code (HMAC) for data integrity and authentication. HMAC uses shared secrets rather than PKI-based ciphertext and asymmetric public-private key pairs to generate digital signatures. This lack of a trusted and extensible mechanism for key exchange introduces a major complexity when document processing software, document exchange programs, and offline applications adopt HMAC authentication.

[0018] Another remaining technological gap is a mechanism for automating and scaling field device onboarding securely and without human error. Current methods of device onboarding require the use of pre-configured device accounts and passwords before the first rendezvous with the device management service. This necessitates cumbersome pre-authorization activities for both original equipment manufacturers (OEMs) and field device owners / operators. It also requires industry- and enterprise-wide consensus on the use of unique device identifiers (e.g., MAC addresses, serial numbers) for initial and local identification between OEMs and end users (based on specifications such as IEEE 802.1AR), but such consensus is difficult to achieve universally across millions of brownfield and greenfield multi-vendor devices, as well as the entire range of device families (types) deployed in the field, whether operational or commercial.

[0019] Another remaining technological gap is the need for mechanisms to automate and scale secure software updates across the supply chain with zero-trust principles for multipart content review-based approval workflows and multiperson digital signature rules, going beyond mere role-based "blind" authorization, to mitigate insider threats and advanced cyberattacks based on compromising golden signing keys. Recent high-profile breaches in upstream supply chains highlight the lack of reliable automated and gated workflows across the producer, intermediary, and consumer content distribution ecosystem for IoT / IIoT / OT device software updates.

[0020] There are five fundamental market drivers for simplifying data and device protection with agentless pre-shared symmetric key distribution services. First, the feasibility of agent-based solutions as an OEM pushback to coresident agents due to supply chain concerns and associated manufacturing and support costs. Second, application complexity introduced by requiring developers to configure, protect, and manage keys and certificates for secure communication and data protection. Essentially, certificates linked to device identifiers for device authentication are a device management function, while key usage linked to security transport and network stacks is a protocol layer function. This results in a long-tail development cycle that introduces delays in product release. Third, the operational complexity of certificate and key lifecycle management and key protection on field devices impacts the high availability of services to field devices. This can lead to service interruptions and improvement activities in the field. Fourth, interoperability challenges that arise with multi-vendor equipment, diverse operating systems and processor platforms, resource constraints for brownfield and low-cost greenfield devices, as well as multi-party protocol stack execution. And finally, infrastructure costs that increase the total cost of ownership, including PKI expansion and support, hybrid PKI systems between device manufacturers and device operators, and certificate services for certificate management.

[0021] The adoption of blockchain technology for obtaining, storing, and analyzing data from millions of decentralized devices using cloud-hosted artificial intelligence (AI) and machine learning (ML) models faces implementation, scalability, and security / privacy challenges. For high scalability and security, smart contracts and transactions require immutable and authoritative real identities from connected leaf devices and edge gateways. Implementing PKI-based systems and certificate-based authentication is expensive and cumbersome to scale and manage. Therefore, proof-based authentication methods for zero-knowledge and zero-trust networking are essential building blocks for blockchain implementation models.

[0022] The IETF Manufacturer Usage Description Specification (MUD) https: / / datatracker.ietf.org / doc / html / draft-ietf-opsawg-mud-13 is not intended to address network authorization. IETF RFC-5280 defines the use of IP addresses or Domain Name System (DNS) labels in the Subject Alternative Name (SAN) extension field of a Certificate Signing Request (CSR). The Certificate Authority (CA) / Browser (CAB) Forum's "Baseline Requirement Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates" imposes restrictions on the use of IP addresses in certificates. Applicants must provide evidence of practical control over IP addresses, for example, by performing a reverse IP address lookup and then verifying control over the resulting domain name. This requires a static IP address embedded in the issued long-life certificate. IP addresses may be dynamically assigned and therefore changeable.

[0023] Various standards, guidelines, and executive orders have been published for quantum-safe devices, including cybertrust labels and secure AI system development. These published guidelines describe the fundamental blocks of cybersecurity for AI systems as secure design, secure development, secure deployment, and secure operation and maintenance. Secure design includes mitigating attacks through control of public APIs, mitigating data and inputs from sources, and verifying the origin of training data supply chains. 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 through authenticated APIs, managing cryptographic keys to protect data, and computing and sharing cryptographic hashes and / or signatures of model files. Secure operation and maintenance includes monitoring system behavior, securing modular update procedures and distribution, and detecting out-of-distribution and / or adversarial inputs. [Overview of the project]

[0024] A system and method for protecting devices in Internet of Things (IoT), Industrial IoT (IIoT), and Operational Technology (OT) environments with application security intended to securely authenticate and communicate with data integrity and confidentiality, without requiring PKI-based digital certificates and asymmetric key pairs on the device, or complex key and certificate lifecycle management services from a Certificate Authority or managed security service provider.

[0025] The proposed system and method provides a key distribution service (KDS) for generating, distributing, and managing symmetric pre-shared keys at scale for use by applications on authenticated and domain-validated devices in an authorized group of devices, for establishing secure communication with pre-shared symmetric keys for data protection (i.e., integrity, authentication, privacy, and confidentiality) and PSK-based TLS authentication.

[0026] The proposed system and method perform a secure and authenticated Domain Name System (DNS) server reverse lookup of the device's IP address (based on DNS A records) and provide device authentication using KDS or a local KDS proxy installed on a server registered as a member device to match resolved DNS hostnames (based on DNS PTR, ALIAS, or CNAME resource records) with member identifiers in digitally signed KDS requests.

[0027] According to exemplary embodiments, the disclosure provides, depending on the implementation, a cost-effective, automated, and scalable symmetric pre-shared key distribution service for confidential (corporate, tactical) and public (Internet) networks, authorized group membership for devices with DNS domain validation, and simplification of key generation, distribution, and management, as well as the elimination of complex certificate provisioning, key renewal, and key / certificate lifecycle management workflows.

[0028] According to yet another exemplary embodiment, the present disclosure provides a flexible deployment mode for hosting a key distribution service (KDS) either on-premises or in the cloud as multi-tenant software-as-a-service (SaaS). A KDS proxy can perform device authentication and domain validation locally and be hosted on-premises to proxy requests for authenticated devices for the service to a cloud-hosted KDS SaaS. The tenant identifier configured for the KDS proxy server (device) and the local member device must be the same. The KDS proxy installed on an on-premises server registers the server as a member device with the KDS (via UDP, TCP, or TLS) and extracts the API token and API secret required for the authenticated REST API to perform proxy transactions with the KDS on behalf of the local member device. The KDS proxy extracts the PSK for the group identifier (e.g., "KDS proxy server") and the PSK identity hint (e.g., UUID) configured in the server (device) configuration file to obtain the API secret and API token for the authenticated REST API. The PSK for the KDS proxy server must be pre-configured on the KDS portal based on the named group identifier.

[0029] The disclosed method provides significant security improvements and efficiencies for enhancing legacy brownfield devices for secure communication and data protection through on-demand, simplified, and automated pre-shared key lifecycle management.

[0030] The disclosed systems and methods provide security to communication protocols between and within multiple devices, including at least the connectionless User Datagram Protocol (UDP), the connection-oriented Transmission Control Protocol (TCP), Internet Protocol (IP v4 / v6), Controller Area Network bus (CAN bus), Modbus (via TCP / UDP), Highway Addressable Remote Transducer (HART), WirelessHART, and RS232 serial communication protocol. CAN bus, HART, and Modbus networks can be bridged to an Ethernet (ETH) network using an intermediate device (CAN-ETH adapter, or HART-ETH adapter, or Modbus via TCP / UDP) that serves as a gateway between a software application program running on an application server device on the Ethernet network and CAN / HART devices on their respective CAN bus and HART networks. The security capabilities for WirelessHART networks can be enhanced through integration of the WirelessHART security manager with the KDS.

[0031] The WirelessHART security protocol and architecture uses a pre-shared join key between wireless devices, network managers, and security managers associated with the WirelessHART network. The security manager is responsible for generating, storing, updating, and revoking the key. The network manager authenticates devices using device-unique or shared pre-shared join keys 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 listing (e.g., to DNS-managed network domains), support for multicast communications, authorization and transactional account security services (for non-IP addressable devices), cryptographic agility for configuring key sizes and algorithms for quantum-resistant cryptography (specifying only AES-128 CBC-MAC, and encryption counter modes, and keyed message integrity checks), or integration of wireless and legacy HART devices. Furthermore, the pre-shared join key must be configured for all wireless devices and stored in the security manager. Since the join key serves as an authentication method to assert that a device (e.g., a sensor, gateway) is listening for advertisement broadcasts on the network to request authorization to join the network, the scope of the device is limited to the broadcast scope, not the domain level scope.

[0032] An alternative approach based on quantum-secure (QS) networks and quantum key exchange protocols requires a fleet of satellites, multiple user ground stations, a QS registration server, device accounts on the QS server, quantum-distributed keys on endpoint devices, a physical channel to the QS registration server for endpoint device provision, and a quantum reference application that must be installed and run on user endpoint devices to establish the QS communication channel.In contrast, the proposed systems and methods for headless (non-user) devices in the OT, IoT, and IIoT ecosystems (a) use enterprise Domain Name System (DNS) services over TLS / HTTPS for domain-based device description, identification, and authentication based on digitally signed resource records retrieved using Domain Name System Security Extensions (DNSSEC); (b) use enterprise Dynamic Host Configuration Protocol (DHCP) services to automatically discover scope-based device attributes; (c) do not require physical or network connectivity to Key Distribution Services (KDS); (d) do not require device provision at the point of manufacture or sale; (e) do not require agent applications to be installed or run on endpoint devices; (f) do not require re-engineering of the security transport stack; and (g) standard security Operating over security protocols (e.g., TLS, IPsec), transport protocols (e.g., TCP, UDP, CAN bus, Modbus (over TCP / UDP), HART, WirelessHART, RS232 serial), and networking protocols (e.g., IP, non-IP), (h) using a secure key exchange protocol (e.g., DH, ECDH, CRYSTALS-Kyber) between a first device and a second device, and (i) distributing a symmetric pre-shared key (PSK) to authenticated member devices based on a group identifier and a PSK identity hint, wherein the peer application communicates and distributes the PSK identity hint during a communication handshake for client authentication, or to establish a secure communication channel for data encryption using the associated PSK, or for data authenticity in consumer-producer transactions.

[0033] In one exemplary embodiment of the proposed system and method, device identification may be performed using the registered DNS hostname (via a PTR, alias, or CNAME DNS record) of a DNS domain-listed 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. For domain-listed resource-slack devices with a native dynamic DNS client (e.g., General Purpose Operating System (GPOS) based edge gateways, greenfield downstream devices), DNS may be configured dynamically with the device hostname. For resource-constrained devices where user-installable secondary market software is not permitted by the OEM, the DHCP server may be configured with an extensible custom attribute for the network domain portion (e.g., acme.com), and the device initial DNS hostname may be inferred using the device's MAC address or serial number as a prefix (e.g., 001B44113AB7.acme.com or Y9831031.acme.com). KDS can be configured to automatically (extract and) configure member devices' MAC addresses or serial numbers as member UUIDs using an inferred initial device DNS hostname. Device DNS aliases can be configured later manually with operator-friendly hostnames (e.g., camera-lobby-west.acme.com). Contract manufacturers or OEMs can provide enterprise IT administrators with manifests (batches) of device MAC addresses or serial numbers to pre-configure the DNS server with address (A) and PTR records for expected devices.

[0034] In one exemplary embodiment of the proposed system and method, device two-factor authentication may be performed using a group shared or device-unique member key as the first factor and a device-unique identifier (e.g., a DNS hostname or SIM ICCID) as the second factor.

[0035] A common use case for headless operating technology devices is authentication with a trusted, unrepudiated identity before initiating a session key exchange for secure transactions with a service or peer device. A client application runs on device A, and a server application runs on device B. Both devices are set up with a device configuration that includes a basic set of parameters for rendezvous with a Key Distribution Service (KDS), either directly or through an on-premises KDS proxy. The proposed method is agentless and may be deployed on brownfield, greenfield, or mobile devices, and applications can use the retrieved keys for data authentication or encryption with any protocol stack or cryptographic engine. The devices are listed in the network domain. Both Address (A) and Pointer (PTR) records are configured in DNS for IP address reverse lookup-based device domain verification. For mobile devices, the device IMSI identifier is used for device verification with mobile service providers where proving ownership of the authentication key presents challenges. Devices may be automatically configured using the KDS interface API to retrieve vendor-specific information from a DHCP server. Devices are authenticated by a KDS proxy over a secure channel with a security challenge as the first factor of authentication, and by a DNS server for device domain verification as the second factor of authentication. Applications can create or retrieve keys over the secure channel using pre-shared key identity hints. All key operations for status verification, updating, and deletion are performed over the secure channel with two-factor device authentication. Applications can use retrieved keys for client authentication over TLS-PSK, and for data authentication and data encryption over insecure UDP, TCP, or non-IP protocols. Retrieved keys can also be used for partial and selective message encryption, content signing, or supply chain tamper resistance.

[0036] In one exemplary embodiment, a method is performed for generating, distributing, and managing the lifecycle of a symmetric pre-shared key (PSK) (C-PSK) for client authentication between applications running on distributed devices, including a client application running on a client device, a server application running on a server device, a Key Distribution Service (KDS), a KDS proxy, a KDS interface, a symmetric KDS member PSK (M-PSK), an 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. The method involves authenticating with the KDS by a client application running on a client device using a configured tenant identifier, a symmetric KDS member PSK (M-PSK), and an M-PSK identity hint, wherein the client device is registered by a DNS hostname on a DNS server configured in the KDS or KDS proxy and configured as a member of a device group in the KDS. The method involves a client application obtaining a C-PSK from a KDS using at least a group identifier and a C-PSK identity hint for use as a shared symmetric key for client authentication via a secure transport protocol for communicating with a server application running on a server device registered by a DNS hostname in a DNS server, further comprising the server device being configured as a member of a device group in the KDS.The method involves authenticating with KDS by a server application running on a server device using a configured tenant identifier, a symmetric KDS member PSK (M-PSK), and an M-PSK identity hint, further comprising authenticating the server device, which is registered by a DNS hostname on a DNS server configured with KDS or a KDS proxy, and configured as a member of a device group in KDS. The method involves obtaining a C-PSK from KDS by a server application using at least a group identifier and a C-PSK identity hint for use as a shared symmetric key for client authentication over a secure transport protocol to communicate with a client application running on a client device registered by a DNS hostname on a DNS server, further comprising obtaining the C-PSK, which is configured as a member of a device group in KDS. The method further involves initiating a TLS-PSK session by a client application using the obtained C-PSK for the client device in the device group as a PSK for client authentication in order to establish secure communication with a server application running on a server device. The method further includes updating the C-PSK programmatically and automatically using the KDS interface, without requiring human intervention and without service interruption, by client and server applications for client authentication upon expiration or for rapid key rotation.

[0037] The approach also includes the following additional methods: The device member authentication handshake is performed by the KDS interface on the client and server devices using the tenant identifier, device member PSK (M-PSK), and M-PSK identity hint for the first factor of device authentication. Furthermore, the session key is generated using the key exchange handshake between the KDS interface and KDS or KDS proxy. Furthermore, device member validation for the second factor of device authentication is performed. Performing a DNS reverse lookup of the device member IP address via KDS or KDS proxy to query the DNS hostname, Retrieving DNS hostnames from resource records in DNS responses using KDS or a KDS proxy, The retrieved DNS hostname is compared and matched with the device member identifier in the KDS request by KDS or a KDS proxy. It will be carried out by [company name].

[0038] The approach further includes the following methods: Device authentication and key exchange handshakes may be performed via connectionless UDP or connection-oriented TCP transport protocols without requiring security transport protocols such as DTLS, TLS, or IPsec, and furthermore, data authentication and / or data encryption may be performed with the retrieved pre-shared key via any communication protocol such as UDP / IP, TCP / IP, or a non-IP protocol.

[0039] The KDS interface provides an application programming interface (API) for client and server applications to send requests about key operations to and from KDS, either directly or indirectly through a KDS proxy, and to receive responses.

[0040] Client and server devices are registered with IP address (A) records and PTR records for DNS hostname reverse lookups using unique DNS hostnames within the domain on the local DNS server.

[0041] In KDS, client and server devices are configured as members of a tenancy associated with a tenant identifier, and as device groups associated with the tenant identifier. Furthermore, each device group consists of a key record containing a key instance (C-PSK) for client authentication.

[0042] In KDS, the key record configured for a device group includes key expiration timestamps and key status to manage automatic key renewal, key rotation, and key revocation operations in KDS.

[0043] In KDS, the key record configured for a device group includes a key token that allows a client application to send authenticated API requests to a server application, using the key instance as an API shared secret and the key token as an API shared token, and furthermore, the API request may be a REST API request.

[0044] Requests from authenticated member devices for any key action based on the group identifier and C-PSK identity hint are processed by the KDS and may be permitted based on a match between the member domain and the domain (i.e., the domain name and top-level domain suffix) derived from the resource record retrieved by a DNS reverse lookup of the member device DNS hostname.

[0045] Requests from authenticated member devices for any key action based on the group identifier, C-PSK identity hint, and application identifier are processed by the KDS and may be permitted or denied based on the match between the application identifier associated with the group identifier.

[0046] Device-specific information configured as extended custom attributes of member devices can be retrieved from the DHCP server using the extended KDS interface API to automate local device configuration and export vendor-specific member device information to KDS.

[0047] Authenticated member device requests for any key action based on the group identifier and C-PSK identity hint are processed by KDS and may be permitted based on a match between the member device tenant identifier and the associated license owner identifier retrieved from the DHCP server as vendor-specific member device information.

[0048] A device-unique C-PSK identity hint can be generated by a client application to create a device-unique PSK for client authentication (C-PSK) using a device-unique registration identifier and a derived function (e.g., the HMAC-SHA256 algorithm).

[0049] In another exemplary embodiment, a method is performed for generating, distributing, and managing the lifecycle of a symmetric pre-shared key (PSK) (S-PSK) for secure communication for use between applications running on distributed devices, including a client application running on a client device, a server application running on a server device, a Key Distribution Service (KDS), a KDS proxy, a KDS interface, a symmetric KDS member M-PSK, an 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, an 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. The method involves authenticating with the KDS by a client application running on a client device using a configured tenant identifier, a symmetric KDS member PSK (M-PSK), and an M-PSK identity hint, wherein the client device is registered by a DNS hostname on a DNS server configured in the KDS or KDS proxy and configured as a member of a device group in the KDS. The method involves a client application obtaining an S-PSK from a KDS using at least a group identifier and an S-PSK identity hint for use as a shared symmetric key for communication with a server application running on a server device registered by a DNS hostname on a DNS server, thereby securing communication over an insecure transport protocol, and further comprising obtaining the S-PSK if the server device is configured as a member of a device group.The method involves authenticating with KDS by a server application running on a server device using a configured tenant identifier, a symmetric KDS member PSK (M-PSK), and an M-PSK identity hint, further comprising authenticating the server device, which is registered by a DNS hostname on a DNS server configured with KDS or a KDS proxy, and configured as a member of a device group in KDS. The method involves the server application obtaining an S-PSK from KDS using at least a group identifier and an S-PSK identity hint for use as a shared symmetric key to secure communication over an insecure transport protocol and to communicate with a client application running on a client device registered by a DNS hostname on a DNS server, further comprising obtaining the S-PSK, which is configured as a member of a device group. The method further involves the client application running on a client device protecting the authenticity and / or confidentiality of data during communication with a server application running on a server device over an insecure connection-oriented or connectionless transport protocol using the obtained S-PSK. The method further includes protecting the authenticity and / or confidentiality of data in communication with a client application running on a client device over an insecure connection-oriented or connectionless transport protocol, using an acquired S-PSK by a server application running on a server device. The method further includes updating the S-PSK by the client and server applications programmatically and automatically using a KDS interface for secure communication at expiration or for fast key rotation, without requiring human intervention and without service interruption.

[0050] The approach also includes the following additional methods: The device member authentication handshake is performed by the KDS interface on the client and server devices using the tenant identifier, device member PSK (M-PSK), and M-PSK identity hint for the first factor of device authentication. Furthermore, the session key is generated using the key exchange handshake between the KDS interface and KDS or KDS proxy. Furthermore, device member validation for the second factor of device authentication is performed. Performing a DNS reverse lookup of the device member IP address via KDS or KDS proxy to query the DNS hostname, Retrieving DNS hostnames from resource records in DNS responses using KDS or a KDS proxy, The retrieved DNS hostname is compared and matched with the device member identifier in the KDS request by KDS or a KDS proxy. It will be carried out by [company name].

[0051] The approach further includes the following: Device authentication and key exchange handshake may be performed over connectionless UDP or connection-oriented TCP transport protocols without requiring a security transport protocol such as DTLS, TLS, or IPsec; and data authentication and / or data encryption may be performed over any communication protocol such as UDP / IP, TCP / IP, or a non-IP protocol with the retrieved pre-shared key.

[0052] The KDS interface provides an application programming interface (API) for client and server applications to send requests about key operations to and from KDS, either directly or indirectly through a KDS proxy, and to receive responses.

[0053] Client and server devices are registered with IP address (A) records and PTR records for DNS hostname reverse lookups using unique DNS hostnames within the domain on the local DNS server.

[0054] In KDS, client and server devices are configured as members of a tenancy associated with a tenant identifier, and as device groups associated with the tenant identifier. Furthermore, each device group consists of a key record containing a key instance (S-PSK) to secure communication between client and server applications.

[0055] In KDS, the key record configured for a device group includes key expiration timestamps and key status to manage automatic key renewal, key rotation, and key revocation operations in KDS.

[0056] Before a client application obtains an S-PSK from the KDS, the S-PSK is created in the KDS by the server application as a key creator on the server member device and with restricted key usage permissions for, for example, data authentication, data encryption, content (producer or intermediary) signing, broadcast signing, broadcast encryption, multicast signing, multicast encryption, token signing, or token encryption operations.

[0057] The acquisition of S-PSKs from KDS by client applications restricts key usage based on permissions configured by the key creator.

[0058] In KDS, the key record configured for a device group includes a key token that allows a client application to send authenticated API requests to a server application, using the key instance as an API shared secret and the key token as an API shared token, and furthermore, the API request may be a REST API request.

[0059] Requests from authenticated member devices for any key action based on the group identifier and S-PSK identity hint are processed by the KDS and may be permitted based on a match between the member domain and the domain (i.e., the domain name and top-level domain suffix) derived from the resource record retrieved by a DNS reverse lookup of the member device DNS hostname.

[0060] Requests from authenticated member devices for any key action based on the group identifier, S-PSK identity hint, and application identifier are processed by the KDS and may be permitted or denied based on the match between the application identifier associated with the group identifier.

[0061] Device-specific information configured as extended custom attributes of member devices can be retrieved from the DHCP server using the extended KDS interface API to automate local device configuration and export vendor-specific member device information to KDS.

[0062] Authenticated member device requests for any key action based on the group identifier and S-PSK identity hint are processed by KDS and may be permitted based on a match between the member device tenant identifier and the associated license owner identifier retrieved from the DHCP server as vendor-specific member device information.

[0063] Derived device keys (D-PSKs) are created locally, just-in-time on demand, using the extracted S-PSK and device unique identifier as registration identifiers for client and server applications, but do not necessarily need to be stored locally, in order to sign and / or encrypt messages or tokens about data authentication and / or secrets.

[0064] In another exemplary embodiment, a method for certificateless authentication and validation of a mobile device is performed, comprising an application running on the 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. The mobile device member authentication handshake is performed by the KDS interface on the client mobile device using a tenant identifier, a device member PSK (M-PSK), and an M-PSK identity hint for the first factor of device authentication; further, a session key is generated using a key exchange handshake between the KDS interface and the KDS or KDS proxy; and further, device member validation for the second factor of device authentication involves the KDS receiving the mobile device's Integrated Circuit Card Identifier (ICCID), International Mobile Equipment Identification Number (IMEI), and International Mobile Telephone Subscriber Identification Number (IMSI) information from the mobile device and securely stored within the SIM. This is carried out by sending a nonce to the mobile device by KDS for signing by the SIM on the mobile device using the assigned authentication key, the storage location of which may be within the card circuit equipment or on an applet on the SIM; receiving the signed nonce from the mobile device by KDS; sending the nonce and IMSI for signing using the mobile device's associated authentication key to the mobile device's mobile service provider by KDS; and authenticating the mobile device by KDS by comparing and matching the signed nonce received from the mobile device and the mobile service provider in order to authenticate and validate the mobile device.

[0065] The approach also includes the following additional methods: Requests from authenticated mobile member devices for any key action based on a group identifier and C-PSK or S-PSK identity hint are processed by the KDS and may be permitted based on a match between the member device tenant identifier and the associated license owner identifier retrieved from the DDS as vendor-specific member device information.

[0066] In another exemplary embodiment, a method is implemented for generating, distributing, and managing the lifecycle of a symmetric pre-shared key (PSK) (S-PSK) for certificate-less selective encryption of a portion of a message over an insecure transport for use between applications running on distributed devices, including a client application running on a client device, a server application running on a server device, a Key Distribution Service (KDS), a KDS proxy, a KDS interface, a symmetric KDS member M-PSK, an 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, an S-PSK identity hint, a key record, a Dynamic Host Configuration Protocol (DHCP) server, and a Domain Name System (DNS) server. The method includes: a client application retrieving a pre-shared key from the KDS using at least a group identifier and an S-PSK identity hint; the client application selectively encrypting a portion of a message transmitted over the network with the retrieved pre-shared key; and a server application retrieving a pre-shared key from the KDS using at least a group identifier and an S-PSK identity hint; and the server application selectively decrypting a portion of a message received over the network with the retrieved pre-shared key.

[0067] The approach also includes the following additional methods: Requests from authenticated member devices for any key action based on group identifiers and S-PSK identity hints are handled by the KDS and may be permitted based on a match between the member domain and the domain (i.e., the domain name and top-level domain suffix portion) derived from the resource record retrieved by a DNS reverse lookup of the member device DNS hostname.

[0068] Requests from authenticated member devices for any key action based on the group identifier, S-PSK identity hint, and application identifier are processed by the KDS and may be permitted or denied based on the match between the application identifier associated with the group identifier.

[0069] Device-specific information configured as extended custom attributes of member devices can be retrieved from the DHCP server using the extended KDS interface API to automate local device configuration and export vendor-specific member device information to KDS.

[0070] Authenticated member device requests for any key action based on the group identifier and S-PSK identity hint are processed by KDS and may be permitted based on a match between the member device tenant identifier and the associated license owner identifier retrieved from the DHCP server as vendor-specific member device information.

[0071] In another exemplary embodiment, a method is implemented for generating, distributing, and managing the lifecycle of a symmetric pre-shared key (PSK) (S-PSK) for certificate-less selective encryption of a portion of a message over an insecure transport for use between applications running on distributed mobile devices, including a client application running on a client mobile device, a server application running on a server mobile device, a Key Distribution Service (KDS), a KDS proxy, a KDS interface, a symmetric KDS member M-PSK, an 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, an S-PSK identity hint, a key record, a Device Directory Service (DDS), and a Mobile Service Provider (MSP) server.

[0072] The approach also includes the following additional methods: Requests from authenticated member devices for any key action based on the group identifier, S-PSK identity hint, and application identifier are processed by the KDS and may be permitted based on the match between the application identifier associated with the group identifier to allow or reject the key action.

[0073] Authenticated member device requests for any key action based on the group identifier and S-PSK identity hint are processed by the KDS and may be permitted based on a match between the member device tenant identifier and the associated license owner identifier retrieved from the DDS as vendor-specific member device information.

[0074] In another exemplary embodiment, a method is implemented for generating, distributing, and managing the lifecycle of a symmetric pre-shared key (PSK) for certificate-less document security by selective object cryptography for use between applications running on distributed devices, including a producer application running on a producer device, a consumer application running on a consumer device, a Key Distribution Service (KDS), a KDS proxy, a KDS interface, a symmetric KDS member M-PSK, an 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. The method includes: creating a pre-shared key with an identity hint by a producer application in a KDS; using the retrieved pre-shared key selectively by the producer application to encrypt embedded objects in a document, wherein the producer application may be document processing software or a document exchange program; further, different embedded objects may be encrypted with different pre-shared keys; and further, the pre-shared key identity hint is tagged with each encrypted embedded object; sending the document containing the embedded encrypted objects and tagged pre-shared key identity hints to a consumer application by the producer application; for decryption, retrieving the pre-shared key for the pre-shared key identity hint tagged with each encrypted embedded object in the received document by the consumer application using at least a group identifier and the pre-shared key identity hint; and restricting access to the encrypted embedded objects in the document by the consumer application on a device authenticated and validated by the KDS, wherein the consumer application may be document processing software or a document exchange program.

[0075] The approach also includes the following additional methods: Requests from authenticated member devices for any key action based on group identifiers and pre-shared key (PSK) identity hints are handled by the KDS and may be permitted based on a match between the member domain and the domain (i.e., the domain name and top-level domain suffix portion) derived from resource records retrieved by a DNS reverse lookup of the member device DNS hostname.

[0076] Requests from authenticated member devices for any key action based on the group identifier, pre-shared key (PSK) identity hint, and application identifier are processed by the KDS and may be permitted or denied based on the match between the application identifier associated with the group identifier.

[0077] Device-specific information configured as extended custom attributes of member devices can be retrieved from the DHCP server using the extended KDS interface API to automate local device configuration and export vendor-specific member device information to KDS.

[0078] Authenticated member device requests for any key action based on the group identifier and pre-shared key identity hint are processed by the KDS and may be permitted based on a match between the member device tenant identifier and the associated license owner identifier retrieved from the DHCP server or DDS as vendor-specific member device information.

[0079] In another exemplary embodiment, a method is implemented for generating, distributing, and managing the lifecycle of a symmetric pre-shared key (PSK) for tamper-resistant certificate-less keyed hash message authentication code (HMAC)-based content signing, for use between applications running on distributed devices, including a producer application running on a producer device, consumer applications running on consumer devices, a Key Distribution Service (KDS), a KDS proxy, a KDS interface, a symmetric KDS member M-PSK, an 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.The method includes: a producer application creating a symmetric pre-shared key with an associated pre-shared key (PSK) identity hint by a producer application in a KDS; the producer application signing digital content using the created pre-shared key; the producer application generating a signature manifest associated with a tenant identifier, group identifier, digital signature, and pre-shared key identity hint; the producer application sending the signed digital content and associated signature manifest to a consumer application; the consumer application receiving the signed digital content, as well as the signature manifest associated with the tenant identifier, group identifier, digital signature, and pre-shared key identity hint; the consumer application retrieving the pre-shared key for the pre-shared key identity hint in the received signature manifest from the KDS using at least the tenant identifier, group identifier, and pre-shared key identity hint; and the consumer application verifying the received signed digital content using the retrieved pre-shared key to regenerate the digital signature and compare it to the digital signature in the received signature manifest for a match.

[0080] The approach also includes the following additional methods: Requests from authenticated member devices for any key action based on group identifiers and pre-shared key (PSK) identity hints are handled by the KDS and may be permitted based on a match between the member domain and the domain (i.e., the domain name and top-level domain suffix portion) derived from resource records retrieved by a DNS reverse lookup of the member device DNS hostname.

[0081] Requests from authenticated member devices for any key action based on the group identifier, pre-shared key (PSK) identity hint, and application identifier are processed by the KDS and may be permitted or denied based on the match between the application identifier associated with the group identifier.

[0082] Device-specific information configured as extended custom attributes of member devices can be retrieved from the DHCP server using the extended KDS interface API to automate local device configuration and export vendor-specific member device information to KDS.

[0083] Authenticated member device requests for any key action based on the group identifier and pre-shared key identity hint are processed by the KDS and may be permitted based on a match between the member device tenant identifier and the associated license owner identifier retrieved from the DHCP server or DDS as vendor-specific member device information.

[0084] In another exemplary embodiment, a method is implemented 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 supply chain tamper resistance, for use between applications running on distributed devices, including an intermediary application running on an intermediary device, consumer applications running on consumer devices respectively, a Key Distribution Service (KDS), a KDS proxy, a KDS interface, a symmetric KDS member M-PSK, an 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.The method involves the intermediary application receiving the signed digital content and associated signature manifest, the intermediary application creating an additional pre-shared key in the KDS, the intermediary application signing the received signed digital content using the created pre-shared key to generate enhanced signed digital content, the intermediary application attaching a tenant identifier, group identifier, additional digital signature, and additional associated pre-shared key identity hint to the received signature manifest to generate an enhanced signature manifest, and the intermediary application sending the enhanced signed digital content and associated enhanced signature manifest to the consumer application. The process includes: a consumer application receiving signed digital content, as well as an extended signature manifest associated with a tenant identifier, group identifier, digital signature, and pre-shared key identity hint; the consumer application retrieving the pre-shared key for the identity hint in the received extended signature manifest from the KDS using at least the tenant identifier, group identifier, and pre-shared key identity hint; and the consumer application verifying the received extended signed digital content using the retrieved pre-shared key to regenerate the digital signature and compare it to the respective digital signature associated with each identity hint in the received extended signature manifest to find a match.

[0085] The approach also includes the following additional methods: Requests from authenticated member devices for any key action based on group identifiers and pre-shared key (PSK) identity hints are handled by the KDS and may be permitted based on a match between the member domain and the domain (i.e., the domain name and top-level domain suffix portion) derived from resource records retrieved by a DNS reverse lookup of the member device DNS hostname.

[0086] Requests from authenticated member devices for any key action based on the group identifier, pre-shared key (PSK) identity hint, and application identifier are processed by the KDS and may be permitted or denied based on the match between the application identifier associated with the group identifier.

[0087] Device-specific information configured as extended custom attributes of member devices can be retrieved from the DHCP server using the extended KDS interface API to automate local device configuration and export vendor-specific member device information to KDS.

[0088] Authenticated member device requests for any key action based on the group identifier and pre-shared key identity hint are processed by the KDS and may be permitted based on a match between the member device tenant identifier and the associated license owner identifier retrieved from the DHCP server or DDS as vendor-specific member device information.

[0089] In another exemplary embodiment, a method for agentless device risk monitoring is performed, comprising a machine learning model, a multidimensional feature matrix, harvested device intelligence, a threat intelligence provider, a device management system, and a network activity monitoring system. The method involves selecting an algorithm for building a machine learning model using the multidimensional feature matrix as a training dataset along with harvested device intelligence; building a multidimensional feature matrix including device tenancy, group membership, key type and usage profile, key usage volume, key rotation rate, and application identifiers (e.g., file name, file hash); and content integrity measurements including scores categorized by application reputation, static / dynamic analysis, runtime introspection analysis, domain generation algorithm (DGA) analysis, obfuscation level, decompression level, IP address and domain reputation, geolocation, autonomous system number (ASN), and IP address age. This includes extending the feature matrix with application-based metrics about hazards imported from external forensic science-based threat intelligence providers, including vulnerability assessments; extending the feature metric by extracting device properties (e.g., model, manufacturer, identifier, attributes, update history) from device management systems; extending the feature matrix by extracting flow records about the connection history of inter-device communications from network activity monitoring systems; predicting device risk scores using multidimensional feature matrices of linear regression; and classifying security events as true positive, false positive, true negative, or false negative using unsupervised models, multilayer deep learning networks, and multidimensional feature matrices of logistic regression.

[0090] Common use cases for wireless operating technology devices include secure delivery in factories on manufacturer networks and field onboarding on production networks. The main or dedicated onboarding application on device A must connect to a secure wireless access point (WAP) on the production network. The device manufacturer is provided with a guest SSID and guest pre-shared key for connecting the device to a guest wireless network. The device must be switched from the guest wireless network to the secure wireless network with zero touch during device onboarding on the production network. The wireless access point is configured for multi-SSID mode, operating with different SSIDs and pre-shared keys for the guest and secure wireless networks. Device A is set up with a device configuration that includes a basic set of parameters for rendezvousing with the KDS, either directly or through an on-site KDS proxy, and an internal key identity hint for retrieving 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 listed in 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 a guest pre-shared key to connect to the guest wireless network. Device A may be automatically configured using the KDS interface API to retrieve vendor-specific information from the DHCP server. The internal SSID may be retrieved from the scope's DHCP attribute. Device A is authenticated by the KDS proxy via a secure channel with security challenges as the first factor of authentication, and by the DNS server for device domain verification as the second factor of authentication.The application uses an internal pre-shared key identity hint to retrieve a pre-shared key for a secure wireless network over a secure channel. The application then uses the retrieved internal pre-shared key to authenticate with the wireless access point over the secure wireless network.

[0091] In another exemplary embodiment, a method is implemented for distributing a symmetric internal wireless access point (WAP) preshared key (IWAP-PSK) for secure wireless authentication by devices using WAP in a production network, including a supplicant program running on the device, a WAP configured for multi-SSID (Service Set Identifier) ​​mode of operation, a Key Distribution Service (KDS), a KDS proxy, a KDS interface, a symmetric KDS member PSK (M-PSK), an 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, an IWAP-PSK identity hint, an internal WAP SSID (IWAP-SSID), a guest WAP preshared key (GWAP-PSK), a key record, a Dynamic Host Configuration Protocol (DHCP) server, and a Domain Name System (DNS) server. The method includes authenticating by a supplicant program using WAP with GWAP-SSID and GWAP-PSK to establish initial wireless access for a device over a production network. The method further includes authenticating with KDS by a supplicant program running on a device using a configured tenant identifier, a symmetric KDS member PSK (M-PSK), and an M-PSK identity hint, wherein the client device is registered by a DNS hostname on a DNS server configured in KDS or KDS proxy and configured as a member of a device group in KDS. The method further includes retrieving IWAP-PSK from KDS by a supplicant program using at least a group identifier and an IWAP-PSK identity hint for use as a shared symmetric key for authentication with a wireless access point.The method further includes authenticating by a supplicant program using WAP, with the IWAP-SSID and extracted IWAP-PSK, to establish secure wireless access for devices over the production network and to perform a switchover from the guest SSID to the internal SSID wireless network.

[0092] The approach also includes the following: In KDS, devices are configured as members of a tenancy associated with a tenant identifier, and as device groups associated with a tenant identifier, and furthermore, device groups consist of key records containing key instances (IWAP-PSK) for secure wireless authentication.

[0093] Requests from authenticated member devices for any key action based on the group identifier and IWAP-PSK identity hint are processed by KDS and may be permitted based on a match between the member domain and the domain (i.e., the domain name and top-level domain suffix) derived from the resource record retrieved by a DNS reverse lookup of the member device DNS hostname.

[0094] The GWAP-SSID, GWAP-PSK, IWAP-SSID, M-PSK, and M-PSK identity hints can be factory-configured attributes for executable application images or system firmware on a Real-Time Operating System (RTOS) platform, or they can be specified through configuration files on a General-Purpose Operating System (GPOS) platform.

[0095] The primary and secondary KDS / KDS proxy URLs, tenant identifiers, and group identifiers and identity hints associated with the production WAP for secure access can be discovered using network characteristics based on custom attributes configured on the DHCP or DNS server associated with the member device LAN.

[0096] Requests from authenticated member devices for any key action based on the group identifier, IWAP-PSK identity hint, and application identifier are processed by the KDS and may be permitted or denied based on the match between the application identifier associated with the group identifier.

[0097] Device-specific information configured as extended custom attributes of member devices can be retrieved from the DHCP server using the extended KDS interface API to automate local device configuration and export vendor-specific member device information to KDS.

[0098] Authenticated member device requests for any key action based on the group identifier and IWAP-PSK identity hint are processed by KDS and may be permitted based on a match between the member device tenant identifier and the associated license owner identifier retrieved from the DHCP server as vendor-specific member device information.

[0099] The supplicant program can detect changes in the IWAP-PSK based on the inability to authenticate with WAP using the IWAP-SSID and the last retrieved and stored IWAP-PSK, automatically switch over to the guest wireless network using the GWAP-SSID and GWAP-PSK, authenticate with the KDS, retrieve the IWAP-PSK from the KDS, and then switch over to the secure wireless network by authenticating with WAP using the IWAP-SSID and the retrieved IWAP-PSK.

[0100] For security reasons, the supplicant program does not need to store the last retrieved IWAP-PSK locally on the device and dynamically during power cycles or application restarts, authenticate with the guest wireless network using the GWAP-SSID and GWAP-PSK, authenticate with the KDS, retrieve the IWAP-PSK from the KDS, or authenticate with the WAP using the IWAP-SSID and retrieved IWAP-PSK to switch over to a secure wireless network.

[0101] The supplicant program may be a Wi-Fi supplicant, or a Wi-Fi supplicant function implemented within a production application or system firmware.

[0102] The member device DNS hostname on the local DNS server is equivalent to the Local Device Identifier (LDevID) as described in the IEEE 802.1AR standard for device identification, and can also be served as the Local Device Identifier (LDevID).

[0103] The disclosure system and method provide automated management within the KDS of the status, updates, and revocation of PSKs distributed to member devices by the KDS (by the administrator or explicitly by the key creator). This addresses major operational and administrative challenges commonly associated with PKI-based solutions, such as the additional cost of certificate revocation, the overhead associated with managing and distributing large Certificate Revocation Lists (CRLs) to resource-constrained devices, the processing of CRLs by online queries for certificate status or real-time applications requiring low latency at runtime, and the complexity associated with implementing key update methods for key lifecycle management on headless devices.

[0104] The disclosure system and method provide just-in-time on-demand retrieval of symmetric pre-shared keys by embedded applications and embedded devices, without requiring local persistence (storage) of retrieved keys. Cloud-based services and microservices may require pre-shared keys for digitally signed tokens, such as Shared Access Signature (SAS) tokens, to provide devices and establish authenticated connections. Microservices (e.g., authorization services) may require pre-shared keys to encrypt access tokens for secure distribution to requesters (e.g., client applications on devices). Key exchange ceremonies with cloud-based services may require securing the retrieval and storage of nonce (i.e., symmetric pre-shared key) on a local secure element (e.g., a Trusted Platform Module, i.e., a TPM), and using the secured nonce to sign and / or encrypt service tokens in future transactions. Local hardware, firmware, or software-based secure elements may not be available on legacy / brownfield devices and significantly resource-slack, low-cost greenfield devices. Furthermore, resource-constrained devices lack writable storage space on non-volatile random-access memory (NVRAM), flash, or hard disk drives (HDDs) to sustain data objects. The use of PKI-based key pairs and explicitly trusted certificates is a complex and unscalable solution due to computational, memory, and storage limitations. Therefore, the ability to dynamically retrieve and use pre-shared keys on demand from a KDS without requiring locally persisted retrieved keys or pre-provided keys intentionally enables low-cost application security on resource-constrained devices.

[0105] A system and method for dynamic retrieval of PKI-based trusted intermediate and root certificates, leaf certificates, and associated private keys by an application (client, server, or command-line utility) running on a device with two-factor device authentication, without installing an agent on the device, and via an application programming interface (API) in any modern programming language. The Key Distribution Service (KDS) interface provides an application programming interface (API) for applications to send requests about certificate behavior directly to / from the KDS or indirectly through a KDS proxy and receive responses. Certificates can be imported, renewed, or key regenerated (in single or batch mode) through the KDS portal. Trusted applications can retrieve trusted certificates, leaf certificates, and associated private keys and verify certificate status using the KDS API. The KDS enforces policy-based authorization using a pre-configured list of trusted applications. For runtime use, applications can store retrieved trusted certificates in the local trust store, and retrieved leaf certificates and associated private keys in the local key store. Optionally, applications can protect retrieved private keys using a local secure element (such as a TPM or SIM). Optionally, applications can dynamically retrieve leaf certificates and associated private keys (i.e., without leaving the retrieved artifacts in a local key store such as a secure file system, secure element, or NVRAM).

[0106] Local secure elements for protecting devices or cryptographic secret keys of asymmetric key pairs in resource-constrained IoT, IIoT, and OT environments (for example, in terms of computation and / or storage capacity) require methods for remote server-side key generation and secure secret key distribution.

[0107] A system and method for dynamic retrieval of PKI-based trusted intermediate and root certificates, leaf certificates, and associated private keys by an application (client, server, or command-line utility) running on a device with two-factor device authentication, without installing an agent on the device, and via an application programming interface (API) in any modern programming language. The Key Distribution Service (KDS) interface provides an application programming interface (API) for applications to send requests about certificate behavior directly to / from the KDS or indirectly through a KDS proxy and receive responses. Certificates can be imported, renewed, or key regenerated (in single or batch mode) through the KDS portal. Trusted applications can retrieve trusted certificates, leaf certificates, and associated private keys and verify certificate status using the KDS API. The KDS enforces policy-based authorization using a pre-configured list of trusted applications. For runtime use, applications can store retrieved trusted certificates in the local trust store, and retrieved leaf certificates and associated private keys in the local key store. Optionally, applications can protect retrieved private keys using a local secure element (such as a TPM or SIM). Optionally, applications can dynamically retrieve leaf certificates and associated private keys (i.e., without leaving the retrieved artifacts in a local key store such as a secure file system, secure element, or NVRAM).

[0108] Local secure elements for protecting devices or cryptographic secret keys of asymmetric key pairs in resource-constrained IoT, IIoT, and OT environments (for example, in terms of computation and / or storage capacity) require methods for remote server-side key generation and secure secret key distribution.

[0109] The disclosure method configures and uses extended attributes, such as security extensions in the X.509 certificate Subject Alternative Name (SAN) field, to specify host addresses, network addresses, and network masks for scope and address pool-based network segmentation for granting client devices managed access to server devices, and the vendor-class identifiers associated with the client devices, scopes, and address pools are configured on the DHCP server associated with the deployment infrastructure. Furthermore, the method provides the use of X.509 certificates issued by a public or private Certificate Authority (CA), or self-signed certificates (i.e., issued by a null CA such as the OpenSSL utility, where the certificate is signed with its own private key, not by a trusted CA). This method provides regulation of self-signed certificates by device two-factor authentication on the local network for evidence of actionable control over host addresses, address pools, and network subnets, as well as runtime validation of extended host (IP) and network (subnet) address attributes in the certificate SAN. Anti-spoofing security countermeasures (for IP addresses, DHCP, and DNS) must be implemented on the local network.

[0110] Many devices in IoT / IIoT lack the computing power, memory, and storage required for application logging and messaging protocols such as MQTT or AMQP to publish messages to topics. The disclosure system and method provides an agentless approach for resource-constrained and resource-slack devices with APIs in any modern programming language for sending device metadata to microservices hosted on-premises or in the cloud, and a method for relaying device metadata to service providers in real time via webhooks for data analysis by AI / ML engines. The method provides device two-factor authentication, a secure channel for managing and distributing quantum proof keys and quantum-resistant certificates for authenticated access, authenticated APIs, and data signatures, deliberately simplified APIs for security, to establish protection from factory to field environments with technologies applicable to numerous industries from retail to manufacturing, energy, healthcare, automotive, and more, as well as trusted data with tamper-proof signatures for training AI / ML models.

[0111] This disclosure is best understood when read in conjunction with the attached drawings, as detailed below. According to common practice, various features / elements in the drawings may not be drawn to scale. Common numerical references represent similar features / elements. The following figures are included in the drawings. [Brief explanation of the drawing]

[0112] [Figure 1A] This schematic diagram illustrates an example of a distributed intelligent network and key distribution service through various exemplary embodiments of the disclosed system. [Figure 1B] This schematic diagram illustrates an exemplary device label scan-based device discovery and provisioning system in various exemplary embodiments of the disclosed system. [Figure 1C]This schematic diagram illustrates an exemplary device label scan-based device onboard workflow using various exemplary embodiments of the disclosed system. [Figure 1D] This schematic diagram illustrates an example of a supply chain tamper-proof content distribution service through various exemplary embodiments of the disclosure system. [Figure 1E] This schematic diagram illustrates exemplary multi-party, multi-person, and multi-part content inspection and approval workflows through various exemplary embodiments of the disclosed system. [Figure 2A] This schematic diagram illustrates a common method for establishing a connection between devices via a secure transport with server certificate verification, illustrating the absence of device authentication. [Figure 2B] This schematic diagram illustrates a common method for establishing a connection between devices via a secure transport with client and server certificate validation, demonstrating the absence of device key protection that does not require a secure element on the device. [Figure 3A] This schematic diagram illustrates, through various exemplary embodiments of the disclosed system, methods for establishing connections between devices via secure transport, including pre-shared key (PSK) based client (and device) authentication and server certificate validation. [Figure 3B] This diagram illustrates a transaction state machine, in various exemplary embodiments of the disclosed system, that uses a Domain Name System (DNS) server to perform device validation, authenticates member devices with the Key Distribution Service (KDS) or KDS proxy using configured KDS member pre-shared keys (M-PSKs) and M-PSK identity hints to perform transactions, and generates session keys using a secure key exchange method. [Figure 3C]This is a diagram of a transaction state machine illustrating a method for authenticating 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, using a mobile service provider (MSP) to perform device authentication and validation, generate a session key using a secure key exchange method, and securely communicate with the KDS or KDS proxy to perform a transaction. [Figure 3D] This is a diagram of an exemplary computer system in which an embodiment of a method for retrieving a pre-shared key to initiate client authentication over TLS using TLS-PSK may be implemented. [Figure 3E] This is a diagram of an exemplary computer system in which an embodiment of a method for retrieving a pre-shared key to accept client authentication over TLS using TLS-PSK may be implemented. [Figure 3F] This is a diagram of an exemplary computer system in which an embodiment of a device-unique pre-shared key method for client authentication (C-PSK) via TLS-PSK between a client application and a server application can be implemented. [Figure 3G] This is a diagram of a transaction state machine illustrating a method for authenticating a mobile member device with the Key Distribution Service (KDS) or KDS proxy using a configured KDS member pre-shared key (M-PSK) and M-PSK identity hint, using a mobile device identifier (e.g., IMEI, ICCID) to perform device authentication and validation using a mobile device identifier (e.g., IMEI, ICCID), generating a session key using a secure key exchange method, and securely communicating with the KDS or KDS proxy to perform a transaction. [Figure 3H]This is a diagram illustrating an exemplary computer system in which embodiments of device two-factor authentication, trusted intermediate and root certificates, leaf certificates, and methods for retrieving associated private keys can be implemented using the KDS interface API, KDS, and a Certificate Authority (CA). [Figure 4] This schematic diagram illustrates common methods for establishing insecure connections between devices via connection-oriented or connectionless transport protocols. [Figure 5A] This schematic diagram illustrates various exemplary embodiments of the disclosed system for establishing secure connections between devices via connection-oriented or connectionless transport protocols using pre-shared keys (PSKs) for mutual device authentication and data protection. [Figure 5B] This is a diagram of an exemplary computer system in which embodiments of methods for retrieving, using, verifying, and updating a pre-shared key to initiate secure communication over an insecure transport protocol may be implemented. [Figure 5C] This is a diagram of an exemplary computer system in which embodiments of methods for retrieving, using, verifying, and updating a pre-shared key to authorize secure communication over an insecure transport protocol may be implemented. [Figure 5D] This is a diagram illustrating an exemplary computer system in which embodiments of other methods for creating, using, and deleting pre-shared keys to authorize secure communication over insecure transport protocols may be implemented. [Figure 5E] This is a diagram of an exemplary computer system in which an embodiment of a method for a device-unique pre-shared key for authenticated secure communication (D-PSK), derived using a group key (S-PSK) and a device-unique registration ID, can be implemented between a client application and a server application. [Figure 6]This schematic diagram illustrates, using various exemplary embodiments of the disclosed system, how to perform device authentication and domain validation using a key distribution service proxy for device Internet Protocol (IP) address-based reverse lookups to retrieve authoritative device DNS hostnames from a configured local DNS server over a local area network. [Figure 7A] This is a schematic diagram illustrating entity relationships between model components in various exemplary embodiments of the disclosed system. [Figure 7B] This schematic diagram illustrates further entity relationships between components of the model in various exemplary embodiments of the disclosed system. [Figure 8A] This is a diagram illustrating an exemplary computer system in which an embodiment of a pre-shared key-based selective encryption / decryption method for subsections of messages sent / received between client / server applications over a local area network may be implemented. [Figure 8B] This is a diagram illustrating an exemplary computer system in which an embodiment of a method for pre-shared key-based selective encryption / decryption of objects embedded in documents exchanged between producer / consumer applications may be implemented. [Figure 8C] This is a diagram of an exemplary computer system in which embodiments of methods for pre-shared key-based content signing by producer applications and pre-shared key-based content verification by consumer applications for tamper resistance may be implemented. [Figure 8D] This is a diagram of an exemplary computer system in which embodiments of methods for additional pre-shared key-based content signing by intermediary applications and multiple pre-shared key-based content verification by consumer applications can be implemented to resist supply chain tampering. [Figure 8E]This is a diagram illustrating an exemplary computer system in which an embodiment of a method for dynamically and securely retrieving an internal wireless access point (WAP) pre-shared key (PSK) via a guest wireless network may be implemented for device authentication by a multi-SSID (Service Set Identifier) ​​mode WAP for switching over to a secure wireless network. [Figure 9A] This is a diagram of an exemplary computer system in which embodiments of a method for predicting device risk scores and classifying security events may be implemented by building a machine learning model using a multidimensional feature matrix with device intelligence as training and test datasets. [Figure 9B] This is a diagram of an exemplary computer system in which embodiments of a method for securely harvesting, processing, and distributing trusted device metadata to webhooks may be implemented. [Figure 10] This is a diagram illustrating an exemplary computer system in which an embodiment of a certificate-less device security and data protection method may be implemented. [Modes for carrying out the invention]

[0113] Further areas of applicability of this disclosure will become apparent from the detailed description provided below. It should be understood that the detailed description of exemplary embodiments is intended for illustrative purposes only and is therefore not necessarily intended to limit the scope of this disclosure.

[0114] While this disclosure is illustrated and described herein with reference to specific embodiments, it is not intended to be limited to the details shown herein. Rather, various modifications can be made in detail within the scope and scope of the equivalent claims and without departing from the scope of this disclosure.

[0115] A system and method for certificate-less device protection and application security is proposed, in which an application running on a first device can connect to an Authorized Key Distribution Service (KDS) to request a symmetric key (generated by KDS or created by a service application) to communicate with an application running on a second device, an application on an authenticated member device can retrieve a symmetric key from the Authorized KDS to communicate with other authenticated member devices in the group, the symmetric key can be set to expire based on a time-to-live (TTL) interval that triggers automatic key regeneration, and the application can use (e.g., UDP) The extracted symmetric key can be used as a pre-shared key for direct message exchange (or via the TCP transport protocol) or via the TLS-PSK secure transport protocol, and communication between the application and the authorized KDS can be via UDP or TCP on resource-constrained devices (e.g., using M-PSK-based authentication and temporary Diffie-Hellman (DH) or elliptic-curve (ECDH) key exchange for session key-based encryption of requests and responses, or NIST-approved quantum-resistant cryptographic algorithms (NISTIR8309 https: / / doi.org / 10.6028 / NIST.IR) for general encryption (e.g., CRYSTALS-Kyber).8309), and authentication and digital signatures (e.g., CRYSTAL-Dilithium, FALCON, and SPHINCS+) may occur via a secure channel (on non-resource-limited devices via TLS with server authentication), the KDS validates devices using DNS reverse lookups (member device IP addresses to DNS hostnames) to resolve DNS hostnames and match them with member identifiers, the KDS may automatically regenerate keys for expired PSKs, or a service application (i.e., key maker) may explicitly regenerate keys for expired PSKs, the KDS performs DNS reverse lookups using a list of configured DNS servers, and a KDS proxy may be installed on-site to resolve and authenticate device DNS hostnames using local DNS reverse lookups. The KDS or KDS proxy may use a Mobile Service Provider (MSP) service for authentication and validated under-managed mobile devices.

[0116] In one exemplary embodiment of the system disclosed, a KDS proxy securely proxies KDS interface application programming interface (API) requests from an authenticated and validated device to an externally hosted (e.g., cloud) KDS, using an API access token and API access secret to digitally sign the mapped Representational State Transfer (REST) ​​API requests to the KDS. The KDS proxy attaches 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), as well as at least the authenticated member identifier and member DNS hostname retrieved from the local DNS server in the proxyed API request to the externally hosted KDS.

[0117] In one exemplary embodiment of the system disclosed, member device authentication may be performed using a Domain Name System (DNS) server, the KDS interface on the member device uses member PSK-based authentication by KDS over UDP, and all API service requests from the member device sent through the KDS interface use (for example, temporary Diffie-Hellmann (DH) or elliptic curve DH (ECDH) key exchange over UDP to generate a session key, or NIST approved quantum-resistant cryptographic algorithms (NISTIR8309) for common cryptography (e.g., CRYSTALS-Kyber). https: / / doi.org / 10.6028 / NIST.IR.8309), and using identity verification and digital signatures (e.g., CRYSTAL-Dilithium, FALCON, and SPHINCS+), encrypted over a secure session, KDS (and KDS proxy, where applicable) performs a DNS reverse lookup against the requester's member device IP address, compares the retrieved DNS hostname with the member identifier received in the digitally signed API request, and retrieves the PTR record for each address (A) record (and optionally, alias and CNAME resource records, where applicable). The KDS (and KDS proxy, where applicable) is configured on the DNS server, and DNS hostnames retrieved through DNS reverse lookups are cached by the KDS (and KDS proxy, where applicable) for a duration specified by the response TTL, and the KDS proxy to KDS requests is secured using an API access token along with an HMAC-MD5-128, HMAC-SHA-160, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, or HMAC-SHA-512 digest of the URL, including, for example, the path, API method, API request time, and API access token, and digitally signed using an API access secret.

[0118] In one exemplary embodiment of the disclosed system, for high availability, a secondary KDS may be configured for data synchronization and service level failover. A KDS interface library initiating a transaction with the KDS switches over to the secondary KDS in the event of a timeout in the primary KDS. An automatic switchback to the primary KDS may be attempted during subsequent transactions.

[0119] In one exemplary embodiment of the disclosure system, a shared device group type includes a list of devices identified by DNS hostnames, a private device group type includes a single device (e.g., for local storage encryption or intra-device communication), and a tenant includes multiple device groups. Other device group types may be defined for specific purposes (e.g., shared, private, onboarding, authenticator, anonymous, community, or any appropriate device group).

[0120] In one exemplary embodiment of the system of disclosure, client and server applications engaging in an Internet Key Exchange (IKE) protocol handshake to establish a security association for data authentication and / or encryption over IPsec can retrieve a pre-shared key (PSK) from a KDS for PSK-based client authentication over IKE.

[0121] In one exemplary embodiment of the system disclosed, a device may be a member of a group of multiple devices, and an application may retrieve a key to access the group of multiple device members (or groups), and the application may use the retrieved symmetric pre-shared key via any transport protocol (e.g., User Datagram Protocol i. UDP, Transmission Control Protocol i. TCP, Internet Protocol i. IP, non-IP), and the application may use the retrieved symmetric key for PSK-based client authentication via a TLS-PSK session or for PSK-based client authentication via an IKE session, and the application may use the retrieved key with any open-source or third-party secure transport or cryptographic library.

[0122] Modifying hundreds of line-of-business (LOB) legacy, brownfield, or greenfield applications (e.g., client, server) running on field devices for application security purposes is a daunting task for developers, product managers, and field operators. Interoperability between LOB applications is essential for seamless transitions in production and mission-critical environments that do not trigger service outages. This requires an agentless solution, where connected applications can selectively integrate with a Key Distribution Service (KDS) using a simple set of APIs for multilingual applications (C, C++, C#, Java, Objective-C, etc.) to perform key operations (e.g., PSK retrieval and renewal). The KDS interface library provides application developers with a simple set of APIs, allowing KDS to transparently manage authentication ceremonies, application identifiers, and secure communication (request-response handshake) on behalf of the application. Once the requested PSK is retrieved, the connected application can use the retrieved PSK, along with any third-party cryptographic library to perform local key operations, and any underlying protocol stack for communication. This level of compatibility and simplicity is essential for quickly and easily enhancing applications for enhanced security by minimizing the coding effort required by application developers.

[0123] In one exemplary embodiment of the system disclosed, the KDS interface application programming interface (API) may include at least the following set of operations: 1) OpenContextKDS (KDS device configuration, key restrictions) - Allocate and initialize a context for connecting directly to (or indirectly through a KDS proxy) a primary or secondary KDS server using specified KDS device configuration settings (e.g., a JSON file that may optionally contain a digitally signed signer's certificate or public key for signature verification for security reasons) including primary and secondary KDS server addresses, protocol (e.g., UDP, TCP, TLS), port number (e.g., 500, 443), key exchange method (e.g., DH, ECDH, CRYSTALS-Kyber), KDS member PSK (M-PSK), M-PSK identity hint, tenant identifier, and member identifier for M-PSK-based device authentication by KDS. Uniform resource locators (URLs) for KDS and KDS proxy specify their respective service endpoint addresses. The tenant identifier identifies the tenant in a multi-tenant "Software as a Service (SaaS)" KDS subscription model. The member identifier identifies the tenant member device to KDS. These common KDS configuration settings can be loaded from a KDS configuration file provided to the application running on the member device. A device may be a member of multiple device groups, and a device group may be assigned multiple key records (i.e., identity hints); therefore, group identifiers and identity hints must be explicitly provided during KDS query operation. The group identifier associated with a member device, and the identity hint associated with the group identifier, may be included in an application-specific configuration file loaded by the application for runtime cross-validation. The key limit specifies the maximum number of active retrieved keys for storage in the internal key cache of the KDS context. During KDS context creation on the device, static public and private authentication keys may be generated based on a configured key exchange method, and each party knows the other party's static public authentication key. • Returns a handle to the KDS context (KDS handle). The context caches the retrieved key record. 2) CreateKey(KDS handle, group identifier, identity hint, key template) As a key creator, create (and own) a PSK with a member identifier. A key template can specify at least the key algorithm, key size, key usage, and key expiration. The key size may be specified as, for example, 56, 80, 112, 128, 192, 256, or larger bits. The key algorithm may be specified as, for example, AES, DES, 3DES, Blowfish, CAST, RC4, RC5, RC6, or ChaCha20. The cryptographic type for the specified key algorithm may be further specified as, for example, GCM, CCM, ECB, CBC, CTR, OFNB, CFNB, EAX, XTS, or CBC-MAC. The key usage may be specified as, for example, client authentication, data authentication, data encryption, content (producer or intermediary) signing, broadcast signing, broadcast encryption, multicast signing, multicast encryption, token signing, or token encryption. The specified key template may include extended attributes provided by the application, such as an activity description, network type (e.g., wired, wireless), network protocol (e.g., IP, CAN bus, Modbus, HART, WirelessHART), and transport protocol for KDS-based key relationship activity inspection logs (e.g., UDP, TCP, TLS, DTLS, IPsec). • Returns the Local Key Identifier (LKID) and key record (the key expiration period may be specified as a timestamp, with 0 suggesting that explicit release by the key creator is required). The key may also be pre-generated using the KDS Administration Portal. The key creator is set as appropriate in the Member Identifier or KDS Administrator in the key record. The LKID is a local fast lookup index stored within the KDS context, and the retrieved key record may be cached in 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 about the key creation error as a security countermeasure against brute-force attacks that attempt to guess the group identifier and identity hint to extract the key. 3) RetrieveKey (KDS handle, group identifier, identity hint) • Retrieve key records based on group identifiers and identity hints. • Returns the LKID and key record. The key record may be returned as a read-only reference to the application. If the specified group identifier or identity hint cannot be met, the KDS may be configured to generate a security event notification as a security countermeasure against brute-force attacks that attempt to guess the group identifier and identity hint to extract the key. 4) RetrieveCommunityKey(KDS handle, community identifier, cotenant identifier, group identifier, identity hint) • Retrieve key records based on group identifiers and identity hints associated with different tenants (co-tenant identifiers) within a tenant's community (community identifier). • Returns the LKID and key record. The key record may be returned as a read-only reference to the application. If the specified group identifier or identity hint cannot be met, the KDS may be configured to generate a security event notification as a security countermeasure against brute-force attacks that attempt to guess the group identifier and identity hint to extract the key. 5) RetrieveKeys(KDS handle, group identifier) Retrieve all key records for the group identifier. • Returns a list of key records (for pre-populating PSKs and identity hints for TLS-PSK-based client authentication, or for caching M-PSKs as the first factor of authentication by a KDS proxy). If the specified group identifier cannot be met, the KDS may be configured to generate a security event notification as a security countermeasure against brute-force attacks that attempt to guess the group identifier and retrieve the key record. 6) VerifyKey (KDS handle, group identifier, identity hint) • Locally verify the key expiration status based on the expiration timestamp in the cached key record stored within the KDS context. If the key is not expired, retrieve the key status from the KDS. • Returns the KDS key status (e.g., active, suspended, expired, deleted, discarded, or invalid). Key statuses other than active or suspended may be considered by the application as deactivated status for previously retrieved keys. If the specified group identifier or identity hint cannot be met, the KDS may be configured to generate a security event notification as a security countermeasure against brute-force attacks that attempt to guess the group identifier and identity hint to extract the key. Alternatively, the application can set up a timer based on the calculated key expiration time and explicitly update the key in the registered callback handler using the key identity hint as context for cross-referencing the associated expired key. 7) RenewKey (KDS handle, group identifier, identity hint) • Update (i.e., recreate) the key record created (owned) by the member identifier for use as a PSK for client authentication or secure communication (due to key expiration or on-demand renewal). For keys not created (owned) by the member identifier, the updated key record (due to expiration) is retrieved. If the specified group identifier or identity hint cannot be met, the KDS may be configured to generate a security event notification as a security countermeasure against brute-force attacks that attempt to guess the group identifier and identity hint to extract the key. 8) DeleteKey(KDS handle, group identifier, identity hint, delete type) • The type of deletion can be specified as local or service. • In local mode, or service mode where the member identifier is not the creator (owner), the key record is cleared (freed) from the local cache of the KDSI context. • In service mode where the member identifier is the creator (owner), the key record is deleted in KDS. Key records can be programmatically deleted by the creator (owner) member identifier, or by an authorized KDS portal administrator of a key created (owned) by the KDS service. Deletion actions in KDS can be configured and performed as erasure (permanent deletion) of the key record, or as adjustment of the key status to maintain key history. If the specified group identifier or identity hint cannot be met, the KDS may be configured to generate a security event notification as a security countermeasure against brute-force attacks that attempt to guess the group identifier and identity hint to extract the key. 9) CloseContextKDS(KDS handle) • Release and free the KDS context.

[0124] In one exemplary embodiment of the system disclosed, the KDS interface application programming interface (API) may be extended to automate local device configuration, export vendor-specific member device information to KDS, integrate with ecosystem services (e.g., DHCP services, cloud-based device provisioning, and hub services), and verify content signatures, and may include at least the following set of operations: 1) DeriveDeviceKey (KDS handle, group identifier, identity hint) for generating a device-unique key for integration with cloud services (e.g., microservices for device registration, device provisioning, hub-mounted business applications for telemetry, data analytics, digital twins). 2) RetrieveDhcpOption(KDS handle, vendor class identifier, custom option code, attribute identifier, attribute buffer, buffer length) to retrieve a specified DHCP option as a string in the attribute buffer. Vendor-specific information about member devices 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. DHCP standard option code 43 for encapsulated vendor-specific information, including a custom option code available for private use, may be configured for a defined vendor class identifier, scope, and address pool by policy on the DHCP service. 3) ReadDhcpOption(KDS handle, attribute identifier, attribute buffer, buffer length) to return the requested attribute value as a string in the attribute buffer. 4) ExportDeviceAttribute (KDS handle, attribute identifier, attribute buffer, buffer length) for sending vendor-specific device information as a device attribute to KDS. 5) ExportDeviceMetadata (KDS handle, metadata identifier, metadata buffer, buffer length) for sending device and application metadata to KDS. 6) GenerateSignatureManifest(KDS handle, content file, signature manifest file) to generate (or optionally extend) a signature manifest file for content signing and supply chain tamper resistance. 7) VerifySignatureManifest (KDS handle, content file, signature manifest file) to verify content signing and supply chain tamper resistance using a signature manifest file. 8) QueryUpdate(KDS handle, group identifier) ​​to check for updates. KDS verifies whether updates for a member ID are pending based on the latest content retrieval date and pending published content associated with the device type and group. 9) RetrieveUpdate(KDS handle, group identifier) ​​to retrieve the download URL and URI of the published content identifier (i.e., content file and extended signature manifest file). 10) NotifyUpdateStatus(KDS handle, group identifier, content identifier, status code) to notify KDS of the status of the device update based on the retrieved download URL / URI for state synchronization (0: completed, non-zero integer: error code).

[0125] In one exemplary embodiment of the disclosed system, the KDS interface application programming interface (API) includes helper utilities (or convenience APIs) for applications running on member devices to optionally perform local key operations using the KDS context. A local key identifier (LKID) is a local fast lookup index stored within the KDS context, and retrieved key records may be cached in process space (execution context). 1)AuthenticateMessage(KDS handle, message buffer, message length, hash function, hash buffer, hash length, LKID) Using a cryptographic hash function (e.g., HMAC-MD5-128, HMAC-SHA-160, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512, HMAC-POLY1305, BLAKE-224, BLAKE-256, BLAKE-384, BLAKE-512, BLAKE2B-256, BLAKE2S-256, or BLAKE3-256) and a secret pre-shared key (S-PSK) associated with a specified local key identifier (LKID), a keyed hash message authentication code (HMAC) is generated for a specified message. • Returns an HMAC for message authentication. The HMAC hash must be sent with the message (whether the message is encrypted or not) for the server application to verify its integrity and authenticate the message from the client application. This helper API can be used by applications during signing (as a producer) and verification (as a consumer). 2) EncryptMessage(KDS handle, plaintext buffer, plaintext length, ciphertext buffer, ciphertext length, LKID) • Encrypts the specified plaintext message using the secret pre-shared key (S-PSK) associated with the specified local key identifier (LKID). • Returns the encrypted message in the specified ciphertext buffer. 3) DecryptMessage(KDS handle, ciphertext buffer, ciphertext length, plaintext buffer, plaintext length, LKID) • Decrypt the specified ciphertext message using the secret pre-shared key (S-PSK) associated with the specified local key identifier (LKID). • Returns the decrypted message in the plaintext buffer.

[0126] In one exemplary embodiment of the system of disclosure, the KDS interface application programming interface (API) may include an application identifier in all requests to the KDS or KDS proxy, including, for example, a file path (e.g., file directory), file name, and file hash. The KDS may store the application identifier (e.g., member identifier, tenant identifier, group identifier, identity hint, request type, transaction status, request timestamp) in the activity record of device transactions for device risk monitoring. The KDS interface may determine the application identifier based on the process identifier (PID) and operating system-specific lookups to retrieve the associated application module load path and application name. The application identifier provides threat intelligence for tracking unauthorized (or malicious) applications on a device attempting to access the KDS. The KDS may consist of security policies to examine the application identifier received as part of a KDS interface request against threat intelligence from external sources, i.e., application image / binary reputation / denial lists, to reject key requests, and to block unauthorized or malware applications from retrieving pre-shared keys. By not storing the extracted pre-shared key in local storage on the device, the pre-shared key in operation can be protected by authorized applications from misuse / exploitation by unauthorized or malware applications residing alongside it. In contrast, configuring, managing, and monitoring application access to persistent PKI-issued certificates and password-protected private keys (for asymmetric key pairs) on headless devices requires local user, group, and service level access control lists (ACLs) that are difficult to administer.

[0127] In the disclosure system and methods, pre-shared keys (PSKs) are described and annotated based on their purpose and function. A PSK pre-configured for a member device to authenticate with the KDS using an associated PSK identity hint for a tenant identifier during the device authentication handshake before initiating key-relationship operations is called a KDS member PSK (M-PSK). A pre-configured M-PSK for a member device is associated with a pre-configured M-PSK identity hint for use during the device authentication handshake. The KDS may be pre-configured with multiple M-PSKs and associated M-PSK identity hints per configured tenant in a multi-tenancy and may be 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 device. The M-PSK identity hint and associated M-PSK may be unique per member device to establish the first factor of authentication for enhanced security, or they may be shared among member devices within a tenancy or device group. A DNS reverse lookup using the member device IP address for the member device hostname via a configured authoritative DNS server for member device domain validation establishes a second factor of authentication. Thus, multi-factor authentication for member devices is performed by the KDS (or KDS proxy).

[0128] Member devices can be pre-configured at the factory (by initializing program variables in the application image on the RTOS platform) or in the field (by loading configuration files into the GPOS platform) during onboarding with default and shared M-PSK identity hints and M-PSKs for initial (day zero) pre-authentication by KDS. Nevertheless, after device authentication and domain validation, member devices can generate a device unique secret M-PSK identity hint and create an associated M-PSK (using the KDS interface API) with the reserved group identifier for "pre-authentication" (and the associated group type for "onboarding") for subsequent pre-authentication by KDS.

[0129] A PSK distributed to a client or server application, running on a member client or server device respectively, for the client application to authenticate with a server application, is called a client authentication PSK (C-PSK). A PSK distributed to a client application running on a member client device for secure communication with a server application running on a member server device via a connection-oriented or connectionless transport protocol is called a secure communication PSK (S-PSK). C-PSKs and S-PSKs may be generated in the KDS for post-configuration of member devices, or optionally pre-configured and distributed to authenticated and domain-validated member devices based on group membership and tenancy associations. Although the PSKs on client and server devices are depicted in the diagram with different labels, the symmetric key is shared and is therefore identical within a particular workflow, as illustrated in Figures 3A and 5A. In one exemplary embodiment of the system and method of disclosure, an application running on a member device acquires and uses multiple PSKs (C-PSK, S-PSK) based on different group identifiers and identity hints. In yet another exemplary embodiment of the system and method of disclosure, a server application running on a member device can acquire and use multiple PSKs (C-PSKs) based on different identity hints of a group identifier, since a group identifier may be associated with multiple key records, as illustrated in Figure 7A.

[0130] Thus, M-PSK, device member domain validation by an authoritative DNS server, securely distributed C-PSK or S-PSK, and negotiated session keys for TLS / DTLS-based connections work together to establish three-factor authentication for member devices, quadrupling security for a more reliable assurance of member devices.

[0131] The purpose of the device authentication handshake between the member device and the KDS using a pre-configured M-PSK and associated PSK identity hint is to pre-authenticate the member device before the configured DNS server initiates any DNS reverse lookup requests. This provides a safeguard mechanism against rogue devices attempting to connect to the KDS using a stolen M-PSK or against dictionary attacks to guess the M-PSK. Despite the safeguard, a sophisticated attacker could still perform the device authentication handshake using a compromised M-PSK and associated PSK identity hint from a cloned rogue device. Nevertheless, subsequent member device DNS hostname validation through an authorized DNS server, based on pre-existing mandatory security countermeasures that protect the LAN from IP address spoofing (by access, distribution in the path, and the network fabric of core switches and routers), should detect the rogue device as an unauthorized device and generate warnings to block subsequent access from the rogue device through intermediate network firewalls or intrusion detection system security countermeasures (rules). The M-PSK and its associated PSK identity hint can optionally be protected using node-locked configuration files and PUFs as security countermeasures. The ability to configure multiple M-PSKs and associated PSK identity hints in KDS provides timely remediation through M-PSK updates if an M-PSK is compromised.

[0132] In the disclosed system and method, member devices may be assigned IP addresses (IPv4 or IPv6) using statically configured IP addresses or IP addresses dynamically assigned by a Dynamic Host Configuration Protocol (DHCP) server configured for the LAN. The DNS server must be configured manually or automatically (e.g., with dynamic DNS) with assigned member device IP address (A) record entries. For member devices configured for dynamic IP address assignment, the allocated (leased) IP address may be reserved by the DHCP server for the member device having an associated Media Access Control (MAC) address, thereby ensuring an immutable IP address for the member device in the network domain described for the device.

[0133] In the disclosure system and methods, all DNS operations are performed over secure DNS (DNS over TLS or DNS over HTTPS) to prevent DNS data tampering by man-in-the-middle (MITM) attacks. To protect against DNS data tampering or DNS cache poisoning attacks, DNS answer resource records (i.e., responses) to KDS requests from configured DNS servers may be digitally signed in accordance with the Domain Name System Security Extension (DNSSEC) specification. Thus, device validation may be performed by KDS using authenticated DNS records.

[0134] Referring to Figure 1, an application or service 165 running on the first device 160 can establish authenticated and secure communication with an application or service on the second device 180 over a local or wide area network (LAN / WAN) 125. The first device 160 and the second device 180 use their respective (and identical) client KDS interface 303 or server KDS interface 310, their respective (and identical) pre-shared symmetric key data 163, standard security protocols (e.g., TLS, DTLS), standard transport protocols (e.g., TCP, UDP), standard networking protocols (e.g., IPv4, IPv6), and non-IP protocols (e.g., CAN bus, HART, WirelessHART, RS232 serial) 161. The first and second devices connect to their respective DHCP service 172 for device configuration and attributes, including vendor-specific information configured with extensible custom options, their respective DNS service 173a for device domain authentication, and their respective Key Distribution Service (KDS) proxy 602 for key operation over local or wide area network (LAN / WAN) 125. Each device may reside in a different LAN / WAN 125 domain and use different DHCP service 172 and DNS service 321. In alternative embodiments of the system and method of disclosure, a mobile device may be authenticated by a Mobile Service Provider (MSP) 322 service over wide area network (WAN) 125. The Key Distribution Service proxy (multiple proxies) 602 connects over LAN / WAN 125 to a Key Distribution Service (KDS) 305 hosted on-premises or in the cloud. The KDS 305 may connect over WAN 125 to a cloud service 197, including, for example, a device registration service or a hub service.

[0135] Referring to Figure 1, in step 166, the application or service 165 can first retrieve (autodiscover) device information (e.g., configuration and attributes) using the client KDS interface 303 or server KDS interface 310 API. The application or service 165 can also load device-specific primary / secondary KDS server addresses and tenant identifiers from the device configuration file. The application or service 165 can also load application-specific group identifiers and pre-shared identity hints from the application-specific configuration file. In step 168, the client KDS interface 303 or server KDS interface 310 queries the DHCP service 172 for the requested device information. Subsequently, in step 166, the application or service 165 can use the client KDS interface 303 or server KDS interface 310 API to send a key request to the KDS proxy 602 (e.g., for key operations such as create, retrieve, verify, update, delete), the key request including at least the tenant identifier and group identifier, and, in the case of a single key, a pre-shared key identity hint. In step 169, the client KDS interface 303 or server KDS interface 310 initiates device authentication and session key exchange, sending a key request to the KDS proxy 602 via a secure channel. In step 194a, the KDS proxy 602 authenticates the device DNS hostname using the DNS service 173a and performs a reverse lookup of the device DNS hostname by the device IP address. For mobile devices, the KDS proxy 602 authenticates the mobile device using the MSP322 service and matches the nonce signed by the MSP based on the SIM on the device and the device IMSI. After device authentication, in step 194, the KDS proxy 602 sends a key request to the KDS 305. The retrieved pre-shared symmetric key data 163 is provided to the application or service 165.In step 164, the application or service 165 uses the retrieved pre-shared symmetric key data 163 to perform an encryption operation based on the designated key type and usage constraints. In step 162, client authentication, data authentication, or data encryption is performed as appropriate to establish authenticated and secure communication with the second device 180 in step 174, on the second device 180, the same sequence of steps is performed to retrieve the pre-shared symmetric key data 163 in step 164 and perform the encryption operation. In step 166, the application or service 165 may request multiple keys from the KDS proxy 602. In steps 192 and 194, the KDS proxy 602 uses security, transport, and network protocols 191 on the key distribution server 190 for communication with the KDS 305, the first device 160, and the second device 180 over the LAN / WAN 125. Reference numbers 171a to 171f in Figure 1A depict communications routed through the LAN / WAN125 network fabric between devices 160 / 180 and services 172 / 305 / 321 / 323 / 602.

[0136] Referring to Figure 2A, a client application 101 running on device 100 establishes a connection 129 with a server application 151 running on device 150 via a local or wide area network (LAN / WAN) 125. In step 105, the client application 101 establishes a secure session 127 with the server application 151 using a security protocol stack 102, such as Connection-Oriented Transport Layer Security (TLS) or Connectionless Datagram TLS (DTLS). In step 106, the security protocol stack 102 uses a transport protocol stack 103, such as Connection-Oriented Transmission Control Protocol (TCP) or Connectionless User Datagram Protocol (UDP). In step 107, the transport protocol stack 103 establishes a network connection 126 via the local or wide area network (LAN / WAN) 125 using a network protocol stack 104, such as Internet Protocol (IP) version 4 (IPv4) or version 6 (IPv6). In step 155, the server application 151 establishes a secure session 127 with the client application 101 using a security protocol stack 152, such as Connection-Oriented Transport Layer Security (TLS) or Connectionless Datagram TLS (DTLS). In step 156, the security protocol stack 152 uses a transport protocol stack 153, such as Connection-Oriented Transmission Control Protocol (TCP) or Connectionless User Datagram Protocol (UDP). In step 157, the transport protocol stack 153 establishes a network connection 126 over a local or wide area network (LAN / WAN) 125 using a network protocol stack 154, such as Internet Protocol (IP) version 4 (IPv4) or version 6 (IPv6).

[0137] Referring to Figure 2A, in a secure session 127, the client application 101 running on device 100 uses the server certificate 128 to perform certificate chain verification and authenticate the server application 151 running on device 150. Certificate chain verification involves verifying all certificates in the chain from the leaf certificate through one or more intermediate (issuer) certificates to the root Certificate Authority (CA) certificate. However, there is no device authentication performed by the server application 151 to identify device 100 as a legitimate connected device. This illustrates the security risks of allowing headless OT / IIoT / IoT devices to connect to legitimate services without device authentication. Implementing TLS or DTLS compliant protocol stacks with PKI certificate-based device authentication on resource-constrained devices is a challenge for original equipment manufacturers (OEMs).

[0138] Referring to Figure 2B, in step 203, the client application 101 running on device 100 establishes a secure connection with the server application 151 running on device 150 via a local or wide area network (LAN / WAN) 125. In step 202, establishing a secure session involves sending a client certificate 201 to the server application 151 for authentication of the client application 101 running on device 100 by the server application 151 running on device 150. However, there is no device key protection without secure elements on device 100. Therefore, the private key corresponding to the public key contained in the client certificate is not protected from malware exploitation and device cloning. This illustrates the security vulnerability of headless OT / IIoT / IoT devices with PKI-based solutions in the absence of private key protection. Adding support for hardware or firmware-based secure elements (e.g., TPM, PUF, integrated or embedded SIM) by the original equipment manufacturer increases the device price per unit.

[0139] Referring to Figures 3A and 7A, in one exemplary embodiment of the system and method of disclosure, in step 316, administrator 318 uses the KDS portal 317 to configure entities and relationships in KDS 305. The configuration includes, at a minimum, the creation of a tenant by tenant identifier 735, a group identifier 705, a group type 707, and a group by multiple key records 709, as well as a member device 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 the system-level configuration of the settings for the DNS connector. In another exemplary embodiment of the system and method of disclosure, in step 316, administrator 318 can use the KDS portal 317 to create key records, create key instances, and update expired key instances. This simplifies the retrieval and use of pre-shared keys using the group identifier 705 and identity hint 711 by applications running on member devices. In yet another exemplary embodiment of the disclosure system and method, 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 local SIMs (e.g., mobile devices, smartphones) configured by the MSPs.

[0140] Referring to Figures 3A and 7A, in one exemplary embodiment of the disclosure system and method, in step 302, a client application 101 running on device 100 authenticates member device 100 with KDS 305 via local or wide area network (LAN / WAN) 125 using a Key Distribution Service (KDS) interface 303. In step 304, the KDS interface communicates with KDS 305 using an API to retrieve, create and retrieve, verify, update, or delete a symmetric key instance 714, depicted as a PSK 312, based on at least a tenant identifier 735, a member identifier 703, a group identifier 705, and an identity hint 711. In yet another exemplary embodiment of the disclosure method, the entire key record 709 is retrieved. The KDS305 uses the configured local domain name server (DNS) 321, which is routed through the LAN / WAN125 network fabric in steps 300 and 320, to perform a reverse lookup of the requester 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 member identifier 703 received in the API request in step 304 to authenticate member device 100. In step 306, the client application 101 uses the retrieved PSK 313 and associated identity hint 711 to initiate TLS-PSK based client authentication in step 307.

[0141] Referring to Figures 3B, 3A, 6, and 7, in one exemplary embodiment of the system and method of disclosure, step 304 includes a device authentication handshake with the KDS 305 (or KDS proxy 602) and the configured DNS server 321 using a configured KDS member PSK (M-PSK) and an M-PSK identity hint. In step 350, the client KDS interface 303 sends a device hello to the KDS 305, the message including at least a configured tenant identifier 735 encrypted with the configured M-PSK and the configured M-PSK identity hint 711. In step 351, the KDS 305 creates (establishes) a session context, and in step 352, sends a server challenge to the client KDS interface 303 including at least a unique and random nonce value and hash function specification, the service challenge being encrypted with the M-PSK associated with the received M-PSK identity hint 711. In step 353, the client KDS interface 303 generates a device response containing a hash output corresponding to the service challenge 352 and sends it to the KDS 305, the device response being encrypted with M-PSK. In step 354, the KDS 305 verifies the received hash output, and if it matches the expected hash output, it authenticates the device and, in step 355, sends a server hello to the client KDS interface 303 to initiate key exchange. The server hello message contains a list of supported key exchange protocols encrypted with M-PSK.In step 356, the KDS interface initiates a secure key exchange protocol handshake using one of the supported key exchange protocols, such as the Transient Diffie-Hellmann (DH) or Elliptic Curve DH (ECDH) key exchange method, or using a NIST-approved quantum-resistant cryptographic algorithm for general encryption (e.g., CRYSTALS-Kyber) over an insecure channel (e.g., UDP or TCP) (NISTIR8309 https: / / doi.org / 10.6028 / NIST.IR.8309), and generates session keys in client KDS interfaces 303 and KDS305. The session keys are never transmitted over an insecure channel. In step 357, client KDS interface 303 sends a KDS request encrypted with the session key. In step 358, in KDS305, the device is validated using the device IP address and a DNS reverse lookup to match the device member DNS hostname 722. Upon validation, in step 359, KDS 305 sends a KDS response encrypted with the session key to the client KDS interface 303. In step 360, steps 357, 358, and 359 may be repeated to initiate subsequent key operations. In step 361, the client KDS interface 303 sends a device finish to KDS 305, and in step 362, the context is freed. The subsequent session may be established by repeating the sequence that began in step 350.

[0142] Referring to Figures 3B and 6, in one exemplary embodiment of the system and method of disclosure, the described message sequence for the device authentication handshake using a configured device member PSK (M-PSK) is identical between the client KDS interface 303 and the KDS proxy 602.

[0143] Referring to Figures 3B and 6, in one exemplary embodiment of the system and method of disclosure, the described message sequence for the device authentication handshake using a configured device member PSK (M-PSK) and M-PSK identity hint may be performed on a resource-constrained device using a connectionless (e.g., UDP) or connection-oriented (e.g., TCP) transport protocol, and the use of a secure transport protocol (e.g., DTLS, TLS, IPsec) is not feasible.

[0144] Referring to Figures 3A and 7A, in one exemplary embodiment of the system and method of disclosure, in step 309, a server application 151 running on device 150 authenticates member device 150 with KDS 305 via local or wide area network (LAN / WAN) 125 using a Key Distribution Service (KDS) interface 310. In step 311, the KDS interface communicates with KDS 305 using an API to retrieve, create and retrieve, verify, update, or delete a symmetric key instance 714, depicted as a PSK 312, based on at least a tenant identifier 735, a member identifier 703, a group identifier 705, and an identity hint 711. In a further, yet more exemplary embodiment of the method of disclosure, the entire key record 709 is retrieved. KDS 305 uses a configured local domain name server (DNS) 321 to reverse look up the requester member device IP address (of device 150) and retrieve a registered member DNS hostname 722. The retrieved member DNS hostname 722 is then matched with the member identifier 703 received in the API request in step 311 to authenticate member device 150. In step 313, the server application 151 uses the retrieved PSK 312 to verify TLS-PSK based client authentication in step 308.

[0145] Referring to Figure 3A, in one exemplary embodiment of the system and method of disclosure, in step 308, PSK-based client authentication and server certificate-based server authentication are achieved to establish a secure session between client application 101 and server application 151.

[0146] Referring to Figures 3A and 7A, in one exemplary embodiment of the system and method of disclosure, in step 315, shared symmetric keys are depicted as 305 and 312, and a server application 151 running on device 150 authenticates a client application 101 running on device 100. The server application 151 may authenticate client applications 101 on different devices 100 using different identity hints 711 and key instances 715, and therefore different symmetric PSKs 506.

[0147] Referring to Figure 3A, in one exemplary embodiment of the system and method of disclosure, in step 309, the server application 151 may use the server KDS interface 310 to retrieve a list of key records 709 by group identifier 705 in step 311 and cache key instances 715 by identity hint 711 for quick lookup during the TLS-PSK based handshake for session establishment.

[0148] Referring to Figures 3C, 3A, 3B, and 7A, in yet another exemplary embodiment of the system and method of disclosure, step 304 includes a device authentication handshake for a mobile member device using a configured KDS member PSK (M-PSK) and M-PSK identity hint by the KDS 305 (or KDS proxy 602) and the configured MSP 322 server. In step 363, the client KDS interface 303 sends a device hello to the KDS 305, the message including at least a configured tenant identifier 735, a device ICCID as a member identifier 703, a device IMEI as a member (uniquely unique identifier) ​​UUID 731, and a device IMSI, all encrypted with the configured M-PSK and configured M-PSK identity hint 711. In step 364, KDS305 creates (establishes) a session context, and in step 365, sends a server challenge containing a random nonce value to the client KDS interface 303, the service challenge is encrypted with the M-PSK associated with the received M-PSK identity hint 711. In step 366, the client KDS interface 303 generates a device response containing a nonce signed with the authentication key of the SIM (stored in the SIM card circuitry or as an applet on the SIM) corresponding to the service challenge 352 and sends it to KDS305, the device response is encrypted with the M-PSK. In step 367, KDS305 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 MSP322, and finally compares and matches the signed nonces received from client KDS interface 303 and MSP322 to authenticate and validate the mobile member device. In step 368, the mobile member device validation performed in step 367 is verified.

[0149] Referring to Figures 3B and 3C, in one exemplary embodiment of the system and method of disclosure, based on a configured and negotiated key exchange method, in steps 350 and 363, the device halo may include a static public authentication key generated by the client KDS interface 303 for the application on the member device, encrypted with M-PSK. Thus, in step 355, the server halo may include a static public authentication key generated in the KDS 305 or KDS proxy 602, encrypted with M-PSK.

[0150] Referring to Figures 3D and 3A, in step 375, the client application 101 loads a separate device and application-specific configuration file containing the configuration settings required to access KDS 305 or KDS proxy 602. In step 376, the client application 101 uses the OpenContextKDS API to initialize the client KDS interface 303 for transactions with KDS 305 or KDS proxy 602 using the KDS URL, connection type, M-PSK, M-PSK identity hint, tenant identifier, and member identifier loaded from the device-specific configuration file. In step 369, the client application 101 uses the group identifier and C-PSK identity key loaded from the application-specific configuration file. In step 377, 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. In step 370, the client application 101 uses the retrieved C-PSK for PSK-based client authentication by the server application over TLS (i.e., TLS-PSK). In step 371, the client application 101 securely sends / receives data to / from the server application via a TLS session using the negotiated session key. In step 383, the client application 101 frees the KDS context using the CloseContextKDS API, thereby removing the local C-PSK (i.e., the C-PSK does not persist locally and is reacquired from KDS305 or KDS proxy 602 via a client application restart).

[0151] Referring to Figures 3E and 3A, in step 375, the server application 151 loads separate device and application-specific configuration files containing the configuration settings required to access KDS 305 or KDS proxy 602. In step 376, the server application 151 uses the OpenContextKDS API to initialize the client KDS interface 303 for transactions with KDS 305 or KDS proxy 602, using the KDS URL, connection type, M-PSK, M-PSK identity hint, tenant identifier, and member identifier loaded from the device-specific configuration file. In step 372, the server application 151 uses the group identifier loaded from the application-specific configuration file. In step 378, the server application 151 uses the RetrieveKeys API to retrieve the pre-shared key (C-PSK) associated with the group identifier (i.e., pre-load the C-PSK required to accept the connection from client application 101). In step 373, the server application 151 uses the C-PSK identity hint received from the client application 101 to reference the associated preloaded C-PSK for PSK-based authentication of the client application 101 over TLS (i.e., TLS-PSK). In step 374, the server application 151 securely receives / sends data from / to the client application over the TLS session using the negotiated session key. In step 383, the server application 151 frees the KDS context using the CloseContextKDS API, thereby removing the locally preloaded C-PSK (i.e., the C-PSK no longer persists locally and is reacquired from KDS305 or KDS proxy 602 via a server application restart).

[0152] Referring to Figures 3E and 3D, client and server applications can use the VerifyKey API to verify the status of the C-PSK on the client KDS interface 303. The client KDS interface 303 checks the C-PSK expiration timestamp, and if the key is not expired, it verifies the activation status of the C-PSK on KDS 305 or KDS proxy 602. In the case of an inactivated C-PSK, client and server applications can use the RenewKey API to retrieve an updated C-PSK.

[0153] The disclosure system and methods allow applications running on the device to use TLS-PSK, or UDP / TCP over IP, TLS without client authentication, or non-IP communication protocols. In the case of a TLS connection with a server, the server's trusted certificates (root, intermediate, leaf) are installed on the device and can be updated using standard device update methods.

[0154] In the disclosed system and method, applications running on a device may be dynamically configured with a device-unique pre-shared key for client authentication via TLS-PSK (C-PSK). During onboarding, the main application (on an RTOS platform) or a client application (on a GPOS platform) can generate a device-unique C-PSK identity hint and programmatically create the device-unique C-PSK using the KDSI API. The device-unique C-PSK identity hint may be generated using a device-unique registration ID (e.g., MAC address, serial number). The device-unique C-PSK may be dynamically created in the KDS using the KDSI API. A server application on a TLS server can dynamically retrieve the client's device-unique C-PSK using the KDSI API during the connection setup phase. TLS client and server applications can perform callbacks to validate the received PSK identity hint and fetch the pre-shared key during connection setup.

[0155] Referring to Figure 3F, in step 384, the client application 101 running on the 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, the HMAC-SHA256 algorithm. In step 385, the client application 101 uses the client KDS interface 303 to create a device-unique C-PSK using the generated C-PSK identity hint. In step 386, the client KDS interface 303 communicates with KDS 305 to create the device-unique C-PSK in step 387. In step 388, the device-unique C-PSK is retrieved by the client application 101. In step 389, 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. In step 390, 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, and communicates with the KDS 305 in step 391. In step 392, the associated C-PSK is retrieved by the server application 151 to perform client authentication.

[0156] Referring to Figure 3H, in one exemplary embodiment of the system of disclosure, the client KDS interface (303) and server KDS interface (310) application programming interfaces (APIs) may include at least the following set of operations: 1) RetrieveTrustedCertificates (KDS handle) • Retrieve trusted certificates in PKCS#8 PEM format for devices based on tenant identifiers (e.g., intermediate and root certificates chained with a new line character as a separator). 2) RetrieveCertificateWithKey(KDS handle, subject name) • Retrieve the leaf certificate in PKCS#8 PEM format for the specified subject name. • Retrieve the associated private key in PKCS#8 PEM format encrypted with the registered member M-PSK. 3) VerifyCertificate (KDS handle, certificate serial number) • Verify the certificate status (active, expired, revoked) of the specified certificate serial number.

[0157] Referring to Figure 3H, in another exemplary embodiment, a method for an agentless solution on a registered member device authenticated with two-factor device authentication is performed to retrieve trusted intermediate and root certificates, as well as leaf certificates and associated private keys, and to verify the status of the retrieved certificates at the Key Distribution Service (KDS) 305 using the client KDS interface 303API in any modern programming language. The public or private PKI-based trusted certificates, as well as leaf certificates and private keys, may be issued by a Certificate Authority (CA) 398 hosted in the cloud or on-premises. KDS 305 interfaces with CA 398 to import, renew, or re-key certificates (in single or batch mode) via an authenticated REST API connector and queries the status of certificates upon request from client applications running on the authenticated member device. KDS 305 enforces policy-based authorization to restrict the retrieval of leaf certificates and associated private keys by trusted applications configured on KDS 305. A client application 101 running on an authenticated device (e.g., a TLS client, IKE client, SSH client, or command-line utility) can use Online Certificate Status Protocol (OCSP) based certificate status verification or the client KDS interface 303 API to verify certificate status. KDS proxies 602 and KDS 305 perform device two-factor authentication in response to API requests for retrieving leaf certificates and associated private keys.

[0158] Referring to Figures 3H, 2A, 3A, and 7A, another exemplary embodiment involves methods for importing, creating, updating, recreating, retrieving, or acquiring leaf certificates for the public and associated private keys of an asymmetric key pair used in client authentication between applications running on distributed devices, in data signing with digital signatures, and in key unwrapping, including a client application running on a first device, a server application running on a second device, trusted intermediate 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, an 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 321.

[0159] The approach also includes the following additional methods:

[0160] Import the leaf certificate and associated private key into the KDS portal 317 by the KDS administrator 318 in single or batch mode.

[0161] The KDS administrator 318 creates an asymmetric key pair on the KDS portal 317, and sends a public key creation leaf certificate request to the Certificate Authority 398.

[0162] The leaf certificate is renewed upon expiration by sending a request to the Certificate Authority 398, and the private key is renewed by the KDS Administrator 318 on the KDS Portal 317 in single or batch mode by sending a request to the Certificate Authority 398.

[0163] Key regeneration is performed by the KDS administrator 318 on the KDS portal 317 by creating a new asymmetric key pair and sending a key regeneration leaf certificate request to the certificate authority 398 along with the old leaf certificate and the new public key.

[0164] The KDS Administrator 318 on the KDS Portal 317 retrieves multiple leaf certificates and associated private keys as a batch generated by the Certificate Authority 398 and associated with a batch identifier, wherein the batch may be generated in response to a request from the KDS Administrator 318 on the KDS Portal 317 or generated autonomously by the Certificate Authority 398.

[0165] Authentication is performed by a client application 101 running on a first device 160 using a tenant identifier, a symmetric KDS member PSK (M-PSK), and an M-PSK identity hint in the KDS 305, wherein the first device 160 is registered with a first DNS hostname in a DNS service 321 configured with the KDS 305 or KDS proxy 602, and the first device 160 is registered as a member device in the KDS 305.

[0166] At a minimum, the client application 101 obtains a trusted certificate, a leaf certificate, and an associated private key from KDS305 using the tenant identifier of the trusted certificate and the subject name of the leaf certificate, and the obtained leaf certificate and associated private key are used in certificate-based client authentication for mutual authentication via a secure transport protocol during communication with a server application 151 running on a second device 180, or when signing data with a digital signature or when unwrapping keys.

[0167] A secure session is initiated by the client application 101 using a security protocol, the session being initiated using the acquired leaf certificate and associated private key for certificate-based client authentication in order to establish secure communication with the server application 151 running on the second device 180.

[0168] Without requiring human intervention and without service interruption, the certificate status is programmatically verified by the client application 101 using the client KDS interface 303, and further certificate-based client authentication is performed during certificate renewal or key regeneration by reacquiring the leaf certificate, associated private key, and trusted intermediate and root certificates.

[0169] The approach also includes the following additional methods:

[0170] A device member authentication handshake is performed by the client KDS interface 303 on the first device 160, using the tenant identifier, device member PSK (M-PSK), and M-PSK identity hint as the first factor of device authentication; further, a session key is generated using a key exchange handshake between the client KDS interface 303 and KDS 305 or KDS proxy 602; and further, device member validation is performed as the second factor of device authentication by performing a DNS reverse lookup of the device member IP address by KDS 305 or KDS proxy 602 to query the first DNS hostname; retrieving the first DNS hostname from the resource record in the DNS response by KDS 305 or KDS proxy 602; and comparing and matching the retrieved first DNS hostname with the device member identifier in multiple KDS requests by KDS 305 or KDS proxy 602.

[0171] The approach also includes the following additional methods:

[0172] Device authentication and multiple key exchange handshakes are performed via connectionless UDP or connection-oriented TCP transport protocols without requiring a security transport protocol, and data authentication and / or data encryption are performed using the retrieved pre-shared key with any communication protocol.

[0173] The client KDS interface 303 provides multiple application programming interfaces (APIs), allowing the client application to directly send multiple requests regarding key and certificate operations to the KDS 305 and directly receive multiple responses regarding key and certificate operations from the KDS 305, or to indirectly send multiple requests regarding key and certificate operations through the KDS proxy 602 and indirectly receive multiple responses regarding key and certificate operations through the KDS proxy 602.

[0174] The first device 160 is registered with a unique DNS hostname in the domain on the local DNS server in the IP address (A) record and PTR record used for DNS hostname reverse lookup.

[0175] In KDS305, the first device 160 is configured as a member of the tenancy associated with the tenant identifier.

[0176] Authenticated requests from the first device 160 for any certificate operation based on the tenant identifier and application identifier are processed by the KDS305 and permitted based on the match with the application identifier associated with the tenant identifier, and the KDS305 is configured to allow or reject the certificate operation.

[0177] The client application 101 uses the acquired leaf certificate and associated private key for data signing using a digital signature.

[0178] Client application 101 uses the acquired leaf certificate for key unwrapping (i.e., to decrypt the wrapped key).

[0179] In response to a request from a KDS administrator 318 in the KDS portal 317, the Certificate Authority 398 generates an asymmetric key pair and a 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.

[0180] Referring to Figures 3H, 2A, 3A, and 7A, in another exemplary embodiment, a method is performed for importing, creating, updating, recreating, retrieving, or acquiring leaf certificates for the public and associated private keys of an asymmetric key pair, used in data signing by digital signatures, and in key unwrapping, in server authentication by applications running on distributed devices, including a client application 101 running on a first device 160, a server application 151 running on a second device 180, trusted intermediate 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 server KDS interface 310, a symmetric KDS member M-PSK, an 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 321, in data signing by digital signatures.

[0181] The approach also includes the following additional methods:

[0182] Import the leaf certificate and associated private key into the KDS portal 317 by the KDS administrator 318 in single or batch mode.

[0183] The KDS administrator 318 creates an asymmetric key pair on the KDS portal 317, and sends a public key creation leaf certificate request to the Certificate Authority 398.

[0184] The leaf certificate will be renewed by the KDS administrator 318 on the KDS portal 317 when it expires by sending a request to the Certificate Authority 398.

[0185] Key regeneration is performed by the KDS administrator 318 on the KDS portal 317 by creating a new asymmetric key pair and sending a key regeneration leaf certificate request to the certificate authority 398 along with the old leaf certificate and the new public key.

[0186] The KDS Administrator 318 on the KDS Portal 317 retrieves multiple leaf certificates and associated private keys as a batch generated by the Certificate Authority 398 and associated with a batch identifier, wherein the batch may be generated in response to a request from the KDS Administrator 318 on the KDS Portal 317 or generated autonomously by the Certificate Authority 398.

[0187] Authentication is performed by a server application 151 running on a second device 180 using a tenant identifier, a symmetric KDS member PSK (M-PSK), and an M-PSK identity hint in the KDS 305, wherein the second device 180 is registered with a second DNS hostname on a DNS service 321 configured with the KDS 305 or KDS proxy 602, and the second device 180 is registered as a member device in the KDS 305.

[0188] At a minimum, the server application 151 obtains a trusted certificate, a leaf certificate, and an associated private key from KDS305 using the tenant identifier of the trusted certificate and the subject name of the leaf certificate, and the obtained leaf certificate and associated private key are used in certificate-based server authentication via a secure transport protocol during communication with a client application 101 running on a first device 160, or in data signing by digital signature, or in key unwrapping.

[0189] A secure session is initiated by the server application 151 using a security protocol, the session being initiated using the acquired leaf certificate and associated private key for certificate-based server authentication in order to establish secure communication with the client application 101 running on the first device 160.

[0190] Without requiring human intervention and without service interruption, the certificate status is programmatically verified by the server application 151 using the server KDS interface 310, and further certificate-based server authentication is performed during certificate renewal or key regeneration by reacquiring the leaf certificate, associated private key, and trusted intermediate and root certificates.

[0191] The approach also includes the following additional methods: A device member authentication handshake is performed by the server KDS interface 310 on the second device 180, using the tenant identifier, device member PSK (M-PSK), and M-PSK identity hint as the first factors of device authentication; further, a session key is generated using a key exchange handshake between the server KDS interface 310 and KDS 305 or KDS proxy 602; and further, device member validation is performed. To query the first DNS hostname, a DNS reverse lookup of the device member IP address is performed by KDS305 or KDS proxy 602, Retrieving the first DNS hostname from the resource record in the DNS response using KDS305 or KDS proxy 602, The retrieved first DNS hostname is compared and matched with the device member identifier in multiple KDS requests using KDS305 or KDS proxy 602. This is implemented as the second factor in device authentication.

[0192] The approach also includes the following additional methods:

[0193] Device authentication and multiple key exchange handshakes are performed via connectionless UDP or connection-oriented TCP transport protocols without requiring a security transport protocol, and data authentication and / or data encryption are performed using the retrieved pre-shared key with any communication protocol.

[0194] The server KDS interface 310 provides multiple application programming interfaces (APIs), and the server application 151 can either directly send multiple requests regarding key and certificate operations to the KDS 305 and directly receive multiple responses regarding key and certificate operations from the KDS 305, or the server application 151 can indirectly send multiple requests regarding key and certificate operations through the KDS proxy 602 and indirectly receive multiple responses regarding key and certificate operations through the KDS proxy 602.

[0195] The second device 180 is registered in the IP address (A) record and PTR record used for DNS hostname reverse lookups by a unique DNS hostname in the domain in the local DNS service 321.

[0196] In KDS305, the second device 180 is configured as a member of the tenancy associated with the tenant identifier.

[0197] Authenticated requests from the second device 180 for any certificate operation based on the tenant identifier and application identifier are processed by the KDS305 and permitted based on the match with the application identifier associated with the tenant identifier, and the KDS305 is configured to allow or reject the certificate operation.

[0198] The server application 151 uses the acquired leaf certificate and associated private key for data signing using digital signatures.

[0199] Server application 151 uses the acquired leaf certificate key unwrapping (i.e., decrypts the wrapped key).

[0200] In response to a request from a KDS administrator 318 in the KDS portal 317, the Certificate Authority 398 generates an asymmetric key pair and a 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.

[0201] In another exemplary embodiment, a method is performed to assign leaf certificates and associated private keys to member devices from an imported or retrieved batch of leaf certificates and associated private keys, and a lookup is performed to match the member UUID, 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 394RetrieveCertificateWithKey API. In yet another exemplary embodiment of the system of disclosure, the lookup and matching of leaf certificates and associated private keys may be performed automatically by KDS 305 or KDS 305 Joint Services during device discovery and onboarding.

[0202] Referring to Figure 3H, in one exemplary embodiment of the system and method of disclosure, in step 375, the client application 101 loads a device-specific configuration file containing the configuration settings required to access KDS 305 or KDS proxy 602. In step 376, the client application 101 uses the OpenContextKDS API to initialize the client KDS interface 303 for transactions on KDS 305 or KDS proxy 602 using the KDS URL, connection type, M-PSK, M-PSK identity hint, tenant identifier, and member identifier loaded from the device-specific configuration file. In step 393, the client application 101 retrieves trusted certificates (i.e., intermediate and root CA certificates) and stores them in the local trust store by retrieving trusted certificates in step 394 using the RetrieveTrustedCertificates API. In step 395, the client application 101 retrieves the leaf certificate and associated private key and stores them in the local key store by retrieving the leaf certificate and associated private key in step 396a using the RetrieveCertificateWithKey API, which is encrypted using the device M-PSK for security. In step 397, the client application 101 uses the retrieved leaf certificate and private key for client authentication, data signing with digital signatures, and key unwrapping. In step 396b, the client application 101 verifies the status of the retrieved leaf certificate (e.g., active, revoked, or expired) using the VerifyCertificate API. In step 383, the client application 101 frees the KDS context and closes the KDS session using the CloseContextKDS API.

[0203] Referring to Figure 3H, in one exemplary embodiment of the disclosure system and method, in step 316, Administrator 318 imports a leaf certificate file and an associated private key file using the KDS portal 317. In step 398a, Administrator 318 uses the KDS portal 317 to send a request to the configured Certificate Authority (CA) 398 to create an asymmetric public and private key pair and to create a leaf certificate for the public key or to regenerate the key. Further in step 398a, Administrator 318 uses the KDS portal 317 to send a renewal or revocation leaf certificate request to the configured Certificate Authority (CA) 398. In step 398b, the client KDS interface 303 interfaces with KDS 305 to retrieve a trusted certificate, or a leaf certificate and associated private key, based on an API request from the client application 101. Furthermore, in step 316, administrator 318 uses the KDS portal 317 to import trusted (intermediate and root CA) certificates (locally) and store them locally for use by KDS 305 to send to the device based on API requests from client application 101 through client KDS interface 303.

[0204] Referring to Figure 3H, in one exemplary embodiment of the system and method of disclosure, the same sequence of steps may be performed by the server application 151 using the server KDS interface 310 for use in server authentication, data signing with a digital signature, and key unwrapping.

[0205] Referring to Figure 3H, in one exemplary embodiment of the system of disclosure, in step 316, Administrator 318 on the KDS portal 317, or in step 398a, Certification Authority 398, for example, Rivest-Shamir-Adleman (RSA) with key sizes of, for example, 512, 1024, 2048, or 4096 bits, Digital Signature Algorithm (DSA) with a key size of, for example, 1024 bits, Elliptic Curve Cryptography (ECC) based on NIST specifications with key sizes of, for example, 224, 256, 384, or 521 bits, or with a key size of, for example, 192 or 256 bits Dynamically generate asymmetric key pairs (i.e., associated public and private keys) using a specified key algorithm and key size, such as ECC based on the X.92 specification, ECC based on the Efficient Ciphertext (SEC) specification standard with key sizes of 224, 384, or 521 bits, ECC based on the Brainpool specification with key sizes of 160, 192, 224, 256, 3209, 384, or 512 bits, or NIST-approved quantum secure cryptography for encryption, digital signatures, or key cryptography (e.g., CRYSTALS-Dilithium, FALCON, SPHINCS+). Certificate Authority 398 creates and issues leaf certificates of public keys based on requests from the KDS portal 317.

[0206] Referring to Figure 3H, in one exemplary embodiment of the disclosure system, in step 316, Administrator 318 on the KDS portal 317 requests Certificate Authority 398 to generate multiple asymmetric key pairs (i.e., batches associated with a universally unique batch identifier), as well as leaf certificates with associated generated public keys and associated private keys, and the certificates and keys are sent to the KDS portal 317 in Privacy-Enhanced Mail (PEM) file format or in PFX (or PKCS#12) combined file format, holding the leaf certificates and associated private keys. The generated batches associated with the universally unique batch identifier can then be retrieved in step 398a by sending a request to Certificate Authority (398) for the retrieval of multiple leaf certificates and associated private keys in batch mode.

[0207] Referring to Figure 3H, in one exemplary embodiment of the disclosure system, a batch of leaf certificates and associated private keys may be autonomously generated by the Certificate Authority 398 for subsequent retrieval by an Administrator 318 on the KDS portal 317 using a universally unique batch identifier and associated with the universally unique batch identifier.

[0208] Referring to Figures 3H, 7A, and 2A, in one exemplary embodiment of the system of disclosure, in step 316, Administrator 318 on the KDS portal 317 initiates a lookup of leaf certificates and associated private keys in batches imported (in step 316) or retrieved (in step 398a) of leaf certificates and associated private keys, where member UUID 731, or member identifier 703, or member DNS hostname 722, is matched with the subject name in the leaf certificate, and the matched certificates and associated private keys are assigned to member device 701 for retrieval in step 396a by a first device 160 or a second device 180 through a client KDS interface 303 or a server KDS interface 310, respectively. In yet another exemplary embodiment of the system of disclosure, the lookup and matching of leaf certificates and associated private keys may be performed automatically by KDS 305 or KDS 305 Joint Services during device discovery and onboarding.

[0209] Referring to Figure 4, in step 403, the client application 101 running on device 100 establishes a connection session with the server application 151 running on device 150 via a local or wide area network (LAN / WAN) 125. In step 402, the client application 101 establishes a session with the server application 151 using a transport protocol stack 102, such as connection-oriented TCP or connectionless UDP. In step 108, the transport protocol stack 103 establishes a network connection 126 via a local or wide area network (LAN / WAN) 125 using a network protocol stack 104, such as IPv4 or IPv6. In step 405, the server application 151 establishes a session with the client application 101 using a transport protocol stack 153, such as connection-oriented TCP or connectionless UDP. In step 157, the transport protocol stack 153 establishes a network connection 126 via a local or wide area network (LAN / WAN) 125 using a network protocol stack 154, such as IPv4 or IPv6.

[0210] Referring to Figure 4, in step 403, the client application 101 running on device 100 can send or receive plaintext or encoded (but unencrypted) data 404 to or from the server application 151 running on device 150 via an established connection session over a local or wide area network (LAN / WAN) 125. The modes of data transmission described herein are not secure without session key-based network traffic encryption.

[0211] Referring to Figures 5A and 7A, in one exemplary embodiment of the system and method of disclosure, in step 302, a client application 101 running on device 100 authenticates member device 100 with KDS 305 via local or wide area network (LAN / WAN) 125 using a Key Distribution Service (KDS) interface 303. In step 304, the KDS interface communicates with KDS 305 using an API to retrieve, or create and retrieve, a symmetric key instance 714 depicted as PSK 501, based on at least a tenant identifier 735, a member identifier 703, a group identifier 705, and an identity hint 711. In a further, yet another exemplary embodiment of the method of disclosure, a key record 709 is retrieved. KDS 305 uses a configured local domain name server (DNS) 321 to reverse look up the requester member device IP address (of device 100) and retrieve a registered member DNS hostname 722. The retrieved member DNS hostname 722 is then matched with the member identifier 703 received in the API request in step 304 to authenticate member device 100. In steps 502 and 503, the client application 101 uses the retrieved PSK 501 and associated identity hint 711 to authenticate and / or encrypt message 504 sent to server application 151 running on device 150, and to verify and / or decrypt message 504 received from server application 151 running on device 150.

[0212] Referring to Figures 5A and 7A, in step 309, the server application 151 running on device 100 authenticates member device 150 with KDS 305 via local or wide area network (LAN / WAN) 125 using the Key Distribution Service (KDS) interface 310. In step 311, the KDS interface communicates with KDS 305 using an API to retrieve, or create and retrieve, a symmetric key instance 714 depicted as PSK 506, based on at least the tenant identifier 735, member identifier 703, group identifier 705, and identity hint 711. In a further alternative exemplary embodiment of the method of disclosure, a key record 709 is retrieved. KDS 305 uses a configured local domain name server (DNS) 321 to reverse look up the requester member device IP address (of device 150) and retrieve a registered member DNS hostname 722. The retrieved member DNS hostname 722 is then matched with the member identifier 703 received in the API request in step 311 to authenticate member device 150. In steps 507 and 508, the server application 151 uses the retrieved PSK 506 and associated identity hint 711 to authenticate and / or encrypt message 504 sent to client application 101 running on device 150, and to verify and / or decrypt message 504 received from client application 101 running on device 150.

[0213] Referring to Figure 5A, in one exemplary embodiment of the system and method of disclosure, in step 509, a client application 101 running on device 100 and a server application 151 running on device 150 establish secure communication with network traffic protection for data exchange, using a shared symmetric key described as 501 and 506.

[0214] Referring to Figures 5B and 5A, in step 505, the client application 101 loads a separate device and application-specific configuration file containing the configuration settings required to access KDS 305 or KDS proxy 602. In step 376, the client application 101 uses the OpenContextKDS API to initialize the client KDS interface 303 for transactions on KDS 305 or KDS proxy 602 using the KDS URL, connection type, M-PSK, M-PSK identity hint, tenant identifier, and member identifier loaded from the device-specific configuration file. In step 510, the client application 101 uses the group identifier and S-PSK identity key loaded from the application-specific configuration file. In step 377, 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. In step 511, the client application 101 uses the retrieved S-PSK to securely send / receive data to / from the server application 151. In step 379, the client application uses the VerifyKey API to verify the status of the S-PSK on the client KDS interface 303. The client KDS interface 303 checks the S-PSK expiration timestamp, and if the key is not expired, verifies the activation status of the S-PSK on KDS 305 or KDS proxy 602. In step 380, if the S-PSK is deactivated, the client application 101 uses the RenewKey API to retrieve the updated S-PSK. In step 512, the client application 101 uses the retrieved S-PSK to securely send / receive data to / from the server application 151.In step 383, client application 101 frees the KDS context using the CloseContextKDS API, thereby removing the local S-PSK (i.e., the S-PSK no longer persists locally and is reacquired from KDS305 or KDS proxy 602 via a client application restart).

[0215] Referring to Figures 5C, 5A, and 5B, in step 505, the server application 151 loads a separate device and application-specific configuration file containing the configuration settings required to access KDS 305 or KDS proxy 602. In step 376, the server application 151 uses the OpenContextKDS API to initialize the client KDS interface 303 for transactions on KDS 305 or KDS proxy 602 using the KDS URL, connection type, M-PSK, M-PSK identity hint, tenant identifier, and member identifier loaded from the device-specific configuration file. In step 513, the server application 151 uses the group identifier and S-PSK identity key loaded from the application-specific configuration file. In step 377, 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. In step 514, the server application 151 uses the retrieved S-PSK to securely receive / send data to / from the client application 101. In step 379, the server application uses the VerifyKey API to verify the status of the S-PSK on the client KDS interface 303. The client KDS interface 303 checks the S-PSK expiration timestamp, and if the key is not expired, verifies the activation status of the S-PSK on KDS 305 or KDS proxy 602. In step 380, if the S-PSK is deactivated, the server application 151 uses the RenewKey API to retrieve the updated S-PSK. In step 515, the server application 151 uses the retrieved S-PSK to securely receive / send data to / from the client application 101.In step 383, the server application 151 frees the KDS context using the CloseContextKDS API, thereby removing the local S-PSK (i.e., the S-PSK does not persist locally and is reacquired from KDS305 or KDS proxy 602 via a server application restart).

[0216] Referring to Figure 5C, the server application 151 can use the RetrieveKeys API to retrieve the pre-shared key (S-PSK) associated with the group identifier (i.e., pre-load the S-PSK required to accept the connection from the client application 101).

[0217] Referring to Figures 5D, 5A, 5B, and 5C, in step 505, the server application 151 loads separate device and application-specific configuration files containing the configuration settings required to access KDS 305 or KDS proxy 602. In step 376, the server application 151 uses the OpenContextKDS API to initialize the client KDS interface 303 for transactions on KDS 305 or KDS proxy 602 using the KDS URL, connection type, M-PSK, M-PSK identity hint, tenant identifier, and member identifier loaded from the device-specific configuration file. In step 516, the server application 151 uses the group identifier and S-PSK identity key loaded from the application-specific configuration file. In step 381, the server application 151 uses the CreateKey API to create and retrieve the pre-shared key (S-PSK) associated with the group identifier and the associated S-PSK identity hint. In step 517, the server application 151 uses the retrieved S-PSK to securely receive / send data to / from the client application 101. In step 382, ​​the server application deletes the S-PSK in KDS 305 using the DeleteKey API. In step 383, the server application 151 frees the KDS context using the CloseContextKDS API, thereby deleting the local S-PSK (i.e., the S-PSK no longer persists locally).

[0218] In the disclosure system and method, applications running on a device may be dynamically configured with a device-unique pre-shared key (S-PSK) for authenticated and secure communication over any transport protocol (e.g., UDP, TCP, TLS). During onboarding, the main application (on the RTOS platform) or a client application (on the GPOS platform) can retrieve a group key (S-PSK) from the KDS using a group key (S-PSK) identity hint embedded (on the RTOS platform) or loaded from a configuration file (on the GPOS platform). A unique device key (D-PSK) can then be derived from the HMAC-SHA256 of the retrieved group key (S-PSK) and a device-unique registration ID pre-shared with the server (e.g., Azure DPS / Hub). In peer-to-peer communication using S-PSK, the device group may be defined as a member in the KDS on the client and server devices, or the client application may dynamically create an S-PSK and send an S-PSK identity hint to the server application to retrieve the S-PSK from the KDS.

[0219] Referring to Figure 5E, in step 519, the client application 101 running on the member device uses a configured group key (S-PSK) identity hint, which is required to retrieve the group key (S-PSK). This hint may be embedded within the application, discovered through network characteristics based on DHCP or DNS-based custom attributes, or loaded from a configuration file. In step 520, the client application 101 uses the client KDS interface 303 to retrieve the group key (S-PSK) using the S-PSK identity hint. In step 521, the client KDS interface 303 communicates with KDS 305 to retrieve the requested group key (S-PSK). In step 522, the device group key (S-PSK) is retrieved by the client application 101. In step 523, the client application 101 uses the group key (S-PSK) and the device unique registration ID (e.g., MAC address, serial number) to derive a unique device key (D-PSK). The derivation function may be, for example, the HMAC-SHA256 algorithm. In step 524, the client application 101 connects to the server application 151 using the device registration ID. In step 525, the server application 151 retrieves the group key (S-PSK) using the server KDS interface 310, which communicates with the KDS 305 in step 526, and returns the requested group key (S-PSK) to the server application 151 in step 527. In step 522, the device group key (S-PSK) is retrieved by the client application 101. In step 528, the server application 151 derives a unique device key (D-PSK) using the device registration ID. The client application 101 and the server application 151 use the unique device key (D-PSK) for authenticated and secure communication.

[0220] Referring to Figures 6 and 7A, in one exemplary embodiment of the system and method of disclosure, the KDS proxy 602 authenticates and validates member device 703 in the DNS domain. Member devices on the local area network (LAN) 125 can connect to the KDS 305 via the wide area network (WAN) through the KDS proxy 602. Because network address translation (NAT) occurs at the LAN / WAN edge, member device IP addresses on the LAN are not accessible to the KDS 305 via the WAN 606. Therefore, a DNS reverse lookup by member device IP address for member device DNS hostname is not feasible. In step 601, KDS interfaces 303 and 309 connect to the KDS proxy 602. In step 603, the KDS proxy uses a configured DNS server 321 on LAN 125 to perform a DNS reverse lookup by member device IP address for member device DNS hostname 722 and matches the resolved DNS hostname with member identifier 703 in the API request. In step 605, the KDS proxy 602 establishes a secure connection with the KDS 305, for example via a web connection using Certificate-Based Mutual Authentication and Hypertext Transfer Protocol Secure (HTTPS), and performs the requested API operation on behalf of a member device on the LAN, for example using the Representational State Transfer (REST) ​​API. The KDS proxy 602 and KDS 305 may be configured for security using authenticated API requests and API access tokens and API access secrets for permission-based access control. The KDS proxy 602 may at least attach the authenticated member identifier 703 and member DNS hostname 722, retrieved from the local DNS server in the proxied API request, to the externally hosted KDS 305.

[0221] Referring to Figures 3B, 3C, and 6, in one exemplary embodiment of the system and method of disclosure, an on-premises KDS proxy implements the first factor of device authentication for local member devices. By default, prior to device onboarding, a device is assigned to the group identifier "Factory Default" and consists of an associated shared or secret M-PSK identity hint and M-PSK. After onboarding, the (RTOS) main or (GPOS) onboarding application on the device should create a device-unique M-PSK identity hint and M-PSK based on the "Registered Members" group for advanced security for subsequent first-factor device authentication (using the KDS interface CreateKey API). During the initial handshake with the local member device, the KDS proxy receives a "Device Hello" from the KDS interface on the member device with the M-PSK identity hint, and then retrieves the tenant identifier of the proxy server (device), the group identifier set to "Registered Members" (group type = "Authenticater"), and the M-PSK with the received M-PSK identity hint. If an M-PSK is not found based on "Registered Members," the KDS proxy retrieves the M-PSK along with the proxy server's (device's) tenant identifier, the group identifier set to "Factory Default" (group type = "Onboarding"), and the received M-PSK identity hint. The retrieved M-PSK can be cached locally on the KDS proxy. Alternatively, the M-PSK for the tenant identifier and the "Registered Members" group identifier can be retrieved in advance using the KDS interface RetrieveKeys API.

[0222] Refer to Figure 7A for an illustration of the entities and relationships. In step 702, member device 701 is associated with member identifier 703. In step 721, member identifier 703 is associated with member DNS hostname 722 registered with the local DNS server. Member DNS hostname 722 is mapped to an alias (ALIAS) or canonical name (CNAME) resource record on the DNS server and may therefore be different from member identifier 703. In step 704, one or more member devices 701 are associated as members of one or more group identifiers 705. In step 736, tenant identifier 735 is associated with one or more group identifiers 705. In step 706, group identifier 705 is associated with group type 707 (e.g., shared, secret, onboarding, authenticator, anonymous, community, or any appropriate group type). In step 708, group identifier 705 is associated with one or more key records 709. In steps 710, 712, 714, 720, 723, and 725, the identity hint 711, key template 713, key instance 715, key creator 724, key status 726, and key expiration 721 are associated with key record 709, respectively. In steps 716, 718, and 727, the key algorithm 717, key size 719, and key usage 728 are associated with key template 713, respectively. The key status 726 is managed by the KDS and can be set to active, suspended, expired, or deleted on the surviving key record 709. Key usage 728 may be set by key creator 724 for, for example, client authentication, data authentication, data encryption, content (producer or intermediary) signing (e.g., code files, data files, image files, Java archive (JAR) files, compressed zip / tar format files), 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 (e.g., to grant data authentication and data encryption permissions). In step 733, the key token 734 is associated with the key record 709, effectively associating the key instance 715 with the key token 734. In step 737, the hash algorithm 738 is associated with the key template 713 for digital signing (e.g., by HMAC authentication). In step 739, one or more member domains 740 are associated with one or more group identifiers 705. In an exemplary embodiment of the proposed method, a request from an authenticated member device 701 for a key instance 715 (or any key operation) based on a specified group identifier 705 and identity hint 711 may be processed by the KDS and granted based on a match between the member domain 740 and the domain (i.e., the domain name and top-level domain suffix portion) derived from a resource record retrieved by a DNS reverse lookup of the member device DNS hostname 722. For example, in the case of member device 701 having a member DNS hostname validated by the DNS server as "my-hostname.my-domain.com", the member domain "my-domain.com" associated with group identifier 705 grants the key record 709 associated with member device 701 based on the specified identity hint 711 of the specified group identifier 705. In step 741, one or more application identifiers 742, represented as a hyphenated alphanumeric string or a universally unique identifier (UUID), may be associated with group identifier 705. The UUID may be the MAC address, serial number, or IMEI of member device 701. In step 743, an image name 744 may be associated with application identifier 742. In step 745, an image hash 746 (e.g., SHA-256) of the application image may be associated with application identifier 742.In an exemplary embodiment of the proposed method, referring to Figures 3A and 5A, a request from an authenticated member device 701 for a key instance 715 (or any key operation) based on a specified group identifier 705 and identity hint 711 is processed by the KDS and may be authorized based on an application identifier sent by the KDS interface (303, 310) in a KDS request (304, 311) that matches the application identifier associated with the specified group identifier 705 and identity hint 711 in the KDS. This provides a method for rejecting key requests to unauthorized applications. In step 747, the key nonce 748 may be associated with the key template 713 as a nonce (i.e., a unique, random, or pseudo-random value) for use, for example, as an initialization vector (input to 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 block ciphers) or the mode of operation of the cryptographic algorithm (e.g., zero or a fixed value for deterministic algorithms). In step 749, the key handle 750 may be associated with the key template 713. The key handle 750 may be used by the application, optionally, to constitute a location identifier for a local secure element (e.g., a TPM handle, NVRAM index, HSM slot) for securely storing the retrieved pre-shared key on the device. In step 751, the message authentication code (MAC) hash algorithm 752 may be associated with the key template 713. In step 753, the MAC hash prime 754 may be associated with the key template 713. For example, additional entities such as member device manufacturers (e.g., vendor class identifiers configured on DHCP service 172) and models may be explicitly associated with member devices through the KDS portal or retrieved from external services (e.g., DHCP extended attributes associated with device MAC addresses). In step 755, the community identifier 756 may be associated with one or more tenant identifiers 735.

[0223] Referring to Figure 7A, group type 707 provides rule-based access control to restrict KDS member devices' access to key records (associated with the group identifier). The “Secret” group type restricts access only to the key creator. 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 retrieval access to members of co-tenants within the community (i.e., tenant identifiers associated with the community identifier). For example, if tenants A-Corporation and B-Corporation are co-tenants of the community referenced (by community identifier 756) during a key retrieval operation initiated by a member of tenant A-Corporation, then a member of tenant A-Corporation can access key record 709 by identity hint 711 associated with the community group identifier 705 (with the group type set to “Community”) of tenant B-Corporation. Community-based key access use cases are suitable for content signing and supply chain tamper resistance using signature manifests (Figure 8C) and extended signature manifests (Figure 8D), the which can include tenant identifiers and group identifiers in entry records for transactions between cross-tenant producer, intermediary, and consumer applications.

[0224] Referring to Figure 7, as an illustrative example, the device may be configured as follows: • Member device = "OT device". • Member identifier = Local device identifier (LDevID) "A2Z029". • Member DNS hostname = "A2Z029.dba.com". A DNS PTR record pointed to A2Z029.dba.com in the A-record pointed to by the assigned IP address (stored in the IP address converted to a 4-bit section with ".in-addr.arpa" appended to the end of IPv4 or ".ip6.arpa" appended to the end of IPv6). For example, stored as "45.34.23.12.in-addr.arpa" for the IPv4 address "12.23.34.45" and as "fedcba0.9.8.7.6.5.4.3.2.1.fedcba0.9.8.7.6.5.4.3.2.1.ipv6.arpa" for the IPv6 address "1234:5678:90ab:cdef". In DNS, CNAME records can be created to assign multiple identities (i.e., aliases) to member devices (for example, a server-grade device can function as a web server, file server, and mail server). ALIAS records may be created with an abbreviated (subset) name (e.g., dba.com), while CNAME records can be prefixed to the abbreviated name (e.g., A2Z029.dba.com). • Member UUID = "dbfdeb0c-19e8-4c26-b1c0-44d22275b591".

[0225] Referring to Figure 7A, for data authentication (e.g., content signing, message signing), the digital signature generated using the retrieved pre-shared key can use the hash algorithm 738 associated with the key template 713 of the key record 709 associated with the identity hint 711.

[0226] Referring to Figure 7A, a message authentication code generated using hash algorithm 738 (e.g., HMAC-MD5-128, which includes 16 bytes) can be mapped to a smaller number of bytes (e.g., equivalent to a 2-byte CRC) using a hash function specified by MAC hash algorithm 752 and, optionally, a prime number specified by MAC hash prime 754.

[0227] In another further exemplary embodiment of the method of disclosure, referring to Figure 7A, on a device using a protocol with a limited message frame length, such as a standard or extended CAN bus, the digital signature of a message may be generated using a hash algorithm 738 (e.g., HMAC-MD5-128), and the cyclic redundancy check (CRC) checksum field in the CAN message may then be replaced with a hash of the generated digital signature of the message using a MAC hash algorithm 752 and a MAC hash prime 754 specified in a key template 713. The specified MAC hash algorithm 752 may be performed on the device using, for example, a MAC hash prime 754, multiplication, bitwise exclusive OR (XOR), bitwise AND, and left / right bit shift operators.

[0228] In another exemplary embodiment of the method of disclosure, KDS305 uses a configured local domain name server (DNS)321 to reverse look up the requester member device IP address of member device 701 and retrieve a registered member DNS hostname722. The retrieved member DNS hostname722 is then validated against the received member identifier703 in the API request to authenticate member device 701, and the validation validates the received member identifier703 (not an exact match) using the received DNS alias or a CNAME record configured on the DNS server.

[0229] Referring to Figures 7A and 3A, in exemplary embodiments of the disclosure system and method, key instance 715 corresponds to the API shared secret, and key token 734 corresponds to the API shared token in the REST API request authentication mechanism. For intentional application security, REST API requests are digitally signed by the client / client application to verify that the server / server application issued the API request from an authorized source and that it was not tampered with during transmission. The API shared secret and API shared token are used to digitally sign and verify the request URL, which includes the API method, API request timestamp, and API token (generic unique identifier, i.e., UUID). API service accounts are typically configured manually through a service portal or are automatically generated during service account creation by the service. Associated API shared credentials (i.e., token and secret) must be securely stored by the service and application administrator. If API shared credentials are lost, a new set of credentials must be generated for the server / server application and synchronized with the associated client application. KDS305 provides an automated and extensible mechanism for distributing and synchronizing API shared credentials between applications on authenticated and domain-validated member devices.

[0230] Referring to Figures 7A and 3A, in the exemplary system and method-specific embodiments of the disclosure, the key instance 715 and key token 734 may be generated externally and imported into the KDS305.

[0231] Referring to Figures 3A, 5A, and 7A, the scheduled task in KDS305 periodically and automatically updates the key instance 715 within a time window configured in KDS305 before the key expiration 721 of each PSK created (and owned) by the KDS administrator as a set in the key record 709 and key creator 724 fields. The key instance 715 for PSKs created (and owned) by applications running on member device 701 can be updated programmatically and automatically through the client KDS interface 303 API.

[0232] Referring to Figures 3A, 5A, and 6, in one exemplary embodiment of the system and method of disclosure, applications 101 and 151 can establish connection-oriented or connectionless secure communication using any transport protocol stack 103 and network protocol stack 104, using client KDS interface 303, KDS 305, and KDS proxy 602. Specific examples of such standards-based communication protocols include Controller Area Network Bus (CAN bus), Modbus (over TCP / UDP), Highway Addressable Remote Transducer (HART), WirelessHART, and RS232 serial communication protocol. The key size 719 may be selected to optimize the encrypted message length and reduce latency in real-time applications. Based on the message types and maximum frame length permitted by the communication standard, the optimal message signature length key size 719 may be selected. The keyed hash message authentication code (HMAC) may optionally be truncated before sending, while simultaneously ensuring the message is authenticated due to message length constraints.

[0233] Referring to Figures 3A, 5, and 7A, in one exemplary embodiment of the system and method of disclosure, member device 701 may be registered as a computer object in directory service 730. In step 732, a member universally unique identifier (UUID) 731 (representing, for example, a device unique MAC address, serial number, or mobile device IMEI) may be configured for member device 701 from the KDS portal 317. In step 729, a tenant identifier 735 may be configured in directory service 730, such as Microsoft(R) Active Directory, from the KDS portal 317. Member device 701 is listed in the directory service 730 management domain and may be assigned a universally unique identifier (UUID) by directory service 730. Member UUID 731 may be configured from the KDS portal 317 as appropriate to match the retrieved UUID of the associated computer object in directory service 730 for member device validation by KDS 305. The group identifier 706 of member device 701 can be retrieved from the groups and group memberships configured in the directory service 730 during the KDS 305 configuration from the KDS portal 317.

[0234] Referring to Figures 3A and 5A, the client KDS interface 303 provides a simplified set of APIs as a library for static or dynamic linking by multilingual 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, as well as an operating system abstraction layer (OSAL) for integration with the device platform. The OSAL provides an OS agnostic interface to the client KDS interface 303 for multi-platform portability. OS-specific hooks for memory, file systems, networks, timers, mutexes, and thread management can be implemented as underlying plug-ins (i.e., operators) to the OSAL based on the target OS platform (e.g., Windows, Linus, FreeRTOS, Azure RTOS, VxWorks, QNX, uCOS).

[0235] Referring to Figures 3A, 5A, and 7A, in exemplary system and method-specific embodiments of the disclosure, a server application operating as a service to multiple client (or initiator) applications can use KDS305 to configure an identity hint 711 for content signing in key instance 715. The server application can sign content using the PSK and send the PSK identity hint and digital signature associated with (and separately from) the digitally signed content using, for example, a Key Hash Message Authentication Code (HMAC). The client (or initiator) application can use the identity hint 711 to retrieve key instance 715 from KDS305, regenerate the digital signature of the received content, and cross-verify the computed digital signature with the digital signature received with the content. In yet another exemplary embodiment of the disclosure system and method, the content signing mechanism may be extended to include multiple signers for supply chain tamper resistance using a chain of PSKs, and a configuration file containing PSK identity hints and a list of digital signatures may be sent over a secure channel together with (and separately from) the digitally signed content for regeneration and cross-verification. A client (or initiator) application can use the identity hint 711 to retrieve the key instance 715 from the KDS305, regenerate the digital signature of the received content, and cross-verify the computed digital signature with the digital signature received with the content.

[0236] KDS's ability to manage dedicated PSKs and distribute them to authenticated member devices for content signing enables client authentication, secure communication, and the use of separate PSKs for content signing. Applications running on member devices can provide digital certificates of data (e.g., runtime operational integrity, loaded configuration, telemetric metrics) to track and trace data objects back to their data sources. Receivers can tag cross-validated data objects to authenticated data sources for their origin.

[0237] Resource constraints on OT / IIoT / IOT device platforms (e.g., memory, storage, and file systems in flash) impose major challenges regarding the use of ciphertext and security protocol stacks. Furthermore, non-volatile electrically erasable programmable read-only memory (EEPROM) imposes limits on the number of permitted write operations (lifespan). Additionally, flash-based file systems may be read-only (non-writable or have a writable overlay that is power-cycle volatile), and therefore, PKI-based key and certificate updates may not be possible. Common approaches to storing long-lived (non-expiring) private keys, seed phrases (nonces), and certificates in NVRAM impose security risks. In contrast, PSKs in disclosure systems do not need to persist on the device and can be dynamically retrieved from the KDS by the application running on the device at runtime (e.g., at application startup) and erased from memory when the application terminates. From a memory usage perspective, the length of an X.509 certificate may vary based on the parameters and key size, typically a few kilobytes (e.g., 1KB, 2KB, 5KB), while the symmetric key size is typically a few bytes (e.g., 56, 80, 112, 128, 192, 256 bits).

[0238] Referring to Figure 5A, in one exemplary embodiment of the system and method of disclosure, PSK501 and 506 for data authentication and data encryption may be used by real-time and mission-critical client applications 101 and server applications 151 to secure a selected section of message 504 in application (user) space. This provides application developers with a simplified method that is independent of the underlying transport and network protocol stack in user or kernel space. For real-time and mission-critical applications requiring low latency, messaging integrity, and confidentiality, partial payload protection is an effective solution. Some examples include (a) industrial control systems that must comply with General Purpose Object-Oriented Substation Events (GOOSE) and IEC-61850 (International Electrotechnical Commission) and NERC-CIP (North American Electroreliability Council Critical Infrastructure Protection) standards, (b) applications in transportation systems (e.g., smart vehicles), (c) applications in aerospace systems (e.g., civilian and military aircraft, unmanned aerial vehicles or drones), (d) applications in space systems (e.g., satellites and spacecraft), and (e) operational technology (OT) applications in healthcare systems (e.g., medical devices, bedside devices, surgical devices, nurse station devices, patient devices, and palliative care or hospice care devices). In integrated systems, inter-system messaging between components (e.g., electronic control units, telemetric control units, onboard diagnostic units, navigation systems, display units, multi-service IoT edge gateways, sensors, actuators, controllers) must adhere to low latency requirements, security, and safety standards.

[0239] Referring to Figures 5A and 7A, in one exemplary embodiment of the disclosure system and method, PSKs 501 and 506 may be used for data encryption, so that selected sections (or embedded component objects) within a document have their content blacked out / obfuscated based on member device identifiers 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 selected content blacked out / obfuscated based on member device identifiers 703. An application generating a secure document uses the PSK to encrypt selected sections of the document and embeds the associated PSK identity hint 711 as metadata within the section. Different sections within a document may be encrypted with different PSKs using their respective PSK identity hints 711. An application rendering a secure document uses the embedded PSK identity hints to retrieve the associated PSKs and decrypt each section. In yet another exemplary embodiment of the disclosure system and method, the rendering application may be a web browser, which enables web applications and services to deliver dynamically generated secure web content (web pages) with blacked-out / obfuscated content based on member device identifier 703 to authenticated and authorized users.

[0240] Referring to Figures 5A and 7A, in one exemplary embodiment of the system and method of disclosure, a blockchain application can retrieve a PSK from the KDS305 with device authentication and device domain validation for (a) secure communication that does not require PKI-issued certificate-based device and / or client authentication, and (b) digital signing of transactions that does not require 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 a root of trust, or trust anchor) contradicts the decentralized first principle of blockchain philosophy. The limitations of computing power, memory, protected local storage for keys to persist, and security protocol stacks on resource-constrained devices make the generation and use of asymmetric keys with high entropy, as well as runtime certificate chain validation, a difficult and challenging task. The use of symmetric PSKs with key rotation managed by KDS305, based on member identifier 703, tenant identifier 735, and group identifier 705, along with their extensible and simplified distribution, defines and assembles a software-defined network (SDN) for blockchain nodes.

[0241] Referring to Figures 8A and 5A, in step 302, the client application 101 retrieves the pre-shared key (S-PSK) 501 from the KDS 305 using the client KDS interface 303. In step 503, the client application 101 uses the retrieved S-PSK 501 to selectively encrypt a portion of the message 801 that is to be sent over the local or wide area network (LAN / WAN) 125. In step 309, the server application 151 retrieves the pre-shared key (S-PSK) 506 from the KDS 305 using the server KDS interface 310. In step 508, the server application 151 uses the S-PSK 506 to selectively decrypt a portion of the message 801 that was received over the local or wide area network (LAN / WAN) 125.

[0242] Referring to Figures 8B and 5A, in step 804, the producer application 802 on device 899 uses the client KDS interface 303 to create a pre-shared key (PSK) 805 in KDS 305. In step 806, the producer application 802 uses the created and retrieved PSK 805 to selectively encrypt the embedded objects and tag each encrypted embedded object with its respective pre-shared identity hint in document 803. In step 808, the consumer application 807 on device 898 uses the server KDS interface 310 to retrieve a pre-shared key (PSK) 809 from KDS 305 for the pre-shared key identity hint to which each encrypted embedded object is tagged, on a member device authenticated and validated by KDS. In step 810, the server application 151 uses the retrieved PSK 809 to selectively decrypt the encrypted embedded objects in the document. In block 892, the structure of the document is illustrated by an example of an encrypted embedded object and an associated PSK identity hint tagged to each of the encrypted objects within the secured document.

[0243] Referring to Figures 8C and 5A, in step 812, the producer application 811 on device 897 receives content 813. In step 814, the producer application 811 uses the client KDS interface 303 to create a pre-shared key (PSK) 815 for content signing in KDS 305. In step 816, the producer application 811 uses the retrieved PSK 815 to digitally sign the received content 813 and generate digitally signed content 817. In step 818, the producer application 811 generates a signature manifest with the tenant identifier, group identifier, digital signature of the digitally signed content 817, the associated PSK identity hint for PSK 815, and the designated object 820 for the digitally signed content 817. In step 829, the consumer application 823 on device 896 receives the digitally signed content 817. In step 824, the consumer application 823 receives the associated signature manifest 819. In step 825, the consumer application 823 uses the client KDS interface 303 to retrieve the pre-shared key (PSK) 826 for the tenant identifier, group identifier, and PSK identity hint 822 in the received signature manifest 819 from the KDS 305. Using the retrieved PSK 826, the consumer application 823 regenerates the digital signature of the received digitally signed content 817 and compares it to the digital signature 821a in the received signature manifest 819 to find a match.

[0244] Referring to Figures 8D and 5A, in step 812, the intermediary application 832 on device 895 receives content 813. In step 812, the intermediary application 832 uses the client KDS interface 303 to create a pre-shared key (PSK) 836 for content signing in KDS 305. In step 816, the intermediary application 832 uses the retrieved PSK 836 to digitally sign the received digitally signed content 828 and generate the enhanced digitally signed content 830. In step 833, the intermediary application 832 receives the signature manifest 819, and in step 834 generates an enhanced signature manifest with the tenant identifier, group identifier, additional digital signatures for the enhanced digitally signed content 830, additional associated PSK identity hints for the PSK 836, and the named object 820 for the enhanced digitally signed content 830. In step 835, the consumer application 823 on device 896 receives the enhanced digitally signed content 830. In step 824, the consumer application 823 receives the associated extended signature manifest 819. In step 825, the consumer application 823 uses the client KDS interface 303 to retrieve the pre-shared key (PSK) 837 for the tenant identifier, group identifier, and PSK identity hint 822 in the received extended signature manifest 831 from the KDS 305. The consumer application 823 uses the retrieved PSK 837 to regenerate the digital signature of the received extended digitally signed content 830 and compares it to the digital signature 821b in the received extended signature manifest 831 to seek a match.

[0245] In one exemplary embodiment of the proposed system and method, content signing for supply chain tamper resistance may be performed as a set of utilities (or tools) including a signing utility (kdssign) and a verifyer utility (kdsverify) on a GPOS platform (e.g., Windows, Linux, or Mac OS) that can be run on a registered KDS member device. 1) kdssign -conf{KDS device configuration file} -tenant{tenant identifier} -group{group identifier} -hint{key identity hint}[-extend] -manifest{signature manifest file} -file{content file to be signed} (a) Retrieve the signing key from the KDS using the signer-specified tenant identifier, group identifier, and key identity hint; (b) generate a hash of the content to be signed and a signature based on the hash algorithm specified in the retrieved key record; and (c) create a new signature manifest file (JSON) with the tenant identifier, group identifier, key identity hint, and content signature as the entry record. • Extension: Adds (attaches) entry records to the specified signature manifest file (JSON). 2) kdsverify -conf{KDS device configuration file} -community{community identifier} -manifest{signature manifest file} -file{content file to be verified} For each entry record in the signature manifest file, (a) retrieve the signing key from the KDS using the verifier-specified community identifier, as well as the manifest-specified tenant identifier, group identifier, and key identity hint; (b) generate a signature based on the hash of the content to be verified and the hash algorithm specified in the retrieved key record; and (c) compare the generated signature with the signature in the signature manifest file for the key identity hint.

[0246] In yet another exemplary embodiment of the proposed method, referring to FIGS. 8C and 8D, two-factor split-channel verification of device updates (e.g., firmware, software, configuration files) may be performed. The steps include downloading a device update (package or module) from a configured update server (e.g., a web service hosted on-premises or in the cloud) by an update program running on the device, verifying the digital code signature of the downloaded device update by the content publisher using a configured asymmetric public key by the update program, or signing the certificate as the first factor of verification, and verifying a signature manifest (or extended signature manifest) file provided with the device update using the Extended KDS Interface VerifySignatureManifest API as the second factor of verification. The signature manifest or extended signature manifest file can be generated respectively by a provider or intermediary application for device updates for content signing and supply chain tampering resistance using the Extended KDS Interface GenerateSignatureManifest API. The workflow for signature manifest-based second factor protection can operate independently (or simultaneously) from the continuous integration (CI) and content distribution (CD) workflows for the first factor of verification, with separation of duty-based permissions to mitigate insider threats by sophisticated attackers and advanced persistent supply chain exploitation. In one embodiment of the proposed method, the signature manifest or extended signature manifest file for a device update package may be generated by a provider or intermediary using the Kdssign signature utility, and the signature manifest or extended signature manifest file verification may be performed by a consumer using the KDSverify verifier utility.

[0247] In yet another exemplary embodiment of the proposed method, the KDS interface can retrieve (automatically discover) primary and secondary KDS / KDS proxy URLs, tenant identifiers, group identifiers, 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 or DNS server associated with the member device LAN. Original Equipment Manufacturers (OEMs) can pre-configure the KDS Member Pre-Shared Key (M-PSK) and M-PSK identity hint required for device authentication in the KDS, as well as the guest WAP service set identifier (SSID) and associated guest (Wi-Fi protected access) WPA2 PSK for the manufacturing and deployment network environment, by embedding them in a production application image on a real-time operating system (RTOS) platform or through a factory default configuration file on a general-purpose operating system (GPOS) platform. In a production network environment, WAP may be configured for a multi-SSID mode of operation, with guest WAP SSIDs (GWAP-SSIDs) and secure internal WAP SSIDs (IWAP-SSIDs) being configured for multiple wireless networks with different security policies for controlled access.In the member device, a supplicant program (e.g., a Wi-Fi supplicant, a production application, or a Wi-Fi supplicant function implemented within system firmware) connects to the production network, authenticates initially using the GWAP-SSID and the associated guest WAP pre-shared key (GWAP-PSK), then extracts the production WAP-specific secure internal WAP pre-shared key (IWAP-PSK) for the IWAP-SSID, tenant identifier, WAP group identifier, and IWAP-PSK identity hint from the discovered KDS / KDS proxy URL, and finally can initiate (trigger) a switch to secure WPA2-PSK or WPA2-EAP-PSK-based authentication by the production WAP using the extracted IWAP-PSK. In KDS, a group can be configured that includes production WAP devices and member devices or member domains with the associated IWAP-PSK and IWAP-PSK identity hint.

[0248] Referring to FIG. 3A, the KDS administrator portal 317 may be configured for single sign-on (SSO) and federated identity-based authentication using an authentication method (e.g., OpenID Connect or OIDC, Security Assertion Markup Language or SAML, OAuth) by an identity provider (IdP) that authenticates portal users, grants permissions based on group membership, and creates an IWAP-PSK for the member domain 740 associated with the group identifier 705. In a distributed deployment model, hundreds / thousands of devices are scattered across geographically dispersed locations on a locally administered field network with local WAPs, and remote field operators require an easy and extensible way to configure IWAP-PSKs in KDS.

[0249] Referring to Figure 8E, in step 860, the supplicant program 850 running on device 893 authenticates with WAP 894 on the production network and accesses the guest wireless network using factory-configured attributes 857, which include the guest WAP SSID (GWAP-SSID) 851 and guest WAP pre-shared key (GWAP-PSK) 852. In step 861, the supplicant program 850 authenticates with KDS 305 in step 304 and retrieves the internal WAP pre-shared key (IWAP-PSK) 862 using the client KDS interface 303, along with the tenant identifier, group identifier, and internal WAP pre-shared key (IWAP-PSK) identification hint, as well as the member identifier, which were discovered in step 858 or retrieved from a configuration file on the device using network characteristics based on custom DHCP attributes 859 configured on the DHCP (or DNS) server. In step 863, the supplicant program 850 uses the extracted IWAP-PSK862 and the internal WAP SSID (IWAP SSID), which is pre-configured within the supplicant program image or extracted from a configuration file on the device, to authenticate with the WAP894 on the production network and access the secure wireless network.

[0250] Referring to Figure 9A, steps 902, 904, 906, 908, 910, and 912 respectively indicate the ordered sequence of actions performed in blocks 901, 903, 905, 907, 909, 911, and 913. In block 901, an algorithm is selected for building a machine learning model using a multidimensional feature matrix with device intelligence as the training dataset. In block 903, a multidimensional feature matrix is ​​constructed that includes device tenancy, group membership, key type and usage profile, key usage volume, key rotation rate, and application identifiers (e.g., file name, file hash). In block 905, the feature matrix is ​​extended with imported application-based metrics about vulnerability to external forensic science-based threat intelligence, including content integrity measurements and vulnerability assessments, with scores categorized by, for example, application reputation, static / dynamic analysis, runtime introspection analysis, domain generation algorithm (DGA) analysis, obfuscation level, decompression level, IP address and domain reputation, geolocation information, autonomous system number (ASN), and IP address age. In block 907, the feature matrix is ​​further extended by extracting device properties (e.g., model, manufacturer, identifier, attributes, update history) from device management systems and network management services (e.g., Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP) servers). In block 909, the feature matrix is ​​further extended by extracting flow records about the connection history of inter-device communications from network activity monitoring systems. In block 911, the device risk score can be predicted using a multidimensional feature matrix for linear regression. In block 913, security events can be classified as true positive, false positive, true negative, or false negative using unsupervised models, multilayer deep learning networks, and multidimensional feature matrices of logistic regression.

[0251] Referring to Figure 9B, steps 921, 923, 925, 927, and 929 indicate the ordered sequence of actions performed in blocks 920, 922, 924, 926, 928, and 930, respectively. In block 920, a metadata connector is configured on the KDS portal 317, which includes at least a service provider, a filter type, a webhook specified as a filter name and URL, an API token, an API secret, and a filter scale specified as a list of metadata types and metadata identifiers, where the filter type is specified as a device type or device group. In block 922, the KDS service 305 or KDS proxy 602 authenticates the client device 100 with two-factor authentication. In block 924, the client application 101 on the client device 100 sends device metadata, including a metadata identifier, metadata type, and metadata value, to the KDS service 305 using the KDS client interface 303 (which has, for example, the ExportDeviceMetadata API), where the metadata type may be, but is not limited to, plain text, formatted text, integer, decimal, image, video, or audio. The text may be any application-defined telemetry, status, or log message. In block 926, the KDS service 305 receives the device metadata, processes the received device metadata for the configured metadata connector and applies it to the specified filter, and sends the received device metadata, along with the filter and device identifier, to the webhook URL in an HTTP request (for example, as a POST request) or, for example, as a JSON payload. In block 928, the service provider's webhook processes the received device metadata as feature vectors for training an AI / ML model, and further intentionally applies methods, including but not limited to linear or logistic regression, neural networks, and decision trees for assessing, predicting, or analyzing cyber risk, threats to devices, or application security.In block 930, the KDS service 305 processes the response from the webhook and stores the received response in the device metadata repository. Furthermore, the response from the webhook may be forwarded by the KDS service 305 to the collaboration service specified in the response payload in order to trigger or execute an improvement action on the client device 100.

[0252] Tenant and group identifiers for pre-shared keys designated for specific purposes, such as document security or content signing, may be defined for extended scope (e.g., any tenant, any group). Key records in the source KDS may be configured to be exportable and importable in the destination KDS, using password-protected keys, encryption, and key encapsulation for secure exchange.

[0253] In yet another exemplary embodiment of the proposed method, a pre-shared key retrieved from a KDS may be used to generate a derived device key associated with a set of local device unique identifiers. One use case may be registering a device with a cloud-based device delivery service. Yet another use case may be signing or encrypting messages and / or authentication tokens to a cloud-based hub service. Cloud-based device management platforms and services require on-device local secure elements (e.g., TPM, HSM, SIM) to protect the pre-shared group key and derived device key. However, local secure elements may not be available for legacy, brownfield, or greenfield devices. Here, the innovation of the proposed method protects the pre-shared group key and derived device key not by requiring these keys to be stored locally, but by providing 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., device registration identifiers configured in the cloud service). Referring to Figure 5A, the client application 101 and the server application 151 may use a publish-subscribe messaging protocol (e.g., Message Queue Telemetry Protocol or MQTT, Advanced Message Queuing Protocol or AMQP) which may require the use of such a derived device key from a pre-shared group key and a unique device registration identifier on devices without a local secure element. Typical cloud services may be, for example, Microsoft Azure Device Provisioning Service (DPS) and IoT Hub, Amazon Web Services, or Google Cloud Device Provisioning and Hub Services.

[0254] In yet another exemplary embodiment of the proposed method, the Secure Shell (SSH) protocol can be extended to use pre-shared keys (PSKs) for client authentication. Today, SSH clients can use passwords, key pairs (e.g., RSA / DSA private-public keys), or X.509 certificates for data encryption / authentication by a remote SSH server. Thus, an SSH server can consist of user accounts, authorized keys, or trusted (root, intermediate, issuer) certificates for all remote users or device clients. Storing and managing authorized keys on a distributed SSH server is cumbersome and expensive. According to the proposed method, an SSH client can dynamically create a PSK for client authentication in a KDS and send a PSK identity hint to the SSH server to initiate PSK-based authentication. The SSH server can retrieve the PSK from the KDS using the received PSK identity hint. Multiple PSKs for client authentication are retrieved from the KDS by the SSH server just-in-time but do not need to persist / store locally on the server. SSH clients can create a PSK for one-time use for security reasons, or update the PSK (key rotation) based on a configured key duration. Therefore, an SSH server can be configured to store only authorized PSK identity hints, retrieve the associated PSK from the KDS just-in-time during connection establishment, and optionally cache the retrieved PSK locally in memory until key expiration. This approach eliminates the cumbersome and expensive SSH server management, key pair generation on remote client devices, and the transfer of public keys to the SSH server, automating key rotation with cryptographic agility orchestrated through the KDS. Today, RSA private keys are typically stored unprotected on SSH client devices when there is no local secure element. SSH clients can be configured to dynamically retrieve the PSK from the KDS when there is no local secure element, and not store the PSK locally on the device unprotected.

[0255] The authorization code issued to a legitimate OAuth 2.0 requester (i.e., a client application) is vulnerable to interception attacks by a malicious application residing alongside it. RFC 3676 describes a technique to mitigate the interception threat based on leveraging inter-application communication within the client's operating system using a Proof Key for Code Exchange (PKCE). In yet another exemplary embodiment of the proposed method, the requester may send a pre-shared key identity hint to the authorization server in a secure authorization request (e.g., over a TLS session) and receive an encrypted access token from the authorization server in a subsequent authorization acceptance request, the authorization server retrieving the pre-shared key associated with the received pre-shared key identity hint and performing the encryption. The received pre-shared key identity hint may further be included in an access token by the authorization server for the requester to sign the access token using the associated pre-shared key in a request to a service provider, the service provider retrieving the pre-shared key associated with the pre-shared key identity hint in the received access token and performing token validation.

[0256] In yet another exemplary embodiment of the proposed method, additional attributes of the authenticated member device may be discovered, and the system comprises a mobile application on a mobile device (dedicated device label scanner), a Device Discovery Service (DDS), a DHCP service, an OEM service, a Key Data System (KDS), and a member device having a device-unique label. Before or after onboarding a member device to the production network, a field operator can use the mobile application on a mobile device to scan a device label containing one or more of the following: a printed MAC address, a printed serial number (S / N), one or more printed barcodes, and a printed quick response (QR) code. The mobile application can send one or more of the scanned codes to the DDS or DHCP service. The DDS or DHCP service can receive device information corresponding to the scanned codes from the OEM service via outbound queries or inbound notifications. The member device can send a key request to the KDS. KDS can query DDS for device information based on a member UUID (e.g., MAC address or serial number) or query the DHCP service for custom vendor-specific options, and retain the retrieved device information for reference in subsequent key requests from member devices. Device information may include device type, manufacturer identifier, country of manufacture, model, MAC address, serial number, supported network types, supported network protocols, and license owner identifier. KDS can use the retrieved device information for policy-based authorization of key requests from member devices by comparing and matching the associated member device tenant identifier with the license owner identifier retrieved from DDS or the DHCP service.

[0257] Alternatively, a technician at the factory can use a mobile application to scan the device and send one or more scan codes to a DDS (Device Data Store) shared with the licensed device owner / operator before the device is shipped.

[0258] DDS can be hosted on-site or in the cloud (on the internet). DHCP servers can be hosted on the same network or on different subnets with relay agents for forwarding. Mobile applications can connect to DDS or DHCP services via wired or wireless networks. DDS and DHCP services can connect to multiple OEM services.

[0259] In one exemplary embodiment, the following are included: a Device Onboarder (DOB) mobile application running on a mobile device, a field technician, a field device, a Device Directory Service (DDS), a Key Distribution Service (KDS), a KDS portal, a KDS application programming interface, a KDS administrator, a pre-configured member pre-shared key (M-PSK) and 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 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, and a printed device having a device-unique immutable initial identifier on the field device issued by an Original Equipment Manufacturer (OEM). A method for device label scan-based zero-touch device onboarding in the initial power cycle is performed, including a label, an asset metadata datastore associated with the DDS, a Dynamic Host Configuration Protocol (DHCP) server, a DHCP administrator, a Domain Name System (DNS) server, a DNS administrator, an initial device identifier issued by the OEM mapped to the initial device IP address in DNS, a local device identifier issued by the device end user mapped to the local device IP address in DNS, a vendor class identifier associated with the device type, and a tenant identifier associated with the tenant network domain, wherein the method involves the KDS administrator importing a device label template for the device type associated with the field device, and the field technician synchronizing the device label template for the tenant identifier and the device type on the mobile device.Using a mobile device with a selected label template for the device type, a field technician scans the printed device label on the field device and generates a scan report; the field technician inspects the scan report on the mobile device and updates the scan report with extended device information; the field technician uploads the updated scan report from the mobile device to the DDS; the DDS stores the received scan report in the associated asset metadata data store; the DDS queries the DHCP server for vendor-specific device information about the vendor class identifier associated with the device type of the field device and stores it in the asset metadata data store; and the DD is listed as a member device in the KDS with associated device information in the asset metadata data store. This includes automatically configuring the field device using S, having the DHCP server create address (A) and pointer (PTR) records for the initial device identifier on the DNS server, having the DNS administrator configure address (A) and pointer (PTR) records for the local device identifier, as well as a canonical name (CNAME) record for mapping the local device identifier to the initial device identifier on the DNS server, and having the bootstrap application on the device register the field device with KDS during the field device's first power cycle using field device two-factor authentication with the initial device identifier and the factory default member pre-shared key, and then registering the field device with a member-unique pre-shared key using the KDS application programming interface for subsequent field device two-factor authentication.

[0260] The approach also includes the following additional methods:

[0261] The device label template includes, for each device identifier on the printed device label, at least a location ordinal number, a prefix, and a regular expression.

[0262] Scanning methods include optical character recognition (OCR) for text-based device identifiers, barcode scanning, and QR code scanning.

[0263] Examining the scan report involves at least manually configuring extended device information, including the field device type, tenant identifier, and network domain.

[0264] The scan report includes at least the MAC address, serial number, model, manufacturing location, device geolocation information, and a scanned image of the printed device label on the field device.

[0265] DHCP queries based on vendor-specific information such as vendor class identifiers may include manufacturer identification, country of manufacture, model, network type, network protocol, and license owner information associated with the field device type.

[0266] The creation of address (A) and pointer (PTR) records on the DNS server for the initial device identifier can be performed manually by the DHCP server administrator or dynamically using the Dynamic DNS (DDNS) protocol to interface with the DNS server.

[0267] Zero-touch device onboarding during the initial power cycle is achieved with field device two-factor authentication using a pre-configured factory default member pre-shared key (M-PSK), an M-PSK identity hint, and a member initial identifier, where the member initial identifier matches a pre-configured DNS hostname based on A and CNAME records.

[0268] The Device Onboarding Mobile Application (DOB) performs two-factor user authentication for field technicians in the tenant domain.

[0269] The Device Onboarding Mobile Application (DOB) performs two-factor device authentication in the tenant domain.

[0270] The Device Onboarding Mobile Application (DOB) communicates with the Device Directory Service (DDS) using an authenticated REST API along with an API key and an API token.

[0271] The API key and the API token can be pre-configured for the Device Onboarding Mobile Application (DOB) on the mobile device.

[0272] The API key and the API token can be dynamically retrieved by the Device Onboarding Mobile Application (DOB) from the KDS using the KDS application programming interface and device two-factor authentication.

[0273] The Device Onboarding Mobile Application (DOB) on the mobile device can generate a device label template for the printed device label based on the scanned label image and artificial intelligence (AI) based on an inference algorithm for ordinal numbers, prefixes, and regular expressions.

[0274] The QR code may be a manufacturer-configured URL for the device type that can be included as extended device information in the scan report for upstream processing in the DDS.

[0275] The disclosure system and methods involve zero-touch device onboarding during the device's initial power cycle in a production environment with device two-factor authentication, in order to configure and manage the lifecycle of device and application-level quantum security keys for secure communication through client authentication, data authentication, and data encryption via secure and insecure transport protocols.

[0276] In one exemplary embodiment of the proposed method, a Device Onboarder (DOB), which is a mobile application running on a mobile device (e.g., an Android or iOS smartphone or tablet), uses a label template to scan and process text, barcodes, and QR codes, identify the device's unique immutable initial identifier on a printed device label issued by an Original Equipment Manufacturer (OEM), discover the device, obtain device information, and store it in the DDS as asset metadata. The mobile device must be configured in the KDS as a member device by the IMEI and ICCID required in the device halo for two-factor authentication by the KDS. The DOB signs in with user two-factor authentication (e.g., using an Azure AD B2C single sign-on (SSO) user flow for tenants based on user policy and initial signing ceremony). The DOB securely communicates with the DDS running on the KDS via an authenticated REST API, using an API key (aka API secret) and API token to receive the device type and send device scan information. Key records for each mobile device must be configured in KDS based on the "Device Label Scanner" device group (private group type) with a member-unique identity hint. API keys and API tokens can be manually configured in DOB for mobile devices based on the "Device Label Scanner" device group. DOB can authenticate with device two-factor authentication using the KDSI API (with M-PSK and KDS authentication) and dynamically retrieve API keys and API tokens for member-unique identity hints manually configured in DOB for mobile devices based on the "Device Label Scanner" device group.

[0277] Label templates describe how unique identifiers appear on printed device labels. Template files (e.g., JSON) are uploaded to the KDS portal by service administrators / operators. An example of a label template is shown below. • [Identifier=MAC address]MAC:[Text|Barcode|QR code] • [Identifier = Serial Number] S / N: [Text | Barcode | QR Code] • [Identifier=Manufacturing Location]...Manufactured: [Text] • [Identifier=Model]Model:[Text] • [Identifier = Part Number] P / N: [Text | Barcode | QR Code]

[0278] A sample JSON label template is illustrated below. { "header": { "Version": "1.0", "Name": "SDO Label Temp" } "template": { "name": "sdo-template-001", "label": [ {"identifier": "Model", "type": "text", "ordinal": "1", "prefix': "Model:", "expression": "alphanumeric-string"}, {"identifier": "Manufacture Location", "type": "text", "ordinal": "2", "prefix": "Made in", "expression": "alphanumeric-string"}, {"identifier": "Part Number", "type": "text", "ordinal": "4", "prefix": "P / N:", "expression": "alphanumeric-string"}, {"identifier": "Part Number", "type": "barcode", "ordinal": "3", "prefix": "P / N:"}, {"identifier": "Serial Number", "type": "text", "ordinal": "4", "prefix": "S / N:", "expression": "alphanumeric-string"}, {"identifier": "Serial Number", "type": "qrcode", "ordinal": "4"}, {"identifier": "MAC Address", "type": "text", "ordinal": "5", "prefix": "MAC:", "expression": "xx:xx:xx:xx:xx:xx"}, {"identifier": "MAC Address", "type": "text", "ordinal": "5", "prefix": "MAC:", "expression": "xx xx xx xx xx xx"} ] } }

[0279] A sample scan report JSON is illustrated below. { "header": { "Version": "1.0", "Name": "SDO Label Scan Report" }, "report": { "template": "sdo-template-001", "technician": [ {"deviceType": "WiFi Access Point"}, {"localIdentifier": "wap-001"}, {"tenantIdentifier": "acme-apac"}, {"networkDomain": "acme.com"} ], "scanAnalysis": [ {"identifier": "Model", "ordinal": "1", "type": "text", "value": "DT2023"}, {"identifier": "Manufacture Location", "ordinal": "2", "type": "text", "value": "Taiwan"}, {"identifier": "Part Number", "ordinal": "3", "type": "barcode", "value": "MXC136501ET-TDGA"}, {"identifier": "Serial Number", "ordinal": "4", "type": "qrcode", "value": "TM1769T07437"}, {"identifier": "MAC Address", "ordinal": "5", "type": "text", "value": "549CC9271C06"}, {"image": "sdo-549CC9271C06-20230527.png"} ], "scanTranscript": { "ocrValues": { "numBlocks": "1", "blocks": [ { "numLines": "7", "lines": [ "Model: DT2023", "Manufacture Location: Taiwan", "Part Number: MXC136501ET-TDGA" "Serial Number: TM1769T07437", "MAC Address: 549CC9271C06", "Product Name: MX Thermostat" ] } ] }, "qrValues": { "numCodes": "1", "qrcodes": [ "Serial Number: TM1769T07437" ] } "bcValues": { "numCodes": "0", "barcodes": } } } }

[0280] Referring to Figure 3G, in step 363C, the KDS interface 303 sends a device hello to the KDS 305, the message including 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. In step 365, the KDS interface 303 sends a server challenge including at least a unique and random nonce value and a hash function specification, the service challenge is encrypted with the M-PSK associated with the received M-PSK identity hint 711. In step 366C, the KDS interface 303 generates a device response including the service challenge 352 and a hash output corresponding to the nonce and hash function specified in the member device ICCID, and sends it to the KDS 305, the device response is encrypted with the M-PSK. In step 367C, KDS305 validates the mobile member device by comparing and matching the locally calculated hash of the nonce and hash function specified in the service challenge 352 corresponding to the IMEI in device hello 363C and the ICCID (which has been manually pre-configured through the KDS portal for the member device) with the hash received from KDS interface 303.

[0281] Referring to Figures 1B, 1A, and 3A, in step 109, the technician 119 scans the printed device label 108 on device 108 using a mobile device 120 (e.g., an Android or iOS phone or tablet). Using a mobile application (i.e., DOB) 135, in step 132, the technician 119 manually specifies the device's tenant identifier, network domain, and device type information based on the scan 108. In step 110, the device label is scanned and processed using the device label template (for device 108) selected by the technician 119 in DOB 135. A scan report containing at least scanned and processed codes (text, barcode, QR code), geolocation information, and device information manually configured in step 132 is sent to the Device Directory Service (DDS) configured in the DOB 135 configuration. The scanning method uses optical character recognition (OCR), barcode analysis, and QR code analysis algorithms. The label template for device 108 includes at least the ordinal number, prefix, and regular expression (for location) required for each device identifier type (e.g., MAC address, serial number, manufacturer, manufacturing location, model, etc.). Technicians can examine the processed scan codes and compile a report to overcome any errors due to damaged or illegible printed device labels, or provide missing identifiers on the printed labels. In step 110, the DDS receives device type, MAC address, serial number, model, geolocation, manufacturer, manufacturing location (etc.) from DOB135 via a certified REST API to scale in the field and securely discover and onboard devices.DDS112 interfaces with KDS195 using local or remote procedure calls (LPC / RPC) or via a REST API, accessing the KDS database to retrieve, for example, configuration settings and label templates, and store label scan reports and device (asset) metadata. In step 114, DDS121 can query DHCP server 121 for vendor-specific custom options that can be configured on the DHCP server by the tenant, and the information may include the device manufacturer, country of manufacture, model, network type, network protocol, and license ownership information. In step 115, DHCP server 121 can use Dynamic DNS (DDNS) to create DNS A / PTR records for the device IP address and initial member identifier (e.g., in MAC address.networkdomain.com format). In step 117, the DNS server administrator 116 creates DNS A / PTR / CNAME records for the device IP address and local member DNS hostname configuration on DNS, where the CNAME points to the device local identifier for the device initial identifier. In step 118, an application running on device 108 (e.g., a bootstrap client or a line of business embedded main application) can issue key requests to KDS195 during device onboarding for device registration and during operation for the operational key.

[0282] The initial device identifier issued by the OEM is mapped in DNS to the initial device IP address (e.g., in a guest wireless network), and the local device identifier issued by the device end-user may be mapped in DNS to the local device IP address (e.g., in a secure wireless or wired network). Furthermore, the numerous IP addresses assigned to the device are appropriately configured in DNS with numerous A and PTR records. For dynamically assigned IP addresses, the DHCP server uses DDNS to update the DNS A / PTR records for the initial device identifier.

[0283] Referring to Figures 1C, 1A, and 3A, in step 131, the tenant administrator or operator 130 imports a device label template (e.g., a JSON file) and configures the device label template for the device type on the KDS portal 317. In step 134, the technician 119 downloads and installs the mobile application (i.e., DOB) 135 from the designated enterprise app store (133). In step 136, the technician 119 configures the settings for DOB 135, which include at least the KDS 195 server address, the API key and API token or key identity hint exclusively assigned to the DOB instance 135 on the mobile device 120 for the authenticated REST API, as well as the mobile device 120 IMEI and ICCID. DDS 112 can run together with KDS 195 on a single server. In step 138, DOB 135 synchronizes the device label template and device type by retrieving the tenant metadata configured in KDS 195 from DDS 112. In step 139, the technician 119 scans the printed device label on device 108, applying the appropriate extracted device label template for the device type. In step 140, the scan report is securely uploaded to DDS 112 via an authenticated REST API. In step 141, the device information from the scan report is stored in the asset metadata data store 142 on the KDS server.

[0284] In one exemplary embodiment, the system includes a content creator at the OEM, a content loader at the end-user facility, multiple 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 running on users or field devices, a first secure channel for two-factor user and device authentication-based creation and retrieval for multiple digitally signed 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 content file, an API key and API token associated with the content file, a content consumer field device, and an OEM application on the content consumer field device. A method for symmetric key-based digital signing for a gate-controlled workflow sequence for content creation, content verification, content inspection, content approval, and supply chain tamper resistance is performed from an original equipment manufacturer (OEM) to a device owner (end-user equipment). The method involves the content creator generating a digital signing key to generate a signature for a content file, the content creator generating a signature manifest file containing the digital signature for the content file, the content creator sending the content file and the generated signature manifest file to the device owner, the content loader verifying the signature for the received content file by the content loader, creating a digital signing key to generate a second signature for the content file, extending the received signature manifest file with the second signature, and the content loader sending a notification to the first content approver at the end-user equipment (device owner).The process involves inspecting content files by notified content approvers at end-user facilities (device owners) using multiple external third-party content inspection methods, creating digital signing keys to generate a third signature for the content files, extending the received signature manifest file with the third signature, sending notifications from the first content approver to the next content approver at the end-user facility (device owner) for further inspection, sending notifications from the final content approver to the policy manager (device owner) at the end-user facility to associate the content files with update policies, device types, and device groups, sending notifications from the policy manager to the field manager (device owner) at the end-user facility to publish the inspected and approved content files and extended signature manifest files to complete the managed content distribution workflow, and sending consumer field data to KDS to check for content updates. The process involves querying the OEM application on the device to retrieve the download URL / URI of the content file and extended signature file associated with the content identifier; downloading the content file and extended signature manifest file from the DDS to the OEM application on the consumer field device using the retrieved URL / URI; retrieving the digital signature key record for the tenant identifier, group identifier, and key identity hint in the extended signature manifest file from the KDS; verifying the content file, calculating a hash, generating a signature for the content file based on the retrieved key record specification, matching the calculated signature with the corresponding signature in the extended signature manifest file; installing the content file by the OEM application on the consumer field device using an OEM-specific update method; and state synchronization with the DDS associated with the KDS.This includes notifying the KDS of the update status on the device via the OEM application on the consumer field device.

[0285] The approach also includes the following additional methods:

[0286] Content files may, but are not limited to, software updates, configuration updates, or operating system (OS) updates.

[0287] The signing key for digital signatures is a symmetric key created and / or retrieved by a KDS portal user using two-factor authentication. Furthermore, key operations using tenant identifiers, group identifiers, and key identity hints are performed using KDS local procedure calls (LPCs), remote procedure calls (RPCs), or authenticated REST APIs.

[0288] The signing key for digital signatures is a symmetric key created and / or retrieved by an application on a KDS-registered member device using two-factor device authentication. Furthermore, key operations using tenant identifiers, group identifiers, and key identity hints are performed using the KDS application programming interface.

[0289] Digital signature keys are created and / or retrieved by KDS portal users and applications on member devices via a first secure channel (e.g., HTTPS or TLS session).

[0290] The content files are downloaded from the retrieved URL or URI by the OEM application on the consumer field device via a second secure channel (e.g., HTTPS or a TLS session).

[0291] Content files are inspected using external third-party content inspection methods, including but not limited to static analysis, dynamic analysis, sandboxing, anomaly detection, and reputation lists, based on the security profiles and threat model assessments of content approvers.

[0292] The content loader configures the received content and signature manifest file in the KDS portal, along with at least the content identifier (uniquely unique identifier), content timestamp, content version, content type, and content description.

[0293] An update policy configured by the policy manager may include at least the date and time of publication (not prior to publication), the day of the week, and the time range (from / to time of day) for scheduling content downloads.

[0294] The OEM application on the field device uses the KDS Application Programming Interface (API) to query for updates, retrieve the download URL / URI, verify the retrieved signature manifest file, and notify KDS of the update status for state synchronization.

[0295] The OEM application on the device installs the extracted content files using OEM-specific update methods, which include, but are not limited to, streaming HTTPS downloads without buffering to a flash memory partition on the device, or storing them in a file system on the flash data partition.

[0296] Verification of content files by content loaders, content approvers, and OEM applications on content consumer field devices includes retrieving digital signing key records for tenant identifiers, group identifiers, and key identity hints in the associated extended signature manifest file from the KDS, calculating hashes and signatures for the content files based on the key record specifications for each of the digital signing keys, and comparing the calculated signatures for the content files with the corresponding signatures in the extended signature manifest file.

[0297] Each digital signer in the OEM and end-user facilities of the content file can extend the signature manifest file using different key algorithms and key sizes for the digital signature key.

[0298] Retrieving content files using the retrieved URL / URI by an OEM application on a consumer field device via the second secure channel requires the use of an API key and API token uniquely associated with the content file retrieved via the first secure channel.

[0299] The disclosure system and method utilizes symmetric key-based multi-party content signing by the producer and one or more intermediaries, and multi-person digital signing. The digital signature (symmetric) key is retrieved out of band via a secure channel (in split mode, where the key is not transmitted with the signed content). The technique uses split mode, including a first secure channel for authentication-based creation and retrieval of multiple digital signature (symmetric) keys, and a second secure channel for content distribution (e.g., content files, signature manifest files). The technique further utilizes device two-factor authentication for content retrieval (without requiring PKI or device certificates) and gate-controlled workflow sequence-based multi-part content inspection, notification-based approval, and notification-based disclosure with duty-based role-based isolation, and multi-person signing rules (at least four digital signatures are recommended). Content approval is content inspection-based (and not simply based on user roles and privileges). External third-party content inspection methods (e.g., static analysis, dynamic analysis, sandboxing, anomaly detection, reputation lists) are based on the approver's security profile and threat model assessment. Authorized download URLs / URIs may be retrieved from the KDS by the OEM application with device two-factor authentication (i.e., not factory-embedded in the OEM's application) and hosted in the device owner's / operator's controlled environment.

[0300] In one exemplary embodiment of the proposed method, the Content Distribution Service (CDS) runs on the KDS server as a companion service with the KDS. Upon receiving a QueryUpdate device request, the CDS returns UPDATE-PENDING if the latest associated content timestamp / version is higher than the current content timestamp / version of the member device. Upon receiving a RetrieveUpdate device request, the CDS sends a download URL / URI of the published content (with API secret and API token) for the updater application on the device, initiates an authenticated REST API-based download over HTTPS to retrieve the content file and extended signature manifest, verifies the signature, and applies the OEM-specific update method. The CDS sets the update status of the member device in the KDS database to "-1: Retrieved". Upon receiving a NotifyUpdateStatus device request, the CDS sets the update status of the member device in the KDS database to (0: Complete, non-zero integer: Error (code)).

[0301] Actions on a pre-shared key (i.e., key instance 715), such as creation and retrieval, may be performed by an authorized application or utility running on an authenticated member device in two-factor device or user authentication within a tenant domain, or by an authenticated KDS portal (317) user (318). For authorized applications running on authenticated member devices (e.g., line-of-business applications or utilities), the device must be a direct member of the device group associated with the key record (709), or a member of a trusted group configured through the KDS portal (317) for the device group associated with the respective key record (709), or be qualified based on a configured inter-tenant community trust policy. For an authenticated user to perform key actions directly from the KDS portal (317), the user must be a member of a designated role-based user group (e.g., in the identity provider's authentication directory service). Furthermore, designated groups such as “Content Creators,” “Content Loaders,” and “Content Approvers” may be composed of tenant administrators or operators (318), and the group type is specified as “Optional.” The group type “Optional” 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 manifest or extended manifest files associated with content files. Authenticated users (318) of the tenancy can access the keys for content signing and verification through the KDS portal (317) and perform content creation, loading, inspection, and approval tasks in the proposed content distribution system workflow.

[0302] Referring to Figures 1D, 1A, and 3A, in step 143a, the producer 143 creates a signing key, and in step 143b, generates a content file and a signature manifest and sends them to the device owner (intermediary) 144. The key creation and signature manifest file generation in step 143a for content file signing can be achieved by a utility running on an authenticated device using the KDS interface (167) API, or by an authenticated user through the KDS portal (317). The producer (OEM) 143 takes on the role of content creator. In step 143c, the content file and signature manifest are shipped together to the device owner (intermediary) 144 (i.e., made available for import). In step 144b, the intermediary 144 receives and verifies the content file using the signature manifest file, and in step 144c, retrieves the key from KDS 195 using the key identity hint in the signature manifest for the associated content file. After verification, intermediary 144 creates a signing key for co-signing and extends the signing manifest in step 144c. In step 144b, the content loader assigns a content identifier (UUID), content timestamp, content version, content type, and content description from the KDS portal (317). Key creation and generation of the extended signing manifest file in step 144c for signing the content file can be achieved by a utility running on an authenticated device using the KDS interface (167) API, or by an authenticated user through the KDS portal (317). Intermediary 144 acts as the content loader (role). In step 144b, intermediary 144 finally notifies the first approver. The first approver inspects the content file using one or more external third-party content inspection methods, such as static analysis, dynamic analysis, sandboxing, anomaly detection, and reputation lists, based on the approver's security profile and threat model assessment.The approver can further extend the extended signature manifest using KDS195 and create a signing key. The approver notifies the next approver that additional content inspection methods may be guaranteed by another approver. Finally, the last approver in the chain notifies the policy manager to configure the update policy to associate the content file with a qualified consumer (device) 145, which is managed by the field manager. In step 144e, the policy manager notifies the field manager to publish the content to device 145. In step 145b, the OEM application 145a running on consumer (device) 145 queries KDS195 to check for content updates, and in step 145c, retrieves the download URLs and URIs (for content file and extended manifest file items) from KDS195 using the KDS interface (167) API for any pending content updates. In step 145d, the OEM application 145a downloads the content file and extended signature manifest from the retrieved URL / URI, verifies the signature by retrieving the key from the KDS 195 in step 145e using the key identity hint in the extended signature manifest file 831, and installs the verified content file using an OEM-specific update method (e.g., streaming the HTTPS download to a flash memory partition on the device without buffering, storing it in a file system on the flash data partition, or executing a custom shell script, helper application, or OS loader). In step 145f, the OEM application 145a notifies the KDS 195 of the update status (of the content identifier associated with the content update) for state synchronization. User notifications in intermediary 144 are generated from the KDS portal 317 and sent (e.g., as email or SMS to the recipient). Users in intermediary 144 are content loaders, content approvers, policy managers, and field managers.In step 146a, DDS146 interfaces with KDS195 using local or remote procedure calls (LPC / RPC), or via a REST API for workflow coordination and content (content files and manifests) management.

[0303] Referring to Figures 1E, 1A, and 3A, in step 175a, the content creator (i.e., a producer such as an OEM) 175 generates a content file (e.g., a software update, configuration update, or OS update that will be installed on a field device) and an associated signature manifest file with the creator's digital signature, and sends the generated content and signature manifest file to the content loader 176 (i.e., an intermediary such as the end user of the device). In step 176a, the content loader 176 imports the received content and signature manifest file, verifies the producer's digital signature, extends the manifest file with the content loader co-signature, and notifies the first content approver 177. In step 177a, the first content approver (in a chain of one or more content approvers) inspects the content file using one or more external third-party content inspection methods and extends the manifest file with the approver's digital signature. The final content approver notifies the policy manager 178. In step 178a, the policy manager 178 associates the content file with the update policy, device type, and (optionally) device group, and notifies the field manager 179. In step 179a, the field manager 179 publishes the inspected and approved content, completing the managed content distribution workflow.

[0304] Referring to Figures 7B, 1D, 1E, 3A, 8C, and 8D, in step 765, member device 701 is associated with device type 760. In step 766, the content file 762 and signature manifest file 819 (and extended signature manifest file 831) received from content creator 175 are imported by content loader 176 on KDS portal 317. Furthermore, in step 767, content loader 176 generates a content identifier 761 and associates it with content file 762, extended signature manifest file 831, generated API key 763, and generated API token 764. The generated API key 763 and API token 764 are unique for each content identifier and are sent to content consumer field device 145 during RetrieveUpdate device request processing by CDS 146. In step 767a, the content timestamp, content version, content type, and content description are transiently assigned to the content identifier 761 (associated with content file 762). In step 765, the download URL 771 is associated with the content identifier 761. In step 767b, the content URI 772 is associated with content file 762. In step 767c, the manifest URI 773 is associated with the extended signature manifest file 831. In step 768, the content identifier, content timestamp, content version, retrieval date / time, update status, and update history (list of content identifiers) are associated with member device 701 by CDS 146. In block 769, the list sequence of content identifiers (e.g., UUIDs) is associated with device type 760 based on the update policy configured by policy manager 178 (in step 178a). In step 770, if a QueryUpdate device request is received, the following content identifier (UUID) is returned by CDS146 based on the pending update for member device 701.The update history of member device 701 is updated by CDS146 when it receives a NotifyUpdateStatus device request (including a content identifier) ​​from member device 701.

[0305] In emerging automotive market segments, national standards (enacted or under consideration) regarding the right of vehicle owners to repairs and the right to fair and professional automotive industry repairs propose the issuance and use of vehicle, owner, and device certificates by certification authorities. Nevertheless, there are major implementation challenges for such an approach, including (a) requiring automotive manufacturers to build a private key infrastructure (PKI) with HSMs as a secure element, (b) requiring compliance with PKI certificate policies and certificate practice statements as a root certification authority for public / private trust, (c) requiring vehicle secure gateways and independent secondary market service applications to be redesigned for secure transport protocols and inactivity timeouts, (d) requiring private key protection by local secure elements, (e) requiring certification authorities to issue short-lived user certificates for technicians, (f) requiring interoperability with hybrid PKI systems, and (g) requiring post-quantum cryptography to strengthen the PKI to support a large number of cryptographic algorithms with large certificate sizes.

[0306] In yet another exemplary embodiment of the proposed method, applicable to numerous industry segments and systems (including automotive, aviation, transportation, manufacturing, healthcare, telecommunications, retail, and space), secure connectivity and data communication can be performed for a zero-trust networking architecture using KDS. A third-party secondary market service application running on an engineer device (e.g., a desktop / laptop computer or mobile device) uses the KDS interface API to retrieve (or create) a pre-shared key (PSK) from the KDS with a statically or dynamically generated PSK identity hint. The service application then sends the PSK identity hint to a secure gateway (SGW) service on the service device (e.g., a vehicle, controller, actuator, or sensor). The SGW service uses the KDS interface API to retrieve 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, if it matches, grants access to the service application. The SGW service and service application can then communicate using the pre-shared key over any security (e.g., DTLS, TLS), transport (UDP, TCP), or network protocol (e.g., Ethernet, Wi-Fi, Bluetooth) with data authentication and encryption (e.g., for telematics, maintenance, and diagnostics). The PSK is automatically rotated by the KDS based on the configured expiration timestamp.

[0307] In one exemplary embodiment of the proposed system and method, the KDS may be run as a microservices-based, highly available, vertically and horizontally scalable architecture that locally caches retrieved keys and DNS records for low-latency key operation, key distribution, and two-factor device authentication.

[0308] While exemplary embodiments have been described in terms of computing devices or instrumentation platforms, it is assumed that they can be performed by software on a microprocessor / general-purpose computer, such as the computer system 1000 illustrated in Figure 10. In various embodiments, one or more functions of various components may be performed by software that controls a computing device, such as the computer system 800 described below with reference to Figure 10.

[0309] The embodiments of the present disclosure shown in Figures 1 to 9, or any part or function thereof, may be implemented using hardware, software modules, firmware, non-temporary computer-readable media having instructions stored therein, or a combination thereof, and may be implemented in one or more computer systems or other processing systems.

[0310] Figure 10 illustrates a computer system 1000 in which embodiments or parts thereof of the present disclosure may be implemented as computer-readable code. For example, the network systems and architectures disclosed herein can be implemented in computer system 800 using hardware, software, firmware, non-temporary computer-readable media having instructions stored therein, or a combination thereof, and may be implemented in one or more computer systems or other processing systems. Hardware, software, or any combination thereof can embody any of the modules and components used to implement the architectures and systems disclosed herein.

[0311] When programmable logic is used, such logic can be executed on a commercially available processing platform or a special-purpose device. Those skilled in the art will recognize that embodiments of the subject matter of the disclosure can be implemented in a variety of computer system configurations, including multi-core multi-processor systems, minicomputers, mainframe computers, computers linked or clustered with distributed functions, and pervasive or miniature computers that can be embedded in virtually any device.

[0312] For example, at least one processor device and memory may be used to carry out the embodiments described above. The processor device may be a single processor, multiple processors, or a combination thereof. The processor device may have one or more processor "cores".

[0313] Various embodiments of the present invention will be described in reference to the computer system 1000 of this example. After reading this description, it will be apparent to those skilled in the art how the present invention may be implemented using other computer systems and / or computer architectures. While the operations may be described as sequential processes, some operations may actually be performed in parallel, simultaneously, and / or in a distributed environment, and in program code stored locally or remotely for access by single or multiprocessor machines. Furthermore, in some embodiments, the order of operations may be rearranged without departing from the spirit of the subject matter of the disclosure.

[0314] The processor device 1002 may be a special-purpose or general-purpose processor device. As will be recognized by those skilled in the art, the processor device 1002 may also be a single processor in a multicore / multiprocessor system, such a system operating alone or in a cluster of computing devices operating in a cluster or server farm. The processor device 1002 is connected to a communication infrastructure 1026, such as a bus, message queue, network, or multicore message passing scheme.

[0315] The computer system 1000 may include main memory 1004, such as random access memory (RAM), and secondary memory 1006. The secondary memory 1006 may include, for example, a hard disk drive 1008 or a removable storage drive 1010. The removable storage drive 1010 may include a floppy disk drive, a magnetic tape drive, an optical disk drive, flash memory, or the like.

[0316] The removable storage drive 1010 reads and writes to the removable storage unit 1012 in a well-known manner. The removable storage unit 1012 may include floppy disks, magnetic tapes, optical disks, etc., which are read and written to by the removable storage drive 1010. As will be recognized by those skilled in the art, the removable storage unit 1012 includes non-temporary computer-usable storage media storing computer software and / or data.

[0317] In alternative implementations, the secondary memory 1006 may include other similar means for enabling computer programs or other instructions to be loaded into the computer system 1000. Such means may include, for example, a removable storage unit 1016 and interface 1014. Examples of such means may include a program cartridge and cartridge interface (such as those found in video game devices), a removable memory chip (such as an EPROM or PROM) and its associated socket, as well as other removable storage units 1016 and interface 1014 that enable the transfer of software and data from the removable storage unit 1012 to the computer system 1000.

[0318] The computer system 1000 may also include a communication interface 1018. The communication interface 1018 enables the transfer of software and data between the computer system 1000 and external devices. The communication interface 1018 may include a modem, a network interface (such as an Ethernet card), a communication port, a PCMCIA slot and card, or similar. The software and data transferred via the communication interface 1018 may be in the form of signals, which may be electronic, electromagnetic, optical, or other signals capable of being received by the communication interface 1018. These signals may be provided to the communication interface 1018 via a communication path 1020. The communication path 1020 carries the signals and may be implemented using wires or cables, optical fibers, telephone lines, cellular phone links, RF links, or other communication channels.

[0319] The computer system 1000 may also include a computer display 1024 and a display interface 1022. According to the embodiment, the display used to display the GUI and dashboard for entities and relationships shown in Figure 7A above may be the computer display 1024, and the console interface may be the display interface 1022.

[0320] In this document, the terms “computer program medium,” “non-temporary computer-readable medium,” and “computer-usable medium” are used to generally refer to media such as the hard disks installed in the removable storage unit 1012, the removable storage unit 1016, and the hard disk drive 1008. Signals carried via the communication path 1020 can also embody the logic described herein. The computer program medium and computer-usable medium may also refer to memories such as the main memory 1004 and the secondary memory 1006, which may be memory semiconductors (e.g., DRAM). These computer program products are means for providing software to the computer system 1000.

[0321] The computer program (also called computer control logic) is stored in main memory 1004 and / or secondary memory 1006. The computer program may also be received via the communication interface 1018. When such a computer program is executed, it enables the computer system 1000 to implement the invention as discussed herein. In particular, when the computer program is executed, it enables the processor device 1002 to execute the processes of the invention, such as the stages in the methods illustrated by the flowcharts in Figures 3A-3E, 5A-5D, 6, 7, 8A-8D, and 9 discussed above. Thus, such a computer program represents the controller of the computer system 1000. When the invention is implemented using software, the software is stored in the computer program product and can be loaded into the computer system 1000 using a removable storage drive 1010, interface 1014, and hard disk drive 1008, or the communication interface 1018.

[0322] Embodiments of the present invention may also cover computer program products comprising software stored on any computer-readable medium. When such software is executed on one or more data processing devices, it causes the data processing devices to operate as described herein. Embodiments of the present invention employ any computer-readable or computer-readable medium. Examples of computer-readable media 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, nanotechnology storage devices, etc.), and communication media (e.g., wired and wireless communication networks, local area networks, wide area networks, intranets, etc.).

[0323] In a particular exemplary embodiment of the disclosure system, group account numbers may be assigned to enterprise business units for role-based control for members of the group.

[0324] In an alternative embodiment of the disclosed system, the service sign-in ceremony may be achieved without requiring a service agent (by the service provider) through a plugin loaded by a client application (e.g., a web browser), the service being accessed is authenticated based on a server certificate, and the encrypted password extracted from the user token is used by the client application plugin to complete the authentication ceremony. Therefore, the digitally signed service identifier in the user token request is optional.

[0325] In an alternative embodiment of the disclosed system, a method is performed for configuring, generating, issuing, sending, and verifying a client certificate to the first device 100 used for client authentication between applications running on distributed devices, including a client application 101 running on the first device 100, a server application 151 running on the 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, an 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 321, the method includes a vendor class identifier, scope, and The process involves configuring a dress pool as an IP address range or subnet in DHCP service 172, configuring a certificate template, a Certificate Authority (CA) 398 identifier, a first device 100, a device group 705, and a device type in KDS portal 317, configuring a first device 101 in KDS portal 317 with the device type, configuring the first device as a member of device group 705 in KDS portal 317, receiving a request for a client certificate from the first device at the IP address for the subject name (SN) set as the first device local identifier via key distribution service 305, generating a certificate signing request (CSR) with the received subject name (SN) via key distribution service 305, and automatically adding X.509 extended attributes in the subject alternative name (SAN), wherein the extended attributes include the first device IP address, network address, and network mask in the certificate template associated with the device group or device type of the first device.The first device initial identifier associated with the first device local identifier is automatically added, set in the received SN; a client certificate is issued by the key distribution service 305 and sent to the first device; authentication is performed by the key distribution service 305 by the client application 101 running on the first device 100 using the tenant identifier 735, symmetric KDS member (M-PSK) 715, and M-PSK identity hint 711, wherein the first device 100 is registered by the first DNS hostname 722 in the DNS service 321 configured in KDS 305 or KDS proxy 602, and the first device 100 is registered as a member device in KDS 305; and at least the trusted certificate, client certificate, and associated private key are sent from KDS 305 to the client application 101 on the first device 100 using the tenant identifier 735 of the trusted certificate and the subject name of the client certificate. Acquiring a client certificate and associated private key, which are used in certificate-based client authentication for mutual authentication via a secure transport protocol during communication with a server application 151 running on a second device 150, or in data signing by digital signature, or in key unwrapping; initiating a secure session using a security protocol by the client application 101 on the first device 100, which is initiated using the acquired client certificate and associated private key for certificate-based client authentication to establish secure communication with the server application 151 running on the second device 150; and sending the client certificate to the server application 151 on the second device 150 during the protocol handshake for client authentication by the client application 101 on the first device 100.This includes validating the client certificate based on the X.509 extended attribute in the Subject Alternative Name (SAN) field of the received client certificate by having the server application 151 on the second device 150 verify the IP address or subnet of the first device 100, and granting authorization to the client certificate by the server application 151 on the second device 150 if the host address or network subnet in the received client certificate matches the IP address or subnet of the first device 100, respectively, in order to continue the protocol-specific authentication handshake for client authentication.

[0326] The approach further includes the following: A device member authentication handshake is performed by the client KDS interface 303 on the first device 100 using the tenant identifier 735, device member PSK (M-PSK) 715, and M-PSK identity hint 711 as the first factor of device authentication; a session key is generated using a key exchange handshake between the client KDS interface 303 and KDS 305 or KDS proxy 602; and device member validation is performed as a second factor of device authentication by performing a DNS reverse lookup of the device member IP address by KDS 305 or KDS proxy 602 to query the first DNS hostname; retrieving the first DNS hostname from the resource record in the DNS response by KDS 305 or KDS proxy 602; and comparing and matching the retrieved first DNS hostname with the device member identifier in multiple KDS requests by KDS 305 or KDS proxy 602.

[0327] Device authentication and the exchange of multiple certificates and keys are performed via connectionless UDP or connection-oriented TCP transport protocols without requiring a security transport protocol.

[0328] Verification by the server application 151 on the second device 150 may be performed by the presence of a single X.509 extension attribute (e.g., IP.1=192.168.10.19) in the received client certificate as a host address in order to match it with the IP address of the first device 100 in the protocol authentication handshake.

[0329] The IP address validation of the first device 100 is performed by the KDS proxy 602 based on the scope of the vendor class identifier and the address pool configured in the DHCP service 172.

[0330] Verification by the server application 151 on the second device 150 may be performed by the presence of two X.509 extension attributes in the received client certificate, which are the network address and network mask (e.g., IP.1=192.168.10.0, IP.2=255.255.255.0), respectively, in order to match the subnet address of the first device 100 in the protocol authentication handshake.

[0331] The subnet address validation of the first device 100 is performed based on the scope and address pool of the vendor class identifier configured in the DHCP service 172.

[0332] Verification by the server application 151 on the second device 150 may be performed by the presence of three X.509 extended attributes (e.g., IP.1=192.168.10.19, IP.2=192.168.10.0, IP.3=255.255.255.0) as host address, network address, and network mask, respectively, in order to match the host address and subnet address of the first device 100 in the protocol authentication handshake.

[0333] The client certificate may be a self-signed certificate or a certificate issued by a trusted public or private certificate authority.

[0334] Before sending the client certificate to the first device 100, the application identifier 742 received in the request from the client application 101 to the KDS 305 for retrieving the client certificate is verified by the KDS 305 to validate that the client application 101 on the first device 100 is configured as a trusted application on the KDS portal 317.

[0335] Verification by the server application on the second device may be performed by the presence of numerous pairs of X.509 extended attributes, each pair specifying a network address and network mask to be matched with the host address and subnet address of the first device 100 in the protocol authentication handshake.

[0336] In the protocol authentication handshake, matching by subnet address of the first device 100 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 the calculated value of the logical AND operation is compared with the network address in the received client certificate.

[0337] Device metadata Device metadata is defined as name-value pairs. Device metadata::Metadata identifier metadata value

[0338] Metadata types are tagged with metadata names. Metadata-identifier::metadata name:metadata type Metadata Type:: Text (Plain) | Text (Formatted) | Number (Integer) | Number (Decimal) | Image | Video | Audio

[0339] The default metadata type is implicitly text (plain).

[0340] Metadata values ​​are string objects. The following are typical examples of metadata identifiers and metadata values ​​that may be sent to the KDS service 305 by the client application 101.

[0341] [Table 1]

[0342] In one exemplary embodiment, a method is performed for configuring multiple metadata connectors on a KDS portal 317. The method includes authenticating a client device with a KDS service 305 or a KDS proxy 602 using two-factor authentication. The method further includes sending device metadata, including metadata identifiers, metadata types, and metadata values, to the KDS service 305 by a client application 101 on a client device 100 using a client KDS interface 303 (e.g., having an ExportDeviceMetadata API). The method further includes receiving the device metadata with the KDS service 305 and processing the received device metadata for the configured metadata connectors. The method further includes sending the received device metadata to a webhook URL and processing the received device metadata by a service provider's webhook.

[0343] The approach further includes the following: The metadata connector includes at least the service provider name, filter type, filter name, webhook specified as a generic resource locator (URL), API token, API secret, and filter measure specified as a list of metadata types and metadata identifiers, where the filter type is specified as a device type or device group 705.

[0344] The exported device metadata includes a metadata identifier, a metadata type, and a metadata value, the metadata type may be, but is not limited to, plain text, formatted text, integers, decimals, images, videos, or audio.

[0345] The metadata type, whether plain text or formatted text, can be any application-defined telemetry, status, or log message.

[0346] The filters configured for the metadata connector 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 scale, as well as the associated device member identifiers of the client device 100 (member UUID 731, member identifier 703, member DNS hostname 722), are sent to the webhook URL in an HTTP request (e.g., as a JSON payload) (e.g., as a POST request).

[0347] The received device metadata is processed by the service provider's webhooks as feature vectors for training AI / ML models, and further processed by intentionally applying methods including, but not limited to, linear or logistic regression, neural networks, and decision trees for assessing, predicting, or analyzing cyber risks, threats to devices, or application security.

[0348] 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, facial recognition based on reported images, determination of the authenticity of reported images, videos, or audio (e.g., genuine, deepfake), or suggested mitigation actions based on reported status or log text messages from client device 100. The response from the webhook may be forwarded by the KDS service 305 to the collaboration service specified in the response payload in order to trigger or execute the mitigation action on client device 100.

[0349] knot It should be recognized that the detailed description section, rather than the summary and abstract section, is intended to be used to interpret the claims. The summary and abstract section may describe one or more exemplary embodiments of the invention, rather than all of the invention as envisioned by the inventor, and is therefore never intended to limit the scope of the invention and the appended claims.

[0350] Embodiments of the present invention have been described above with the assistance of function building blocks illustrating implementations of specified functions and their relationships. The boundaries of these function building blocks have been arbitrarily defined herein for the convenience of description. Alternative boundaries can be defined as long as the specified functions and their relationships are adequately implemented.

[0351] The foregoing description of specific embodiments will thus fully reveal the general nature of the invention that others, by applying the knowledge of those skilled in the art, can readily modify and / or adapt such specific embodiments for various uses without departing from the general concept of the invention or without conducting unnecessary experimentation. Such adaptations and modifications are therefore intended to be within the meaning and scope of equivalent embodiments of the disclosures based on the teachings and guidance presented herein. It should be understood that the terminology or technical terms used herein are for illustrative purposes only, not limitation, and therefore should be interpreted by those skilled in the art in terms of the teachings and guidance.

[0352] Although the present invention has been illustrated and described herein with reference to specific embodiments, the invention is not intended to be limited to the details shown. Rather, various modifications can be made in detail within the scope and range of the equivalent claims and without departing from the invention.

Claims

1. A method for generating, distributing, and managing the lifecycle of a symmetric pre-shared key (PSK) (C-PSK) used in client authentication between applications running on distributed devices, including a client application running on a client device, a server application running on a server device, a Key Distribution Service (KDS), a KDS proxy, a KDS interface, a symmetric KDS member PSK (M-PSK), an 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, A step of authenticating with the KDS by the client application running on the client device using the tenant identifier, the symmetric KDS member PSK (M-PSK), and the M-PSK identity hint, wherein the client device is registered by a first DNS hostname on the DNS server configured with the KDS or the KDS proxy, and the client device is configured as a first member of a device group in the KDS. A step of obtaining the C-PSK from the KDS by the client application using at least the group identifier and the C-PSK identity hint, wherein the C-PSK is used as a shared symmetric key for client authentication over a secure transport protocol during communication with the server application running on the server device, the server device is registered by a second DNS hostname on the DNS server, and the server device is configured as a second member of the device group in the KDS. A step of authenticating with the KDS by the server application running on the server device using the tenant identifier, the symmetric KDS member PSK (M-PSK), and the M-PSK identity hint, wherein the server device is registered by a second DNS hostname on the DNS server configured with the KDS or the KDS proxy. A step of obtaining the C-PSK from the KDS by the server application using at least the group identifier and the C-PSK identity hint, wherein the C-PSK is used as the shared symmetric key for client authentication via the secure transport protocol during communication with the client application running on the client device, and the client device is registered with the DNS server by a first DNS hostname, A step of initiating a TLS-PSK session by the client application, wherein the session is initiated using the acquired C-PSK for the client device in the device group as the PSK used in client authentication to establish secure communication with the server application running on the server device; A step of updating the C-PSK programmatically and automatically by the client application and the server application using the KDS interface without requiring human intervention and without service interruption, wherein further client authentication is performed upon expiration or fast key rotation is performed. Methods that include...

2. A device member authentication handshake is performed by the KDS interface on the client device and the server device, using the tenant identifier, the device member PSK (M-PSK), and the M-PSK identity hint as the first factor of device authentication; further, a session key is generated using a key exchange handshake between the KDS interface and the KDS or the KDS proxy; and further, device member validation is performed. The steps include performing a DNS reverse lookup of the device member IP address by the KDS or the KDS proxy in order to query the first DNS hostname, The steps include: extracting the first DNS hostname from the resource record in the DNS response using the KDS or the KDS proxy; The steps include comparing and matching the extracted first DNS hostname with the device member identifiers in multiple KDS requests using the KDS or the KDS proxy. The method according to claim 1, which is performed as a second factor of the device authentication.

3. The method according to claim 2, wherein the device authentication and multiple key exchange handshakes are performed via a connectionless UDP or connection-oriented TCP transport protocol without requiring a security transport protocol, and further, data authentication and / or data encryption are performed using the retrieved pre-shared key with any communication protocol.

4. The method according to claim 1, wherein the KDS interface provides a plurality of application programming interfaces (APIs), and the client application and the server application directly send a plurality of requests for key operations to the KDS and directly receive a plurality of responses for key operations from the KDS, or the client application and the server application indirectly send a plurality of requests for key operations through the KDS proxy and indirectly receive a plurality of responses for key operations through the KDS proxy.

5. The method according to claim 1, wherein the client device and the server device are registered in the IP address (A) record and PTR record used for DNS hostname reverse lookup by a unique DNS hostname in the domain on the local DNS server, respectively.

6. The method according to claim 1, wherein in the KDS, the client device and the server device are configured as members of a tenancy associated with the tenant identifier and the device group associated with the tenant identifier, and the device group is further configured as a key record including a key instance used for client authentication.

7. The method according to claim 1, wherein the key record configured for the device group in the KDS includes a key expiration timestamp and a key status for managing automatic key renewal, key rotation, and key revocation operations in the KDS.

8. The method according to claim 1, wherein the key record configured for the device group in the KDS includes a key token, and the client application sends 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 furthermore, the API request may be a REST API request.

9. The method according to claim 1, wherein a request from an authenticated member device for any key action based on the group identifier and the C-PSK identity hint is processed by the KDS and permitted based on a match of the member domain with a domain name and a plurality of top-level domain suffixes derived from a plurality of resource records retrieved by a DNS reverse lookup of the member device DNS hostname.

10. The method according to claim 1, wherein a request from an authenticated member device for any key action based on the group identifier, the C-PSK identity hint, and the application identifier is processed by the KDS and permitted based on a match with the application identifier associated with the group identifier, and the KDS is configured to allow or reject the key action.

11. The method according to claim 1, wherein device-specific information configured as extended custom attributes of member devices is retrieved from a DHCP server using a plurality of extended KDS interface APIs to automate local device configuration and export vendor-specific member device information to the KDS.

12. The method according to claim 1, wherein a request from an authenticated member device for any key action based on the group identifier and the C-PSK identity hint is processed by the KDS and granted based on a match of the member device tenant identifier with an associated license owner identifier retrieved from the DHCP server as vendor-specific member device information.

13. The method according to claim 1, wherein a device-unique C-PSK identity hint may be generated by the client application to create a device-unique PSK for client authentication using a device-unique registration identifier and a derivation function.

14. A method for generating, distributing, and managing the lifecycle of a symmetric pre-shared key (PSK) used in secure communication for use between applications running on distributed devices (S-PSK), comprising a client application running on a client device, a server application running on a server device, a Key Distribution Service (KDS), a KDS proxy, a KDS interface, a symmetric KDS member M-PSK, an 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, an 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, A step of authenticating with the KDS by the client application running on the client device using the tenant identifier, the symmetric KDS member PSK (M-PSK), and the M-PSK identity hint, wherein the client device is registered by a first DNS hostname on the DNS server configured with the KDS or the KDS proxy, and the client device is configured as a first member of a device group in the KDS. A step of obtaining the S-PSK from the KDS by the client application using at least the group identifier and the S-PSK identity hint, wherein the C-PSK is used as a shared symmetric key to secure communication over an insecure transport protocol during communication with the server application running on the server device, the server device is registered by a second DNS hostname on the DNS server, and the server device is configured as a second member of the device group. A step of authenticating with the KDS by the server application running on the server device using the tenant identifier, the symmetric KDS member PSK (M-PSK), and the M-PSK identity hint, wherein the server device is registered by a second DNS hostname on the DNS server configured with the KDS or the KDS proxy. A step of obtaining the S-PSK from the KDS by the server application using at least the group identifier and the S-PSK identity hint, wherein the S-PSK is used as the shared symmetric key for securing communication over the insecure transport protocol during communication with the client application running on the client device, and the client device is registered by a first DNS hostname on the DNS server. The steps include: protecting the authenticity and / or confidentiality of data during communication with the server application running on the server device via an insecure connectional or connectionless transport protocol by the client application running on the client device using the acquired S-PSK; The steps include: protecting the authenticity and / or confidentiality of data during communication with the client application running on the client device via the insecure connection-oriented or connectionless transport protocol by the server application running on the server device using the acquired S-PSK; A step of updating the S-PSK programmatically and automatically by the client application and the server application using the KDS interface without requiring human intervention and without service interruption, wherein further client authentication is performed upon expiration or fast key rotation is performed. Methods that include...

15. The method according to claim 14, wherein a device member authentication handshake is performed by the KDS interface on the client device and the server device, using the tenant identifier, the device member PSK (M-PSK), and the M-PSK identity hint as a first factor of device authentication; further, a session key is generated using a key exchange handshake between the KDS interface and the KDS or the KDS proxy; further, device member validation is performed as a second factor of device authentication, comprising the steps of: performing a DNS reverse lookup of the device member IP address by the KDS or the KDS proxy to query a DNS hostname; retrieving the first DNS hostname from the resource record in the DNS response by the KDS or the KDS proxy; and comparing and matching the retrieved first DNS hostname with the device member identifier in a plurality of KDS requests by the KDS or the KDS proxy.

16. The method according to claim 14, wherein the device authentication and multiple key exchange handshakes are performed via a connectionless UDP or connection-oriented TCP transport protocol without requiring a security transport, and further, data authentication and / or data encryption are performed via any communication protocol using the retrieved pre-shared key.

17. The method according to claim 14, wherein the KDS interface provides a plurality of application programming interfaces (APIs), and the client application and the application directly send a plurality of requests for key operations to the KDS and directly receive a plurality of responses for key operations from the KDS, or the client application and the server application indirectly send a plurality of requests for key operations through the KDS proxy and indirectly receive a plurality of responses for key operations through the KDS proxy.

18. The method according to claim 14, wherein the client device and server device are registered in the IP address (A) record and PTR record used for DNS hostname reverse lookup by a unique DNS hostname in the domain on the local DNS server, respectively.

19. The method according to claim 14, wherein in the KDS, the client device and the server device are configured as members of a tenancy associated with the tenant identifier and the device group associated with the tenant identifier, and the device group is further configured as a key record including a key instance used to secure communication between the client application and the server application.

20. The method according to claim 14, wherein the key record configured for the device group in the KDS includes a key expiration timestamp and a key status for managing automatic key renewal, key rotation, and key revocation operations in the KDS.

21. The method according to claim 14, wherein, prior to the client application obtaining the S-PSK from the KDS, the S-PSK is created in the KDS by the server application on the server member device and with restricted key usage permissions for data authentication, data encryption, content signing, broadcast signing, broadcast encryption, multicast signing, multicast encryption, token signing, or token encryption operations.

22. The method according to claim 14, wherein the acquisition of the S-PSK from the KDS by the client application restricts key usage based on permissions configured by the key creator.

23. The method according to claim 14, wherein the key record configured for the device group in the KDS includes the key token for the client application to send authenticated API requests to the server application, using the key instance as an API shared secret and the key token as an API shared token, and further, the API request may be a REST API request.

24. The method according to claim 14, wherein a request from an authenticated member device for any key action based on the group identifier and the S-PSK identity hint is processed by the KDS and permitted based on a match between the member domain and a domain name and a plurality of top-level domain suffixes derived from a plurality of resource records retrieved by a DNS reverse lookup of the member device DNS hostname.

25. The method according to claim 14, wherein a request from an authenticated member device for any key action based on the group identifier, the S-PSK identity hint, and the application identifier is processed by the KDS and permitted based on a match with the application identifier associated with the group identifier, and the KDS is configured to allow or reject the key action.

26. The method according to claim 14, wherein device-specific information configured as extended custom attributes of member devices is retrieved from a DHCP server using a plurality of extended KDS interface APIs to automate local device configuration and export vendor-specific member device information to the KDS.

27. The method according to claim 14, wherein a request from an authenticated member device for any key action based on the group identifier and the S-PSK identity hint is processed by the KDS and authorized based on a match of the member device tenant identifier with an associated license owner identifier retrieved from the DHCP server as vendor-specific member device information.

28. The method according to claim 14, wherein a derived device key (D-PSK) is created locally just in time on demand, but does not have to be stored locally, using the extracted S-PSK and device unique identifier as the registration identifiers for the client and server applications, in order to sign and / or encrypt messages or tokens about data authentication and / or secrets.

29. A method for generating, distributing, and managing the lifecycle of a symmetric pre-shared key (PSK) used in client authentication (C-PSK) between applications running on distributed mobile devices, comprising: a client application running on a client mobile device; a server application running on a server device; a Key Distribution Service (KDS); a KDS proxy; a KDS interface; a symmetric KDS member PSK (M-PSK); an 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 Domain Name System (DNS) server; a Device Directory Service (DDS); and a Mobile Service Provider (MSP) server, A step of authenticating with the KDS by the client application running on the client mobile device using the tenant identifier, the symmetric KDS member PSK (M-PSK), and the M-PSK identity hint, wherein the client mobile device is registered with an International Mobile Subscriber Identification Number (IMSI) on the MSP server configured with the KDS or the KDS proxy, and the client mobile device is configured as a first member of a device group in the KDS. A step of obtaining the C-PSK from the KDS by the client application using at least the group identifier and the C-PSK identity hint, wherein the C-PSK is used as a shared symmetric key for client authentication via a secure transport protocol during communication with the server application running on the server device, the server device is registered by a DNS hostname on the DNS server, and the server device is configured as a second member of the device group in the KDS. A step of authenticating with the KDS by the server application running on the server device using the tenant identifier, the symmetric KDS member PSK (M-PSK), and the M-PSK identity hint, wherein the server device is registered by the DNS hostname on the DNS server configured with the KDS or the KDS proxy. A step of obtaining the C-PSK from the KDS by the server application using at least the group identifier and the C-PSK identity hint, wherein the C-PSK is used as a shared symmetric key for client authentication over the secure transport protocol during communication with the client application running on the client device, and the client device is registered with the DNS server by its DNS hostname. A step of initiating a TLS-PSK session by the client application, wherein the session is initiated using the acquired C-PSK for the client mobile device in the device group as the PSK used in client authentication in order to establish secure communication with the server application running on the server device. The steps include updating the C-PSK programmatically and automatically by the client application and the server application using the KDS interface without requiring human intervention and without service interruption, and Methods that include...

30. A mobile device member authentication handshake is performed by the KDS interface on the client mobile device, using the tenant identifier, the symmetric KDS member PSK (M-PSK), and the M-PSK identity hint as the first factor of device authentication; further, a session key is generated using a key exchange handshake between the KDS interface and the KDS or the KDS proxy; and further, device member validation is performed. The KDS receives the integrated circuit card identifier (ICCID), International Mobile Equipment Identification Number (IMEI), and IMSI information of the client mobile device from the client mobile device. A step of sending a nonce for signing by the SIM on the client mobile device using the authentication key securely stored in the SIM to the client mobile device by the KDS, wherein the storage location is in a card circuit device or on an applet on the SIM, The steps include receiving the signed nonce from the client mobile device via the KDS, The KDS sends the nonce and IMSI for signing using the associated authentication key of the mobile device to the mobile service provider of the client mobile device, The steps include: authenticating the client mobile device with the KDS by comparing and matching the client mobile device with the signed nonce received from the mobile service provider in order to authenticate and validate the client mobile device; The method according to claim 29, which is performed as a second factor of the device authentication.

31. A device member authentication handshake is performed by the KDS interface on the server device using the symmetric KDS member PSK (M-PSK) and M-PSK identity hint, and the session key is generated using a key exchange handshake between the KDS interface and the KDS or the KDS proxy, and device member validation is performed, The steps include performing a DNS reverse lookup of the device member IP address by the KDS or the KDS proxy in order to query the DNS hostname, The steps include: extracting the DNS hostname from the resource record in the DNS response using the KDS or the KDS proxy; The steps include comparing and matching the extracted DNS hostname with the device member identifier in multiple KDS requests using the KDS or the KDS proxy. The method according to claim 29, as implemented by [the present invention].

32. The method according to claim 31, wherein the device authentication and multiple key exchange handshakes are performed via a connectionless UDP or connection-oriented TCP transport protocol without requiring a security transport protocol, and further, data authentication and / or data encryption are performed with the retrieved pre-shared key using any communication protocol.

33. The method according to claim 29, wherein the KDS interface provides a plurality of application programming interfaces (APIs), and the client application and the server application directly send a plurality of requests for key operations to the KDS and directly receive a plurality of responses for key operations from the KDS, or the client application and the server application indirectly send a plurality of requests for key operations through the KDS proxy and indirectly receive a plurality of responses for key operations through the KDS proxy.

34. The method according to claim 29, wherein the server device is registered in the IP address (A) record and PTR record used for DNS hostname reverse lookup by a unique DNS hostname in the domain on the local DNS server.

35. The method according to claim 29, wherein in the KDS, the client device and the server device are configured as members of a tenancy associated with the tenant identifier and the device group associated with the tenant identifier, and the device group is further configured as a key record including a key instance used for client authentication.

36. The method according to claim 29, wherein the key record configured for the device group in the KDS includes a key expiration timestamp and a key status for managing automatic key renewal, key rotation, and key revocation operations in the KDS.

37. The method according to claim 29, wherein the key record configured for the device group in the KDS includes a key token, and the client application sends 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 furthermore, the API request may be a REST API request.

38. The method according to claim 29, wherein a request from an authenticated member device for any key action based on the group identifier and the C-PSK identity hint is processed by the KDS and permitted based on a match between the member domain and a domain name and a plurality of top-level domain suffixes derived from a plurality of resource records retrieved by a DNS reverse lookup of the member device DNS hostname.

39. The method according to claim 29, wherein a request from an authenticated member device for any key action based on the group identifier, the C-PSK identity hint, and the application identifier is processed by the KDS and permitted based on a match with the application identifier associated with the group identifier, and the KDS is configured to allow or reject the key action.

40. The method according to claim 29, wherein a request from an authenticated member device for any key action based on the group identifier and the C-PSK identity hint is processed by the KDS and authorized based on a match of the member device tenant identifier with an associated license owner identifier retrieved from the DDS as vendor-specific member device information.

41. The method according to claim 29, wherein a device-unique C-PSK identity hint is generated by the client application to create a device-unique PSK for client authentication using a device-unique registration identifier and a derived function.

42. A method for generating, distributing, and managing the lifecycle of a symmetric pre-shared key (PSK) used in secure communication for use between applications running on distributed mobile devices (S-PSK), comprising a client application running on a mobile device, a server application running on a server device, a Key Distribution Service (KDS), a KDS proxy, a KDS interface, a symmetric KDS member M-PSK, an 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, an S-PSK identity hint, a derived device key (D-PSK), a key record, a Device Directory Service (DDS), and a mobile service provider (MSP) server, A step of authenticating with the KDS by the client application running on the mobile device using the tenant identifier, the symmetric KDS member PSK (M-PSK), and the M-PSK identity hint, wherein the mobile device is registered with a first International Mobile Subscriber Identification Number (IMSI) on the MSP server configured with the KDS or the KDS proxy, and is configured as a first member of a device group in the KDS. A step of obtaining the S-PSK from the KDS by the client application using at least the group identifier and the S-PSK identity hint, wherein the C-PSK is used as a shared symmetric key to secure communication over an insecure transport protocol during communication with the server application running on the server device, the server device is registered by a second International Mobile Subscriber Identification Number (IMSI) on the MSP server, and the server device is configured as a second member of the device group. A step of authenticating with the KDS by the server application running on the server device using the tenant identifier, the symmetric KDS member PSK (M-PSK), and the M-PSK identity hint, wherein the server device is registered with a second International Mobile Subscriber Identification Number (IMSI) on the MSP server configured with the KDS or the KDS proxy. A step of obtaining the S-PSK from the KDS by the server application using at least the group identifier and the S-PSK identity hint, wherein the S-PSK is used as the shared symmetric key for securing communication over the insecure transport protocol during communication with the client application running on the client mobile device, and the client mobile device is registered with a first International Mobile Subscriber Identification Number (IMSI) on the MSP server, The steps include: protecting the authenticity and / or confidentiality of data during communication with the server application running on the server device via an insecure connectional or connectionless transport protocol by the client application running on the mobile device using the acquired S-PSK; The steps include: protecting the authenticity and / or confidentiality of data in communication with the client application running on the mobile device via the insecure connection-oriented or connectionless transport protocol by the server application running on the server device using the acquired S-PSK; The steps include updating the S-PSK programmatically and automatically by the client application and the server application using the KDS interface without requiring human intervention and without service interruption, and Methods that include...

43. A device member authentication handshake is performed by the KDS interface on the client device and the server device, using the tenant identifier, the device member PSK (M-PSK), and the M-PSK identity hint as the first factor of device authentication; further, a session key is generated using a key exchange handshake between the KDS interface and the KDS or the KDS proxy; and further, device member validation is performed. The steps include receiving the integrated circuit card identifier (ICCID), International Mobile Equipment Identification Number (IMEI), and IMSI information of the mobile device from the mobile device via the KDS, A step of sending a nonce to the mobile device by the KDS using the authentication key securely stored in the SIM, wherein the storage location may be within the card circuit equipment or on an applet on the SIM, The steps include receiving the signed nonce from the mobile device via the KDS, The KDS sends the nonce and the IMSI for signing using the associated authentication key of the mobile device to the mobile service provider of the mobile device, The steps include: authenticating the mobile device with the KDS by comparing and matching the signed nonce received from the mobile device and the mobile service provider in order to authenticate and validate the mobile device; The method according to claim 42, which is performed as a second factor of the device authentication.

44. The method according to claim 41, wherein the device authentication and multiple key exchange handshakes are performed via a connectionless UDP or connection-oriented TCP transport protocol without requiring a security transport protocol, and further, data authentication and / or data encryption are performed via any communication protocol using the retrieved pre-shared key.

45. The method according to claim 41, wherein the KDS interface provides a plurality of application programming interfaces (APIs), and the client application and the server application directly send a plurality of requests for key operations to the KDS and directly receive a plurality of responses for key operations from the KDS, or the client application and the server application indirectly send a plurality of requests for key operations through the KDS proxy and indirectly receive a plurality of responses for key operations through the KDS proxy.

46. The method according to claim 41, wherein in the KDS, the client device and the server device are configured as members of a tenancy associated with the tenant identifier and the device group associated with the tenant identifier, and the device group is further configured as a key record including a key instance used to secure communication between the client application and the server application.

47. The method according to claim 41, wherein the key record configured for the device group in the KDS includes a key expiration timestamp and key status for managing automatic key renewal, key rotation, and key revocation operations in the KDS.

48. The method according to claim 41, wherein, prior to the client application obtaining the S-PSK from the KDS, the S-PSK is created in the KDS by the server application on the server member device and with restricted key usage permissions for data authentication, data encryption, content signing, broadcast signing, broadcast encryption, multicast signing, multicast encryption, token signing, or token encryption operations.

49. The method according to claim 41, wherein the acquisition of the S-PSK from the KDS by the client application restricts key usage based on permissions configured by the key creator.

50. The method according to claim 41, wherein the key record configured for the device group in the KDS includes the key token for the client application to send authenticated API requests to the server application, using the key instance as an API shared secret and the key token as an API shared token, and further, the API request may be a REST API request.

51. The method according to claim 41, wherein a request from an authenticated member device for any key action based on the group identifier and the S-PSK identity hint is processed by the KDS and granted based on a match between the member domain and a domain derived from a plurality of resource records retrieved by a DNS reverse lookup of the member device DNS hostname.

52. The method according to claim 41, wherein a request from an authenticated member device for any key action based on the group identifier, the S-PSK identity hint, and the application identifier is processed by the KDS and permitted based on a match with the application identifier associated with the group identifier, and the KDS is configured to allow or deny the key action.

53. The method according to claim 41, wherein a request from an authenticated member device for any key action based on the group identifier and the S-PSK identity hint is processed by the KDS and authorized based on a match of the member device tenant identifier with an associated license owner identifier retrieved from the DDS as vendor-specific member device information.

54. The method according to claim 41, wherein a derived device key (D-PSK) is created locally, just in time on demand, but is not stored locally, using the extracted S-PSK and device unique identifier as the registration identifiers for the client and server applications, in order to sign and / or encrypt messages or tokens about data authentication and / or secrets.

55. A method for generating, distributing, and managing the lifecycle of a symmetric pre-shared key (PSK) used in certificate-less selective encryption (S-PSK) of a portion of a message over an insecure transport for use between applications running on distributed devices, including a client application running on a client device, a server application running on a server device, a Key Distribution Service (KDS), a KDS proxy, a KDS interface, a symmetric KDS member M-PSK, an 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, an S-PSK identity hint, a key record, a Dynamic Host Configuration Protocol (DHCP) server, and a Domain Name System (DNS) server, A step of authenticating with the KDS by the client application running on the client device using the tenant identifier, the symmetric KDS member PSK (M-PSK), and the M-PSK identity hint, wherein the client device is registered by a DNS hostname on the DNS server configured with the KDS or the KDS proxy, and is configured as a first member of a device group in the KDS. A step of obtaining the S-PSK from the KDS by the client application using at least the group identifier and the S-PSK identity hint, wherein the S-PSK is used as a shared symmetric key for selective encryption of a portion of a message over an insecure transport protocol during communication with the server application running on the server device registered by the DNS hostname on the DNS server, and the server device is configured as a second member of the device group. A step of authenticating with the KDS by the server application running on the server device using the configured tenant identifier, the symmetric KDS member PSK (M-PSK), and the M-PSK identity hint, wherein the server device is registered by the DNS hostname on the DNS server configured with the KDS or the KDS proxy. A step of obtaining the S-PSK from the KDS by the server application using at least the group identifier and the S-PSK identity hint, wherein the S-PSK is used as a shared symmetric key for selective encryption of a portion of a message over an insecure transport protocol during communication with the client application running on the client device, and the client device is registered by a DNS hostname on the DNS server. The steps include: selectively protecting the authenticity and / or confidentiality of a portion of a message in communication with the server application running on the server device via an insecure connectional or connectionless transport protocol, by the client application running on the client device, using the acquired S-PSK; The steps include: selectively protecting the authenticity and / or confidentiality of a portion of a message in communication with the client application running on the client device via the insecure connection-oriented or connectionless transport protocol by the server application running on the server device using the acquired S-PSK; The steps include updating the S-PSK programmatically and automatically by the client application and the server application using the KDS interface without requiring human intervention and without service interruption, and Methods that include...

56. A device member authentication handshake is performed by the KDS interface on the client device and the server device, using the tenant identifier, the device member PSK (M-PSK), and the M-PSK identity hint as the first factor of device authentication; further, a session key is generated using a key exchange handshake between the KDS interface and the KDS or the KDS proxy; and further, device member validation is performed. The steps include performing a DNS reverse lookup of the device member IP address by the KDS or the KDS proxy in order to query the DNS hostname, The steps include: extracting the DNS hostname from the resource record in the DNS response using the KDS or the KDS proxy; The steps include comparing and matching the retrieved DNS hostname with the device member identifier in the KDS request using the KDS or the KDS proxy, and The method according to claim 55, which is performed as a second factor of the device authentication.

57. The method according to claim 56, wherein the device authentication and multiple key exchange handshakes are performed via a connectionless UDP or connection-oriented TCP transport protocol without requiring a security transport protocol, and further, data authentication and / or data encryption are performed via any communication protocol using the retrieved pre-shared key.

58. The method according to claim 55, wherein the KDS interface provides a plurality of application programming interfaces (APIs), and the client application and the server application directly send a plurality of requests for key operations to the KDS and directly receive a plurality of responses for key operations from the KDS, or the client application and the server application indirectly send a plurality of requests for key operations through the KDS proxy and indirectly receive a plurality of responses for key operations through the KDS proxy.

59. The method according to claim 55, wherein the client device and the server device are registered in the IP address (A) record and PTR record used for DNS hostname reverse lookup by a unique DNS hostname in the domain on the local DNS server.

60. The method according to claim 55, wherein in the KDS, the client device and the server device are configured as members of a tenancy associated with the tenant identifier and the device group associated with the tenant identifier, and the device group is further configured as a key record including a key instance used to secure communication between the client application and the server application.

61. The method according to claim 55, wherein the key record configured for the device group in the KDS includes a key expiration timestamp and a key status for managing automatic key renewal, key rotation, and key revocation operations in the KDS.

62. The method of claim 55, wherein, before the client application obtains the S-PSK from the KDS, the S-PSK is created in the KDS by the server application as a key creator on the server device and with restricted key usage permissions for data authentication, data encryption, content signing, broadcast signing, broadcast encryption, multicast signing, multicast encryption, token signing, or token encryption operations.

63. The method according to claim 55, wherein the acquisition of the S-PSK from the KDS by the client application restricts key usage based on permissions configured by the key creator.

64. The method according to claim 55, wherein a request from an authenticated member device for any key action based on the group identifier and the S-PSK identity hint is processed by the KDS and granted based on a match between the member domain and a domain derived from a plurality of resource records retrieved by a DNS reverse lookup of the member device DNS hostname.

65. The method of claim 55, wherein a request from an authenticated member device for any key action based on the group identifier, the S-PSK identity hint, and the application identifier is processed by the KDS and permitted based on a match with the application identifier associated with the group identifier, and the KDS is configured to allow or deny the key action.

66. The method according to claim 55, wherein device-specific information configured as an extended custom attribute of a member device is retrieved from the DHCP server using a plurality of extended KDS interface APIs to automate local device configuration and export vendor-specific member device information to the KDS.

67. The method according to claim 55, wherein a request from an authenticated member device for any key action based on the group identifier and the S-PSK identity hint is processed by the KDS and authorized based on a match of the member device tenant identifier with an associated license owner identifier retrieved from the DHCP server as vendor-specific member device information.

68. A method for generating, distributing, and managing the lifecycle of a symmetric pre-shared key (PSK) used in certificateless selective encryption (S-PSK) of a portion of a message over an insecure transport for use between applications running on distributed mobile devices, comprising: a client application running on a client mobile device; a server application running on a server mobile device; a Key Distribution Service (KDS); a KDS proxy; a KDS interface; a symmetric KDS member M-PSK; an 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; an S-PSK identity hint; a key record; a device directory service (DDS); and a mobile service provider (MSP) server. A step of authenticating with the KDS by the client application running on the client mobile device using the tenant identifier, the symmetric KDS member PSK (M-PSK), and the M-PSK identity hint, wherein the client mobile device is registered with an International Mobile Subscriber Identification Number (IMSI) on the MSP server configured with the KDS or the KDS proxy, and is configured as a first member of a device group in the KDS. A step of obtaining the S-PSK from the KDS by the client application using at least the group identifier and the S-PSK identity hint, wherein the S-PSK is used as a shared symmetric key for selective encryption of a portion of a message over an insecure transport protocol during communication with the server application running on the server mobile device, the server mobile device is registered by a second International Mobile Subscriber Identification Number (IMSI) on the MSP server, and the server mobile device is configured as a second member of the device group. A step of authenticating with the KDS by the server application running on the server mobile device using the tenant identifier, the symmetric KDS member PSK (M-PSK), and the M-PSK identity hint, wherein the server mobile device is registered with a second International Mobile Subscriber Identification Number (IMSI) on the MSP server configured with the KDS or the KDS proxy. A step of obtaining the S-PSK from the KDS by the server application using at least the group identifier and the S-PSK identity hint, wherein the S-PSK is used as the shared symmetric key for selective encryption of a portion of a message over the insecure transport protocol during communication with the client application running on the client mobile device, and the client mobile device is registered with a first International Mobile Subscriber Identification Number (IMSI) on the MSP server, The steps include: selectively protecting the authenticity and / or confidentiality of a portion of a message in communication with the server application running on the server mobile device via an insecure connectional or connectionless transport protocol, by the client application running on the client mobile device, using the acquired S-PSK; The steps include: selectively protecting the authenticity and / or confidentiality of a portion of a message in communication with the client application running on the client mobile device via the insecure connection-oriented or connectionless transport protocol by the server application running on the server mobile device using the acquired S-PSK; The steps include updating the S-PSK programmatically and automatically by the client application and the server application using the KDS interface without requiring human intervention and without service interruption, and Methods that include...

69. A device member authentication handshake is performed by the KDS interface on the client mobile device and server mobile device, using the tenant identifier, the device member PSK (M-PSK), and the M-PSK identity hint as the first factor of device authentication; further, a session key is generated using a key exchange handshake between the KDS interface and the KDS or the KDS proxy; and further, device member validation is performed. The KDS receives the integrated circuit card identifier (ICCID), International Mobile Equipment Identification Number (IMEI), and IMSI information of the client mobile device from the client mobile device. A step of sending a nonce for signing by the SIM on the client mobile device using the authentication key securely stored in the SIM, wherein the storage location is on the card circuit equipment or on an applet on the SIM, The steps include receiving the signed nonce from the client mobile device via the KDS, The KDS sends the nonce and the IMSI for signing using the authentication key associated with the client mobile device to the mobile service provider of the client mobile device, The steps include authenticating the client mobile device by comparing and matching the client mobile device with the signed nonce received from the mobile service provider in order to authenticate and validate the client mobile device, and authenticating the client mobile device by the KDS. The method according to claim 68, which is performed as a second factor of the device authentication.

70. The method according to claim 68, wherein the device authentication and multiple key exchange handshakes are performed via a connectionless UDP or connection-oriented TCP transport protocol without requiring a security transport protocol, and further, data authentication and / or data encryption are performed via any communication protocol using the retrieved pre-shared key.

71. The method according to claim 68, wherein the KDS interface provides a plurality of application programming interfaces (APIs), and the client application and the server application directly send a plurality of requests for key operations to the KDS and directly receive a plurality of responses for key operations from the KDS, or the client application and the server application indirectly send a plurality of requests for key operations through the KDS proxy and indirectly receive a plurality of responses for key operations through the KDS proxy.

72. The method according to claim 68, wherein in the KDS, the client device and the server device are configured as members of a tenancy associated with the tenant identifier and the device group associated with the tenant identifier, and the device group is further configured as a key record including a key instance used to secure communication between the client application and the server application.

73. The method according to claim 68, wherein the key record configured for the device group in the KDS includes a key expiration timestamp and a key status for managing automatic key renewal, key rotation, and key revocation operations in the KDS.

74. The method of claim 68, wherein, prior to the client application obtaining the S-PSK from the KDS, the S-PSK is created in the KDS by the server application on the server member device and with restricted key usage permissions for data authentication, data encryption, content signing, broadcast signing, broadcast encryption, multicast signing, multicast encryption, token signing, or token encryption operations.

75. The method according to claim 68, wherein the acquisition of the S-PSK from the KDS by the client application restricts key usage based on permissions configured by the key creator.

76. The method according to claim 68, wherein a request from an authenticated member device for any key action based on the group identifier and the S-PSK identity hint is processed by the KDS and granted based on a match between the member domain and a domain derived from a plurality of resource records retrieved by a DNS reverse lookup of the member device DNS hostname.

77. The method according to claim 68, wherein a request from an authenticated member device for any key action based on the group identifier, the S-PSK identity hint, and the application identifier is processed by the KDS and permitted based on a match with the application identifier associated with the group identifier, and the KDS is configured to allow or reject the key action.

78. The method according to claim 68, wherein a request from an authenticated member device for any key action based on the group identifier and the S-PSK identity hint is processed by the KDS and authorized based on a match of the member device tenant identifier with an associated license owner identifier retrieved from the DDS as vendor-specific member device information.

79. A method for generating, distributing, and managing the lifecycle of a symmetric pre-shared key (PSK) used in certificate-less document security by selective object cryptography for use between applications running on distributed devices, comprising: a producer application running on a producer device; a consumer application running on a consumer device; a Key Distribution Service (KDS); a KDS proxy; a KDS interface; a symmetric KDS member M-PSK; an 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; and a Domain Name System (DNS) server. A step of authenticating with the KDS by the producer application running on the producer device using the configured tenant identifier, the symmetric KDS member PSK (M-PSK), and the M-PSK identity hint, wherein the producer device is registered by a DNS hostname on the DNS server configured in the KDS or the KDS proxy, and the producer device is configured as a first member of a device group in the KDS. A step of creating a symmetric pre-shared key with associated pre-shared key (PSK) identity hints by a producer application in the KDS, A step of using the created pre-shared key selectively to encrypt embedded objects in a document by the producer application in the KDS, wherein the producer application in the KDS is document processing software or a document exchange program, and different embedded objects are encrypted with different pre-shared keys, and the pre-shared key identity hint is tagged with each of the encrypted objects. The steps include sending the document containing the embedded encrypted object and the tagged pre-shared key identity hint to the consumer application running on the consumer device by the producer application in the KDS, A step of authenticating with the KDS by the consumer application running on the consumer device using the tenant identifier, the symmetric KDS member PSK (M-PSK), and the M-PSK identity hint, wherein the consumer device is registered by a DNS hostname on the DNS server configured with the KDS or the KDS proxy, and the consumer device is configured as a second member of the device group in the KDS. The steps include: receiving the document having the embedded encrypted object and the tagged pre-shared key identity hint by the consumer application running on the consumer device; For decryption, the consumer application running on the consumer device retrieves the pre-shared key for the pre-shared key identity hint tagged with each of the encrypted embedded objects in the received document, using at least the group identifier and the pre-shared key identity hint, from the KDS; A step of restricting access to the encrypted embedded objects in the document by a consumer application running on a device authenticated and validated by the KDS, wherein the consumer application is document processing software or a document exchange program. Methods that include...

80. A device member authentication handshake is performed by the KDS interface on the producer and consumer devices, using the tenant identifier, the device member PSK (M-PSK), and the M-PSK identity hint as the first factor of device authentication; further, a session key is generated using a key exchange handshake between the KDS interface and the KDS or the KDS proxy; and further, device member validation is performed. The steps include performing a DNS reverse lookup of the device member IP address by the KDS or the KDS proxy in order to query the DNS hostname, The steps include: extracting the DNS hostname from the resource record in the DNS response using the KDS or the KDS proxy; The steps include comparing and matching the retrieved DNS hostname with the device member identifier in the KDS request using the KDS or the KDS proxy, and The method according to claim 79, which is performed as a second factor of the device authentication.

81. The method according to claim 80, wherein the device authentication and the multiple key exchange handshakes are performed via a connectionless UDP or connection-oriented TCP transport protocol without requiring a security transport.

82. The method according to claim 79, wherein the KDS interface provides a plurality of application programming interfaces (APIs), and the producer and consumer applications directly send a plurality of requests for key operations to the KDS and directly receive a plurality of responses for key operations from the KDS, or the producer and consumer applications indirectly send a plurality of requests for key operations through the KDS proxy and indirectly receive a plurality of responses for key operations through the KDS proxy.

83. The method according to claim 79, wherein the producer and consumer devices are registered in the IP address (A) record and PTR record used for DNS hostname reverse lookup by a unique DNS hostname in the domain on the local DNS server.

84. The method according to claim 79, wherein in the KDS, the producer and consumer devices are configured as members of a tenancy associated with the tenant identifier and the device group associated with the tenant identifier, and the device group further comprises a key record including key instances used when exchanging documents between the producer application and the consumer application.

85. The method according to claim 79, wherein the key record configured for the device group in the KDS includes a key expiration timestamp and a key status for managing automatic key renewal, key rotation, and key revocation operations in the KDS.

86. The method of claim 79, wherein, prior to the consumer application obtaining the pre-shared key from the KDS, the pre-shared key is created in the KDS by the producer application on the producer member device and with restricted key usage permissions for data authentication, data encryption, content signing, broadcast signing, broadcast encryption, multicast signing, multicast encryption, token signing, or token encryption operations.

87. The method according to claim 79, wherein the acquisition of the pre-shared key from the KDS by the consumer application restricts key usage based on permissions configured by the key creator.

88. The method according to claim 79, wherein a request from an authenticated member device for any key action based on the group identifier and the pre-shared key identity hint is processed by the KDS and granted based on a match between the member domain and a domain derived from a plurality of resource records retrieved by a DNS reverse lookup of the member device DNS hostname.

89. The method according to claim 79, wherein a request from an authenticated member device for any key action based on the group identifier, the pre-shared key identity hint, and the application identifier is processed by the KDS and permitted based on a match with the application identifier associated with the group identifier, and the KDS is configured to allow or deny the key action.

90. The method according to claim 79, wherein device-specific information configured as an extended custom attribute of a member device is retrieved from the DHCP server using a plurality of extended KDS interfaces (APIs) to automate local device configuration and export vendor-specific member device information to the KDS.

91. The method according to claim 79, wherein a request from an authenticated member device for any key action based on the group identifier and the pre-shared key identity hint is processed by the KDS and authorized based on a match of the member device tenant identifier with an associated license owner identifier retrieved from the DHCP server as vendor-specific member device information.

92. A method for generating, distributing, and managing the lifecycle of a symmetric pre-shared key (PSK) used in certificate-less document security by selective object cryptography for use between applications running on distributed devices, comprising: a producer application running on a producer device; a consumer application running on a consumer device; a Key Distribution Service (KDS); a KDS proxy; a KDS interface; a symmetric KDS member M-PSK; an 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 Domain Name System (DNS) server; a Device Directory Service (DDS); and a Mobile Service Provider (MSP) server, wherein the lifecycle of a symmetric pre-shared key (PSK) used in certificate-less document security by selective object cryptography for use between applications running on distributed devices, comprising: a producer application running on a producer device; a consumer application running on a consumer device; a Key Distribution Service (KDS); a KDS proxy; a KDS interface; a symmetric KDS member M-PSK; an 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 Domain Name System (DNS) server; a Device Directory Service (DDS); and a Mobile Service Provider (MSP) server, A step of authenticating with the KDS by the producer application running on the producer device using the tenant identifier, the symmetric KDS member PSK (M-PSK), and the M-PSK identity hint, wherein the producer device is registered by a DNS hostname on the DNS server configured with the KDS or the KDS proxy, and the producer device is configured as a first member of a device group in the KDS. A step of creating a symmetric pre-shared key with associated pre-shared key (PSK) identity hints by a producer application in the KDS, A step of using the created pre-shared key selectively to encrypt embedded objects in a document by the producer application in the KDS, wherein the producer application in the KDS is document processing software or a document exchange program, and different embedded objects are encrypted with different pre-shared keys, and the pre-shared key identity hint is tagged with each of the encrypted objects. The steps include sending the document containing the embedded encrypted object and the tagged pre-shared key identity hint to the consumer application running on the consumer device by the producer application in the KDS, A step of authenticating the consumer application running on the consumer mobile device with the KDS using the tenant identifier, the symmetric KDS member PSK (M-PSK), and the M-PSK identity hint, wherein the responder mobile device is registered with an International Mobile Subscriber Identification Number (IMSI) on the MSP server configured with the KDS or the KDS proxy, and the responder mobile device is configured as a second member of a device group in the KDS. The steps include: receiving the document having the embedded encrypted object and the tagged pre-shared key identity hint by the consumer application running on the consumer device; The steps include: retrieving the pre-shared key for the pre-shared key identity hint tagged with each of the encrypted embedded objects in the received document by the consumer application running on the consumer device, using at least the group identifier and the pre-shared key identity hint; A step of restricting access to the encrypted embedded objects in the document by a consumer application running on a device authenticated and validated by the KDS, wherein the consumer application is document processing software or a document exchange program. Methods that include...

92. A device member authentication handshake is performed by the KDS interface on the producer device, using the tenant identifier, the device member PSK (M-PSK), and the M-PSK identity hint as the first factor of device authentication; further, a session key is generated using a key exchange handshake between the KDS interface and the KDS or the KDS proxy; and further, device member validation is performed. The steps include performing a DNS reverse lookup of the device member IP address by the KDS or the KDS proxy in order to query the DNS hostname, The steps include: extracting the DNS hostname from the resource record in the DNS response using the KDS or the KDS proxy; The steps include comparing and matching the retrieved DNS hostname with the device member identifier in the KDS request using the KDS or the KDS proxy, and The method according to claim 92, which is performed as a second factor of the device authentication.

93. The method according to claim 92, wherein the device authentication and the multiple key exchange handshakes are performed via a connectionless UDP or connection-oriented TCP transport protocol without requiring a security transport protocol.

94. A device member authentication handshake is performed by the KDS interface on the consumer mobile device using the device member PSK (M-PSK) and the M-PSK identity hint, and the session key is generated using a key exchange handshake between the KDS interface and the KDS or the KDS proxy, and the device member validation is performed, The steps include receiving the Integrated Circuit Card Identifier (ICCID), International Mobile Equipment Identification Number (IMEI), and IMSI information of the consumer mobile device from the consumer mobile device via the KDS, A step of sending a nonce to the consumer mobile device by the KDS for signing by the SIM on the consumer mobile device using an authentication key securely stored in the SIM, wherein the storage location is within the card circuit equipment or on an applet on the SIM, The steps include receiving the signed nonce from the consumer mobile device via the KDS, The KDS sends the nonce and the IMSI for signing using the associated authentication key of the consumer mobile device to the mobile service provider of the consumer mobile device, The steps include authenticating the consumer mobile device by the KDS by comparing and matching the consumer mobile device with the signed nonce received from the mobile service provider in order to authenticate and validate the consumer mobile device, and The method according to claim 92, as implemented by [the present invention].

95. The method according to claim 92, wherein the KDS interface provides a plurality of application programming interfaces (APIs), and the producer and consumer applications directly send a plurality of requests for key operations to the KDS and directly receive a plurality of responses for key operations from the KDS, or the producer and consumer applications indirectly send a plurality of requests for key operations through the KDS proxy and indirectly receive a plurality of responses for key operations through the KDS proxy.

96. The method according to claim 92, wherein in the KDS, the producer and consumer devices are configured as members of a tenancy associated with the tenant identifier and the device group associated with the tenant identifier, and the device group further comprises a key record including key instances used when exchanging documents between the producer application and the consumer application.

97. The method according to claim 92, wherein the key record configured for the device group in the KDS includes a key expiration timestamp and a key status for managing automatic key renewal, key rotation, and key revocation operations in the KDS.

98. The method of claim 92, wherein, prior to the consumer application obtaining the pre-shared key from the KDS, the pre-shared key is created in the KDS by the producer application on the producer member device and with restricted key usage permissions for data authentication, data encryption, content signing, broadcast signing, broadcast encryption, multicast signing, multicast encryption, token signing, or token encryption operations.

99. The method according to claim 92, wherein the acquisition of the pre-shared key from the KDS by the consumer application restricts key usage based on permissions configured by the key creator.

100. The method according to claim 92, wherein a request from an authenticated member device for any key action based on the group identifier and the pre-shared key identity hint is processed by the KDS and granted based on a match of the member domain with a domain derived from a plurality of resource records retrieved by a DNS reverse lookup of the member device DNS hostname.

101. The method of claim 92, wherein a request from an authenticated member device for any key action based on the group identifier, the pre-shared key identity hint, and the application identifier is processed by the KDS and permitted based on a match with the application identifier associated with the group identifier, and the KDS is configured to allow or deny the key action.

102. The method according to claim 92, wherein a request from an authenticated member device for any key action based on the group identifier and the pre-shared key identity hint is processed by the KDS and authorized based on a match of the member device tenant identifier with an associated license owner identifier retrieved from the DDS as vendor-specific member device information.

103. A method for generating, distributing, and managing the lifecycle of a symmetric pre-shared key (PSK) used in certificate-less keyed hash message authentication code (HMAC)-based content signing for tamper resistance for use between applications running on distributed devices, comprising: a producer application running on a producer device; consumer applications running on consumer devices, respectively; a Key Distribution Service (KDS); a KDS proxy; a KDS interface; a symmetric KDS member M-PSK; an 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; and a Domain Name System (DNS) server. A step of authenticating with the KDS by the producer application running on the producer device using the tenant identifier, the symmetric KDS member PSK (M-PSK), and the M-PSK identity hint, wherein the producer device is registered by a DNS hostname on the DNS server configured with the KDS or the KDS proxy, and is configured as a first member of a device group in the KDS. The steps include creating the symmetric pre-shared key (PSK) with associated pre-shared key (PSK) identity hints using a producer application in the KDS, The steps include: signing the digital content using the pre-shared key created above by the producer application running on the producer device; The steps include generating a signature manifest associated with the tenant identifier, the group identifier, the digital signature, and the pre-shared key identity hint by the producer application running on the producer device, The steps include sending the signed digital content and the associated signature manifest to the consumer application running on the consumer device by the producer application running on the producer device, A step of authenticating with the KDS by the consumer application running on the consumer device using the tenant identifier, the symmetric KDS member PSK (M-PSK), and the M-PSK identity hint, wherein the consumer device is registered by a DNS hostname on the DNS server configured with the KDS or the KDS proxy, and is configured as a second member of the device group in the KDS. The steps include: receiving the signed digital content, as well as the signature manifest associated with the tenant identifier, the group identifier, the digital signature, and the pre-shared key identity hint, by the consumer application; The steps include: retrieving the pre-shared key for the pre-shared key identity hint in the received signature manifest from the KDS by the consumer application using at least the tenant identifier, the group identifier, and the pre-shared key identity hint; The steps include: verifying the received signed digital content by the consumer application using the retrieved pre-shared key in order to regenerate the digital signature and compare it with the digital signature in the received signature manifest to find a match; Methods that include...

104. A device member authentication handshake is performed by the KDS interface on the producer and consumer devices, using the tenant identifier, the device member PSK (M-PSK), and the M-PSK identity hint as the first factor of device authentication; further, a session key is generated using a key exchange handshake between the KDS interface and the KDS or the KDS proxy; and further, device member validation is performed. The steps include performing a DNS reverse lookup of the device member IP address by the KDS or the KDS proxy in order to query the DNS hostname, The steps include: extracting the DNS hostname from the resource record in the DNS response using the KDS or the KDS proxy; The steps include comparing and matching the retrieved DNS hostname with the device member identifier in the KDS request using the KDS or the KDS proxy, and The method according to claim 103, which is performed as a second factor of the device authentication.

105. The method according to claim 104, wherein the device authentication and the multiple key exchange handshakes are performed via a connectionless UDP or connection-oriented TCP transport protocol without requiring a security transport protocol.

106. The method according to claim 103, wherein the KDS interface provides a plurality of application programming interfaces (APIs), and the producer and consumer applications directly send a plurality of requests for key operations to the KDS and directly receive a plurality of responses for key operations from the KDS, or the producer and consumer applications indirectly send a plurality of requests for key operations through the KDS proxy and indirectly receive a plurality of responses for key operations through the KDS proxy.

107. The method according to claim 103, wherein the producer and consumer devices are registered in the IP address (A) record and PTR record used for DNS hostname reverse lookup by a unique DNS hostname in the domain on the local DNS server.

108. The method according to claim 103, wherein in the KDS, the producer and consumer devices are configured as members of a tenancy associated with the tenant identifier and the device group associated with the tenant identifier, and the device group further comprises a key record containing key instances used when generating and verifying digital signatures.

109. The method according to claim 103, wherein the key record configured for the device group in the KDS includes a key expiration timestamp and a key status for managing automatic key renewal, key rotation, and key revocation operations in the KDS.

110. The method according to claim 103, wherein, prior to the producer application obtaining the pre-shared key from the KDS, the pre-shared key is created in the KDS by the producer application on the producer member device and with restricted key usage permissions for data authentication, data encryption, content signing, broadcast signing, broadcast encryption, multicast signing, multicast encryption, token signing, or token encryption operations.

111. The method according to claim 103, wherein the acquisition of the pre-shared key from the KDS by the consumer application restricts key usage based on permissions configured by the key creator.

112. The method according to claim 103, wherein a request from an authenticated member device for any key action based on the group identifier and the pre-shared key identity hint is processed by the KDS and permitted based on a match of the member domain with a domain derived from a plurality of resource records retrieved by a DNS reverse lookup of the member device DNS hostname.

113. The method according to claim 103, wherein a request from an authenticated member device for any key action based on the group identifier, the pre-shared key identity hint, and the application identifier is processed by the KDS and permitted based on a match with the application identifier associated with the group identifier, and the KDS is configured to allow or deny the key action.

114. The method according to claim 103, wherein device-specific information configured as an extended custom attribute of a member device is retrieved from the DHCP server using a plurality of extended KDS interface APIs to automate local device configuration and export vendor-specific member device information to the KDS.

115. The method according to claim 103, wherein a request from an authenticated member device for any key action based on the group identifier and the pre-shared key identity hint is processed by the KDS and authorized based on a match of the member device tenant identifier with an associated license owner identifier retrieved from the DHCP server as vendor-specific member device information.

116. A method for generating, distributing, and managing the lifecycle of a symmetric pre-shared key (PSK) used in certificate-less keyed hash message authentication code (HMAC) based content signing for tamper resistance for use between applications running on distributed devices, comprising: a producer application running on a producer device; consumer applications running on consumer mobile devices, respectively; a Key Distribution Service (KDS); a KDS proxy; a KDS interface; a symmetric KDS member M-PSK; an 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; and a Domain Name System (DNS) server, a Device Directory Service (DDS), and a Mobile Service Provider (MSP) server, wherein the lifecycle of a symmetric pre-shared key (PSK) used in certificate-less keyed hash message authentication code (HMAC) based content signing for tamper resistance for use between applications running on distributed devices, the producer application running on a producer device; consumer applications running on consumer mobile devices, respectively; a Key Distribution Service (KDS); a KDS proxy; a KDS interface; a symmetric KDS member M-PSK; an 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; and a Domain Name System (DNS) server, a Device Directory Service (DDS), and a Mobile Service Provider (MSP) server, the lifecycle of a certificate-less keyed hash message authentication code (HMAC) based content signing for tamper resistance for use between applications running on distributed devices, the lifecycle of a symmetric pre-shared key (PSK), the lifecycle of a producer application running on a producer device; consumer applications running on consumer mobile devices, respectively; a Key Distribution Service (KDS); a KDS proxy; a KDS interface; a symmetric KDS member M-PSK; an 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; and A step of authenticating with the KDS by the producer application running on the producer device using the tenant identifier, the symmetric KDS member PSK (M-PSK), and the M-PSK identity hint, wherein the producer device is registered by a DNS hostname on the DNS server configured with the KDS or the KDS proxy, and is configured as a first member of a device group in the KDS. A step of creating a symmetric pre-shared key with associated pre-shared key (PSK) identity hints by a producer application in the KDS, The steps include: signing the digital content using the pre-shared key created above by the producer application running on the producer device; The steps include generating a signature manifest associated with the tenant identifier, the group identifier, the digital signature, and the pre-shared key identity hint by the producer application running on the producer device, The steps include sending the signed digital content and the associated signature manifest to the consumer application running on the consumer mobile device via the producer application running on the producer device, A step of authenticating the consumer application running on the consumer mobile device with the KDS using the tenant identifier, the symmetric KDS member PSK (M-PSK), and the M-PSK identity hint, wherein the consumer mobile device is registered with an International Mobile Subscriber Identification Number (IMSI) on the MSP server configured with the KDS or the KDS proxy, and is configured as a second member of the device group in the KDS. The steps include: receiving the signed digital content, as well as the signature manifest associated with the tenant identifier, the group identifier, the digital signature, and the pre-shared key identity hint, by the consumer application; The steps include: retrieving the pre-shared key for the pre-shared key identity hint in the received signature manifest from the KDS by the consumer application using at least the tenant identifier, the group identifier, and the pre-shared key identity hint; The steps include: verifying the received signed digital content by the consumer application using the retrieved pre-shared key in order to regenerate the digital signature and compare it with the digital signature in the received signature manifest to find a match; Methods that include...

117. A device member authentication handshake is performed by the KDS interface on the producer device, using the tenant identifier, the device member PSK (M-PSK), and the M-PSK identity hint as the first factor of device authentication; further, a session key is generated using a key exchange handshake between the KDS interface and the KDS or the KDS proxy; and further, device member validation is performed. The steps include performing a DNS reverse lookup of the device member IP address by the KDS or the KDS proxy in order to query the DNS hostname, The steps include: extracting the DNS hostname from the resource record in the DNS response using the KDS or the KDS proxy; The steps include comparing and matching the retrieved DNS hostname with the device member identifier in the KDS request using the KDS or the KDS proxy, and The method according to claim 116, which is performed as a second factor of the device authentication.

118. The method according to claim 116, wherein the device authentication and the multiple key exchange handshakes are performed via a connectionless UDP or connection-oriented TCP transport protocol without requiring a security transport protocol.

119. A device member authentication handshake is performed by the KDS interface on the consumer mobile device using the device member PSK (M-PSK) and the M-PSK identity hint, and the session key is generated using a key exchange handshake between the KDS interface and the KDS or the KDS proxy, and the device member validation is performed, The steps include receiving the Integrated Circuit Card Identifier (ICCID), International Mobile Equipment Identification Number (IMEI), and IMSI information of the consumer mobile device from the consumer mobile device via the KDS, A step of sending a nonce to the consumer mobile device by the KDS using an authentication key securely stored in the SIM, wherein the storage location is on the card circuit equipment or on an applet on the SIM, The steps include receiving the signed nonce from the consumer mobile device via the KDS, The KDS sends the nonce and the IMSI for signing using the associated authentication key of the consumer mobile device to the mobile service provider of the consumer mobile device, The steps include authenticating the consumer mobile device by the KDS by comparing and matching the consumer mobile device with the signed nonce received from the mobile service provider in order to authenticate and validate the consumer mobile device, and The method according to claim 116, as implemented by [the present invention].

120. The method according to claim 116, wherein the KDS interface provides a plurality of application programming interfaces (APIs), and the producer and consumer applications directly send a plurality of requests for key operations to the KDS and directly receive a plurality of responses for key operations from the KDS, or the producer and consumer applications indirectly send a plurality of requests for key operations through the KDS proxy and indirectly receive a plurality of responses for key operations through the KDS proxy.

121. The method according to claim 116, wherein in the KDS, the producer and consumer devices are configured as members of a tenancy associated with the tenant identifier and the device group associated with the tenant identifier, and the device group further comprises a key record containing key instances used when generating and verifying digital signatures.

122. The method according to claim 116, wherein the key record configured for the device group in the KDS includes a key expiration timestamp and a key status for managing automatic key renewal, key rotation, and key revocation operations in the KDS.

123. The method according to claim 116, wherein, prior to the consumer application obtaining the pre-shared key from the KDS, the pre-shared key is created in the KDS by the producer application on the producer member device and with restricted key usage permissions for data authentication, data encryption, content signing, broadcast signing, broadcast encryption, multicast signing, multicast encryption, token signing, or token encryption operations.

124. The method according to claim 116, wherein the acquisition of the pre-shared key from the KDS by the consumer application restricts key usage based on permissions configured by the key creator.

125. The method according to claim 116, wherein a request from an authenticated member device for any key action based on the group identifier and the pre-shared key identity hint is processed by the KDS and granted based on a match of the member domain with a domain derived from a plurality of resource records retrieved by a DNS reverse lookup of the member device DNS hostname.

126. The method according to claim 116, wherein a request from an authenticated member device for any key action based on the group identifier, the pre-shared key identity hint, and the application identifier is processed by the KDS and permitted based on a match with the application identifier associated with the group identifier, and the KDS is configured to allow or deny the key action.

127. The method according to claim 116, wherein a request from an authenticated member device for any key action based on the group identifier and the pre-shared key identity hint is processed by the KDS and authorized based on a match of the member device tenant identifier with an associated license owner identifier retrieved from the DDS as vendor-specific member device information.

128. A method for generating, distributing, and managing the lifecycle of a symmetric pre-shared key (PSK) used in certificate-less keyed hash message authentication code (HMAC)-based content signing for supply chain tamper resistance, for use between applications running on distributed devices, including an intermediary application running on an intermediary device, consumer applications running on consumer devices, a Key Distribution Service (KDS), a KDS proxy, a KDS interface, a symmetric KDS member M-PSK, an 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, and a Domain Name System (DNS) server, A step of authenticating with the KDS by the intermediary application running on the intermediary device using the tenant identifier, the symmetric KDS member PSK (M-PSK), and the M-PSK identity hint, wherein the intermediary device is registered by a DNS hostname on the DNS server configured with the KDS or the KDS proxy, and is configured as a first member of a device group in the KDS. The steps include receiving the signed digital content and associated signature manifest through the intermediary application, The KDS includes the step of creating an additional pre-shared key using the intermediary application, To generate extended signed digital content, the intermediary application signs the received signed digital content using the created pre-shared key, To generate an extended signature manifest, the intermediary application attaches the tenant identifier, the group identifier, an additional digital signature, and an additional associated pre-shared key identity hint to the received signature manifest. The steps include sending the extended-signed digital content and the associated extended-signed manifest to the consumer application via the intermediary application, A step of authenticating with the KDS by the consumer application running on the consumer device, using the tenant identifier, the symmetric KDS member PSK (M-PSK), and the M-PSK identity hint, wherein the consumer device is registered by a DNS hostname on the DNS server configured with the KDS or the KDS proxy, and is configured as a second member of the device group in the KDS. The steps include: receiving the extended signed digital content, as well as the extended signature manifest associated with the tenant identifier, the group identifier, the digital signature, and the pre-shared key identity hint, by the consumer application; The steps include: retrieving the pre-shared key for the identity hint in the received extended signature manifest from the KDS by the consumer application using at least the tenant identifier, the group identifier, and the pre-shared key identity hint; The steps include: verifying the received extended-signed digital content by the consumer application using the retrieved pre-shared key in order to regenerate the digital signature and compare it with the respective digital signatures associated with each identity hint in the received extended-signed manifest to find a match; Methods that include...

129. A device member authentication handshake is performed by the KDS interface on the intermediary and consumer devices, using the tenant identifier, the device member PSK (M-PSK), and the M-PSK identity hint as the first factor of device authentication; further, a session key is generated using a key exchange handshake between the KDS interface and the KDS or the KDS proxy; and further, device member validation is performed. The steps include performing a DNS reverse lookup of the device member IP address by the KDS or the KDS proxy in order to query the DNS hostname, The steps include: extracting the DNS hostname from the resource record in the DNS response using the KDS or the KDS proxy; The steps include comparing and matching the retrieved DNS hostname with the device member identifier in the KDS request using the KDS or the KDS proxy, and The method according to claim 128, which is performed as a second factor of the device authentication.

130. The method according to claim 129, wherein the device authentication and the multiple key exchange handshakes are performed via a connectionless UDP or connection-oriented TCP transport protocol without requiring a security transport protocol.

131. The method according to claim 130, wherein the KDS interface provides a plurality of application programming interfaces (APIs), and the intermediary and consumer applications directly send a plurality of requests for key operations to the KDS and directly receive a plurality of responses for key operations from the KDS, or the intermediary and consumer applications indirectly send a plurality of requests for key operations through the KDS proxy and indirectly receive a plurality of responses for key operations through the KDS proxy.

132. The method according to claim 128, wherein the intermediary and consumer devices are registered in the IP address (A) record and PTR record used for DNS hostname reverse lookup by a unique DNS hostname in the domain on the local DNS server.

133. The method according to claim 128, wherein in the KDS, the intermediary and consumer devices are configured as members of a tenancy associated with the tenant identifier and the device group associated with the tenant identifier, and the device group further comprises a key record containing key instances used when generating and verifying digital signatures.

134. The method according to claim 128, wherein the key record configured for the device group in the KDS includes a key expiration timestamp and key status for managing automatic key renewal, key rotation, and key revocation operations in the KDS.

135. The method of claim 128, wherein, prior to the intermediary application obtaining the pre-shared key from the KDS, the pre-shared key is created in the KDS by the intermediary application on the intermediary member device and with restricted key usage permissions for data authentication, data encryption, content signing, broadcast signing, broadcast encryption, multicast signing, multicast encryption, token signing, or token encryption operations.

136. The method of claim 128, wherein the acquisition of the pre-shared key from the KDS by the consumer application restricts key usage based on permissions configured by the key creator.

137. The method according to claim 128, wherein a request from an authenticated member device for any key action based on the group identifier and the pre-shared key identity hint is processed by the KDS and granted based on a match between the member domain and a domain derived from a plurality of resource records retrieved by a DNS reverse lookup of the member device DNS hostname.

138. The method according to claim 128, wherein a request from an authenticated member device for any key action based on the group identifier, the pre-shared key identity hint, and the application identifier is processed by the KDS and permitted based on a match with the application identifier associated with the group identifier, and the KDS is configured to allow or deny the key action.

139. The method according to claim 128, wherein device-specific information configured as an extended custom attribute of a member device is retrieved from the DHCP server using a plurality of extended KDS interface APIs to automate local device configuration and export vendor-specific member device information to the KDS.

140. The method according to claim 128, wherein a request from an authenticated member device for any key action based on the group identifier and the pre-shared key identity hint is processed by the KDS and permitted based on a match of the member device tenant identifier with an associated license owner identifier retrieved from the DHCP server as vendor-specific member device information.

141. A method for generating, distributing, and managing the lifecycle of a symmetric pre-shared key (PSK) used in certificate-less keyed hash message authentication code (HMAC)-based content signing for supply chain tamper resistance, for use between applications running on distributed devices, including an intermediary application running on an intermediary device, consumer applications running on consumer mobile devices, a Key Distribution Service (KDS), a KDS proxy, a KDS interface, a symmetric KDS member M-PSK, an 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 Domain Name System (DNS) server, a Device Directory Service (DDS), and a Mobile Service Provider (MSP) server, A step of authenticating with the KDS by the intermediary application running on the intermediary device using the tenant identifier, the symmetric KDS member PSK (M-PSK), and the M-PSK identity hint, wherein the intermediary device is registered by a DNS hostname on the DNS server configured with the KDS or the KDS proxy, and is configured as a first member of a device group in the KDS. The steps include receiving the signed digital content and associated signature manifest through the intermediary application, The KDS includes the step of creating an additional pre-shared key using the intermediary application, To generate extended signed digital content, the intermediary application signs the received signed digital content using the created pre-shared key, To generate an extended signature manifest, the intermediary application attaches the tenant identifier, the group identifier, an additional digital signature, and an additional associated pre-shared key identity hint to the received signature manifest. The steps include sending the extended-signed digital content and the associated extended-signed manifest to the consumer application via the intermediary application, A step of authenticating the consumer application running on the consumer mobile device with the KDS using the tenant identifier, the symmetric KDS member PSK (M-PSK), and the M-PSK identity hint, wherein the responder mobile device is registered with an International Mobile Subscriber Identification Number (IMSI) on the MSP server configured with the KDS or the KDS proxy, and is configured as a second member of the device group in the KDS. The steps include: receiving the extended signed digital content, as well as the extended signature manifest associated with the tenant identifier, the group identifier, the digital signature, and the pre-shared key identity hint, by the consumer application; The steps include: retrieving the pre-shared key for the identity hint in the received extended signature manifest from the KDS by the consumer application using at least the group identifier and the pre-shared key identity hint; The steps include: verifying the received extended-signed digital content by the consumer application using the retrieved pre-shared key in order to regenerate the digital signature and compare it with the respective digital signatures associated with each identity hint in the received extended-signed manifest to find a match; Methods that include...

142. A device member authentication handshake is performed by the KDS interface on the intermediary device, using the tenant identifier, the device member PSK (M-PSK), and the M-PSK identity hint as the first factor of device authentication; further, a session key is generated using a key exchange handshake between the KDS interface and the KDS or the KDS proxy; and further, device member validation is performed. The steps include performing a DNS reverse lookup of the device member IP address by the KDS or the KDS proxy in order to query the DNS hostname, The steps include: extracting the DNS hostname from the resource record in the DNS response using the KDS or the KDS proxy; The steps include comparing and matching the retrieved DNS hostname with the device member identifier in the KDS request using the KDS or the KDS proxy, and The method according to claim 141, which is performed as a second factor of the device authentication.

143. The method according to claim 141, wherein the device authentication and the multiple key exchange handshakes are performed via a connectionless UDP or connection-oriented TCP transport protocol without requiring a security transport protocol.

144. A device member authentication handshake is performed by the KDS interface on the consumer mobile device using the device member PSK (M-PSK) and the M-PSK identity hint, and the session key is generated using a key exchange handshake between the KDS interface and the KDS or the KDS proxy, and the device member validation is performed, The steps include receiving the Integrated Circuit Card Identifier (ICCID), International Mobile Equipment Identification Number (IMEI), and IMSI information of the consumer mobile device from the consumer mobile device via the KDS, A step of sending a nonce to the consumer mobile device by the KDS using an authentication key securely stored in the SIM, wherein the storage location is on the card circuit equipment or on an applet on the SIM, The steps include receiving the signed nonce from the consumer mobile device via the KDS, The KDS sends the nonce and the IMSI for signing using the associated authentication key of the consumer mobile device to the mobile service provider of the consumer mobile device, The steps include authenticating the consumer mobile device by the KDS by comparing and matching the consumer mobile device with the signed nonce received from the mobile service provider in order to authenticate and validate the consumer mobile device, and The method according to claim 141, as implemented by [the present invention].

145. The method according to claim 141, wherein the KDS interface provides a plurality of application programming interfaces (APIs), and the intermediary and consumer applications directly send a plurality of requests for key operations to the KDS and directly receive a plurality of responses for key operations from the KDS, or the intermediary and consumer applications indirectly send a plurality of requests for key operations through the KDS proxy and indirectly receive a plurality of responses for key operations through the KDS proxy.

146. The method according to claim 141, wherein in the KDS, the intermediary and consumer devices are configured as members of a tenancy associated with the tenant identifier and the device group associated with the tenant identifier, and the device group further comprises a key record including key instances used when generating and verifying digitals.

147. The method according to claim 141, wherein the key record configured for the device group in the KDS includes a key expiration timestamp and key status for managing automatic key renewal, key rotation, and key revocation operations in the KDS.

148. The method according to claim 141, wherein, prior to the consumer application obtaining the pre-shared key from the KDS, the pre-shared key is created in the KDS by the intermediary application on the intermediary member device and with restricted key usage permissions for data authentication, data encryption, content signing, broadcast signing, broadcast encryption, multicast signing, multicast encryption, token signing, or token encryption operations.

149. The method according to claim 141, wherein the acquisition of the pre-shared key from the KDS by the consumer application restricts key usage based on permissions configured by the key creator.

150. The method according to claim 141, wherein a request from an authenticated member device for any key action based on the group identifier and the pre-shared key identity hint is processed by the KDS and granted based on a match between the member domain and a domain derived from a plurality of resource records retrieved by a DNS reverse lookup of the member device DNS hostname.

151. The method according to claim 141, wherein a request from an authenticated member device for any key action based on the group identifier, the pre-shared key identity hint, and the application identifier is processed by the KDS and permitted based on a match with the application identifier associated with the group identifier, and the KDS is configured to allow or deny the key action.

152. The method according to claim 141, wherein a request from an authenticated member device for any key action based on the group identifier and the pre-shared key identity hint is processed by the KDS and authorized based on a match of the member device tenant identifier with an associated license owner identifier retrieved from the DDS as vendor-specific member device information.

153. A method for distributing the symmetric IWAP-PSK for secure wireless authentication by a device using the WAP in a production network, comprising: a supplicant program running on the device; a wireless access point (WAP) configured for multi-SSID (Service Set Identifier) ​​mode of operation; a Key Distribution Service (KDS); a KDS proxy; a KDS interface; a symmetric KDS member PSK (M-PSK); an 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; an internal WAP pre-shared key (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 (DHCP) server; and a Domain Name System (DNS) server. To establish initial wireless access for the device via the production network, the steps include: authenticating with the supplicant program using the WAP with the GWAP-SSID and GWAP-PSK; A step of authenticating with the KDS by the supplicant program running on the device using the tenant identifier, the symmetric KDS member PSK (M-PSK), and the M-PSK identity hint, wherein the device is registered by a DNS hostname on the DNS server configured with the KDS or the KDS proxy, and is configured as a first member of a device group in the KDS. For use as a shared symmetric key for authentication using the wireless access point, the supplicant program retrieves the IWAP-PSK from the KDS using at least the group identifier and the IWAP-PSK identity hint. To establish secure wireless access for the device via the production network and to perform a switchover from the guest SSID to the internal SSID wireless network, the steps include: authenticating with the WAP using the supplicant program with the IWAP-SSID and the extracted IWAP-PSK; Methods that include...

154. A device member authentication handshake is performed by the KDS interface on the device, using the tenant identifier, the device member PSK (M-PSK), and the M-PSK identity hint as the first factor of device authentication; further, a session key is generated using a key exchange handshake between the KDS interface and the KDS or the KDS proxy; and further, device member validation is performed. The steps include performing a DNS reverse lookup of the device member IP address by the KDS or the KDS proxy in order to query the DNS hostname, The steps include: extracting the DNS hostname from the resource record in the DNS response using the KDS or the KDS proxy; The steps include comparing and matching the retrieved DNS hostname with the device member identifier in the KDS request using the KDS or the KDS proxy, and The method according to claim 153, which is performed as a second factor of the device authentication.

155. The method according to claim 154, wherein the device authentication and the multiple key exchange handshakes are performed via a connectionless UDP or connection-oriented TCP transport protocol without requiring a security transport protocol.

156. The method according to claim 153, wherein the KDS interface provides a plurality of application programming interfaces (APIs), and an application directly sends a plurality of requests for key operations to the KDS and directly receives a plurality of responses for key operations from the KDS, or the application indirectly sends a plurality of requests for key operations through the KDS proxy and indirectly receives a plurality of responses for key operations through the KDS proxy.

157. The method according to claim 153, wherein the device is registered in the IP address (A) record and PTR record used for DNS hostname reverse lookup by a unique DNS hostname in the domain on the local DNS server.

158. The method according to claim 153, wherein in the KDS, the device is configured as a member of a tenancy associated with the tenant identifier and the device group associated with the tenant identifier, and the device group is further configured as a key record including a key instance for secure wireless authentication (IWAP-PSK).

159. The method according to claim 153, wherein the key record configured for the device group in the KDS includes a key expiration timestamp and a key status for managing automatic key renewal, key rotation, and key revocation operations in the KDS.

160. The method according to claim 153, wherein a request from an authenticated member device for any key action based on the group identifier and the IWAP-PSK identity hint is processed by the KDS and granted based on a match of the member domain with a domain derived from a plurality of resource records retrieved by a DNS reverse lookup of the member device DNS hostname.

161. The method according to claim 153, wherein the GWAP-SSID, the GWAP-PSK, the IWAP-SSID, the M-PSK, and the M-PSK identity hint are factory-configured attributes for an executable application image or system firmware on a real-time operating system (RTOS) platform, or are specified through a configuration file on a general-purpose operating system (GPOS) platform.

162. The method according to claim 153, wherein the primary and secondary KDS / KDS proxy URLs associated with the production WAP for secure access, the tenant identifier, and the group identifier and identity hint are discovered using network characteristics based on custom attributes configured on a DHCP server or DNS server associated with the member device LAN.

163. The method according to claim 153, wherein a request from an authenticated member device for any key action based on the group identifier, the IWAP-PSK identity hint, and the application identifier is processed by the KDS and permitted based on a match with the application identifier associated with the group identifier to allow or reject the key action.

164. The method according to claim 153, wherein device-specific information configured as an extended custom attribute of a member device is retrieved from the DHCP server using a plurality of extended KDS interfaces to automate local device configuration and export vendor-specific member device information to the KDS.

165. The method according to claim 153, wherein a request from an authenticated member device for any key action based on the group identifier and the IWAP-PSK identity hint is processed by the KDS and authorized based on a match of the member device tenant identifier with an associated license owner identifier retrieved from the DHCP server as vendor-specific member device information.

166. The method according to claim 153, wherein the supplicant program detects a change in the IWAP-PSK based on the inability to authenticate with the WAP using the IWAP-SSID and the last retrieved and stored IWAP-PSK, automatically switches over to the guest wireless network using the GWAP-SSID and the GWAP-PSK, authenticates with the KDS, retrieves the IWAP-PSK from the KDS, authenticates with the WAP using the IWAP-SSID and the retrieved IWAP-PSK, and switches over to the secure wireless network.

167. The method according to claim 153, wherein the supplicant program does not, for security reasons, locally store the last retrieved IWAP-PSK on the device and dynamically during a power cycle or application restart, authenticate on the guest wireless network using the GWAP-SSID and the GWAP-PSK, authenticate on the KDS, retrieve the IWAP-PSK from the KDS, and authenticate on the WAP using the IWAP-SSID and the retrieved IWAP-PSK to switch over to a secure wireless network.

168. The method according to claim 153, wherein the supplicant program is a Wi-Fi supplicant or a Wi-Fi supplicant function implemented within a production application or system firmware.

169. Device-on-board (DOB) mobile applications running on mobile devices, field devices, Device Directory Service (DDS), Key Distribution Service (KDS), KDS portal, KDS application programming interface, KDS administrator, pre-configured member pre-shared key (M-PSK) and M-PSK identity hint associated with the mobile device, pre-configured API key and pre-configured API token associated with the mobile device, pre-configured factory default member pre-shared key (M-PSK) and M-PSK identity hint associated with the field device, bootstrap applications on the field device, tenant identifiers associated with the mobile device and the field device, device type identifiers associated with the field device. A method for device label scan-based zero-touch device onboarding in the first power cycle, comprising: a printed device label having a device-unique, immutable initial identifier on the field device issued by an original equipment manufacturer (OEM); an asset metadata datastore associated with the DDS; a Dynamic Host Configuration Protocol (DHCP) server; a DHCP administrator; a Domain Name System (DNS) server; a DNS administrator; an initial device identifier issued by the OEM mapped in the DNS to an initial device IP address; a local device identifier issued by the device end user mapped in the DNS to a local device IP address; a vendor class identifier associated with the device type; and a tenant identifier associated with the tenant network domain. The KDS administrator imports device label templates for multiple device types associated with the field device. The steps include synchronizing the device label template for the tenant identifier and the plurality of device types on the mobile device, The steps include: scanning a printed device label on the field device using the mobile device with a selected label template for the device type, and generating a scan report; The steps include inspecting the scan report on the mobile device and updating the scan report with extended device information, The steps include uploading the updated scan report from the mobile device to the DDS, The steps include storing the scan report in the associated asset metadata data store using the DDS, The steps include querying the DHCP server using the DDS for vendor-specific device information regarding the vendor class identifier associated with the device type of the field device, and storing it in the asset metadata data store, The steps include: automatically configuring the field device by the DDS as a member device in the KDS having the associated device information in the asset metadata data store; The steps include: creating an address (A) and a plurality of pointer (PTR) records for the initial device identifier on the DNS server using the DHCP server; The DNS administrator configures the address (A) and the plurality of pointer (PTR) records for the local device identifier, as well as the canonical name (CNAME) record for mapping the local device identifier to the initial device identifier, on the DNS server. The steps include: registering the field device with the KDS during the first power cycle of the field device by the bootstrap application on the field device using field device two-factor authentication with the initial device identifier and factory default member pre-shared key; and registering the field device with a member unique pre-shared key using the KDS application programming interface for subsequent field device two-factor authentication; Methods that include...

170. The method according to claim 169, wherein the device label template comprises at least a location ordinal number, a prefix, and a regular expression for each device identifier on the printed device label.

171. The method according to claim 169, wherein the method for scanning a printed device label includes optical character recognition (OCR) for text-based device identifiers, barcode scanning, and QR code scanning.

172. The method according to claim 169, wherein the step of inspecting the scan report includes manually configuring extended device information, including at least the device type of the field device, a tenant identifier, and a network domain.

173. The method according to claim 169, wherein the scan report includes at least a media access control (MAC) address, a serial number, a model, a manufacturing location, device geolocation information, and the scanned image of the printed device label on the field device.

174. The method according to claim 169, wherein the query by the DDS from the DHCP server based on the vendor class identifier of the vendor-specific information includes manufacturer identification, country of manufacture, model, network type, network protocol, and license owner information associated with the field device type.

175. The method according to claim 169, wherein the creation of the address (A) and pointer (PTR) records on the DNS server for the initial device identifier is performed manually by the DHCP server administrator or dynamically using the dynamic DNS (DDNS) protocol to interface with the DNS server.

176. The method according to claim 169, wherein the zero-touch device onboarding in the initial power cycle is achieved by field device two-factor authentication using the pre-configured factory default member pre-shared key (M-PSK), the M-PSK identity hint, and the member initial identifier, wherein the member initial identifier matches the pre-configured DNS hostname based on the A and CNAME records.

177. The method according to claim 169, wherein the device onboarding mobile application (DOB) performs two-factor user authentication of the user of the mobile device in the tenant domain.

178. The method according to claim 169, wherein the device onboarding mobile application (DOB) performs two-factor device authentication in the tenant domain.

179. The method according to claim 169, wherein the device onboarding mobile application (DOB) uses the authenticated REST API together with the pre-configured API key and the pre-configured API token when communicating with the device directory service (DDS).

180. The method according to claim 179, wherein the pre-configured API key and the pre-configured API token are pre-configured for the device onboarding mobile application (DOB) on the mobile device.

181. The method according to claim 179, wherein the pre-configured API key and the pre-configured API token are dynamically retrieved from the KDS by the Device Onboarding Mobile Application (DOB) using the KDS application programming interface and the field device two-factor authentication.

182. The method according to claim 169, wherein the device onboarding mobile application (DOB) on the mobile device generates a device label template for a printed device label based on the scanned label image and artificial intelligence (AI) based on an inference algorithm for the ordinal, prefix, and regular expression.

183. The method according to claim 169, wherein the QR code is a URL configured by the manufacturer for the device type to be included in the scan report as extended device information for upstream processing in the DDS.

184. A method for symmetric key-based digital signing for a gated workflow sequence for content creation, content verification, content inspection, content approval, and supply chain tamper resistance from a device OEM to the end-user equipment, comprising at least a content creator at an original equipment manufacturer (OEM), a content loader at an end-user facility, multiple 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 running on user devices or field devices, a first secure channel for two-factor user and device authentication-based creation and retrieval of multiple digital signature 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 content file, an API key and API token associated with the content file, a content consumer field device, and an OEM application on the content consumer field device, wherein the method includes: The steps include: generating a first signature for the content file by creating a digital signature key by the content creator; The steps include: generating the signature manifest file containing the first signature for the content file by the content creator; The steps include sending the content file and the signature manifest file to multiple end-user devices by the content creator, The steps include verifying the signature for the received content file using the content loader in the end-user equipment, creating a digital signature key for generating a second signature for the content file, and extending the signature manifest file containing the first signature with the second signature, The steps include sending a notification to the first content approver in the end-user equipment via the content loader, Steps include: inspecting the content file by the first content approver at the end-user facility using multiple external third-party content inspection methods; creating a digital signature key for generating a third signature for the content file; and extending the signature manifest file containing the first and second signatures with the third signature; The first content approver sends a notification to a second content approver at the end-user equipment for further inspection, The steps include sending a notification to the policy manager in the end-user facility by the final content approver in order to associate the content file with the update policy, device type, and device group, The steps include sending a notification via the policy manager to a field manager at the end-user facility in order to publish the inspected and approved content files and extended signature manifest files, including the first, second, and third signatures, and to complete the managed content distribution workflow, The steps include querying the KDS via the OEM application on the content consumer field device to check for content updates and retrieving the download URL / URI of the content file and extended signature file associated with the content identifier, The steps include: downloading the content file and extended signature manifest file from the DDS to the content consumer field device using the OEM application; The steps include: retrieving the digital signing key records for the tenant identifier, group identifier, and key identity hint in the extended signature manifest file containing the first, second, and third signatures from the KDS; verifying the content file by the OEM application on the content consumer field device; calculating a hash; generating a signature for the content file based on the retrieved key record specifications for each of the digital signing keys; and matching the generated signature for the content file with the corresponding signature in the extended signature manifest file; The steps include: installing the content files by the OEM application on the content consumer field device using an OEM-specific update method; For state synchronization with the DDS associated with the KDS, the OEM application on the content consumer field device notifies the KDS of the update status on the content consumer field device. Methods that include...

185. The method according to claim 184, wherein the content file is a software update, a configuration update, or an operating system (OS) update.

186. The method according to claim 184, wherein the signing key for the digital signature is a symmetric key created and / or retrieved by a KDS portal user in two-factor authentication, and further, 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.

187. The method according to claim 184, wherein the signing key for the digital signature is a symmetric key created and / or retrieved by an application on a registered member device of the KDS in two-factor device authentication, and further, key operations using a tenant identifier, a group identifier, and a key identity hint are performed using the KDS application programming interface.

188. The method according to claim 184, wherein the digital signature key is created and / or retrieved by the KDS portal user and the application on the member device via the first secure channel.

189. The method according to claim 184, wherein the content file is downloaded from the retrieved URL / URI by the OEM application on the content consumer field device via the second secure channel.

190. The method according to claim 184, wherein the content file is inspected using an external third-party content inspection method which includes at least static analysis, dynamic analysis, sandboxing, anomaly detection, and reputation list, based on the security profile and threat model assessment of the content approver.

191. The method according to claim 184, wherein the content loader configures the received content and signature manifest file in the KDS portal, along with at least a content identifier, a content timestamp, a content version, a content type, and a content description.

192. The method according to claim 184, wherein the update policy configured by the policy manager may include at least the publication date and time, the day of the week, and a time range for scheduling content downloads, and further, a content identifier may be associated with the update policy, device type, and device group.

193. The method according to claim 184, wherein the OEM application on the content consumer field device queries for an update using the KDS application programming interface (API), retrieves a download URL / URI, verifies the retrieved signature manifest file, and notifies the KDS of the update status for state synchronization.

194. The method according to claim 184, wherein the OEM application on the content consumer field device installs the retrieved content files using an OEM-specific update method which includes the steps of streaming an HTTPS download without buffering to a flash memory partition on the device, or storing it in a file system on a flash data partition.

195. The method according to claim 184, wherein the step of verifying the content file by the content loader, the plurality of content approvers, and the OEM application on the content consumer field device includes the steps of: retrieving the digital signing key records for the tenant identifier, the group identifier, and the key identity hint in the associated extended signature manifest file from the KDS; calculating the hash and signature for the content file based on the key record specifications for each of the digital signing keys; and comparing the calculated signature for the content file with the corresponding signature in the extended signature manifest file.

196. The method according to claim 184, wherein each digital signer in the OEM and end-user facilities of the content file extends the signature manifest file using different key algorithms and key sizes for the digital signature key.

197. The method according to claim 184, wherein the retrieval of the content file by the OEM application on the content consumer field device via the second secure channel using the retrieved URL / URI requires the use of the API key and API token uniquely associated with the content file retrieved via the first secure channel.

198. A method for importing, creating, updating, recreating, retrieving, assigning, or acquiring leaf certificates for the public key and associated private key of an asymmetric key pair, used in client authentication between applications running on distributed devices in an Internet of Things (IoT), Industrial IoT (IIoT), or Operational Technology (OT) environment, in data signing with digital signatures, and in key unwrapping, wherein the method provides a client application running on a first device, a server application running on a second device, multiple trusted intermediate certificates and trusted root certificates issued by a Certificate Authority (CA), a Key Distribution Service (KDS), a KDS portal, a KDS administrator, a KDS proxy, a client KDS interface, a member identifier, a member universally unique identifier (UUID), a member Domain Name System (DNS) hostname, a symmetric KDS member (M-PSK), an M-PSK identity hint, a tenant identifier, an application identifier, a Dynamic Host Configuration Protocol (DHCP) service, and a Domain Name System (DNS) service. The steps include: importing a first set of leaf certificates and a first set of associated private keys by the KDS administrator on the KDS portal in single or batch mode; The steps include creating an asymmetric key pair by the KDS administrator on the KDS portal and sending a public key creation leaf certificate request to the Certificate Authority, The steps include: updating the expiration of the first plurality of leaf certificates by the KDS administrator on the KDS portal by sending a request to the Certificate Authority; The steps include: creating a new asymmetric key pair and sending a key regeneration leaf certificate request with the leaf certificate and the new public key to the certification authority, thereby performing key regeneration by the KDS administrator on the KDS portal; The KDS administrator on the KDS portal retrieves a second set of leaf certificates and a second set of associated private keys as a batch generated by the Certificate Authority and associated with a batch identifier, The batch is generated either in response to a request from the KDS administrator on the KDS portal or autonomously by the certification authority, step, A step of authenticating with the KDS by the client application running on the first device using the tenant identifier, the symmetric KDS member (M-PSK), the M-PSK identity hint, and the first DNS hostname, wherein the first device is registered with the first DNS hostname in the DNS service configured with the KDS or the KDS proxy, and the first device is registered as the member device in the KDS. A step of obtaining the plurality of trusted intermediate and root certificates, the leaf certificates, and the associated private key from the KDS using at least the tenant identifier of the plurality of trusted intermediate and root certificates and the subject name of the leaf certificate, wherein the obtained leaf certificates and the associated private key are used in certificate-based client authentication for mutual authentication via a secure transport protocol during communication with the server application running on the second device, or in data signing by digital signature, or in key unwrapping. A step of initiating a secure session by the client application using a security protocol, wherein the session is initiated using the acquired leaf certificate and the associated private key for certificate-based client authentication in order to establish secure communication with the server application running on the second device, A step of programmatically verifying the certificate status by the client application using the client KDS interface without requiring human intervention and without service interruption, wherein further certificate-based client authentication is performed during certificate renewal or key regeneration by reacquiring the leaf certificate, the associated private key, and the plurality of trusted intermediate and root certificates. Methods that include...

199. A device member authentication handshake is performed by the client KDS interface on the client device, using the tenant identifier, the symmetric KDS member PSK (M-PSK), and the M-PSK identity hint as the first factor of device authentication; further, a session key is generated using a key exchange handshake between the client KDS interface and the KDS or the KDS proxy; and further, device member validation is performed. The steps include performing a DNS reverse lookup of the device member IP address by the KDS or the KDS proxy in order to query the first DNS hostname, The steps include: extracting the first DNS hostname from the resource record in the DNS response using the KDS or the KDS proxy; The steps include comparing and matching the extracted first DNS hostname with the member identifier in multiple KDS requests using the KDS or the KDS proxy, and The method according to claim 198, which is implemented as a second factor of the device authentication.

200. The method according to claim 199, wherein the device authentication and multiple key exchange handshakes are performed via a connectionless UDP or connection-oriented TCP transport protocol without requiring a security transport protocol, and further, data authentication and / or data encryption are performed with the retrieved pre-shared key using any communication protocol.

201. The method according to claim 198, wherein the client KDS interface provides a plurality of application programming interfaces (APIs), and the client application directly sends a plurality of requests for key and certificate operations to the KDS and directly receives a plurality of responses for key and certificate operations from the KDS, or the client application indirectly sends a plurality of requests for key and certificate operations through the KDS proxy and indirectly receives a plurality of responses for key and certificate operations through the KDS proxy.

202. The method according to claim 198, wherein the client device is registered in the IP address (A) record and PTR record used for DNS hostname reverse lookup by a unique DNS hostname in the domain on the local DNS service.

203. The method according to claim 198, wherein in the KDS, the first device is configured as a member of the tenancy associated with the tenant identifier.

204. The method of claim 198, wherein a request from an authenticated member device for any certificate operation based on the tenant identifier and the application identifier is processed by the KDS and permitted based on a match with the application identifier associated with the tenant identifier, and the KDS is configured to allow or reject the certificate operation.

205. The method according to claim 198, wherein the client application uses the acquired leaf certificate and the associated private key for data signing by digital signature.

206. The method according to claim 198, wherein the client application uses the acquired leaf certificate for key unwrapping.

207. The method according to claim 198, wherein, in response to a request from the KDS administrator in the KDS portal, the Certificate Authority generates a plurality of asymmetric key pairs and a plurality of second leaf certificates for associated generated public keys, and sends the generated plurality of second leaf certificates and associated generated private key files to the KDS portal.

208. The method of claim 198, wherein a lookup is performed in the leaf certificate for retrieval by the first device using the client KDS interface, (i) to find a match between the subject name and the member UUID, the member identifier, or the member DNS hostname, or further, the lookup and matching of the leaf certificate is performed automatically by the KDS during device discovery and onboarding.

209. A method for importing, creating, updating, recreating, retrieving, assigning, or acquiring leaf certificates for the public key and associated private key of an asymmetric key pair, used in server authentication by applications running on distributed devices in an Internet of Things (IoT), Industrial IoT (IIoT), or Operational Technology (OT) environment, in data signing with digital signatures, and in key unwrapping, The steps include providing a client application running on a first device, a server application running on a second device, multiple trusted intermediate certificates and trusted root certificates issued by a Certificate Authority (CA), a Key Distribution Service (KDS), a KDS portal, a KDS administrator, a KDS proxy, a server KDS interface, a member identifier, a member universally unique identifier (UUJID), a member Domain Name System (DNS) hostname, a symmetric KDS member (M-PSK), an M-PSK identity hint, a tenant identifier, an application identifier, a Dynamic Host Configuration Protocol (DHCP) service, and a Domain Name System (DNS) service, The steps include: importing a first set of leaf certificates and a first set of associated private keys by the KDS administrator on the KDS portal in single or batch mode; The steps include creating an asymmetric key pair by the KDS administrator on the KDS portal and sending a public key creation leaf certificate request to the Certificate Authority, The steps include: updating the expiration of the first plurality of leaf certificates by the KDS administrator on the KDS portal by sending a request to the Certificate Authority; The KDS administrator on the KDS portal performs key regeneration by creating a new asymmetric key pair and sending a key regeneration leaf certificate request with the leaf certificate and the new public key to the certification authority. The KDS administrator on the KDS portal retrieves a second plurality of leaf certificates and a second plurality of associated private keys as a batch generated by the Certificate Authority and associated with the batch identifier, The batch is generated either in response to a request from the KDS administrator on the KDS portal or autonomously by the certification authority, step, A step of authenticating with the KDS by the server application running on the second device using the tenant identifier, the symmetric KDS member (M-PSK), the M-PSK identity hint, and the second DNS hostname, wherein the second device is registered by the second DNS hostname on the DNS server configured with the KDS or the KDS proxy, and the second device is registered as a member device in the KDS. A step of obtaining the plurality of trusted intermediate and root certificates, the leaf certificates, and the associated private key from the KDS using at least the tenant identifier of the plurality of trusted intermediate and root certificates and the subject name of the leaf certificate, wherein the obtained leaf certificates and the associated private key are used in certificate-based server authentication via a secure transport protocol during communication with the client application running on the first device, or in data signing by digital signature, or in key unwrapping. A step of initiating a secure session using a security protocol by the server application, wherein the session is initiated using the acquired leaf certificate and the associated private key for certificate-based server authentication in order to establish secure communication with the client application running on the first device, A step of programmatically verifying the certificate status by the server application using the server KDS interface without requiring human intervention and without service interruption, wherein further certificate-based server authentication is performed during certificate renewal or key regeneration by reacquiring the leaf certificate, the associated private key, and the plurality of trusted intermediate and root certificates. Methods that include...

210. A device member authentication handshake is performed by the server KDS interface on the second device, using the tenant identifier, the symmetric KDS member PSK (M-PSK), and the M-PSK identity hint as the first factor of device authentication; further, a session key is generated using a key exchange handshake between the server KDS interface and the KDS or the KDS proxy; and further, device member validation is performed. The steps include performing a DNS reverse lookup of the device member IP address by the KDS or the KDS proxy in order to query the first DNS hostname, The steps include: extracting the first DNS hostname from the resource record in the DNS response using the KDS or the KDS proxy; The steps include comparing and matching the extracted first DNS hostname with the member identifier in multiple KDS requests using the KDS or the KDS proxy, and The method according to claim 209, which is performed as a second factor of the device authentication.

211. The method according to claim 209, wherein the device authentication and multiple key exchange handshakes are performed via a connectionless UDP or connection-oriented TCP transport protocol without requiring a security transport protocol, and further, data authentication and / or data encryption are performed with the retrieved pre-shared key using any communication protocol.

212. The method according to claim 209, wherein the server KDS interface provides a plurality of application programming interfaces (APIs), and the server application directly sends a plurality of requests for key and certificate operations to the KDS and directly receives a plurality of responses for key and certificate operations from the KDS, or the server application indirectly sends a plurality of requests for key and certificate operations through the KDS proxy and indirectly receives a plurality of responses for key and certificate operations through the KDS proxy.

213. The method according to claim 209, wherein the second device is registered in the IP address (A) record and PTR record used for DNS hostname reverse lookup by a unique DNS hostname in the domain on the local DNS service.

214. The method according to claim 209, wherein in the KDS, the second device is configured as a member of the tenancy associated with the tenant identifier.

215. The method according to claim 209, wherein a request from an authenticated second device for any certificate operation based on the tenant identifier and the application identifier is processed by the KDS and permitted based on a match with the application identifier associated with the tenant identifier, and the KDS is configured to allow or reject the certificate operation.

216. The method according to claim 209, wherein the server application uses the acquired leaf certificate and the associated private key for data signing by digital signature.

217. The method according to claim 209, wherein the server application uses the acquired leaf certificate key unwrapping.

218. The method according to claim 209, wherein, in response to a request from the KDS administrator in the KDS portal, the Certificate Authority generates a plurality of second leaf certificates for a plurality of asymmetric key pairs and associated generated public keys, and sends the generated second leaf certificates and associated generated private key files to the KDS portal.

219. The method according to claim 209, wherein a lookup is performed in the leaf certificate for retrieval by the second device using the server KDS interface, (i) to find a match between the subject name and the member UUID, the member identifier, or the member DNS hostname, or further, the lookup and matching of the leaf certificate is performed automatically by the KDS during device discovery and onboarding.

220. A method for configuring, generating, issuing, sending, and verifying a client certificate to a first device used in client authentication between applications running on distributed devices in an Internet of Things (IoT), Industrial IoT (IIoT), or Operational Technology (OT) environment, comprising: a client application running on the first device; a server application running on a second device; a client certificate issued by a Certificate Authority (CA); a Key Distribution Service (KDS); a KDS portal; a KDS administrator; a KDS proxy; a client KDS interface; a member identifier; a member universally unique identifier (UUID); a member Domain Name System (DNS) hostname; a symmetric KDS member (M-PSK); an M-PSK identity hint; a tenant identifier; an application identifier; a Dynamic Host Configuration Protocol (DHCP) service; and a Domain Name System (DNS) service. The steps include configuring the vendor class identifier, scope, and address pool as an IP address range or subnet in the DHCP service, The steps include configuring a certificate template, a Certificate Authority (CA) identifier, the first device, a device group, and a device type in the KDS portal, The steps include configuring the first device of the aforementioned device type in the KDS portal, The steps include configuring the first device as a member of the device group in the KDS portal, The KDS receives a request from the first device for a client certificate at an IP address for a subject name (SN) set as the local identifier of the first device, A step of generating a Certificate Signing Request (CSR) having the received Subject Name (SN) using the KDS, and automatically adding the X.509 extended attribute to the Subject Alternative Name (SAN), wherein the X.509 extended attribute includes the IP address, network address, and network mask of the first device in the certificate template associated with at least one of the device groups or device types of the first device, and the initial identifier of the first device associated with the local identifier of the first device is set in the received Subject Name (SN), The steps include issuing a client certificate using the KDS and sending the client certificate to the first device, A step of authenticating with the KDS by the client application running on the first device using the tenant identifier, the symmetric KDS member (M-PSK), the M-PSK identity hint, and the first DNS hostname, wherein the first device is registered with the first DNS hostname in the DNS service configured with the KDS or the KDS proxy, and the first device is registered as a member device in the KDS. A step in which the client application running on the first device obtains a plurality of trusted certificates, the client certificate, and an associated private key from the KDS using at least the tenant identifier of the plurality of trusted certificates and the subject name of the client certificate, The acquired client certificate and the associated private key are used in certificate-based client authentication. The certificate-based client authentication is performed via a secure transport protocol during data signing with a digital signature or key unwrapping while communicating with the server application running on the second device. The certificate-based client authentication provides mutual authentication in the following steps: A step of initiating a secure session using a security protocol by the client application running on the first device, wherein the session is initiated using the acquired client certificate and the associated private key that provide certificate-based client authentication, and secure communication is established with the server application running on the second device. A step of sending the client certificate to the server application running on the second device by the client application running on the first device, wherein the client certificate is sent during a protocol-specific handshake for client authentication. A step of verifying the IP address or subnet of the first device by the server application running on the second device, wherein the verification includes validating the client certificate based on the X.509 extended attribute in the Subject Alternative Name (SAN) field of the client certificate, If the host address or network subnet in the client certificate matches the IP address of the first device or subnet, the server application running on the second device grants authorization to the client certificate, and the protocol-specific handshake for client authentication continues. Methods that include...

221. A device member authentication handshake is performed by the client KDS interface on the first device, using the tenant identifier, the symmetric KDS member PSK (M-PSK), and the M-PSK identity hint as the first factors of device authentication; further, a session key is generated using a key exchange handshake between the client KDS interface and the KDS or the KDS proxy; and further, device member validation is performed. The steps include performing a DNS reverse lookup of the device member IP address by the KDS or the KDS proxy in order to query the first DNS hostname, The steps include: extracting the first DNS hostname from the resource record in the DNS response using the KDS or the KDS proxy; The steps include comparing and matching the extracted first DNS hostname with the member identifier in multiple KDS requests using the KDS or the KDS proxy, and The method according to claim 220, which is performed as a second factor of the device authentication.

222. The method according to claim 220, wherein the device authentication and the multiple certificate and key exchange handshake are performed via a connectionless UDP or connection-oriented TCP transport protocol without requiring a security transport protocol.

223. The method according to claim 220, wherein the step of verification by the server application running on the second device is performed by the presence of a single X.509 extension attribute in the client certificate as the host address, and the single X.509 attributed to the client certificate is used for matching with the IP address of the first device in the protocol-specific handshake.

224. The method according to claim 223, wherein the validation of the IP address of the first device is performed by the KDS proxy based on the scope of the vendor class identifier configured in the DHCP service and the address pool.

225. The method according to claim 220, wherein the step of verification by the server application running on the second device is performed based on two X.509 extension attributes in the client certificate, the two X.509 extension attributes comprising the network address and the network mask, the network address and the network mask are used for matching with the subnet address of the first device in the protocol-specific handshake.

226. The method according to claim 225, wherein the validation of the subnet address of the first device is performed based on the scope of the vendor class identifier configured in the DHCP service and the address pool.

227. The method according to claim 220, wherein the step of verification by the server application running on the second device is performed based on three X.509 extended attributes, the host address, network address, and network mask matching the host address and subnet address of the first device, respectively, in the protocol-specific handshake.

228. The method according to claim 220, wherein the client certificate is a self-signed certificate, or the client certificate is a certificate issued by a trusted public or private certificate authority.

229. The method according to claim 220, wherein, before sending the client certificate to the first device, the application identifier in the request by the client application to the KDS for retrieving the client certificate is verified by the KDS, and the client application running on the first device is validated to be configured as a trusted application in the KDS portal.

230. The method according to claim 220, wherein the step of verification by the server application running on the second device is performed based on a number of pairs of X.509 extended attributes, each of which pairs of X.509 extended attributes specifies a network address and a network mask, and the respective network address and network mask are used to match the host address and subnet address of the first device in the protocol-specific handshake.

231. A method for configuring a metadata connector, including a client application running on a client device, a Key Distribution Service (KDS), a KDS portal, a KDS administrator, a KDS proxy, a client KDS interface, a member identifier, a member universally unique identifier (UUID), a member Domain Name System (DNS) hostname, and a webhook, sending metadata by the client device, receiving metadata by a service, processing it, and sending it to the webhook, The steps include configuring multiple metadata connectors in the KDS portal, The steps include: authenticating the client device using two-factor authentication with the KDS service or KDS proxy; The steps include sending a message via the client application on the client device using the client KDS interface, The steps include receiving the device metadata through the KDS service, The steps include processing the received device metadata for the configured metadata connector, The steps include sending the received device metadata to the webhook URL, The steps include processing and storing the received device metadata using the webhook of the service provider, and Methods that include...

232. The method according to claim 231, wherein the metadata connector includes at least a service provider name, a filter type, a filter name, a webhook specified as a generic resource locator (URL), an API token, an API secret, and a filter measure specified as a list of metadata types and metadata identifiers, wherein the filter type is specified as a device type or a device group.

233. The method according to claim 231, wherein the exported device metadata includes a metadata identifier, a metadata type, and a metadata value, wherein the metadata type includes at least one of plaintext, formatted text, integer, decimal, image, video, and audio.

234. The method according to claim 231, wherein the metadata type, which is plain text or formatted text, includes any application-defined telemetry, status, or log messages.

235. The filter configured for the metadata connector is applied by the KDS service, and the received device metadata, along with the filter type and filter name, is matched based on the filter scale. The associated device member identifier of the client device is sent to the webhook URL as the payload in the HTTP request. The method according to claim 231, wherein the associated device member identifier includes at least one of the member UUID, member identifier, and member DNS host name.

236. The method according to claim 231, wherein the received device metadata is processed by the webhook of the service provider as feature vectors for training an AI / ML model, and further by intentionally applying methods, each including at least one of linear or logistic regression, neural networks, cyber risk, threats to the device, and decision trees for evaluation, prediction, and analysis of application security.

237. The method according to claim 231, wherein the response from the webhook is processed by the KDS service and stored in the device metadata repository.

Images