General-purpose device identifiers and signal exchange integration

Abstract

In certain aspects of this disclosure, a computer implementation method includes registering at least one managed device in a mobile device management service. This method includes receiving a client certificate on at least one managed device. This method includes integrating a generic device identifier SDK via a trusted ecosystem vendor app on at least one managed device. This method includes obtaining a pre-salted device identifier address associated with at least one managed device by the generic device identifier SDK based on a request from the trusted ecosystem vendor app. This method includes at least one managed device sending the pre-salted device identifier address to a security vendor service via a trusted ecosystem vendor to generate a generic device identifier address. This method includes at least one managed device receiving a generic device identifier address from the security vendor service via a trusted ecosystem vendor.

Description

Cross - Reference to Related Applications ,

[0001] This application claims the benefit of priority under 35 U.S.C. § 119 based on U.S. Provisional Patent Application No. 63 / 484,997, titled "Universal Device Identifiers and Signal Exchange", filed on February 14, 2023, the disclosure of which is hereby incorporated by reference in its entirety for all purposes.

Technical Field

[0002] This disclosure generally relates to device identifiers, and more specifically to the generation of universal open device identifiers.

Background Art

[0003] It is difficult for a trusted ecosystem vendor or participant (e.g., security vendor and application provider) to establish a common identifier for which everyone can obtain and agree upon for a particular physical device asset. This is mainly due to open - source (OS) vendors restricting the ability of applications to obtain a common device identifier for privacy and anti - tracking purposes. However, in the case of enterprise security, it is reasonable and necessary for multiple security tools to establish opaque identifiers that can be used by all trusted ecosystem vendors or participants to identify a particular physical asset. <00​​​​​The descriptions provided in the background of this invention should not be assumed to be prior art simply because they are described in or related to the background section. The background of this invention may include information describing one or more aspects of the subject art. [Overview of the project]

[0006] In certain aspects of this disclosure, the following computer implementation methods are provided: The method includes registering at least one managed device in a mobile device management service; the method includes receiving a client certificate on at least one managed device; the method includes integrating a generic device identifier SDK via a trusted ecosystem vendor app on at least one managed device; the method includes obtaining a pre-salted device identifier address associated with at least one managed device via the generic device identifier endpoint SDK based on a request from the trusted ecosystem vendor app; the method includes at least one managed device sending the pre-salted device identifier address to a security vendor service via a trusted ecosystem vendor in order to generate a generic device identifier address; and the method includes at least one managed device receiving a generic device identifier address from a security vendor service via a trusted ecosystem vendor.

[0007] In certain aspects of this disclosure, the following system is provided: The system includes one or more memories containing instructions and one or more processors configured to execute instructions, which, when executed, cause one or more processors to register at least one managed device in a mobile device management service. The one or more processors, when executed, are configured to execute instructions causing one or more processors to receive client certificates on at least one managed device. The one or more processors, when executed, are configured to execute instructions causing one or more processors to integrate a generic device identifier SDK via a trusted ecosystem vendor app on at least one managed device. The one or more processors, when executed, are configured to execute instructions causing one or more processors to obtain a pre-salted device identifier address associated with at least one managed device via a generic device identifier endpoint SDK based on a request from a trusted ecosystem vendor app. The one or more processors, when executed, are configured to execute instructions causing at least one managed device to send a pre-salted device identifier address via a trusted ecosystem vendor to a security vendor service in order to generate a generic device identifier address. One or more processors, when executed, are configured to execute instructions causing at least one managed device to receive a generic device identifier address from a security vendor service via a trusted ecosystem vendor.

[0008] In certain aspects of this disclosure, the following computer implementation method is provided: This method includes associating a generic device identifier address with a vendor device ID associated with at least one managed device; this method includes modifying metadata in a database based on a change in the risk status associated with at least one managed device; and this method includes publishing the change in the risk status as an entry in a distributed ledger using a generic device identifier secret key associated with the generic device identifier address.

[0009] According to certain aspects of this disclosure, the following system is provided: The system includes one or more memories containing instructions and one or more processors configured to execute instructions, which, when executed, cause one or more processors to associate a generic device identifier address with a vendor device ID associated with at least one managed device. The one or more processors, when executed, are configured to execute instructions that cause one or more processors to modify metadata in a database based on changes in the risk status associated with at least one managed device. The one or more processors, when executed, are configured to execute instructions that cause one or more processors to publish changes in the risk status as entries in a distributed ledger using a generic device identifier secret key associated with a generic device identifier address.

[0010] It will be understood that other configurations of the subject art will be readily apparent to those skilled in the art from the following detailed description, and various configurations of the subject art are illustrated and described by example. As realized, the subject art is capable of other different configurations, and several of its details can be modified in various other ways without departing from the scope of the subject art. Various embodiments may be described herein with reference to medical, retail, educational, or corporate settings, but these should be noted as examples only and not to be considered limiting. The teachings of this disclosure can be applied to any mobile device environment, including but not limited to residential, medical, retail, educational, corporate, and other appropriate environments. Accordingly, the drawings and detailed description should be considered illustrative rather than limiting. [Brief explanation of the drawing]

[0011] The accompanying drawings are included to provide further understanding, are incorporated herein, constitute part of this specification, illustrate the disclosed embodiments, and serve to illustrate the principles of the disclosed embodiments together with the description. In the drawings:

