PASSWORD AUTHENTICATION WITH CRYPTOGRAPHIC KEY HANDLE-BASED AUTHENTICATION PHRASES

Abstract

A process includes receiving credentials associated with a request to access a computing platform. The credentials include a password and a user identification. The process includes determining a key handle and a cryptographic reference digest corresponding to the user identification. The process includes determining a second cryptographic digest corresponding to the user identification. Determining the second cryptographic digest includes providing the key handle and the password to a security processor of the computing platform and initiating, by the security processor, an operation to apply a keyed hashing function to the password based on a cryptographic key corresponding to the key handle to provide the second cryptographic digest.The security processor stores the cryptographic key. This process involves regulating access to the computing platform based on a comparison of the second cryptographic summary with the reference cryptographic summary.

Description

BACKGROUND

[0001] A computing platform may have an access control system to regulate access to the platform's resources. A user may provide credentials in connection with a request to log in to the computing platform. The access control system may authenticate the credentials to verify the user's identity and decide whether to grant or deny the user access. The credentials include a knowledge factor (e.g., a password) that is presumably limited to the user's knowledge. If the access control system successfully verifies the user's identity based on the provided credentials, the access control system may regulate the level of access permitted to the user based on one or more other criteria (e.g., role-based permissions associated with the user account). BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 is a block diagram of a computer network including a network device that provides a password authentication solution using cryptographic key handle-based password authentication records according to an example implementation. Fig. 2 is a flowchart illustrating the communication and actions of a hardware processor and a security processor to create or update a password authentication record with a cryptographic key handle and a hash of a password, according to an example implementation. Fig. 3 is a flowchart illustrating the communication and actions of a hardware processor and a security processor to authenticate a password using a cryptographic key handle-based password authentication record, according to an example implementation. Fig. 4 is a block diagram of a computing platform that authenticates a password using a cryptographic key handle-based password authentication record according to an example implementation. Fig. 5 is an illustration of machine-readable instructions that, when executed by a network switch, cause the network switch to create and use a cryptographic key handle-based password authentication record to authenticate a password, according to an example implementation. Fig. 6 is a flowchart illustrating a process for authenticating a password using a cryptographic key handle-based password authentication record according to an example implementation DETAILED DESCRIPTION

[0002] An operating system for a computer platform can regulate access to the computer platform's resources through user accounts. A user account is assigned a set of privileges that govern access to the computer platform's resources. From the perspective of a user (e.g., a human or a software entity), a user account can be identified by a name, called a "username." For its operations, an operating system can identify a user account by a number called a "user ID" (or "UID"). To log in to a user account, the requestor can provide credentials such as a username and password, which are authenticated by the computer platform. In this context, "authenticating" credentials means verifying the requestor's identity against the credentials. The password serves as a knowledge factor known to the account holder (e.g.,created by the account holder for the user name according to a record of the computing platform) and presumably limited to the knowledge of the account holder. The computing platform may include an authentication module (e.g., a pluggable authentication module (PAM)) to compare a password provided by an access requester with the computing platform's records of a password created for the user account.

[0003] More specifically, an authentication module can access a password authentication file (e.g., a Linux shadow file) to verify a password provided by an access requestor. The password authentication file can contain authentication entries or records corresponding to various user names. The authentication module can first identify a specific authentication entry of the password authentication file that corresponds to the user name. The authentication module can then access the identified authentication record and verify the password based on the information contained in the authentication record.

[0004] Because a password authentication file can be relatively insecure and therefore potentially viewable by a malicious actor, the actual passwords may not be stored in the authentication records. Instead, an authentication record may contain a hash (also referred to here as a "digest") of the password, with the password omitted from the record. The authentication module can verify a given password by determining a hash of the password and then comparing the hash to a reference hash stored in the authentication record corresponding to the username. The reference hash corresponds to the password created for the user account. A password supplied by an access requester passes verification if the hashes match and fails verification if the hashes differ.Because a sophisticated malicious actor can derive a password from its reference hash (e.g., through a dictionary or rainbow table attack), an authentication record may contain a randomly or pseudorandomly generated value called a "salt." For example, a salt may be stored along with a reference hash in an authentication record, so that the input to the hashing function is a concatenation of the salt and the password. Similarly, the reference hash is a function of the password created for the user account and the salt. Although the use of a salt can increase the time and computational effort a malicious actor must spend learning a password, the addition of a salt may be ineffective against a sophisticated malicious actor with significant computing power.In addition, a salt can significantly increase the time required to verify a password.

[0005] According to implementation examples, a password authentication solution stores cryptographic key handles (hereinafter referred to as "key handles") in corresponding authentication records. For a specific password associated with a user account, the key handle is a pointer or reference that identifies a cryptographic key used to derive the corresponding reference hash for the password. The relevance of the key handle is limited to internal operations of a security processor of the computing platform and does not reveal any information from which the cryptographic key can be derived outside the security processor. Thus, disclosing the key handle does not result in the disclosure or other compromise of the corresponding password.As mentioned above, the key handle is linked to security-related features of the security processor that prevent the underlying password from being compromised.

[0006] In one example, an authentication record may include data representing user identification, such as a username, a key handle, and a reference hash. The key handle points to a cryptographic key stored in the security processor. The reference hash is the result of a keyed hash algorithm whose input value is derived from the password and the cryptographic key. In one example, the security processor may have a keyed hash module or engine to apply a keyed hash algorithm based on the cryptographic key and password to provide the corresponding reference hash. In one example, the security processor may generate the cryptographic key and provide a corresponding key handle that is used internally by the security processor to reference the cryptographic key.

[0007] According to example implementations, a computing platform includes a password authentication engine (e.g., a PAM) to verify passwords based on corresponding key handles and reference hashes. According to example implementations, to verify a password, the password authentication engine identifies an authentication record for the corresponding username and reads the data corresponding to the key handle from the identified authentication record. The password authentication module invokes a keyed hashing operation performed by a keyed hashing module of the security processor via an API call directed to the security processor. The platform authentication engine passes the password and the key handle, among other input parameters of the API call, to the security processor.In response to the API call, the security processor identifies the cryptographic key from the key handle, and the security processor's keyed hashing engine hashes the password based on the cryptographic key to provide a digest, or hash, which is a returned output of the API call. The password authentication engine reads data corresponding to the reference hash from the identified authentication record and compares the hash returned as the output of the API call with the reference hash. The result of the comparison controls whether the password passes the password verification (e.g., if the hashes match) or fails (e.g., if the hashes do not match).

[0008] The security processor has features that prevent the cryptographic key from being disclosed outside the security processor and that prevent unauthorized use of the security processor's keyed hashing engine with the cryptographic key. In one example of the security features, the security processor does not allow the cryptographic key to be exported or otherwise disclosed outside the security processor. In another example of the security features, the security processor restricts the use of the cryptographic key to a specific authorization value. Therefore, the cryptographic key cannot be used in a keyed hashing operation unless the authorization value is provided in an API call that invokes the operation.Therefore, a malicious actor cannot test a given password candidate using the security processor's keyed hashing engine, even if the malicious actor gains access to the key handle.

[0009] According to example implementations, the computing platform includes a password management engine (e.g., a PAM) that manages password-related information stored in the authentication records. In one example, in response to a password being created or changed for a user account, the password management engine stores data in the corresponding authentication record representing a key handle and a reference hash corresponding to the password. To derive the key handle and the reference hash, according to example implementations, the password management engine can, via API calls to the security processor, cause the security processor to generate a cryptographic key, store and maintain the cryptographic key, and provide (to the password management engine) the key handle for the cryptographic key.In addition, according to example implementations, the password management engine can, via an API call to the security processor, cause the security processor to perform a key hash operation on the password based on the cryptographic key to provide the reference hash.

