An operator station server of a technical installation upon which a certification service is implemented, wherein the certification service is configured to receive configuration information, which depends on a role of the operator station server in the technical installation, from at least one of (i) an engineering station server and (ii) a registration service of the technical installation, where the configuration information comprises information identifying which certificates of the certification service of the operator station server must be requested from a certification authority of the technical installation.

Techniques for managing secure communication certificates for medical devices in a clinical environment are provided. A short-lived, limited-use token may be uniquely assigned to a medical device. The medical device can self-provision a secret key and corresponding public key based on a unique identifier in the token. The medical device generates a certificate signing request (“CSR”) that includes the public key, and sends the CSR and the token to a verification system that serves as an intermediary between medical devices and a certificate authority. The intermediary may only send the CSR to the certificate authority (“CA”) for a certificate if the intermediary is able to validate the token.

A system for providing access is configured to receive an application access request from an application for authorization to access and a sensitive data access request from the application for authorization to access a document that includes sensitive data. The system is further configured to determine to authorize access to the application in response to the application access request; to determine the user authentication device in response to the sensitive data access request; to provide a secondary request for authorization to access sensitive data to the user authentication device in response to the sensitive data access request, receive a secondary request response from the user authentication device to the secondary request; and to provide the secondary request response to the application enabling access to the sensitive data, where the document is encrypted for delivery to the application for the user using a blinding secret and an identity private key.

There is provided a system for creating a cryptographic non-fungible identity unique token (IUT), comprising code for: obtaining a private key linked to a public address of an electronic wallet, associated with a wallet address, obtaining a digital representation of a hashed genetic sequence of a user and an associated wallet address of the electronic wallet, storing in the cryptographic non-fungible IUT, an IUT identifier, the IUT identifier is an outcome of hashing a subset of the hashed digital representation and a unique password, storing the IUT in a genetic sequence record stored in a block of a blockchain dataset, wherein the genetic sequence record is associated with the IUT, the IUT is associated to the wallet address, wherein the user is authenticated by a match between a computed value of a password and the wallet address provided by the user, and the IUT identifier stored on the blockchain.

An embodiment of the present invention is directed to delivering an entitlements model that scales to both mid-frequency and low-latency use cases. The innovative solution may be distributed in nature and able to operate in low priority threads alongside the main logic of the software. An embodiment of the present invention may be implemented as a software module with APIs for ease of adoption.

During factory provisioning of an Information Handling System (IHS), a key injection authorization certificate is stored that authorizes key injection by a renter of the IHS. An IHS owner retains capabilities for specifying the use of boot code of successive renters of the IHS. Upon a transfer of control or ownership of the IHS, a key injection request certificate provided by the renter is validated and use of the key injection request certificate is authorized for transferring cryptographic credentials to the IHS. The key injection authorization certificate specifies an identity of the IHS that is authorized for key injection by the renter and the key injection request certificate specifies an identity of the IHS that is requested for key injection by the renter. Transfer of credentials is authorized when the two certificates are both valid and the identity of the IHS specified in the two certificates is the same.

During factory provisioning of an Information Handling System (IHS), a key injection authorization certificate is stored that authorizes key injection by a renter of the IHS. An IHS owner retains capabilities for specifying the use of boot code of successive renters of the IHS. Upon a transfer of control or ownership of the IHS, a key injection request certificate provided by the renter is validated and use of the key injection request certificate is authorized for transferring cryptographic credentials to the IHS. The key injection authorization certificate specifies an identity of the IHS that is authorized for key injection by the renter and the key injection request certificate specifies an identity of the IHS that is requested for key injection by the renter. Transfer of credentials is authorized when the two certificates are both valid and the identity of the IHS specified in the two certificates is the same.

Systems and methods are provided for validating components of an Information Handling System (IHS). During factory provisioning of the IHS, an owner certificate is stored that specifies an identity of a motherboard installed during manufacture of the IHS. The owner certificate is signed by a certificate authority of an owner of the IHS that retains capabilities for specifying the use of boot code provided by successive renters of the IHS. A renter certificate is also stored that specifies an identity of a chassis to which the motherboard is installed during manufacture of the IHS. Upon a transfer of control or ownership of the IHS, boot code operations by the security processor identify a motherboard and chassis in use by the IHS and utilize the motherboard and chassis certificates to validate that the identified motherboard and chassis are the same motherboard and chassis installed during manufacture of the IHS.

Systems and methods are provided for validating components of an Information Handling System (IHS). During factory provisioning of the IHS, an owner certificate is stored that specifies an identity of a motherboard installed during manufacture of the IHS. The owner certificate is signed by a certificate authority of an owner of the IHS that retains capabilities for specifying the use of boot code provided by successive renters of the IHS. A renter certificate is also stored that specifies an identity of a chassis to which the motherboard is installed during manufacture of the IHS. Upon a transfer of control or ownership of the IHS, boot code operations by the security processor identify a motherboard and chassis in use by the IHS and utilize the motherboard and chassis certificates to validate that the identified motherboard and chassis are the same motherboard and chassis installed during manufacture of the IHS.

As part of a factory provisioning of an Information Handling System (IHS), a configuration certificate is stored that identifies a pre-boot configuration of the IHS resulting from the factory provisioning. Upon a transfer of control or ownership of the IHS, a pre-boot configuration of the IHS is identified and the configuration certificate is utilized to validate that the identified pre-boot configuration is the same as the pre-boot configuration of the IHS resulting from the factory provisioning. A security processor of the IHS may support boot code operations for generating additional configuration certificates that can be used to validate the integrity of any changes the IHS configuration, such as upon its next power cycle.