[0012] [Figure 1] Figure 1 shows an exemplary architecture for generating a general-purpose device identifier.

[0013] [Figure 2] Figure 2 is a block diagram illustrating an exemplary mobile device management service, at least one managed device, a certificate authority service, a security vendor service, a push notification service, and a distributed ledger from the architecture of Figure 1, according to a particular aspect of the disclosure.

[0014] [Figure 3] Figure 3 is a diagram illustrating an exemplary flowchart for generating a general-purpose device identifier according to a particular aspect of the disclosure.

[0015] [Figure 4]Figure 4 is a diagram illustrating an exemplary flowchart for exchanging device metadata via a blockchain using a generic device identifier address associated with a generic device identifier generated in Figure 3 according to a specific aspect of the disclosure.

[0016] [Figure 5] Figure 5 is a block diagram showing an alternative, exemplary flowchart for generating a general-purpose device identifier according to a particular aspect of the disclosure.

[0017] [Figure 6] Figure 6 is a block diagram showing a distributed ledger (such as a blockchain public ledger) for a trusted ecosystem vendor or participant related to the flowchart in Figure 5, depending on the specific aspect of disclosure.

[0018] [Figure 7] Figure 7 shows an exemplary process for generating a generic device identifier using the exemplary mobile device management service, at least one managed device, a certificate authority service, a security vendor service, and a push notification service shown in Figure 2.

[0019] [Figure 8] Figure 8 shows an exemplary process for generating a generic device identifier using the exemplary mobile device management service, at least one managed device, a certificate authority service, a security vendor service, a push notification service, and a distributed ledger as shown in Figure 2.

[0020] [Figure 9] Figure 9 is a block diagram illustrating an exemplary computer system that can implement the mobile device management service, at least one managed device, certificate authority service, security vendor service, and push notification service shown in Figure 2.

[0021] In one or more implementations, not all of the components depicted in each figure are required, and one or more implementations may include additional components not shown in the figures. Changes to the arrangement and type of components can be made without departing from the scope of the subject disclosure of the present invention. Additional components, different components, or fewer components may be utilized within the scope of the subject disclosure.

Best Mode for Carrying Out the Invention

[0022] The detailed description set forth below is intended as a description of various implementations and is not intended to represent the only implementation in which the subject technology may be practiced. As will be recognized by those of skill in the art, the described implementations may be modified in various different ways without departing from the scope of the present disclosure. Accordingly, the drawings and description are to be regarded as illustrative in nature and not as restrictive.

[0023] Encryption and secure hardware back key stores are supported by a large number of different combinations of cryptography. Common standards between trusted ecosystem vendors, hardware, and operating systems will significantly improve future signal exchange interoperability. For example, by expanding these standards, portability of use can be further improved. These standards can be extended, for example, to other open standards (e.g., public key cryptography, blockchain, etc.).

[0024] In certain embodiments of the disclosed technology, a generic device identifier is created that can be deployed and seeded using device management (e.g., mobile device management), but is not limited to this, thereby eliminating the traditional need for specific device management vendors and conforming to clearly defined standards. In certain embodiments, a generic device identifier (address) compatible with distributed ledger systems (e.g., blockchain) is created, and public or private blockchains may be used for thread exchange in a truly decentralized manner. In certain embodiments, the disclosed technology utilizes system-level public keys as private key inputs for further key generation sets, thus adding compatibility between trusted ecosystem vendors and key types. The disclosed technology has an advantage over existing technologies in that the trust chain can be derived and its authenticity proven by tracing it back to the original system-level key pair. In certain embodiments, the disclosed technology leverages blockchain technology to exchange signals and metadata among members (e.g., trusted ecosystem vendors or participants) by using these generic device identifiers as device subject identifiers.

[0025] Figure 1 shows an exemplary architecture 100 for generating a general-purpose device identifier. For example, architecture 100 includes a mobile device management service 10, at least one managed device 12 such as a first managed device 12a, a second managed device 12b, an nth managed device 12n, a certificate authority service 14, a security vendor service 16, a push notification service 18, and in a particular embodiment, a distributed ledger 20, all connected via a network 22. In a particular embodiment, the mobile device management service 10 may be connected to the push notification service 18 via a separate network.

[0026] The mobile device management service 10 can be any device having a suitable processor, memory, and communication capabilities for communicating with at least one managed device 12, a certificate authority service 14, a security vendor service 16, a push notification service 18, and, in certain embodiments, a distributed ledger 20. For load balancing purposes, the mobile device management service 10 may include multiple servers. The certificate authority service 14 can be any device having a suitable processor, memory, and communication capabilities for communicating with the mobile device management service 10, the certificate authority service 14, the security vendor service 16, at least one managed device 12, and, in certain embodiments, a distributed ledger 20. The security vendor service 16 can be any device having a suitable processor, memory, and communication capabilities for communicating with the mobile device management service 10, the certificate authority service 14, the security vendor service 16, at least one managed device 12, and, in certain embodiments, a distributed ledger 20.