[0010] In one example, in response to a user updating an existing password to replace the existing password with a new password, the password management engine may make corresponding updates to the corresponding authentication record. In one example, these actions may include creating a new cryptographic key using the security processor, importing the new cryptographic key into the security processor, receiving a corresponding key handle for the new cryptographic key from the security processor, and using the security processor to create a new reference hash. The password management engine may then update the authentication record to replace the old reference hash and key handle corresponding to the previous password with the new reference hash and key handle.In another example, the password management system may reuse an existing key handle (and thus the same cryptographic key) for an existing password to change the existing password to a new password. In this way, the password management system may use the security processor to create a new reference hash for the new password without changing the cryptographic key. In another example, in response to a user account being removed or deleted from the computing platform, the password management engine may remove the reference hash and key handle from the corresponding authentication record. In one example, removing the reference hash and key handle may include the password management engine deleting the authentication record.

[0011] The password management engine, according to example implementations, takes steps to generate a different cryptographic key for each password. The reference hash described here is unique for each password, and the cryptographic key is securely stored outside of the authentication record. These features prevent a dictionary-based or rainbow-table attack from being used to derive the password.

[0012] Consistent with example implementations, the computing platform may be a network device, such as a managed network switch. The network switch may have one or more associated user accounts. A user may log in to a user account by providing the appropriate credentials, for example, to configure the network switch and set up the network switch for management by a network management service.

[0013] Referring to Fig. 1, as a more specific example, in accordance with some implementations, a computing platform 110 includes an authentication engine 168 that authenticates the identification of access requesters based on credentials provided by the requesters. According to example implementations, to log in to a particular user account, an access requester enters a password, resulting in a corresponding password verification request being sent to the authentication engine 168. In one example, the access requester may log in to the computing platform 110 through a particular program 172, and the program 172 may send a corresponding password verification request to the authentication system 168.In this context, a "password verification request" generally refers to a request to determine whether a password provided by an access requester matches the computing platform's record of the password created for the corresponding user account (e.g., the account holder corresponding to a username associated with the access requester).

[0014] According to example implementations, in response to a password verification request, authentication engine 168 determines whether the password associated with the request matches the password created by the account holder for the user account as reflected in the records of the computing platform. In one example, authentication engine 168 returns a response to a password verification request indicating whether or not verification of a particular password was successful. In one example, upon a failed verification, computing platform 110 denies login, thereby preventing the access requester from accessing the resources of computing platform 110 through the corresponding user account.In an example of a passed verification, the computing platform 110 may next determine the level of access that the computing platform 110 allows to the resources of the computing platform 110 based on one or more other criteria (e.g., permissions associated with the user account, whether the password has expired, usage restrictions, time-based restrictions, and other possible criteria).

[0015] As used herein, a "password" generally refers to a string of characters used to gain access to one or more resources, such as one or more resources of computing platform 110. In examples, a password may be a sequence of numbers, a sequence of alphabetic letters, an alphanumeric sequence, a sequence of special characters (e.g., "$," "%," "&," and / or other characters that are neither numbers nor alphabetic letters), a sequence of alphabetic letters, numbers, and special characters, or any other combination of characters with one or more character types. For example, a password may have a minimum number of characters, a maximum number of characters, characters that correspond to certain character types, or one or more other characteristics.

[0016] A "resource" of the computing platform 110, as used herein, refers to a physical or virtual component or service associated with the computing platform 110. A resource may be, for example, an operating system, memory, configuration, virtual machine, container environment, application service, infrastructure service, specific infrastructure, application operating environment, hardware processor, utility, file system, storage device, storage array, storage service, cache, virtualization service, network interface, network virtualization layer, storage virtualization layer, or any other component or service that is part of or provided by the computing platform 110.

[0017] The authentication system 168 may receive a password verification request from any number of different sources. In one example, a password verification request may be provided by a program 172 executing on the computing platform 110. In one example, a program 172 may prompt an access requester to enter a password for a particular user account, and in response to the access requester entering the password, the program 172 may send a corresponding password verification request to the authentication engine 168. In examples, a user or a script executing on the computing platform 110 may provide input via a shell or user interface of an operating system 164 of the computing platform 110, resulting in the execution of a program 172 that sends a password verification request to the authentication engine 168.In one example, a user or script may enter a login command via the shell to begin a session on the computing platform 110. The login command causes a login utility 172 to execute, prompting for a password, and the login utility 172 may submit a corresponding password check request to the authentication system 168 to determine whether to allow the session.

[0018] In another example for a LINUX operating system, a user or script may enter a substitute user command (also referred to as a "switch user" command or "su" command) via the shell to replace or switch user accounts. The substitute user command causes a substitute user helper 172 to execute, prompting for the password for the new user account, and the substitute user helper 172 may submit a corresponding password check request to the authentication system 168 to determine whether the user account switch is permissible.

[0019] In another example for a LINUX operating system, a user or script may enter a passwd command via the shell to change the password for the current user account. The passwd command causes a password helper 172 to execute, prompting for the current password, and the helper 172 may submit an appropriate password verification request to the authentication engine 168 to determine whether to allow the password update.

[0020] In another example, a background or daemon program 172 may be executed on the computing platform 110 to enable a requestor on a remote client device 180 to log in to the computing platform 110. In one example, the daemon program 172 may be a Secure Shell Daemon (SSHd) server that communicates with an SSH client of the client device 180.

[0021] In other examples, a program 172 of the computing platform 110 that is not associated with a utility, such as an application or display manager, may send a password verification request to the authentication module 168.

[0022] The authentication engine 168, according to example implementations, processes a password verification request based on information stored in a password authentication file 141. In one example, the password authentication file 141 may be stored in a memory 136 of the computing platform 110. In another example, the password authentication file 141 may be stored remotely with respect to the computing platform 110. In an example for a LINUX operating system 164, the password authentication file 141 may be a text-based shadow file having the following file path: / etc / shadow. Access to the password authentication file 141 may be restricted to a root user, according to example implementations.

[0023] According to example implementations, the password authentication file 141 contains password authentication entries or records 137 (referred to herein as "authentication records 137"). According to example implementations, each authentication record 137 is associated with a particular user name and, accordingly, with a particular user account. Among other possible information, an authentication record 137 may include fields with data representing a user name, a reference digest or hash 138 corresponding to the password created by the account holder, and a key handle 139.

[0024] The key handle 139 refers to a cryptographic key 152 stored in a secure memory 148 of a security processor 144 of the computing platform 110. As used herein, a "cryptographic key" refers to a string of characters associated with a cryptographic algorithm or function. In one example, a cryptographic key may be a number formed from a concatenation of numbers (e.g., a concatenation of numbers represented in a base sixteen or hexadecimal format). In other examples, a cryptographic key may be an alphanumeric sequence, such as a sequence of letters and numbers, a sequence of letters and special characters (e.g., "%," "&," "$," and other characters that are not letters or numbers), or a sequence of letters, special characters, and numbers.In one example, and as further described herein, the cryptographic key 152 is associated with a cryptographic keyed hash algorithm. In one example, the keyed hash algorithm may be a Keyed-Hash Message Authentication Code (HMAC) algorithm. The keyed hash algorithm may be, for example, the algorithm described in Section 11.4.4 of Part 1 of the Trusted Platform Module Library Specification, Family 2.0, Level 00, Revision 01.59 (November 2019), published by the Trusted Computing Group (hereinafter referred to as the "TPM 2.0 Specification"). In one example, the keyed hash algorithm may use a hash algorithm from the Secure Hash Algorithm 2 (SHA-2) family of hash algorithms, such as an SHA-256 hash algorithm or an SHA-512 hash algorithm.