[0027] The push notification service 18 can be any device having a suitable processor, memory, and communication capabilities for communicating with the mobile device management service 10 and at least one managed device 12. In a particular embodiment, the distributed ledger 20 can be any device having a suitable processor, memory, and communication capabilities for communicating with the mobile device management service 10, at least one managed device 12, the certificate authority service 14, and the security vendor service 16. The at least one managed device 12, such as a first managed device 12a and a second managed device 12b, with which the mobile device management service 10 communicates via the push notification service 18 through the network 22, can be, for example, a tablet computer, a mobile phone, a mobile computer, a laptop computer, a portable media player, an eBook reader, or any other device having a suitable processor, memory, and communication capabilities. In certain embodiments, the mobile device management service 10, certificate authority service 14, security vendor service 16, and push notification service 18 can be infrastructure-as-a-service (IaaS) cloud computing servers and can support platform-as-a-service (PaaS) and software-as-a-service (SaaS) services.

[0028] It should be noted that this disclosure is not limited to any particular configuration or number of devices. In certain embodiments, there may be different numbers of devices.

[0029] Network 22 may include, for example, one or more of the following: Personal Area Network (PAN), Local Area Network (LAN), Campus Area Network (CAN), Metropolitan Area Network (MAN), Wide Area Network (WAN), Broadband Network (BBN), Internet, etc. Furthermore, Network 22 may include, but is not limited to, one or more of the following network topologies, including bus networks, star networks, ring networks, mesh networks, star bus networks, tree or hierarchical networks, etc.

[0030] Figure 2 is a block diagram illustrating an example of the architecture of Figure 1, including a mobile device management service 10, at least one managed device 12 such as a first managed device 12a, a certificate authority service 14, a security vendor service 16, a push notification service 18, and, in a particular aspect, a distributed ledger 20, according to a particular aspect of the disclosure. For illustrative purposes, we will describe the first managed device 12a, but it should be understood that any number of at least one managed device 12 can be used.

[0031] The mobile device management service 10, at least one managed device 12 such as the first managed device 12a, the certificate authority service 14, the security vendor service 16, and the push notification service 18 are connected through the network 22 via their respective communication modules 24, 26, 28, 30, and 32. The communication modules 24, 26, 28, 30, and 32 are configured to interface with the network 22 and send and receive information such as data, requests, responses, and commands to and from other devices on the network 22. The communication modules 24, 26, 28, 30, and 32 can be, for example, modems or Ethernet cards.

[0032] The mobile device management service 10 includes a processor 34, a communication module 24, and memory 36. The processor 34 of the mobile device management service 10 is configured to execute instructions such as instructions physically coded into the processor 34, instructions received from software in memory 36, or a combination of both. The processor 34 of the mobile device management service 10 is configured to perform any of its functions described herein.

[0033] The certificate authority service 14 includes a processor 38, a communication module 28, and memory 40. The processor 38 of the certificate authority service 14 is configured to execute instructions such as instructions physically coded into the processor 38, instructions received from software in memory 40, or a combination of both. The processor 38 of the certificate authority service 14 is configured to perform any of its functions as described herein.

[0034] The security vendor service 16 includes a processor 42, a communication module 30, and memory 44. The processor 42 of the security vendor service 16 is configured to execute instructions such as instructions physically coded into the processor 42, instructions received from software in memory 44, or a combination of both. The processor 42 of the security vendor service 16 is configured to perform any of its functions described herein.

[0035] The push notification service 18 includes a processor 46, a communication module 32, and memory 48. The processor 42 of the push notification service 18 is configured to execute instructions such as instructions physically coded to the processor 46, instructions received from software in memory 48, or a combination of both. The processor 42 of the push notification service 18 is configured to perform any of its functions as described herein.

[0036] At least one managed device 12, such as the first managed device 12a, includes a processor 50, a communication module 26, and memory 52. ​​The processor 42 of at least one managed device 12 is configured to execute instructions such as instructions physically coded to the processor 50, instructions received from software in memory 52, or a combination of both. The processor 42 of at least one managed device 12 is configured to perform any of its functions described herein.

[0037] The distributed ledger 20 can be, but is not limited to, a blockchain or other suitable distributed ledger.

[0038] Referring to Figures 2 and 3, the disclosed technology provides a method, system, and non-temporary machine-readable storage medium for generating a general-purpose device identifier. An exemplary method for generating a general-purpose device identifier (e.g., a shared identifier) ​​may include the following steps: a. At least one managed device 12 (e.g., macOS, Windows, iOS / iPadOS, Android) may be registered with a device management system such as a mobile device management service 10 (e.g., Jamf Pro, Microsoft Intune, Mobile Device Management System, etc.). b. A certificate-based identity (e.g., client certificate 54) is issued by the Certificate Authority Service 14 and installed on at least one managed device 12. a. Use any certificate authority (public or private), such as Certificate Authority Services 14. b. Generate the private key 56 for certificate 54 on at least one managed device 12 (e.g., SCEP, ACME). c. Generate a private key 56 on-device on at least one managed device 12 in a non-exportable / non-extractable manner. d. In a particular embodiment, a secret key 56 is generated using a hardware back keystore 58 on at least one managed device 12 to enhance security. e. Using a device certification service in a specific embodiment c. All participating trusted ecosystem vendor endpoint agent software (e.g., trusted ecosystem vendor app 60) runs on the target device (e.g., at least one managed device 12) and integrates the new generic device identifier SDK 62 described in this disclosure. d. A participating trusted ecosystem vendor software (e.g., trusted ecosystem vendor app 60) calls a single function in the generic device identifier SDK 62 to request the pre-salted device identifier address 64 of a device (e.g., at least one managed device 12). This function behaves as follows at the generic device identifier endpoint SDK 66 when called: a. Verify that the trust chain of the client certificate (e.g., client certificate 54) installed by the MDM (e.g., Mobile Device Management Service 10) was issued by a certificate authority trusted by the enterprise (e.g., Certificate Authority Service 14). b. The generic device identifier endpoint SDK66 generates a nonce 68 to challenge the hardware back keystore 58 using the API. c. The generic device identifier endpoint SDK66 refers to the client certificate 54 installed by the subject (or other) attribute (e.g., CN=generic device identifier, OID 1.2.3.4.x, etc.) and sends the nonce 68 to the keystore 58. d. Using the private key 56 in keystore 58, keystore 58 returns a signed nonce challenge response 68 along with the corresponding public certificate / key 70. e. The generic device identifier endpoint SDK66 verifies the nonce response68 using the returned public key72. f. The generic device identifier endpoint SDK66 verifies the integrity of the private key 56 using available platform-specific certification services / functions. g. The generic device identifier endpoint SDK66 returns a pre-salted device identifier (e.g., pre-salted device identifier address 64) to the calling application. e. The pre-salted device identifier (e.g., pre-salted device identifier address 64) is sent by a trusted ecosystem vendor app 60 to the cloud backend (e.g., security vendor service 16) via existing vendor-specific mechanisms and means. f. The security vendor service 16 generates a value 76 by hashing a pre-salted device identifier (e.g., pre-salted device identifier address 64) with a secret (string or administrator-defined salt 74) entered by the customer administrator on the backend / console of a trusted ecosystem vendor communicating with the security vendor service 16. a. All trusted ecosystem vendors are required to define this shared secret (string or administrator-defined salt) to prove that the vendor has the authority to generate identifiers (e.g., private keys 56) in the customer's environment (e.g., at least one managed device 12). g. In certain embodiments, the resulting value 76 may be subject to any of the following further processing: a. Using the hash generated in the previous step, a new key pair is generated using the SECP256K1 key generation algorithm. This new key pair is known as the generic device identifier key pair 78, which contains the generic device identifier private key 80 and the generic device identifier public key 82. b. The general-purpose device identifier secret key 80 may be associated with and stored with a logical device entry and is used to decrypt the payload when receiving a message in which this device (e.g., at least one managed device 12) is the subject of the message. c. The generic device identifier public key 82 is associated with and stored for this device (e.g., at least one managed device 12) and used for message encryption for signaling with other ecosystem vendors. The value of the generic device identifier public key 82 is hashed using an algorithm to generate a byte string. i. In certain embodiments, the disclosed technology may, for example, use the keccak-256 hash algorithm for Ethereum blockchain compatibility. d. With this option, the resulting string is truncated to the last 20 bytes (40 characters) and "0x" is prepended to it. i. This step is optional, but is required in some distributed ledgers, such as for Ethereum blockchain address compatibility. e. This generates a final general-purpose device identifier address 84, which is represented as a hexadecimal address with a length of 42 characters. f. The general-purpose device identifier address 84 is associated with a logical device (e.g., at least one managed device 12) in the ecosystem vendor's database and is used as the final correlated device identifier. h. A participating trusted ecosystem vendor app 60 possesses a generic device identifier address 84 that can be used as a generic device identifier for subsequent inter-vendor (e.g., trusted ecosystem vendor) communication and logging use cases: a. Send event logs to one or more SIEM / SOAR / Datalake / BI tools, referencing a device (e.g., at least one managed device 12) by its generic device identifier address 84 as the primary correlation identifier for the device. b. Use the generic device identifier address 84 as the device ID / subject / correlation identifier to publish events to other trusted ecosystem vendors using other proprietary or open standards (e.g., OpenID SSF / CAEP). c. Encode in exchange for cross-domain packet flow. d. The "To" recipient submits the event as a ledger entry to the distributed ledger 20 (e.g., blockchain), which is a generic device identifier address 84 value. e. Such events can be dequeued from trusted ecosystem vendor endpoint agent software (e.g., trusted ecosystem vendor app60), backend cloud / on-premises services, or both, depending on out-of-scope use case requirements. i. Other participating trusted ecosystem vendors can repeat the exact same steps above for their endpoint applications and backends. All participating trusted ecosystem vendors signal to each other and to ecosystem tools using a common, universally unique, and cryptographically difficult-to-spoof correlation identifier (e.g., a generic device identifier). j. Generic Device Identifiers: Vendor consumers can also embed the Generic Device Identifier SDK66 into their applications to obtain the Generic Device Identifier address 84 of the device on which the application binary is running (e.g., at least one managed device 12) using the process described above. a. This application (e.g., Generic Device Identifier SDK66) or its backend (e.g., Security Vendor Service 16) can use the Generic Device Identifier address 84 to reference / subscribe to specific trusted ecosystem security vendor events and derive the trust status of a device (either via vendor-specific APIs or, ideally, a decentralized blockchain).