[0025] The key handle 139 does not contain any information that could be used to disclose the corresponding cryptographic key 152 outside the security processor 144. Fig. 1 shows a key handle 155 (e.g., a key handle 139 of an authentication record 137 passed to the security processor 144 via an API call) used within the security processor 144. The security processor 144 uses the key handle 155 to identify a corresponding cryptographic key 152 (as represented by association 153) for internal operations of the security processor 144. As further described herein, in accordance with example implementations, the authentication engine 168 may pass a key handle and a password (which is verified) to the security processor 144 via an API call to invoke a keyed hashing operation by a keyed hashing engine 160 of the security processor 144.The keyed hashing operation involves the keyed hashing engine 160 applying a keyed hash algorithm, where the inputs to the algorithm are the password and the cryptographic key 152. The security processor 144 returns the resulting digest or hash generated by the keyed hashing operation in response to the API call.

[0026] As used herein, an application programming interface, or "API," of security processor 144 refers to a collection of one or more software and / or hardware components of security processor 144 that collectively provide one or more functions or operations to security processor 144. Security processor 144 performs an API-related operation in response to a request, referred to herein as an "API call." Submitting or providing an API call to security processor 144 may be referred to as invoking a particular function or operation of security processor 144. An API call may have an associated construct that defines how parameters are passed through the API call and how parameters are returned as output(s) resulting from security processor 144's performance of an operation invoked by the API call.In one example, an API call may have a specific name or identifier. In one example, one or more parameters may be passed as part of an API call, corresponding to options and / or arguments (e.g., inputs) for the function or operation invoked by the API call. According to embodiments, the security processor 144 may include one or more registers that a hardware processor 124 may write with data corresponding to the parameters of a particular API call. In addition, the security processor 144 may include one or more registers containing data representing output generated by the security processor 144 in response to a particular API call. In accordance with further implementations, API calls and the corresponding results may be communicated between a hardware processor 124 and the security processor 144 via shared memory messaging.A response from the security processor 144 to a particular API call is referred to herein as an “API call response” or “API response.”

[0027] The authentication system 168 verifies the password associated with a password verification request by first identifying an authentication record 137 corresponding to the username. The authentication system 168 then reads the key handle 139 from the identified authentication record 137 and sends an API call to the security processor 144 to invoke a key processing operation. In conjunction with the API call, the authentication system 168 passes the key handle 139 and the password to be verified to the security processor 144 as inputs of the API call. In response to the API call, the security processor 144 then returns a digest or hash corresponding to the encrypted hash of the password and the cryptographic key 152 corresponding to the key handle 139.The authentication system 168 then compares the hash returned by the security processor 144 with a reference hash 139 of the identified authentication record 137. If the hashes match, the authentication system 168 provides a response to the password verification request indicating successful verification. If the hashes do not match, the authentication system 168 provides a response to the password verification request indicating that verification failed.

[0028] Computing platform 110 includes, in accordance with example implementations, a password management engine 169 (referred to herein as "management engine 169") that manages password information-related updates to password authentication file 141 in response to password update requests. Generally, a "password update request" refers to an instruction to change password information (e.g., information stored in password authentication file 141) related to a particular user account. In one example, a password update request may be directed to the creation of an authentication record 137. In another example, a password update request may be directed to the deletion of an authentication record 137.In another example, a password update request may be directed to changing or modifying password-related information of an existing authentication record 137. In one example, changing information of an authentication record 137 in response to creating a new password for a user account may include replacing an existing reference hash and an existing key handle of the authentication record 137 with a new reference hash and a new key handle. In another example, changing information of an authentication record 137 in response to creating a new password for a user account may include maintaining an existing key handle of the authentication record 137 (i.e.reusing the same cryptographic key) and replacing an existing reference hash of the authentication record 137 with a new reference hash.

[0029] A password update request may originate from any number of different sources. In one example, a password update request may be provided by a program 172 executing on the computing platform 110. In one example, a program 172 may prompt a user to create a new password (e.g., the first password created for the user account or a password to replace the current password). In response to the user creating a new password, the program may send a password request containing the new password and username to the management engine 169.

[0030] In an example of a LINUX operating system, a user may enter a passwd command via an operating system shell 164 to change the password for the user account. The passwd command causes a password utility 172 to execute, prompting for a new password, and in response to the new password being entered, the password utility 172 may transmit a corresponding password update request to the management system 169.

[0031] In another example, a password update request may be associated with a system administrator deleting a user account from the computing platform 110. In another example, a daemon program 172, such as an SSHd server, may provide a password update request in response to a password change submitted by a remote client device 180.

[0032] To process a password update request that changes or creates a password, the management module 169 may perform the following actions. The management module 169 uses the security processor 144 to generate a new cryptographic key 152 for the new password and provide a new key handle 139 corresponding to the new cryptographic key 152. The management module 169 also uses the security processor 144 to provide a new reference hash 138 corresponding to the new password and the new cryptographic key 152. The management module 169 then updates the authentication record 137 to replace the old reference hash 138 and the old key handle 139 with the new reference hash 138 and the new key handle 139.

[0033] In accordance with example implementations, the management module 169 uses a random number generator 158 of the security processor 144 to generate the new cryptographic key 152. In accordance with example implementations, the random number generator 158 randomly or pseudorandomly generates a number, and the management module 169 uses the number as the cryptographic key 152.

[0034] In accordance with some implementations, the random number generator 158 may be a true random number generator that generates a random number based on an input provided by an entropy source. In one example, the random number generator may sample a true analog random signal, such as a thermal noise signal (e.g., a Johnson-Nyquist noise signal provided by a resistor) or an atmospheric noise signal received from an antenna. In other examples, the random number generator 158 may process an input representing clock jitter, air movement, or an input provided by another entropy source.

[0035] In another example, in accordance with some implementations, the security processor 144 may include a number generator that is not truly random, but instead generates a pseudorandom number. In these implementations, the management module 169 may use the pseudorandom number as the cryptographic key 152.

[0036] In accordance with example implementations, the management engine 169 may invoke an operation of the random number generator 158 via an API call to the service processor 144 to generate a number that the security processor 144 returns as an output parameter in an API response to the management engine 169. In one example, the management module 169 uses the number returned by the security processor 144 as the cryptographic key 152 without further modification. In another example, the management module 169 may modify the number. For example, the management module 169 may apply a key derivation function to the number returned by the security processor 144 to derive the cryptographic key 152.In another example, the management module 169 may concatenate the number returned by the security processor 144 with other information or make another modification for the purpose of deriving the cryptographic key 152. In another example, the management module 169 may combine (e.g., concatenate) the number returned by the security processor 144 with other information to provide input to a key derivation function that yields the cryptographic key 152.

[0037] In one example, the random number generator 158 may be a digital random number generator (RNG) module described in Part 1, Section 11.4.11 of the TPM 2.0 specification. In another example, the management module 169 may generate a cryptographic key 152 without using the security processor 144 and then load the cryptographic key 152 into the security processor 144 as described herein. For example, for the purpose of generating a cryptographic key 152, the management module 169 may execute machine-readable instructions corresponding to a cryptographic key generator or a number generator. As another example, the management module 169 may use a cryptographic processor separate from the security processor 144 to generate a cryptographic key 152.In another example, the management module 169 may use a graphics processing unit (GPU) to generate a random or pseudorandom number to be used as the cryptographic key 152.

[0038] After a cryptographic key 152 is generated, the management engine 169 may load or import the cryptographic key 152 into the security processor 144 via an API call. In particular, in accordance with example implementations, the API call may cause the security processor 144 to load or import the cryptographic key 152 as a transient object. In this context, "a transient object" refers to an entity that does not survive a power failure of the security processor 144. In other words, the security processor 144 retains the transient object until power to the security processor 144 is interrupted. In one example, transient objects of the security processor 144 may be deleted when the computing platform 110 is shut down or rebooted.According to example implementations, the security processor 154 responds to an API call to load the cryptographic key 152 with an API response that returns a corresponding transient key handle that points to the transient object.