[0039] Furthermore, referring to Figure 2-4, the disclosed technology provides a method, system, and non-temporary machine-readable storage medium for exchanging device metadata of a device via a distributed ledger (e.g., a blockchain) using a generic device identifier address associated with the device's generic device identifier. An exemplary method for exchanging device metadata of a device via a distributed ledger (e.g., a blockchain) using a generic device identifier address associated with the device's generic device identifier may include the following steps: a. Following the above, with reference to Figure 3, a participating trusted ecosystem vendor (e.g., security vendor service 16) associates the generic device identifier address 84 obtained from the generic device identifier endpoint SDK 66 with a unique representation (e.g., vendor device ID 86) of a specific device identifier associated with a device (e.g., at least one managed device 12). b. When the risk status 88 or context of the device changes, metadata associated with the device (e.g., at least one managed device 12) is modified in the database 90 / records of the trusted ecosystem vendors in which it participates. c. With each relevant change, the new entry is published to the public blockchain ledger (e.g., distributed ledger 20) using the institutional private key of a trusted ecosystem security vendor used for blockchain ledger entries (e.g., generic device identifier private key 80). No values ​​need to be sent; only mining / gas fees are required along with the aforementioned metadata. a. The metadata to be made public should be encrypted using a private key derived during the SECP256K1 key pair generation process (e.g., the generic device identifier private key 80), or obfuscated in other ways (e.g., using zero-knowledge proofs) to protect the privacy of the data to be made public on the blockchain (e.g., the distributed ledger 20). d. The entry is verified by a blockchain (e.g., distributed ledger 20) miner, and the updated representation of the device (e.g., distributed ledger 20) becomes readable by anyone. e. In order to limit data intrusion that may be possible on public blockchains, invalid "noise" may be exposed to the blockchain in the form of additional ledger entries. f. Blockchain subscribers (e.g., other participating trusted ecosystem vendors) observe new entries. g. The "From" address of an entry is matched against a "permitted" list of trusted ecosystem vendors that the subscriber consuming the entry trusts. a. If the "from" address is not in this list, such an entry may represent a) an untrusted security vendor, b) a malicious entry that should be ignored, or c) a malicious entry that should be evaluated as an indicator of an attack. h. Therefore, subscribers can evaluate all blockchain entries with a specific "To" generic device identifier address to capture the cradle-to-grave threat exposure and trusted ecosystem security vendor assessment risk status of that device over time. a. This eliminates the single vendor / entity that can be the designated interpreter of threat intelligence on the blockchain (e.g., Distributed Ledger 20). i. Subscribers can use a private key generated as part of the SECP256K1 process for observed generic device identifier addresses to ingest and decrypt the contents of blockchain entries. j. Subscribers may use the received signals to apply database updates, enforce policies, or perform any other functions that are substantially expected of the product with the new information.

[0040] Figure 5 is a block diagram showing an alternative, exemplary flowchart for generating a general-purpose device identifier.

[0041] Figure 6 is a block diagram showing a distributed ledger (such as a blockchain public ledger) for a trusted ecosystem vendor or participant related to the flowchart in Figure 5.

[0042] Figure 7 shows an exemplary process 700 that uses a mobile device management service 10, at least one managed device 12 such as a first managed device 12a, a certificate authority service 14, a security vendor service 16, a push notification service 18, and, in certain embodiments, a distributed ledger 20. Figure 7 is described with reference to Figures 2 and 3, but it should be understood that the process steps in Figure 7 may be performed by other systems.

[0043] Process 700 proceeds to step 710, when the processor 34 of the mobile device management service 10 registers at least one managed device 12. As shown in step 712, the processor 50 of at least one managed device 12 receives a client certificate 54. As shown in step 714, the processor 50 of at least one managed device 12 integrates the generic device identifier SDK 62 via the ecosystem vendor app 60. The generic device identifier endpoint SDK obtains a pre-salted device identifier address 64 associated with at least one managed device 12 based on a request from the trusted ecosystem vendor app 60, as shown in step 716. The processor 50 of at least one managed device 12 sends the pre-salted device identifier address 64 to the security vendor service 16 via the ecosystem vendor app 60 to generate a generic device identifier address 84, as shown in step 718. As shown in step 720, the processor 50 of at least one managed device 12 receives a general-purpose device identifier address 84 from the security vendor service 16 via the security vendor service 16.

[0044] Figure 8 shows an exemplary process 800 that uses a mobile device management service 10, at least one managed device 12 such as a first managed device 12a, a certificate authority service 14, a security vendor service 16, a push notification service 18, and, in certain embodiments, a distributed ledger 20. Figure 8 is described with reference to Figure 2-4, but it should be understood that the process steps in Figure 8 may be performed by other systems.

[0045] Process 800 begins with step 810, when the processor 42 of the security vendor service 16 associates a generic device identifier address 84 with a vendor device ID 86 associated with at least one managed device 12. As shown in step 812, the processor 42 of the security vendor service 16 modifies metadata in the database 90 based on a change in risk status 88 associated with at least one managed device 12. The processor 42 of the security vendor service 16 publishes the change in risk status 88 as an entry in the distributed ledger using the generic device identifier secret key 80 associated with the generic device identifier address 84.

[0046] Figure 9 is a block diagram showing an exemplary computer system 900 that can implement the mobile device management service 10, at least one managed device 12 such as the first managed device 12a, a certificate authority service 14, a security vendor service 16, and a push notification service 18 of Figure 2. In certain embodiments, the computer system 900 may be implemented using hardware or a combination of software and hardware, either integrated into a dedicated server or other entity, or distributed across multiple entities.