[0039] In accordance with example implementations, the management engine 169 follows the API call that imports the cryptographic key 152 with a subsequent API call to the security processor 144 to instruct the security processor 144 to retain the loaded cryptographic key 152. In one example, the management module 169 passes the temporary key to the security processor 144 in the subsequent API call, and in response to the API call, the security processor 144 retains the cryptographic key 152 and returns a persistent key handle (pointing to the retained cryptographic key 152) in a corresponding API response. The returned persistent key handle corresponds to the key handle 139. In this context, "persistent" means that the cryptographic key 152 is stored in a manner that will survive a power failure of the security processor 144.Therefore, if the cryptographic key 152 is stored permanently, the security processor 144 retains the key 152 when the computing platform 110 is turned off or rebooted.

[0040] After importing the cryptographic key 152 into the security processor 144 and storing the cryptographic key 152, the management engine 169 may take action to generate the new reference hash 138. Specifically, according to example implementations, the management module 169 passes the new key handle 139 and the new password to the security processor 144 via an API call to generate a new reference hash 138. The security processor 144 returns the new reference hash 138 as an output parameter in the corresponding API response.

[0041] According to some implementations, the authentication engine 168 and the password management engine 169 may each be pluggable authentication modules (PAMs). According to some implementations, a program 172 that submits requests to a particular PAM may be compiled with a corresponding PAM library. In other implementations, the authentication engine 168 and the password management engine 169 may be part of the same PAM.

[0042] As in Fig. 1, in accordance with example implementations, computing platform 110 may be a network device 120, such as a managed network switch. Network device 120 may have one or more associated user accounts. Access to a particular user account may be provided for a variety of reasons. In one example, configuration data, such as data corresponding to one or more configuration files (e.g., YAML files), may be made available to network device 120 via access by a user account. In another example, various settings of network device 120 may be configured via access provided by a user account.In examples, these settings may include Quality of Service (QoS) settings, Class of Service (CoS) settings, Virtual Local Area Network (VLAN) tagging settings, VLAN untagging settings, ingress bandwidth settings, egress bandwidth settings, Power over Ethernet (POE) settings, and other and / or other configurable settings for the network device 120. In one example, the network device 120 may be configured to report network telemetry metrics to a network management service via access provided by a user account. In another example, the network device 120 may be configured to report network telemetry metrics to a network management service via access provided by a user account.

[0043] As also in Fig. 1, in accordance with some implementations, the network device 120 may be part of a computer network 100 that includes multiple network devices 120. In accordance with example implementations, each network device 120 may have a security processor 144, an authentication engine 168, and a management engine 169. Additionally, depending on the implementation, different network devices 120 may be associated with different user accounts. In one example, the network devices 120 may correspond to a local branch network (e.g., a local area network (LAN)), such as a network corresponding to a particular building, group of buildings, campus, edge computer system, or data center. In one example, the network devices 120 may be part of an edge system to connect edge devices (e.g.,Servers, clients, Internet of Things (IoT) devices, and other devices) to the network fabric 190 to connect the edge devices to a larger wide area network (WAN), such as the Internet. In another example, the network devices 120 may be connected to multiple local branch networks.

[0044] In accordance with example implementations, the network fabric 190 may be connected to one or more types of communication networks, such as (as examples) Fibre Channel networks, Compute Express Link (CXL) fabrics, dedicated management networks, local area networks (LANs), WANs, global networks (e.g., the Internet), wireless networks, or any combination thereof.

[0045] In one example, the network devices 120 may be managed by central network management system (NMS) components deployed on one or more network resources 186 connected to the network devices 120 via the network fabric 190. In one example, the network resources 186 may be cloud-based resources. In one example, the central NMS components may include a central server that provides one or more NMS services to the network devices 120. In examples, the NMS services may include firmware update services, network telemetry monitoring services, network troubleshooting services, network performance improvement services, and other services.

[0046] As used herein, a "network device," such as network device 120, refers to an actual or physical electronic component that enables data communication between other components. In one example, a network device may be a switch that operates at layer two (L2) of the Open Systems Interconnection (OSI) model to interconnect components of a computer network. In another example, a network device may be a layer three (L3) switch that interconnects both components of a computer network and interconnects computer networks. In other examples, a network device may be a gateway, a multicast router, a bridge, a component of a Gen-Z or Compute Express Link (CXL) network, a processor device, a network interface controller (NIC), or a fabric switch, including one or more of the foregoing.A network device can be a wired or wireless device.

[0047] In accordance with further implementations, the computing platform 110 may not be a network device. As used herein, the term "computing platform" refers to a processor-based electronic device having an associated operating system. In other examples, the computing platform 110 may be a standalone server, a distributed server, a rack-mounted server module, a rack-mounted edge processing module, a blade server, a blade enclosure with one or more blade servers, a client, a thin client, a desktop computer, a portable computer, a laptop computer, a notebook computer, a tablet computer, a smartphone, a wearable computer, or another processor-based platform.

[0048] At the Fig. 1, the computing platform 110 includes actual or physical hardware components, such as one or more hardware processors 124, system memory 128, network ports or interfaces 142, input / output (I / O) memory, and other hardware devices. In one example, a hardware processor 124 may include one or more central processing unit (CPU) cores and / or one or more graphical processing unit (GPU) cores. In another example, a hardware processor 124 may include one or more semiconductor CPU packages (or "sockets"). In another example, a hardware processor 124 may include one or more GPU packages. In one example, a hardware processor 124 may execute machine-executable instructions, such as machine-readable instructions 132 stored in the system memory 128, to provide one or more software components of the computing platform 110, such as: B.the authentication engine 168 and / or the management engine 169. In another example, a hardware processor 124 may be a hardware circuit that does not execute machine-executable instructions, such as an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a programmable logic device, or other hardware dedicated to providing one or more functions (e.g., functions related to the authentication module 168 and / or the management module 169) to the computing platform 110.

[0049] System memory 128 includes non-transitory storage media, which may consist of semiconductor memory devices, memristor-based memory devices, magnetic memory devices, phase-change memory devices, a combination of devices of one or more of these memory technologies, etc. System memory 128 may represent a collection of memories comprising volatile and non-volatile memory devices.

[0050] The operating system 164 can be, for example, a LINUX operating system, a WINDOWS operating system, a MAC operating system, a FREEBSD operating system, a hypervisor (e.g., an ESXi, KVM, or Hyper-V hypervisor), or another operating system.

[0051] In accordance with example implementations, computing platform 110 may include virtualization technology to provide one or more hardware abstractions. In one example, computing platform 110 may include a hypervisor that provides a virtual machine housing operating system 164, authentication engine 168, management engine 169, and programs 172. In another example, computing platform 110 may include a container engine that provides a container environment (e.g., a single container, a container pod, or a cluster of container pods) housing authentication engine 168, management engine 169, and programs 172. In another example, operating system 164, authentication engine 168, management engine 169, and programs 172 may run on bare metal.