[0047] The computer system 900 (e.g., a mobile device management service 10, at least one managed device 12 such as a first managed device 12a, a certificate authority service 14, a security vendor service 16, and a push notification service 18) includes a bus 908 or other communication mechanism for communicating information, and processors 902 (e.g., processors 34, 38, 42, 46, 50) coupled with the bus 908 for processing information. According to one embodiment, the computer system 900 can be an IaaS cloud computing server capable of supporting PaaS and SaaS services.

[0048] In addition to hardware, the computer system 900 may include code that creates the execution environment for the computer program in question, such as processor firmware, protocol stacks, database management systems, operating systems, or one or more combinations thereof, which are stored in memory 904 (e.g., memories 36, 40, 44, 48, 52), which includes random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), eraseable PROM (EPROM), registers, hard disks, removable disks, CD-ROMs, DVDs, or any other suitable storage devices, and are coupled to bus 908 to store information and instructions executed by processor 902. Processor 902 and memory 904 may be complemented or incorporated by special-purpose logic circuits.

[0049] The instructions are stored in memory 904 and may be implemented in one or more modules of computer program instructions encoded on a computer-readable medium to perform or control the operation of one or more computer program products, such as computer system 900.

[0050] The computer programs discussed herein do not necessarily correspond to files in a file system. A program may be part of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), a single file dedicated to the program in question, or multiple collaborative files (e.g., a file containing one or more modules, subprograms, or parts of code). Computer programs may be deployed to run on a single computer, or on multiple computers located in one site or distributed across multiple sites interconnected by a communication network, for example, in a cloud computing environment. The processes and logical flows described in this specification may be executed by one or more programmable processors that run one or more computer programs to perform functions by manipulating input data and producing outputs.

[0051] The computer system 900 further includes a data storage device 906, such as a magnetic disk or optical disk, coupled to a bus 908 for storing information and instructions. The computer system 900 may be coupled to various devices via input / output modules 910. The input / output modules 910 can be any input / output module. An exemplary input / output module 910 includes a data port, such as a USB port. Furthermore, the input / output modules 910 may communicate with a processor 902 to enable short-range communication with other devices of the computer system 900. The input / output modules 910 may provide, for example, wired communication in some implementations and wireless communication in other implementations, and multiple interfaces may also be used. The input / output modules 910 are configured to connect to a communication module 912. An exemplary communication module 912 (e.g., communication modules 24, 26, 28, 30, 32) includes a networking interface card, such as an Ethernet card or a modem.

[0052] In certain embodiments, the input / output module 910 is configured to connect to multiple devices, such as an input device 914 and / or an output device 916. An exemplary input device 914 includes a keyboard and pointing device (e.g., a mouse or trackball) that allows a user to provide input to the computer system 900. Other types of input devices 914 may also be used to provide user interaction, such as haptic input devices, visual input devices, audio input devices, or brain-computer interface devices.

[0053] According to one aspect of this disclosure, a mobile device management service 10, at least one managed device 12 such as a first managed device 12a, a certificate authority service 14, a security vendor service 16, and a push notification service 18 may be implemented using a computer system 900 in response to a processor 902 executing one or more sequences of one or more instructions contained in memory 904. Such instructions may be read into memory 904 from other machine-readable media such as a data storage device 906. By executing a sequence of instructions contained in main memory 904, the processor 902 performs the process steps described herein. One or more processors in a multiprocessing arrangement may also be used to execute a sequence of instructions contained in memory 904. The processor 902 may remotely access and process computer program products, for example, by downloading executable instructions and / or data structures from a remote server via a communication module 912 (e.g., as in a cloud computing environment). In an alternative embodiment, hardwired circuits may be used instead of or in combination with software instructions to implement various aspects of this disclosure. Therefore, aspects of this disclosure are not limited to any particular combination of hardware circuitry and software.

[0054] Various aspects of the present invention described in this specification may be implemented in a computing system that includes backend components (e.g., as a data server), middleware components (e.g., as an application server), or frontend components (e.g., as a client computer having a graphical user interface or web browser on which a user can interact with an implementation of the present invention described in this specification), or any combination of one or more such backend, middleware, or frontend components. For example, some aspects of the present invention described in this specification may be executed in a cloud computing environment. Thus, in certain embodiments, a user of the systems and methods disclosed herein may perform at least some steps by accessing a cloud server through a network connection. Furthermore, data files, schematics, performance specifications, etc., resulting from the disclosure may be stored in a database server in the cloud computing environment or downloaded from the cloud computing environment to private storage.

[0055] As used herein, the terms “machine-readable storage medium” or “computer-readable medium” refer to any medium or media that participates in providing instructions or data to the processor 902 for execution. As used herein, the term “storage medium” refers to any permanent recording medium that stores data and / or instructions that cause the machine to operate in a particular way. Such mediums may take many forms, including but not limited to non-volatile media, volatile media, and transmission media.

[0056] As used in the specifications of this application, the terms “computer-readable storage medium” and “computer-readable media” are strictly limited to tangible physical objects that store information in a format readable by a computer. These terms exclude radio signals, wired download signals, and other transient signals. Storage media are distinct from transmission media, although they may be used in conjunction with transmission media. Transmission media are the transfer of information between storage media. For example, transmission media include coaxial cables, copper wires, and optical fibers, including the wires that make up bus 908. Transmission media can also take the form of acoustic or optical waves, such as those generated during radio and infrared data communications. Furthermore, as used in the specifications of this application, the terms “computer,” “server,” “processor,” and “memory” all refer to electronic or other technological devices. These terms exclude persons or groups of persons. For the purposes of the specifications, the terms “display” or “to display” mean a display on an electronic device.

[0057] In one embodiment, a method may be an operation, a command, or a function, and vice versa. In one embodiment, a section or claim may be modified to include some or all of the words (e.g., command, operation, function, or component) contained in one or more sections, one or more words, one or more sentences, one or more phrases, one or more paragraphs, and / or any of the words (e.g., command, operation, function, or component) contained in one or more claims.

[0058] To illustrate hardware-software compatibility, various exemplary blocks, modules, components, methods, operations, instructions, and algorithms are generally described in terms of their functionality. Whether such functionality is implemented in hardware, software, or a combination of hardware and software depends on the specific application and design constraints imposed on the overall system. Experts in this art may implement the described functionality in various ways for each specific application.

[0059] As used herein, the term “at least one” precedes a list of items separated by the terms “and” or “or” and qualifies the entire list rather than each individual item (e.g., each item). The term “at least one” does not require the selection of at least one item. Rather, the term allows for meanings including at least one of any one of the items, and / or at least one of any combination of the items, and / or at least one of each item. For example, the terms “at least one of A, B, and C” or “at least one of A, B, or C” refer to A only, B only, or C only, respectively; any combination of A, B, and C, and / or at least one of each of A, B, and C.

[0060] The word “exemplary” is used herein to mean “serving as an example, illustration, or illustration.” Any embodiment described herein as “exemplary” should not necessarily be construed as being preferable or advantageous to other embodiments. Terms such as aspect, aspect, another aspect, some aspect, one or more aspects, implementation, implementation, another implementation, some implementation, one or more implementations, embodiment, embodiment, another embodiment, some embodiment, one or more embodiments, configuration, configuration, another configuration, some configuration, one or more configurations, subject art, disclosure, this disclosure, other variations and similar, are for convenience only and do not mean that the disclosure relating to such phrases is essential to the subject art or that such disclosures apply to all configurations of the subject art. The disclosure relating to such terms may apply to all configurations or one or more configurations. The disclosure relating to such terms may provide one or more examples. Phrases such as aspect or some aspect may refer to one or more aspects, and this also applies to other aforementioned terms.

[0061] References to elements in the singular form are not intended to mean “one only” unless otherwise stated, but rather “one or more.” The term “part” refers to “one or more.” Underlined and / or italicized headings and subheadings are used for convenience only and do not limit the subject art and are not referenced in connection with the interpretation of the description of the subject art. Relational terms such as “first” and “second” and similar terms may be used to distinguish one entity or action from another without necessarily requiring or implying an actual relationship or order between such entities or actions. All structural and functional equivalents to elements of the various configurations described through this disclosure, which are known to those skilled in the art or will become known later, are expressly incorporated by reference herein and are intended to be encompassed by the subject art. Furthermore, nothing disclosed herein is intended to be dedicated to the public, regardless of whether such disclosure is expressly stated in the above description. No claim element is interpreted under Section 36 of the Patent Act unless the element is expressly described using the phrase “means for” or, in the case of a method claim, uses the phrase “steps for.”

[0062] This specification contains many details, but these should not be interpreted as limitations on the scope that can be claimed, but rather as descriptions of specific implementations of the invention. Certain features described in this specification in the context of separate embodiments may be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may be implemented separately in multiple embodiments or in any suitable subcombinations. Furthermore, features are described above as acting in a particular combination, and may initially be claimed as such, but one or more features from the claimed combination may be excluded from the combination in some cases, and the claimed combination may be directed towards subcombinations or variations of subcombinations.

[0063] While the subject matter of this specification is described in terms of a particular embodiment, other embodiments are also implementable and fall within the scope of the following claims. For example, although operations are depicted in a particular order in the drawings, this should not be understood as requiring that such operations must be performed in a specific or sequential order shown, or that all illustrated operations must be performed, in order to achieve the desired result. Actions described in the claims can achieve the desired result even if performed in a different order. As an example, processes depicted in the accompanying diagrams do not necessarily require a specific or sequential order shown to achieve the desired result. In certain situations, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems may generally be integrated into a single software product or packaged into multiple software products.

[0064] The title, background, brief description of the drawings, abstract, and drawings are incorporated into this disclosure and provided as illustrative examples of the disclosure, not as restrictive descriptions. They are submitted under the understanding that they are not used to limit the scope or meaning of the claims. Furthermore, in the detailed description, it is found that various features are grouped in various implementations for the purpose of streamlining the disclosure. This method of disclosure should not be interpreted as reflecting an intention that the claimed subject matter requires more features than those expressly described in each claim. Rather, as the claims reflect, the inventive subject matter lies in fewer features than all the features of a single disclosed configuration or operation. The claims are incorporated into the detailed description, with each claim being an independent claimed subject matter.

[0065] The claims are not intended to be limited to the embodiments described herein, but are intended to conform to the full scope consistent with the language of the claims and to encompass all legal equivalents. Nevertheless, none of the claims are intended, nor should they be construed, to encompass subject matter that does not meet the requirements of applicable patent law.