[0052] In accordance with some implementations, the security processor 144 may provide trusted computational operations for the computing platform 110 to ensure that the computing platform 110 behaves consistently in the expected manner. As examples of trusted computational operations, the security processor 144 may generate cryptographic keys; store security artifacts (e.g., cryptographic keys and certificates); access security artifacts; delete security artifacts; store integrity measurement digests; provide signed integrity measurement digests for remote attestation; encrypt data; and decrypt data. The security processor 144 may provide a flexible policy-based access control mechanism that ties the sealing of cryptographic keys to specific integrity measurement digest states (e.g.,Binding a storage device's encryption key to a set of integrity measurements may enable unsealing of cryptographic keys, or any other sealing-related function. As further examples, the security processor 144 may provide nonces for cryptographic communication, sign certificates, and provide random or pseudorandom numbers. The trusted computational operations may also include operations to configure the security processor 144 and operations to own the security processor 144.

[0053] According to example implementations, the security processor 144 is an actual or physical component, e.g., a hardware device in the form of a semiconductor package (or "chip") mounted on a motherboard of the computing platform 110. The memory 148 may be secure memory, such as non-volatile random access memory, or "NVRAM." In one example, the memory 148 may store data representing cryptographic artifacts other than the cryptographic keys 152, such as sealed cryptographic keys, certificates, public keys, private keys, and so on. In another example, the memory 148 may also store data representing metrics. The security processor 144 may be designed according to industry standards to provide hardware-based security features while resisting tampering and malicious software.

[0054] According to example implementations, security processor 144 may be a trusted platform module (TPM). In examples, security processor 144 may perform one, more, or all of the trusted computation operations described in the TPM 2.0 specification. In accordance with further implementations, security processor 144 may perform one or more trusted computation operations not described in the TPM 2.0 specification.

[0055] In accordance with further implementations, the security processor 144 may be a virtual TPM (vTPM). Furthermore, according to further example implementations, the security processor 144 may be a firmware TPM (fTPM).

[0056] The security processor 144 may have one or more "key hierarchies." As used herein, a key "hierarchy" refers to a tree-like organization of key-related objects, where the objects are connected by parent-child relationships and the organization has an origin or beginning that may be referred to as a "root node." According to example implementations, a particular cryptographic key of a key hierarchy may be a child of another object (the parent object) of the key hierarchy. In one example, the root node of a key hierarchy may correspond to a persistent seed. In this context, "persistent" means that the seed survives one power cycle of the security processor 144.The security processor 144 may derive one or more non-persistent cryptographic keys (also called "transient" cryptographic keys) of the hierarchy each time the security processor 144 is powered on. In one example, a key hierarchy may include one or more persistent cryptographic keys. In one example, a child cryptographic key may be derived from its corresponding parent cryptographic key. In another example, a child cryptographic key, e.g., a cryptographic key imported into the security processor 144 and associated with a particular parent cryptographic key, may not be derived from the parent cryptographic key.

[0057] A cryptographic key of a key hierarchy may be referenced internally by the security processor 144 using a corresponding key handle, such as a key handle 139, provided to the security processor 144 via an API call, as described herein. In accordance with example implementations, the security processor 144 may control the use of or access to a particular cryptographic key through the use of an authentication value associated with the cryptographic key. The authentication value serves as a key password that restricts the use of the cryptographic key to a requestor who provides the authentication value. In one example, a requestor, such asthe authentication engine 168 of the management engine 169, passes the authentication value as a parameter in an API call for an operation of the security processor 144 that uses the cryptographic key as input.

[0058] In one example, the authentication engine 168 may import cryptographic keys corresponding to user passwords into a platform key hierarchy (also called a "platform hierarchy") of the security processor 144. According to example implementations, the platform hierarchy is associated with the platform vendor, and use of the platform hierarchy is authorized via a platform hierarchy authorization value that may be set by the firmware of the network device 120 during the boot process of the network device. In addition to the cryptographic keys corresponding to user passwords, the platform hierarchy may store a variety of different cryptographic keys, such as keys stored and used by the firmware (e.g., Unified Extensible Firmware Interface (UEFI) services) of the network device 120.In another example, the authentication engine 168 may import cryptographic keys corresponding to user passwords into a key hierarchy (e.g., a storage hierarchy) of the security processor 144 that is not a platform hierarchy.

[0059] As used herein, an "engine" may refer to one or more circuits. The circuits may be, for example, hardware processing circuitry, which may include any one or a combination of a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit (e.g., a programmable logic device (PLD), such as a complex PLD (CPLD)), a programmable gate array (e.g., a field programmable gate array (FPGA)), an application-specific integrated circuit (ASIC), or other hardware processing circuitry. An "engine" may refer to a combination of one or more hardware processing circuits and machine-readable instructions (software and / or firmware) executable on the one or more hardware processing circuits.In accordance with some implementations, one or more engines of the network device 120, such as the authentication engine 168 and / or the management engine 169, may be constituted by one or more hardware processors 124 executing machine-readable instructions 132.

[0060] As used here, a "hash" (which may also be called a "digest," "hash value," or "hash digest") is generated by applying a cryptographic hash algorithm to an input value. A cryptographic hash algorithm receives an input value, and the cryptographic hash algorithm generates a hexadecimal string (the digest or hash) corresponding to the input value. In one example, the input value might contain a string of data (e.g., a data structure in memory identified by a starting memory address and an ending memory address). In such an example, the cryptographic hash algorithm outputs a hexadecimal string (the digest or hash) based on the string of data. Any tiny change in the input value changes the hexadecimal output.For example, the cryptographic hash function can be a secure hash algorithm (SHA), a Federal Information Processing Standards (FIPS)-approved hash algorithm, a National Institute of Standards and Technology (NIST)-approved hash algorithm, or another cryptographic hash algorithm. In some examples, a different format for the string can be used instead of hexadecimal.

[0061] As used here, a "keyed hash algorithm" refers to a function that uses a cryptographic hash algorithm (e.g., an SHA, a FIPS-approved hash algorithm, a NIST-approved hash algorithm, or another hash algorithm) to generate a digest or hash based on a cryptographic key and a message input. The keyed hash algorithm derives an input to the cryptographic hash algorithm from the cryptographic key and the message input.

[0062] The keyed hash algorithm may derive a digest or hash in a single pass or in multiple iterations of the cryptographic hash algorithm. In one example, a keyed hash algorithm may form an input value based on a concatenation of the cryptographic key and the message input, and the keyed hash algorithm may provide the input value to a cryptographic hash algorithm, which provides a digest that is the output or result of the keyed hash algorithm. In another example, a keyed hash algorithm may form an input value based on a concatenation of a key derived from the cryptographic key and the message input, and the keyed hash algorithm may provide the input value to a cryptographic hash algorithm, which provides a digest that is the output or result of the keyed hash algorithm.In another example, a hash-based Message Authentication Code (HMAC) keyed hash algorithm derives a first key (also called an "inner key") and a second key (also called an "outer key") from the cryptographic key. In a first iteration, or pass (also called an "inner pass"), of the HMAC keyed hash algorithm, the first key and an input message are combined to obtain a first input value for a cryptographic hash algorithm, which yields a first digest (also called an "inner digest result").In a second iteration or pass (also called an "outer pass") of the HMAC key hash algorithm, the second key and the first hash value are combined to provide a second input value for the cryptographic hash algorithm, which provides a second hash value, which is the output or result of the HMAC key hash algorithm. The output of the HMAC key hash algorithm can be referred to as an HMAC.

[0063] Depending on the implementation, a cryptographic hash algorithm and / or a keyed hash algorithm may be executed by executing machine-readable instructions (i.e., in software), by special-purpose hardware that does not execute machine-readable instructions, or by a combination of machine-readable instruction execution and special-purpose hardware.

[0064] Fig. 2 is a sequence flow diagram 200, in accordance with example implementations, illustrating a sequence of actions and communications involved in updating a password in response to a password update request. Fig. 2 particularly illustrates actions and communications associated with a hardware processor 124 and a security processor 144. In one example, the hardware processor 124 may be configured to perform the Fig. 2, execute machine-readable instructions that are compatible with a password management engine, such as the management engine 169 of Fig. 1, are connected.

[0065] As in Fig. 2, the hardware processor 124 accesses a username and a new password 208. In one example, the hardware processor 124 may receive data representing the username and new password 208 in conjunction with a password update request. The hardware processor 124 invokes an operation of the security processor 144, as shown at 212, to generate a cryptographic key for the new password 208.

[0066] In accordance with further example implementations, the hardware processor 124 may generate the cryptographic key without using the security processor 144. In one example, the hardware processor 124 may generate the cryptographic key by executing machine-readable instructions. In another example, the hardware processor 124 may generate the cryptographic key using a cryptographic processor (e.g., a component of the hardware processor 124 or a component separate from the hardware processor 124) that is not the security processor 144.

[0067] In implementations where the hardware processor 124 generates a cryptographic key for the new password 208 using the security processor 144, the hardware processor 124 may communicate an API call or request 216 to the security processor 144. In an example where the security processor 144 is assumed to process API calls according to the TPM 2.0 specification, the API call 216 may be a TPM2_GetRandom() API call with TPM2B_Digest as the key type passed as an option. As illustrated at 220, the security processor 144 generates a cryptographic key 224 in response to the API call 216. According to example implementations, the security processor 144 returns a random number for this purpose, which the hardware processor 124 uses as the cryptographic key 224.In accordance with further implementations, the security processor 144 may return a random number that the hardware processor 124 further processes to generate the cryptographic key 224. In one example, the hardware processor 124 may apply a key derivation function to a random number returned by the security processor 144. In another example, the hardware processor 124 may concatenate the random number returned by the security processor 144 with a prefix and / or suffix to form the cryptographic key 224.

[0068] After the cryptographic key is generated, the hardware processor 124, in accordance with example implementations, may invoke an operation to load the cryptographic key into a memory of the security processor 144, as illustrated at 228. More specifically, to this end, in accordance with example implementations, the hardware processor 124 provides an API call 232 to load or import the cryptographic key into the security processor 144. In an example assuming that the security processor 144 processes requests according to the TPM 2.0 specification, the API call 232 may be a TPM2_LoadExternal() API call, in which the random number (the cryptographic key) is loaded as a child of any parent of the platform hierarchy of the security processor 144.In response to API call 232, security processor 144 loads the cryptographic key into its memory, as illustrated at 236, and returns a transient key handle 240 for the cryptographic key. Transient key handle 240 references the loaded cryptographic key.

[0069] After the cryptographic key is imported into the security processor 144, the hardware processor 124 may invoke an operation of the security processor 144, as illustrated at 244, to persist the cryptographic key stored in the memory of the security processor 144. To this end, in accordance with example implementations, the hardware processor 124 provides an API call 248 to the security processor 144 to persist the loaded cryptographic key. In an example assuming the security processor 144 processes requests in accordance with the TPM 2.0 specification, the API call 248 may be a TPM2_EvictControl() API request passing the transient key handle as an argument and an authentication value as an option. The authentication value serves as the password for the cryptographic key.The security processor 144 stores the cryptographic key as shown at 252 and returns a persistent key handle 256 in the corresponding API response.

[0070] After the cryptographic key has been retained, the hardware processor 124 may, as illustrated at 260, invoke an operation of the security processor 144 to crack the new password 208 based on the associated cryptographic key stored in the security processor 144. To this end, the hardware processor 124 may provide a keyed hash API call 264 to the security processor 144. In an example assuming the security processor 144 is processing requests according to the TPM 2.0 specification, the API call 264 may be a TPM2_HMAC() API call passing the new password 208 as an argument and the authentication value, persistent key handle, and identification of a cryptographic hash algorithm as options.In response to the API call 264, the security processor 144 provides an API response that returns a digest or hash 272 corresponding to the new password 208 (see . Fig. ).

[0071] At this point, the hardware processor 124 has the new key handle 256 and the new hash 272 for the new password 208. As shown in 276, the hardware processor 124 can then create a new authentication record or update an existing authentication record (depending on whether the authentication record already exists) with the new key handle 256 and the new reference hash 272, as shown in 280.

[0072] In another example, when an existing password is changed to the new password 208, in accordance with some implementations, the existing key handle and corresponding existing cryptographic key may be reused. In this variation, the sequence 200 omits actions 212 through 252 and begins at 260 by calling an operation to hash the new password 208. The security processor 144 may then generate the new reference hash 272, as shown at 268. The hardware processor 144 may then update the authentication record with the new reference hash 272, as shown at 276, without changing or replacing the existing key handle of the authentication record.

[0073] Fig. 3 is a sequence flow diagram 300 illustrating a sequence of actions and communications involved in authenticating a password in accordance with example implementations. In Fig. 3, actions and communications associated with a hardware processor 124 and a security processor 144 are particularly illustrated. In one example, the hardware processor 124 may execute machine-readable instructions associated with a password authentication engine, such as the password authentication engine 168 of Fig. 1, are connected to perform the actions and carry out the communication.

[0074] As in Fig. 3, the hardware processor 124 accesses a username 304 and a password 308 for verification according to the sequence flow diagram 300. In one example, the username 304 and password 308 may be associated with a password verification request. As shown at 312, the hardware processor 124 may read data from an authentication record of a password authentication file 141 corresponding to the username. As shown in Fig. 3, this data may represent a reference hash 316 and a key handle 320 for the password associated with the user account.

[0075] As illustrated at 330, the hardware processor 124 may invoke a keyed hashing operation of the security processor 144 to apply a keyed hash algorithm to an input corresponding to the password 308 and the cryptographic key referenced by the key handle 320. This operation generates a reference hash 342, which may then be compared to the reference hash 316 to verify the password 308. For the purpose of generating the hash 342, the hardware processor 124 may provide a keyed hash API call 334 to the security processor 144. In an example where the security processor 144 is assumed to process requests in accordance with the TPM 2.0 specification, the API call 334 may be a TPM2_HMAC() API call that passes the password 308 as an argument and the corresponding authentication value, the key handle 320, and a cryptographic hash algorithm identification as options.As in the . Fig. As shown, in response to the API call 334, the security processor 144 performs the keyed hashing operation and returns the hash 342 in a corresponding API response.

[0076] The hardware processor 124 may then determine, as illustrated at 336, whether the hash 342 matches the reference hash 316. If the hashes do not match, the hardware processor 124 may perform one or more responsive actions, including providing a verification failure response (as illustrated at 350) and logging the verification failure, as illustrated at 354. If the hardware processor 124 determines that the hashes match, as illustrated at 346, the hardware processor 124 may provide a verification success response, as illustrated at 360.

[0077] As in Fig. 4, a computing platform 400 includes a security processor 404 and a hardware processor 420. The security processor 404 includes a memory 408 and a keyed hash generator 412. The memory 408 stores a cryptographic key, and the security processor 404 associates the cryptographic key with a key handle. In one example, the security processor may be a trusted platform module (TPM). In one example, the security processor 404 may comply with the TPM 2.0 specification. In one example, the security processor 404 may be a physical hardware component mounted on a motherboard of the computing platform 400. In one example, the security processor 404 may be a virtual component. In one example, the security processor 404 may be a component implemented in firmware. In one example, the memory 408 may be NVRAM.In one example, keyed hash generator 412 may be configured to apply a secure hash algorithm version 2 (SHA-2). In one example, the cryptographic key may be stored in security processor 404. In one example, the key handle may be a persistent key handle.

[0078] The hardware processor 420 accesses a password and user identification associated with the request in response to a request to access the computing platform 400. In one example, the request may be generated by a program executing on the computing platform 400. In one example, the program may be a utility program. In one example, the program may be an application. In one example, the program may be launched in response to a command communicated to an operating system of the computing platform 400. In one example, the request may originate from another computing platform that is remotely located with respect to the computing platform 400. In one example, the request may be associated with a server daemon executing on the computing platform 400 that communicates with a remote client.The hardware processor 420 further accesses an authentication record corresponding to the user identification. In one example, the authentication record may be an entry in a password authentication file. In one example, the password authentication file may be a LINUX shadow file. In one example, the user identification may be a username.

[0079] The hardware processor 420 determines a key handle and a first cryptographic hash from the authentication record. In one example, the authentication record may be an entry in a text file, and the hardware processor 420 determining the key handle and the first cryptographic hash may include the hardware processor 420 reading the entry from the text file. In one example, the first cryptographic hash may be a reference or expected hash for a password associated with the user identification. In one example, the authentication record may include data corresponding to information other than the key handle and the first cryptographic hash. In one example, the other information may include privileges associated with the user identification. In one example, the other information may include a usage limit associated with the user identification.In one example, the other information may include a time-based limit associated with user identification. In one example, the other information may be an indicator of whether the password is valid. In another example, the other information may be a validity period or an expiration date for the password.

[0080] The hardware processor 420 provides the key handle and the password to the security processor 404 and initiates an operation of the security processor 404 in which the keyed hash generator 412 generates a second cryptographic hash based on the password and the cryptographic key. In one example, the hardware processor 420 may provide an API call to the security processor 404 because the keyed hash generator 412 of the security processor 404 generates the second cryptographic hash. In one example, the hardware processor 420 may pass the key handle as a parameter of the API call. In one example, the hardware processor 420 may pass the password as an argument of the API call. In one example, the hardware processor 420 may pass, as a parameter of the API call, an identification of a hash algorithm to be used by the keyed hash generator 412.In one example, the security processor 404 may return the second cryptographic hash in an API response to the API call.

[0081] The hardware processor 420 regulates whether the request is permissible based on a comparison of the second cryptographic hash to the first cryptographic hash. In one example, the hardware processor 420 may deny the request if the first cryptographic hash differs from the second cryptographic hash. In one example, the hardware processor 420 may regulate access to resources of the computing platform 400 in response to determining whether the second cryptographic hash matches the first cryptographic hash. In one example, the hardware processor 420 may determine a level of access to resources of the computing platform 400 based on one or more other criteria in response to determining that the second cryptographic hash matches the first cryptographic hash.In one example, the criteria may include one or more permissions or privileges associated with user identification.

[0082] According to Fig. 5, a non-transitory, machine-readable storage medium 500 stores machine-readable instructions 504. The instructions 504, when executed by a network device, cause the network device, in response to the creation of a password for user identification, to store a cryptographic key in a security processor of the network device and to determine a handle used by the security processor to reference the cryptographic key. In one example, the network device may be a network switch. In one example, the network device may be a managed network device. In one example, the instructions 504, when executed by the network device, cause the network device to send an API call to the security processor to import the cryptographic key into the security processor.In one example, the API call may cause the security processor to load the cryptographic key as a transient object and provide a transient handle to the transient object as returned output in response to the API call. In one example, instructions 504 may cause the network device to send an API call to the security processor to cause the security processor to maintain the cryptographic key. In one example, the security processor may respond to an API call to maintain the cryptographic key by returning a persistent key handle that corresponds to the handle used by the security processor to reference the cryptographic key. In one example, instructions 504 may cause the network device to perform one or more actions to generate the cryptographic key.In one example, instructions 504 may cause the network device to submit an API call to the security processor to cause the security processor to generate a random number and return the random number as part of an API response to the API call. In one example, the network device may use the returned random number as a cryptographic key.

[0083] Instructions 504, when executed by the network device, further cause the network device to access a cryptographic reference summary determined based on the cryptographic key and the password and create an authentication record corresponding to the user identification. In one example, the cryptographic summary may be determined based on the application of a keyed hash algorithm whose input is derived from the cryptographic key and the password. In one example, the keyed hash algorithm may be an HMAC algorithm. In one example, the authentication record may be an entry in a shadow file.

[0084] Instructions 504, when executed by the network device, further cause the network device to store in the authentication record data representing the user identification, the cryptographic reference digest, and the handle. Instructions 504, when executed by the network device, further cause the network device, in response to a request associated with the user identification to access the network device, to access the authentication record and process the request based on the cryptographic reference digest and the handle. In one example, processing the request may include verifying a password associated with the request based on the cryptographic reference digest and the handle.In one example, processing the request may include verifying the password and further evaluating one or more other criteria that govern the level of access. In one example, the criteria may include a privilege associated with a username. For example, one criterion may be a usage limit for a user account. In one example, processing the request may include rejecting the request in response to a lack of verification of a password based on a cryptographic reference evaluation and the handle.

[0085] As in Fig.6, in accordance with example implementations, a process 600 includes receiving (block 604) by an authorization engine of a computing platform, credentials associated with a request to access the computing platform. The credentials include a password and a user identification. The process 600 includes determining (block 608) by the authorization engine a key handle corresponding to the user identification and determining (block 612) by the authorization engine a cryptographic reference evaluation corresponding to the user identification. In one example, determining the key handle includes identifying an authentication record corresponding to the user identification and reading data from the authentication record corresponding to the key handle.In one example, determining the cryptographic reference summary includes identifying an authentication record corresponding to the user identifier and reading data from the authentication record corresponding to the cryptographic reference summary. In one example, the authentication record may be one of a plurality of entries of a shadow file. In one example, the authorization module may be a pluggable authentication module (PAM). In one example, the user identification may be a username.

[0086] The process 600 includes determining (block 616) a second cryptographic digest corresponding to the user identification. Determining the second cryptographic digest includes providing, by the authorization engine, the key handle and the password to a security processor of the computing platform; and initiating, by the authorization engine, an operation to apply a keyed hashing function to the password based on a cryptographic key corresponding to the key handle to provide the second cryptographic digest. The security processor stores the cryptographic key. In one example, the security processor may be a hardware component. In another example, the security processor may be a virtual component. In another example, the security processor may be a component implemented in firmware.In one example, the security processor may be a trusted platform module (TPM) configured to perform trusted computation according to the TPM 2.0 specification. In one example, the security processor may include a keyed hash generator. In one example, the keyed hash generator may be constructed to apply a secure hash algorithm version 2 (SHA-2). In one example, the cryptographic key may be retained in the security processor. In one example, the key handle may be a persistent key handle.

[0087] The process 600 includes regulating (block 620) access to the computing platform by the authorization engine based on a comparison of the second cryptographic digest with the reference cryptographic digest. In one example, regulating access to the computing platform includes regulating access to resources of the computing platform. In one example, regulating access to the computing platform includes permitting or denying access to the computing platform. In one example, regulating access to the computing platform includes permitting access based on a result of the comparison of the second cryptographic evaluation with the reference cryptographic evaluation and further regulating a level of access based on one or more other criteria, such as a privilege associated with user identification or a resource usage limit.

[0088] According to implementation examples, in response to password generation, the hardware processor initiates a security processor operation to load an object into secure memory and pass the cryptographic key as an object to the operation. A particular advantage is that password-related information can be generated, stored, and retrieved in a secure manner that is impervious to security attacks, such as dictionary-based and rainbow-table attacks.

[0089] According to example implementations, the security processor's operation to load the object into secure storage causes the security processor to designate the cryptographic key as a temporary object and return a temporary handle that the security processor associates with the cryptographic key. A particular advantage is that password-related information can be generated, stored, and retrieved in a secure manner that is not vulnerable to security attacks, such as dictionary-based attacks and rainbow-table attacks.

[0090] Consistent with example implementations, the hardware processor further initiates a security processor operation to cause the security processor to designate the cryptographic key as a persistent object and return a persistent handle that the security processor associates with the cryptographic key. The hardware processor stores the persistent handle in the authentication record as a key handle. A particular advantage is that password-related information can be generated, stored, and retrieved in a secure manner that cannot be compromised by security attacks, such as dictionary-based and rainbow-table attacks.

[0091] According to example implementations, the security processor also includes a random number generator. In response to password generation, the hardware processor initiates a security processor operation in which the random number generator generates a number. Further, in response to password generation, the hardware processor determines the number as a cryptographic key, initiates a security processor operation to load an object into secure storage, and passes the cryptographic key as an object to the operation to load the object into secure storage. A particular advantage is that password-related information can be generated, stored, and retrieved in a secure manner that cannot be compromised by security attacks, such as dictionary-based attacks and rainbow table-based attacks.

[0092] In accordance with example implementations, the hardware processor is further capable of, in response to the password being changed to a second password, providing the key handle and the second password to the security processor and initiating an operation of the security processor wherein the keyed hash generator generates a third cryptographic hash based on the second password and the cryptographic key. The hardware processor may further, in response to the password being changed to the second password, modify the authentication record, including replacing the first cryptographic hash with the third cryptographic hash. A particular advantage is that password-related information may be generated, stored, and retrieved in a secure manner that is not susceptible to security attacks, such asdictionary-based attacks and rainbow table-based attacks.

[0093] According to example implementations, the security processor includes a trusted platform module (TPM). A particular advantage is that password-related information can be generated, stored, and retrieved in a secure manner that is impervious to security attacks, such as dictionary-based and rainbow-table attacks.

[0094] The detailed description contained herein refers to the accompanying drawings. Wherever possible, the same reference numerals are used in the drawings and the above description to refer to the same or similar parts. However, it is to be expressly understood that the drawings are for the purpose of illustration and description only. Although several examples are described in this document, modifications, adaptations, and other embodiments are possible. Accordingly, the detailed description does not limit the disclosed examples. Instead, the proper scope of the disclosed examples may be defined by the appended claims.

[0095] The terminology used herein is for the purpose of describing specific examples only and is not intended to be limiting. The singular forms “a,” “an,” and “the” include the plural forms unless the context clearly indicates otherwise. As used herein, “plural” is defined as two or more than two. As used herein, “another” means at least a second or more. The term “connected,” as used herein, is defined as connected, either directly without any intervening elements or indirectly with at least one intervening element, unless otherwise noted. Two elements may be mechanically, electrically, or communicatively connected through a communications channel, pathway, network, or system. As used herein, the term “and / or” refers to and includes all possible combinations of the listed elements. Although the terms “first,” “second,” “third,” etc.are used here to describe various elements, those elements should not be limited by these terms, as these terms are used only to distinguish one element from another unless otherwise stated or the context indicates otherwise. As used herein, the term "includes" means includes, but is not limited to; the term "including" means includes, but is not limited to; and the term "based on" means based at least in part on.

[0096] Although the present disclosure has been described with respect to a limited number of implementations, those skilled in the art, having the benefit of this disclosure, will appreciate numerous modifications and variations thereof. The appended claims are intended to cover all such modifications and variations. QUOTES CONTAINED IN THE DESCRIPTION

[0000] This list of documents submitted by the applicant was generated automatically and is included solely for the convenience of the reader. This list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions. Cited non-patent literature

[0000] Trusted Platform Module Library Specification, Family 2.0, Level 00, Revision 01.59 (November 2019

[0024]

Claims

[1] A computer platform consisting of: a security processor with: a memory for storing a cryptographic key, wherein the security processor associates the cryptographic key with a key handle; and a keyed hash generator; and a hardware processor: in response to a request to access the computer platform, access a password and user identification associated with the request; access an authentication record corresponding to the user identification; determine a key handle and a first cryptographic hash from the authentication record; provide the key handle and the password to the security processor and initiate an operation of the security processor in which the keyed hash generator generates a second cryptographic hash based on the password and the cryptographic key; and determine whether the request is admissible based on a comparison of the second cryptographic hash with the first cryptographic hash. [2] The computer platform of claim 1, wherein the hardware processor further, in response to the creation of the password initiates a security processor operation to load an object into secure storage; and passes the cryptographic key as an object to the operation. [3] The computer platform of claim 2, wherein the operation of the security processor to load the object into the secure storage causes the security processor to designate the cryptographic key as a temporary object and to return a temporary handle that the security processor associates with the cryptographic key. [4] The computer platform of claim 3, wherein the hardware processor is further configured to: triggering an operation of the security processor to cause the security processor to designate the cryptographic key as a persistent object and to return a persistent handle that the security processor associates with the cryptographic key; and Store the persistent handle in the authentication record as a key handle. [5] The computer platform of claim 1, wherein: the security processor also includes a random number generator; the hardware processor is designed to further respond to the creation of the password: trigger a security processor operation in which the random number generator generates a number; to designate the number as a cryptographic key; initiate a security processor operation to load an object into secure storage; and to pass the cryptographic key as an object to the operation for loading the object into secure storage. [6] The computer platform of claim 1, wherein the hardware processor is further responsive to changing the password to a second password: provide the key handle and the second password to the security processor and initiate an operation of the security processor in which the keyed hash generator generates a third cryptographic hash based on the second password and the cryptographic key; and Changing the authentication record in response to the password change, including replacing the first cryptographic hash with the third cryptographic hash. [7] The computer platform of claim 1, wherein the security processor comprises a trusted platform module (TPM). [8] A non-transitory, machine-readable storage medium that stores machine-readable instructions that, when executed by a network device, cause the network device to: in response to the creation of a password for a user ID: to store a cryptographic key in a security processor of the network device; determine a handle used by the security processor to reference the cryptographic key; Access to a cryptographic reference extract determined on the basis of the cryptographic key and password; and create an authentication record corresponding to the user identifier; to store in the authentication record data representing the user identification, the cryptographic reference digest and the handle; and in response to a request for access to the network device associated with user identification: Access to the authentication record; and process the request based on the cryptographic reference digest and handle. [9] The storage medium of claim 8, wherein the instructions, when executed by the network device, further cause the network device, in response to the request: Submitting an application programming interface (API) call to the security processor to cause the security processor to provide a second cryptographic summary based on the handle and a password associated with the request; and reject or allow the request based on a comparison of the second cryptographic digest with the first cryptographic digest. [10] The storage medium of claim 9, wherein the instructions, when executed by the network device, further cause the network device to transmit, via the API call, an authorization value associated with the cryptographic key. [11] The storage medium of claim 9, wherein the operation comprises a hash operation of the security module, wherein the security module determines the second cryptographic hash by applying an encrypted cryptographic hash algorithm to the password associated with the request based on the cryptographic key. [12] The storage medium of claim 8, wherein the instructions, when executed by the network device, further cause the network device to communicate with the security processor via an application programming interface (API) call to cause a random number generator of the security processor to generate the cryptographic key. [13] The storage medium of claim 8, wherein the key handle comprises a persistent key handle, and the instructions, when executed by the network device, further cause the network device to: Sending a first application programming interface (API) call to the security processor to cause the processor to load the cryptographic key as a transient object into a platform hierarchy of the processor and to receive a transient handle of the cryptographic key; and Send a second API call to the processor to instruct it to store the cryptographic key as a persistent object and receive the handle of the persistent key. [14] The storage medium of claim 8, wherein the instructions, when executed by the network device, further cause the network device to communicate to the processor, via the first API call, an authorization value for the processor to associate with the cryptographic key. [15] A process comprising: Receiving, by an authorization engine of a computer platform, login data associated with a request to access the computer platform, the login data comprising a password and a user identification; Determination of a key handle corresponding to the user identification by the authorization engine; Determination of a cryptographic reference evaluation corresponding to the user identification by the authorization engine; Determining a second cryptographic summary corresponding to the user identification, wherein determining the second cryptographic summary comprises: Providing the key handle and password by the authorization engine to a security processor of the computer platform; and initiating, by the authorization engine, an operation by the security processor to apply a keyed hashing function to the password based on a cryptographic key corresponding to the key handle to provide the second cryptographic summary, wherein the security processor stores the cryptographic key; and Regulation of access to the computer platform by the authorization engine based on a comparison of the second cryptographic digest with the reference cryptographic digest. [16] The method of claim 15, wherein determining the second cryptographic digest further comprises providing, by the authentication engine and to the security processor, an authorization value corresponding to the cryptographic key. [17] The method of claim 15, wherein determining the key handle comprises identifying an authentication record corresponding to the user identification and reading data from the authentication record representing the key handle. [18] The method of claim 17, wherein: the authentication record is part of a shadow file that is restricted to the root user, and Reading the data involves reading the shadow file by the authentication system as the root user. [19] The method of claim 15, wherein determining the key handle comprises identifying an authentication record corresponding to the user identification and reading data from the authentication record representing the cryptographic reference digest. [20] The method of claim 15, wherein: the security processor includes a trusted platform module (TPM); the cryptographic key is linked to a platform hierarchy of the TPM; and determining the second cryptographic digest comprises the authentication engine passing the key handle to a hashing application programming interface (API) as an option of the API and the authentication engine passing a file path corresponding to the password as an argument of the API.

Images