Claims

1. A computer implementation method for generating a general-purpose device identifier, In the mobile device management service, at least one managed device must be registered, Receiving a client certificate on at least one of the managed devices, Integrating a general-purpose device identifier SDK via a trusted ecosystem vendor app on at least one of the managed devices, Based on a request from the aforementioned trusted ecosystem vendor application, the generic device identifier endpoint SDK obtains the pre-salted device identifier address associated with the at least one managed device, In order to generate a general-purpose device identifier address, the at least one managed device transmits the pre-salted device identifier address to the security vendor service via the trusted ecosystem vendor, A method comprising the at least one managed device receiving the generic device identifier address from the security vendor service via the trusted ecosystem vendor.

2. Receiving the aforementioned client certificate The computer implementation method according to claim 1, comprising generating the private key of the client certificate on the at least one managed device.

3. The computer implementation method according to claim 2, wherein the private key is non-exportable.

4. The computer implementation method according to claim 2, wherein the private key is generated via a hardware back key store.

5. Obtaining the identifier address of the aforementioned pre-salted device is Verify the trust chain of the aforementioned client certificate, To generate a nonce to challenge the aforementioned hardware back key store, Sending the nonce to the hardware back keystore by referring to the client certificate, Based on the aforementioned private key, the system receives a signed nonce challenge response and the corresponding public key. The nonce challenge response is verified using the corresponding public key returned, To prove the integrity of the aforementioned private key, The computer implementation method according to claim 4, comprising returning the pre-salted device identifier.

6. The generation of the aforementioned general-purpose device identifier address is The computer implementation method according to claim 2, comprising generating a value by hashing the pre-salted device identifier with an administrator-defined salt.

7. To generate the aforementioned value, The computer implementation method according to claim 6, comprising generating a general-purpose device identifier key pair via the SECP256K1 key generation algorithm.

8. The computer implementation method according to claim 1, wherein the general-purpose device identifier address includes a length of 42 characters and is represented as a hexadecimal address.

9. The computer implementation method according to claim 1, wherein the general-purpose device identifier address is associated with the at least one managed device in a database associated with the security vendor service as the final correlated device identifier.

10. It is a system, One or more memory locations containing instructions, The system comprises one or more processors configured to execute the aforementioned instructions, and when executed, the one or more processors, In the mobile device management service, register at least one managed device. The client certificate is received on at least one of the managed devices. The general-purpose device identifier SDK is integrated via a trusted ecosystem vendor app on at least one of the managed devices. Based on a request from the trusted ecosystem vendor application, the generic device identifier endpoint SDK is used to obtain the pre-salted device identifier address associated with the at least one managed device. In order to generate a general-purpose device identifier address, the at least one managed device causes the security vendor service to send the pre-salted device identifier address via the trusted ecosystem vendor. A system in which at least one managed device receives the generic device identifier address from the security vendor service via the trusted ecosystem vendor.

11. The instruction to receive the client certificate is directed to one or more processors, The system according to claim 10, further comprising an instruction to generate a private key for the client certificate on the at least one managed device.

12. The system according to claim 11, wherein the private key is non-exportable.

13. The system according to claim 11, wherein the private key is generated via a hardware back keystore.

14. The instruction to obtain the pre-salted device identifier address is performed by one or more processors. Verify the trust chain of the aforementioned client certificate, To generate a nonce to challenge the aforementioned hardware back key store, The client certificate is referenced to send the nonce to the hardware back keystore. Based on the aforementioned private key, a signed nonce challenge response and the corresponding public key are received. The nonce challenge response is then validated using the corresponding public key returned. The integrity of the aforementioned private key is to be proven. The system according to claim 13, comprising an instruction to return the pre-salted device identifier.

15. The instruction that generates the general-purpose device identifier address is performed by one or more processors, The system according to claim 11, further comprising instructions for generating a value by hashing the pre-salted device identifier with an administrator-defined salt.

16. The instruction that generates the value is performed by one or more processors, The system according to claim 15, further comprising instructions for generating a value by hashing the pre-salted device identifier with an administrator-defined salt.

17. The system according to claim 10, wherein the general-purpose device identifier address includes a length of 42 characters and is represented as a hexadecimal address.

18. The system according to claim 10, wherein the general-purpose device identifier address is associated with the at least one managed device in a database associated with the security vendor service as the final correlated device identifier.

19. A computer implementation method for exchanging device metadata of devices via a distributed ledger, Associating a general-purpose device identifier address with a vendor device ID associated with at least one managed device, Based on changes in the risk status associated with the at least one managed device, the metadata in the database is modified, A method comprising: publishing the change in the risk situation as an entry in the distributed ledger using the general-purpose device identifier secret key associated with the general-purpose device identifier address.

20. It is a system, One or more memory locations containing instructions, The system comprises one or more processors configured to execute the aforementioned instructions, and when executed, the one or more processors, Associate a general-purpose device identifier address with a vendor device ID associated with at least one managed device. Based on the change in the risk status associated with the at least one managed device, the metadata in the database is modified. A system that uses the general-purpose device identifier secret key associated with the general-purpose device identifier address to publish changes in the risk status as entries in the distributed ledger.

Images