Password authentication using cryptographic key handle-based authentication records

Abstract

Embodiments of the present disclosure relate to password authentication using an authentication record based on a cryptographic key handle. A process includes receiving credentials associated with a request to access a computer platform. The credential includes a password and a user identification. The process includes determining a key handle and a reference cryptographic 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 secure processor of the computer platform, and initiating an operation of the secure processor to apply a key hash function to the password based on a cryptographic key corresponding to the key handle to provide the second cryptographic digest. The secure processor stores a cryptographic key. The process includes regulating access to the computer platform based on a comparison of the second cryptographic digest to the reference cryptographic digest.

Description

Background Art

[0001] A computer platform can access a control system to regulate access to platform resources. A user can provide credentials associated with a request to log in to the computer platform. To determine whether to allow or deny any access by the user, the access control system can authenticate the credentials to verify the user's identity. The credential provision may be limited to a cognitive factor of the user's cognition (e.g., a password). If the access control system successfully verifies the user's identity based on the provided credentials, the access control system can regulate the degree of permitted access by the user based on one or more other criteria (e.g., role-based permissions associated with the user's account). Brief Description of the Drawings

[0002] Figure 1 is a block diagram of a computer network including a network device that provides a password authentication solution according to an example implementation, the password authentication solution using a password authentication record based on a cryptographic key handle.

[0003] Figure 2 is a sequence diagram of communication and actions for a hardware processor and a security processor to create or update a password authentication record using a cryptographic key handle and a hash of a password according to an example implementation.

[0004] Figure 3 is a sequence diagram of communication and actions for a hardware processor and a security processor to authenticate a password using a password authentication record based on a cryptographic key handle according to an example implementation.

[0005] Figure 4 is a block diagram of a computer platform that authenticates a password using a password authentication record based on a cryptographic key handle according to an example implementation.

[0006] Figure 5 is an illustration of machine-readable instructions that, when run by a network switch, cause the network switch to create and use a password authentication record based on a cryptographic key handle to authenticate a password according to an example implementation.

[0007] Figure 6 is a flowchart depicting a process of authenticating a password using a password authentication record based on a cryptographic key handle according to an example implementation. Detailed Description

[0008] The operating system of a computer platform can regulate access to the resources of the computer platform via user accounts. A user account has a set of associated privileges that control the level of access to the resources of the computer platform. From the perspective of a user (e.g., a person or a software entity), a user account can be identified by a name referred to as a "user name" (or "username"). For its operation, the operating system can identify a user account by a number referred to as a "user ID" (or "UID"). To log in to a user account, an access requester can provide credentials, such as a user name and a password, that are authenticated by the computer platform. In this context, "authenticating" the credentials means verifying the identity of the access requester based on 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 the records of the computer platform) and may be limited to the knowledge of the account holder. The computer platform can include an authentication module (e.g., a pluggable authentication module (PAM)) to verify the password provided by the access requester against the password records of the computer platform created for the user account.

[0009] More specifically, to verify the password provided by the access requester, the authentication module can access a password authentication file (e.g., the LINUX shadow file). The password authentication file can contain authentication entries or records corresponding to different user names. The authentication module can first identify a specific authentication record of the password authentication file corresponding 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.

[0010] Because password authentication files can be relatively insecure and thus potentially accessible to malicious actors, the actual password MUST NOT be stored in the authentication record. Instead, the authentication record can include a hash of the password (also referred to herein as a “digest”), with the password omitted from the record. The authentication module can verify a particular password by determining the hash of the password and then comparing the hash to a reference hash stored in the authentication record corresponding to the user name. The reference hash corresponds to the password that has been created for the user account. If the hashes are the same, the password provided by the access requester is verified, and if the hashes are different, the verification fails. Because sophisticated malicious actors may be able to derive the password from its reference hash (e.g., using a dictionary-based attack or a rainbow table-based attack to derive the password), the authentication record MAY include a value that is randomly or pseudo-randomly generated and referred to as a “salt”. For example, the salt, along with the reference hash, can be stored in the authentication record such that the input to the hash function is the concatenation of the salt and the password. Accordingly, the reference hash is a function of the password that has been created for the user account and the salt. Although the use of a salt may increase the time and amount of computation required for a malicious actor to learn the password, the addition of a salt may be ineffective against sophisticated malicious actors with substantial computing power. Additionally, a salt can significantly increase the time required to verify a password.

[0011] According to an example implementation, a password authentication solution stores a cryptographic key handle (referred to herein as a “key handle”) in the corresponding authentication record. For a given password associated with a user account, the key handle is a pointer or reference to the cryptographic key that identifies the corresponding reference hash used to derive the password. The relevance of the key handle is limited to the internal operations of the secure processor of the computer platform and does not disclose information from which the cryptographic key can be derived outside of the secure processor. In this way, the exposure of the key handle does not disclose or otherwise compromise the corresponding password. As discussed herein, the key handle is associated with the security-enhancing features of the secure processor, which prevents the underlying password from being compromised.

[0012] In one example, the authentication record can contain data representing a user identifier (such as a user name), a key handle, and a reference hash. The key handle references a cryptographic key stored in the secure processor. The reference hash is the result of a keyed-hash algorithm with an input value derived from the password and the cryptographic key. In one example, the secure processor can have a keyed-hash module or engine to apply the keyed-hash algorithm based on the cryptographic key and the password to provide the corresponding reference hash. In one example, the secure processor can generate the cryptographic key and provide the corresponding key handle that the secure processor uses internally to reference the cryptographic key.

[0013] According to an example implementation, a computer platform includes a password authentication engine (e.g., PAM) to authenticate a password based on a corresponding key handle and a reference hash. According to an example implementation, to authenticate a password, the password authentication engine identifies an authentication record for a corresponding user name and reads data corresponding to the key handle from the identified authentication record. The password authentication engine invokes a key hashing operation performed by a key hashing engine of a security processor via an API call (call) to the security processor. The platform authentication engine passes the password, the key handle, and other input parameters of the API call to the security processor. In response to the API call, the security processor identifies a cryptographic key from the key handle, and the key hashing engine of the security processor hashes the password based on the cryptographic key to provide a digest or hash that is the output returned by 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 (e.g., hash match) or fails (e.g., hash mismatch) the password authentication.

[0014] The security processor has features that prevent the cryptographic key from being exposed outside the security processor and prevent unauthorized use of the key hashing engine and the cryptographic key of the security processor. In one example of a security feature, the security processor does not allow the cryptographic key to be exported or otherwise leaked outside the security processor. In another example of a security feature, the security processor constrains the use of the cryptographic key to specific authorized values. Thus, the cryptographic key cannot be used for a key hashing operation unless an authorized value is provided in the API call that invokes the operation. Thus, a malicious actor cannot use the key hashing engine of the security processor to test a specific candidate password even if the malicious actor gains access to the key handle.

[0015] According to an example implementation, a computer platform includes a password management engine (e.g., PAM) that manages password-related information stored in authentication records. In one example, in response to creating or modifying a password for a user account, the password management engine stores data representing the key handle and a reference hash corresponding to the password in the corresponding authentication record. To export the key handle and the reference hash, according to an example implementation, the password management engine can cause the security processor to generate a cryptographic key, store and save the cryptographic key, and provide (to the password management engine) the key handle of the cryptographic key via an API call to the security processor. Additionally, according to an example implementation, the password management engine can cause the security processor to apply a key hashing operation to the password based on the cryptographic key to provide a reference hash via an API call to the security processor.

[0016] 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 perform corresponding updates to the appropriate authentication records. In one example, these actions may include creating a new password key using a security processor, importing the new password key into the security processor, receiving a corresponding key handle for the new password key from the security processor, and creating a new reference hash using the security processor. The password management engine may then update the authentication record to replace the old reference hash and old key handle corresponding to the previous password with the new reference hash and new key handle. In another example, to change an existing password to a new password, the password management engine may reuse the existing key handle for the existing password (and thus, reuse the same password key). In this way, the password management engine may create a new reference hash for the new password using the security processor without changing the password key. In another example, the password management engine may remove the reference hash and key handle from the corresponding authentication record in response to removing or deleting a user account from the computer platform. In one example, removing the reference hash and key handle may include the password management engine deleting the authentication record.

[0017] According to an example implementation, the password management engine takes actions to generate a different password key for each password. The reference hash described herein is unique for each password, and the password key is securely stored outside the authentication record. These features may prevent dictionary-based attacks or rainbow table-based attacks from being used to derive passwords.

[0018] According to an example implementation, the computer 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 appropriate credentials in order to, for example, configure the network switch and set up the network switch to be managed via a network management service.

[0019] Reference Figure 1 , as a more specific example, according to some implementations, the computer platform 110 has an authentication engine 168 that authenticates the identity of an access requester based on credentials provided by the requester. According to an example implementation, for an access requester attempting to log in to a particular user account, the requester provides a password, which causes a corresponding password verification request to be sent to the authentication engine 168. In one example, the access requester may log in to the computer platform 110 via a particular program 172, and the program 172 may send the corresponding password verification request to the authentication engine 168. In this context, a "password verification request" generally refers to a query to determine whether the password provided by the access requester is the same as the password record of the computer platform that has been created for the corresponding user account (e.g., the account holder corresponding to the user name associated with the access requester).

[0020] According to the example implementation, in response to a password verification request, the authentication engine 168 determines whether the password associated with the request is the same as the password that the account holder has created for the user account, as reflected in the records of the computer platform. In one example, the authentication engine 168 returns a response to the password verification request to indicate whether the verification of a particular password has passed or failed. In one example, for a failed verification, the computer platform 110 rejects the login, thereby preventing the access requester from accessing the resources of the computer platform 110 via the corresponding user account. In one example, for a successful verification, the computer platform 110 can then determine the level of access to the resources of the computer platform 110 that is allowed by the computer platform 110 based on one or more other criteria (e.g., permissions associated with the user account, whether the password has expired, usage constraints, time-based constraints, and other possible criteria).

[0021] In the context used herein, a "password" generally refers to a character sequence used to obtain access to one or more resources (such as one or more resources of the computer platform 110). In an example, the password can be: a sequence of numbers; a sequence of letters; an alphanumeric sequence; a sequence of special characters (e.g., "$", "%", "&", and / or other characters that are neither numbers nor letters); a sequence of letters, numbers, and special characters; or another combination of characters having one or more character types. In an example, the password can be constrained to have a minimum number of characters, a maximum number of characters, characters corresponding to certain character types, or possess one or more other characteristics.

[0022] In the context used herein, "resources" of the computer platform 110 refer to physical or virtual components or services associated with the computer platform 110. In an example, the resources can be 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 another component or service that is part of or provided by the computer platform 110.

[0023] The authentication engine 168 can receive a password verification request from any one of a plurality of different sources. In one example, the password verification request can be provided by a program 172 running on the computer platform 110. In one example, the program 172 can prompt an access requester for a password for a specific user account, and in response to the access requester providing the password, the program 172 can submit a corresponding password verification request to the authentication engine 168. In an example, a user or script running on the computer platform 110 can provide input through the command line interface (shell) or user interface of the operating system 164 of the computer platform 110, which causes the program 172 that sends the password verification request to the authentication engine 168 to run. In one example, to start a session on the computer platform 110, a user or script can enter a login command via the command line interface. The login command causes the login utility 172 that prompts for a password to run, and to determine whether the session is allowed, the login utility 172 can transmit a corresponding password verification request to the authentication engine 168.

[0024] In another example, for the LINUX operating system, to substitute or switch user accounts, a user or script can enter a substitute user command (also known as the "switch user" command or "su" command) via the command line interface. The substitute user command causes the substitute user utility 172 that prompts for the password of the new user account to run, and to determine whether the switch of the user account is allowed, the substitute user utility 172 can transmit a corresponding password verification request to the authentication engine 168.

[0025] In another example, for the LINUX operating system, to change the password of the current user account, a user or script can enter a password command via the command line interface. The password command causes the password utility 172 that prompts for the current password to run, and to determine whether the update of the password is allowed, the utility 172 can transmit a corresponding password verification request to the authentication engine 168.

[0026] In another example, to allow a requester on the remote client device 180 to log in to the computer platform 110, a background or daemon program 172 can be run on the computer platform 110. In one example, the daemon program 172 can be an SSH server that communicates with the secure shell daemon (SSHd) client of the client device 180.

[0027] In other examples, a program 172 on the computer platform 110 that is not affiliated with a utility (such as an application or display manager) can send a password verification request to the authentication engine 168.

[0028] According to an example implementation, the authentication engine 168 processes password verification requests based on information stored in the password authentication file 141. In one example, the password authentication file 141 can be stored in the memory 136 of the computer platform 110. In another example, the password authentication file 141 can be stored remotely relative to the computer platform 110. In one example, for the LINUX operating system 164, the password authentication file 141 can be a text-based shadow file with the following file path: / etc / shadow. According to an example implementation, access to the password authentication file 141 can be restricted to the root user.

[0029] According to an example implementation, the password authentication file 141 includes password authentication entries or records 137 (referred to herein as "authentication records 137"). According to an example implementation, each authentication record 137 is associated with a specific user name and, correspondingly, with a specific user account. Among other possible information, the authentication record 137 can include fields containing data representing: the user name; a reference digest or hash 138 that corresponds to a password that has been created by the account holder; and a key handle 139.

[0030] The key handle 139 references a cryptographic key 152 stored in the secure memory 148 of the secure processor 144 of the computer platform 110. In the context used herein, a "cryptographic key" refers to a sequence of characters associated with a cryptographic algorithm or function. In one example, a cryptographic key can be a number formed by the concatenation of digits (e.g., the concatenation of digits represented in hexadecimal or hex format). In other examples, a cryptographic key can 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, as further described herein, the cryptographic key 152 is associated with a cryptographic key hash algorithm. In one example, the key hash algorithm can be a hash message authentication code (HMAC) algorithm. In one example, the key hash algorithm can be the algorithm described in Section 11.4.4 of Part 1 of the Trusted Platform Module Library Specification Family, Level 2.0, Revision 00, Version 01.59 (November 2019) (hereinafter referred to as the "TPM2.0 Specification") published by the Trusted Computing Group. In one example, the key hash algorithm can use a hash algorithm from the Secure Hash Algorithm 2 (SHA-2) hash algorithm family, such as the SHA-256 hash algorithm or the SHA-512 hash algorithm.

[0031] The key handle 139 does not contain information that could be used to leak the corresponding cryptographic key 152 outside the secure processor 144. Figure 1 Depicts the use of the key handle 155 (e.g., the key handle 139 of the authentication record 137 that has been passed to the secure processor 144 via an API call) within the secure processor 144. The secure processor 144 uses the key handle 155 to identify the corresponding cryptographic key 152 for (one or more) internal operations of the secure processor 144 (as depicted by the association 153). As further described herein, according to an example implementation, in order to invoke the key hashing operation of the key hashing engine 160 of the secure processor 144, the authentication engine 168 may pass the key handle and the password (being authenticated) to the secure processor 144 via an API call. The key hashing operation involves the key hashing engine 160 applying a key hashing algorithm, where the input to the algorithm is the password and the cryptographic key 152. In response to the API call, the secure processor 144 returns the resulting digest or hash produced by the key hashing operation.

[0032] In the context used herein, the application programming interface or "API" of the secure processor 144 refers to a collection of one or more software and / or hardware components of the secure processor 144 that together provide one or more functions or operations for the secure processor 144. The secure processor 144 performs API-related operations in response to a request, which is referred to herein as an "API call". Transmitting or providing an API call to the secure processor 144 may be referred to as invoking a specific function or operation of the secure processor 144. An API call may have an associated structure that defines how (one or more) parameters are passed via the API call and how (one or more) parameters are returned as (one or more) outputs produced by the operation invoked by the secure processor 144 executing 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 the API call corresponding to options and / or parameters (e.g., inputs) of the function or operation invoked by the API call. According to an example implementation, the secure processor 144 may include one or more registers that the hardware processor 124 can write with data corresponding to the parameters of a specific API call. Additionally, the secure processor 144 may include one or more registers that contain data representing the output produced by the secure processor 144 in response to a specific API call. According to another implementation, the API call and the corresponding result may be transmitted between the hardware processor 124 and the secure processor 144 via a shared memory message. The response of the secure processor 144 to a specific API call is referred to herein as an "API call response" or "API response".

[0033] The authentication engine 168 validates the password associated with a password verification request by first identifying the authentication record 137 corresponding to the user name. The authentication engine 168 then reads the key handle 139 from the identified authentication record 137 and submits an API call to the security processor 144 to invoke a key hashing operation. In conjunction with the API call, the authentication engine 168 passes the key handle 139 and the password being verified as inputs to the API call to the security processor 144. In response to the API call, the security processor 144 then returns a digest or hash corresponding to the key hash of the password and a cryptographic key 152 corresponding to the key handle 139. The authentication engine 168 then compares the hash returned by the security processor 144 with the reference hash 139 of the identified authentication record 137. If the hashes match, the authentication engine 168 provides a response to the password verification request indicating successful verification. If the hashes are different, the authentication engine 168 provides a response to the password verification request indicating verification failure.

[0034] According to an example implementation, the computer platform 110 includes a password management engine 169 (referred to herein as "management engine 169"), and the password management engine 169 manages updates related to password information of the password authentication file 141 in response to a password update request. Generally speaking, a "password update request" refers to an instruction for modifying password information associated with a specific user account (e.g., information stored in the password authentication file 141). In one example, the password update request may be directed to creating an authentication record 137. In another example, the password update request may be directed to deleting an authentication record 137. In another example, the password update request may be directed to changing or modifying password-related information of an existing authentication record 137. In one example, modifying the information of the authentication record 137 may include: in response to creating a new password for a user account, replacing the existing reference hash and the existing key handle of the authentication record 137 with a new reference hash and a new key handle. In another example, modifying the information of the authentication record 137 may include: in response to creating a new password for a user account, retaining the existing key handle of the authentication record 137 (i.e., reusing the same cryptographic key) and replacing the existing reference hash of the authentication record 137 with a new reference hash.

[0035] The password update request may originate from any one of a plurality of different sources. In one example, the password update request may be provided by a program 172 running on the computer platform 110. In one example, the program 172 may prompt the user to create a new password (e.g., the first password created for a user account or a password used to replace the current password). In response to the user creating a new password, the program may submit a password request containing the new password and the user name to the management engine 169.

[0036] In one example, for the LINUX operating system, to change the password of a user account, the user can enter a password command via the command line interface of the operating system 164. The password command causes the password utility 172 that prompts for a new password to run, and in response to providing the new password, the password utility 172 can transmit a corresponding password update request to the management engine 169.

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

[0038] To service a password update request to change or create a password, the management engine 169 can perform the following actions. The management engine 169 uses the security processor 144 to generate a new cryptographic key 152 for the new password and provides a new key handle 139 corresponding to the new cryptographic key 152. In addition, the management engine 169 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 engine 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.

[0039] According to an example implementation, the management engine 169 uses the random number generator 158 of the security processor 144 to generate the new cryptographic key 152. According to an example implementation, the random number generator 158 randomly or pseudo-randomly generates numbers, and the management engine 169 uses the numbers as the cryptographic key 152.

[0040] According to some implementations, the random number generator 158 can be a true random number generator that generates random numbers based on inputs provided by an entropy source. In one example, the random number generator can sample truly random analog signals (such as thermal noise signals (e.g., Johnson - Nyquist noise signals provided by a resistor) or atmospheric noise signals received by an antenna). In other examples, the random number generator 158 can process inputs representing clock variations, air movement, or inputs provided by another entropy source.

[0041] In another example, according to some implementations, the security processor 144 can include a digital generator that generates pseudo-random numbers rather than truly random numbers. For these implementations, the management engine 169 can use the pseudo-random numbers as the cryptographic key 152.

[0042] According to an example implementation, the management engine 169 can invoke the operation of the random number generator 158 to generate a number via an API call to the service processor 144, and the security processor 144 returns the number to the management engine 169 as an output parameter in the API response. In one example, the management engine 169 uses the number returned by the security processor 144 as the cryptographic key 152 without further modification. In another example, the management engine 169 can modify the number. For example, the management engine 169 can 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 engine 169 can concatenate the number returned by the security processor 144 with other information, or apply another modification to derive the cryptographic key 152. In another example, the management engine 169 can combine (e.g., concatenate) the number returned by the security processor 144 with other information to provide an input to a key derivation function that provides the cryptographic key 152.

[0043] In one example, the random number generator 158 can be the digital random number generator (RNG) module described in section 11.4.11 of part 1 of the TPM 2.0 specification. In another example, the management engine 169 can generate the 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, to generate the cryptographic key 152, the management engine 169 can run machine-readable instructions corresponding to a cryptographic key generator or a number generator. As another example, to generate the cryptographic key 152, the management engine 169 can use a password processor separate from the security processor 144. In another example, the management engine 169 can use a graphics processing unit (GPU) to generate a random or pseudo-random number to be used as the cryptographic key 152.

[0044] After generating the cryptographic key 152, the management engine 169 can load or import the cryptographic key 152 into the security processor 144 via an API call. More specifically, according to an example implementation, the API call can cause the security processor 144 to load or import the cryptographic key 152 as a temporary object. In this context, a "temporary object" refers to an entity that cannot survive a power cycle of the security processor 144. In other words, the security processor 144 retains the temporary object until the security processor 144 is powered off. In one example, when the computer platform 110 shuts down or restarts, the temporary objects of the security processor 144 can be deleted or erased. According to an example implementation, the security processor 154 responds to the API call to load the cryptographic key 152 with an API response that returns a corresponding temporary key handle referencing the temporary object.

[0045] According to an example implementation, after the API call to import the cryptographic key 152, the management engine 169 makes a subsequent API call to the security processor 144 to direct the security processor 144 to save the loaded cryptographic key 152. In one example, the management engine 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 saves the cryptographic key 152 and returns a persistent key handle (referencing the saved cryptographic key 152) in the corresponding API response. The returned persistent key handle corresponds to the key handle 139. In this context, "saving" the cryptographic key 152 means that the cryptographic key 152 is stored in a way that can survive a power-off of the security processor 144. Thus, in the case where the cryptographic key 152 is saved, when the computer platform 110 shuts down or restarts, the security processor 144 retains the key 152.

[0046] After importing the cryptographic key 152 into the security processor 144 and saving the cryptographic key 152, the management engine 169 can take an action to generate a new reference hash 138. More specifically, according to an example implementation, to generate the new reference hash 138, the management engine 169 passes the new key handle 139 and the new password to the security processor 144 via an API call. The security processor 144 returns the new reference hash 138 as an output parameter in the corresponding API response.

[0047] According to some implementations, the authentication engine 168 and the password management engine 169 can be corresponding pluggable authentication modules (PAMs). According to some implementations, a program 172 that submits requests to a specific PAM can be compiled with the corresponding PAM library. According to another implementation, the authentication engine 168 and the password management engine 169 can be part of the same PAM.

[0048] As Figure 1As depicted, according to an example implementation, the computer platform 110 can be a network device 120, such as a managed network switch. The network device 120 can have one or more associated user accounts. A particular user account may be accessed for any of a variety of different reasons. In one example, configuration data, such as data corresponding to one or more configuration files (e.g., yet another markup language (YAML) files), can be provided to the network device 120 via the access provided by the user account. In another example, different settings of the network device 120 can be configured via the access provided by the user account. In the example, these settings can include Quality of Service (QoS) settings, Class of Service (CoS) settings, virtual local area network (VLAN) tag settings, VLAN untag settings, ingress bandwidth settings, egress bandwidth settings, Power over Ethernet (POE) settings, and different and / or other configurable settings of the network device 120. In one example, the network device 120 can be configured to report network telemetry metrics to a network management service via the access provided by the user account. In another example, the network device 120 can be set to report network telemetry metrics to a network management service via the access provided by the user account.

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

[0050] According to an example implementation, the network switching fabric 190 can be associated with one or more types of communication networks, such as (by way of example) a Fibre Channel network, a Compute Express Link (CXL) fabric, a dedicated management network, a local area network (LAN), a WAN, a global network (e.g., the Internet), a wireless network, or any combination thereof.

[0051] In one example, the network device 120 can be managed by a central network management system (NMS) component deployed on one or more network resources 186, which are coupled to the network device 120 via the network switching fabric 190. In one example, the network resources 186 can be cloud-based resources. In one example, the central NMS component can include a central server that provides one or more NMS services to the network device 120. In an example, the NMS services can include firmware update services, network telemetry monitoring services, network troubleshooting services, network performance enhancement services, and other services.

[0052] In the context used herein, a "network device" (such as the network device 120) refers to an actual or physical electronic component capable of communicating data between other components. In one example, the network device can be a switch that operates at the second layer (L2) of the Open Systems Interconnection (OSI) model to connect components of a computer network together. In another example, the network device can be a third layer (L3) switch that connects two components of a computer network together and connects computer networks together. In other examples, the network device can 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 Fibre Channel switch that includes one or more of the foregoing devices. The network device can be a wired or wireless device.

[0053] According to another implementation, the computer platform 110 can be a non-network device. In the context used herein, a "computer platform" refers to a processor-based electronic device with an associated operating system. In other examples, the computer platform 110 can be: a stand-alone server; a distributed server; a rack-mounted server module; an edge processing rack-mounted module; a blade server; a blade enclosure containing 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 smart phone; a wearable computer; or another processor-based platform.

[0054] For Figure 1 the specific implementation depicted, computer platform 110 has 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, hardware processor 124 may include one or more central processing unit (CPU) cores and / or one of multiple graphics processing unit (GPU) cores. In another example, hardware processor 124 may include one or more semiconductor CPU packages (or “sockets”). In another example, hardware processor 124 may include one or more GPU packages. In one example, to provide one or more software components of computer platform 110, such as authentication engine 168 and / or management engine 169, hardware processor 124 may run machine-executable instructions, such as machine-readable instructions 132 stored in system memory 128. In another example, hardware processor 124 may be a hardware circuit that does not run 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 for computer platform 110 (e.g., functions related to authentication engine 168 and / or management engine 169).

[0055] System memory 128 includes a non-transitory storage medium that may be formed by semiconductor storage devices, memristor-based storage devices, magnetic storage devices, phase change memory devices, a combination of devices of one or more of these storage technologies, etc. System memory 128 may represent a memory collection of volatile memory devices and non-volatile memory devices.

[0056] In an example, operating system 164 may be a LINUX operating system, a WINDOWS operating system, a MAC operating system, a FREEBSD operating system, a hypervisor (e.g., ESXi, KVM, or Hyper-V hypervisor), or another operating system.

[0057] According to an example implementation, to provide one or more hardware abstractions, computer platform 110 may have virtualization technology. In one example, computer platform 110 may have a hypervisor that provides virtual machines, and operating system 164, authentication engine 168, management engine 169, and program 172 are located within the virtual machines. In another example, computer platform 110 may have a container engine that provides a container environment (e.g., a single container, a pod, or a pod cluster), and authentication engine 168, management engine 169, and program 172 are located within the container environment. In another example, operating system 164, authentication engine 168, management engine 169, and program 172 may run on bare metal.

[0058] According to some implementations, to ensure that computer platform 110 always behaves in an expected manner, security processor 144 may provide trusted computing operations for computer platform 110. As examples of trusted computing operations, security processor 144 may: generate cryptographic keys; store security artifacts (e.g., cryptographic keys and certificates); access security artifacts; erase security artifacts; store integrity measurement digests; provide signed integrity measurement digests for remote attestation; encrypt data; and decrypt data. Security processor 144 may provide a flexible access control mechanism based on multiple policies, and these policies may be used for: sealing, such as sealing a cryptographic key to certain integrity measurement digest states (e.g., binding the encryption key of a storage device to an integrity measurement set); unsealing a cryptographic key; or any other sealing-related functions. As other examples, security processor 144 may: provide random numbers for cryptographic communications; sign certificates; and provide random or pseudorandom numbers. Trusted computing operations may also include operations for configuring security processor 144 and operations for owning security processor 144.

[0059] According to an example implementation, security processor 144 is an actual or physical component, such as a hardware device in the form of a semiconductor package (or "chip") installed on the motherboard of computer platform 110. Memory 148 may be a secure memory, such as non-volatile random access memory or "NVRAM". In one example, memory 148 may store data representing password artifacts other than cryptographic key 152, such as sealed cryptographic keys, certificates, public keys, private keys, etc. Additionally, in another example, memory 148 may store data representing measurement digests. Security processor 144 may be designed according to industry standards to provide hardware-based security functions while also resisting tampering and malware.

[0060] According to an example implementation, the security processor 144 can be a Trusted Platform Module (TPM). In the example, the security processor 144 can perform one, multiple, or all of the trusted computing operations described in the TPM 2.0 specification. According to another implementation, the security processor 144 can perform one or more trusted computing operations not described in the TPM 2.0 specification.

[0061] According to another implementation, the security processor 144 can be a virtual TPM (vTPM). Additionally, according to another example implementation, the security processor 144 can be a firmware TPM (fTPM).

[0062] The security processor 144 can have one or more "key hierarchies". In the context used herein, a key "hierarchy" refers to a tree-like organization of key-related objects, where the objects are linked by a parent-child relationship, and the organization has an origin or starting point that can be referred to as a "root node". According to an example implementation, a given cryptographic key of the key hierarchy can be a child object of another object (the parent object) of the key hierarchy. In one example, the root node of the key hierarchy can correspond to a persistent seed. In this context, a seed is "persistent" if it survives a power cycle of the security processor 144. The security processor 144 can export one or more non-persistent cryptographic keys (also referred to as "ephemeral" cryptographic keys) of the hierarchy each time the security processor 144 powers on. In one example, the key hierarchy can include one or more persistent cryptographic keys. In one example, a child cryptographic key can be derived from its corresponding parent cryptographic key. In another example, a child cryptographic key (such as a cryptographic key imported into the security processor 144 and associated with a specific parent cryptographic key) may not be derived from the parent cryptographic key.

[0063] The cryptographic keys of the key hierarchy can be internally referenced by the security processor 144 using corresponding key handles (such as the key handle 139 provided to the security processor 144 via an API call), as discussed herein. According to an example implementation, the security processor 144 can control the use or access to a cryptographic key by using an authentication value associated with the specific cryptographic key. The authentication value acts as a key password that restricts the use of the cryptographic key by the requester providing the authentication value. In one example, a requester (such as the authentication engine 168 of the management engine 169) can pass the authentication value as a parameter in an API call for an operation of the security processor 144 that uses the cryptographic key as an input.

[0064] In one example, the authentication engine 168 can import a cryptographic key corresponding to a user password into the platform key hierarchy (also referred to as the "platform hierarchy") of the security processor 144. According to an example implementation, the platform hierarchy is associated with the platform manufacturer, and the use of the platform hierarchy is authorized via a platform hierarchy authorization value that can be set by the firmware of the network device 120 during the startup of the network device. For example, in addition to the cryptographic key corresponding to the user password, the platform hierarchy can also store various different cryptographic keys, such as keys stored and used by the firmware of the network device 120 (e.g., Unified Extensible Firmware Interface (UEFI) services). In another example, the authentication engine 168 can import the cryptographic key corresponding to the user password into the key hierarchy (e.g., storage hierarchy) of the security processor 144 instead of the platform hierarchy.

[0065] As used herein, an "engine" can refer to one or more circuits. For example, a circuit can be a hardware processing circuit, which can include 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 any one or some combination thereof in another hardware processing circuit. An "engine" can refer to a combination of one or more hardware processing circuits and machine-readable instructions (software and / or firmware) that can run on the one or more hardware processing circuits. According to some implementations, one or more engines of the network device 120 (such as the authentication engine 168 and / or the management engine 169) can be formed by one or more hardware processors 124 running machine-readable instructions 132.

[0066] In the context used herein, a "hash" (which may also be referred to by terms such as "digest", "hash value", or "hash digest") is generated by applying a cryptographic hash algorithm to an input value. The cryptographic hash algorithm receives the input value, and the cryptographic hash algorithm generates a hexadecimal string (digest or hash) that matches the input value. In one example, the input value may include a data string (e.g., a data structure represented in memory by a starting memory address and an ending memory address). In such an example, based on the data string, the cryptographic hash algorithm outputs a hexadecimal string (digest or hash). Any minor change to the input value will change the output hexadecimal string. In an example, the cryptographic hash function may be a secure hash algorithm (SHA), a Federal Information Processing Standard (FIPS)-approved hash algorithm, a National Institute of Standards and Technology (NIST)-approved hash algorithm, or any other cryptographic hash algorithm. In some examples, another format may be used instead of the hexadecimal format.

[0067] In the context used herein, a "keyed hash algorithm" is a function that uses a cryptographic hash algorithm (e.g., SHA, a FIPS-approved hash algorithm, a NIST-approved hash algorithm, or other hash algorithms) to generate a digest or hash based on a cryptographic key and a message input. The keyed hash algorithm derives the input to the cryptographic hash algorithm from the cryptographic key and the message input.

[0068] A key hash algorithm can derive a digest or hash using a single pass or multiple iterations of a cryptographic hash algorithm. In one example, the key hash algorithm can form an input value based on the concatenation of a cryptographic key and a message input, and the key hash algorithm can provide the input value to a cryptographic hash algorithm that provides a digest, where the digest is the output or result of the key hash algorithm. In another example, the key hash algorithm can form an input value based on the concatenation of keys derived from a cryptographic key and a message input, and the key hash algorithm can provide the input value to a cryptographic hash algorithm that provides a digest, where the digest is the output or result of the key hash algorithm. In another example, a hashed message authentication code (HMAC) key hash algorithm derives a first key (also referred to as an "inner key") and a second key (also referred to as an "outer key") from a cryptographic key. In the first iteration or first pass (also referred to as the "inner pass") of the HMAC key hash algorithm, the first key and the message input are combined to provide a first input value to a cryptographic hash algorithm that provides a first digest (also referred to as an "inner digest result"). In the second iteration or second pass (also referred to as the "outer pass") of the HMAC key hash algorithm, the second key and the first digest are combined to provide a second input value to a cryptographic hash algorithm that provides a second digest, where the second digest 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.

[0069] Depending on the particular implementation, a cryptographic hash algorithm and / or a key hash algorithm can be performed by running machine-readable instructions (i.e., executing in software), by dedicated hardware that does not run machine-readable instructions, or by a combination of running machine-readable instructions and dedicated hardware.

[0070] Figure 2 is a sequence flow diagram 200 depicting the sequence of actions and communications involved in updating a password in response to a password update request according to an example implementation. Figure 2 Specifically depicts actions and communications associated with a hardware processor 124 and a security processor 144. In one example, to perform Figure 2 the depicted actions and communications, the hardware processor 124 can run machine-readable instructions associated with a password management engine (such as Figure 1 the management engine 169).

[0071] Referring to Figure 2 , the hardware processor 124 accesses the user name and the new password 208. In one example, the hardware processor 124 can receive data representing the user name and the new password 208 associated with a password update request. As depicted at 212, the hardware processor 124 invokes the operation of the security processor 144 to generate a cryptographic key for the new password 208.

[0072] According to another example implementation, the hardware processor 124 may generate a cryptographic key without using the secure processor 144. In one example, the hardware processor 124 may generate a cryptographic key by running machine-readable instructions. In another example, the hardware processor 124 may use a password processor other than the secure processor 144 (e.g., a component of the hardware processor 124 or a component separate from the hardware processor 124) to generate a cryptographic key.

[0073] For an implementation where the hardware processor 124 uses the secure processor 144 to generate a cryptographic key for the new password 208, the hardware processor 124 may provide an API call or request 216 to the secure processor 144. In one example, assuming the secure processor 144 processes API calls according to the TPM 2.0 specification, the API call 216 may be a TPM2_GetRandom() API call with the key type TPM2B_Digest passed as an option. As depicted at 220, in response to the API call 216, the secure processor 144 generates a cryptographic key 224. According to the example implementation, for this purpose, the secure processor 144 returns a random number that the hardware processor 124 uses as the cryptographic key 224. According to another implementation, the secure 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 the random number returned from the secure processor 144. In another example, the hardware processor 124 may concatenate the random number returned from the secure processor 144 with a prefix and / or suffix to form the cryptographic key 224.

[0074] After generating the cryptographic key, according to the example implementation, as depicted at 228, the hardware processor 124 may invoke an operation to load the cryptographic key into the memory of the secure processor 144. More specifically, for this purpose, according to the example implementation, the hardware processor 124 provides an API call 232 to load or import the cryptographic key into the secure processor 144. In one example, assuming the secure processor 144 processes requests according to the TPM 2.0 specification, the API call 232 may be a TPM2_LoadExernal() API call with a random number (the cryptographic key) loaded as a child object of any parent object at the platform level of the secure processor 144. As depicted at 236, in response to the API call 232, the secure processor 144 loads the cryptographic key into its memory and returns a temporary key handle 240 for the cryptographic key. The temporary key handle 240 references the loaded cryptographic key.

[0075] After importing the cryptographic key into the secure processor 144, as depicted at 244, the hardware processor 124 can invoke the operation of the secure processor 144 to save the cryptographic key stored in the memory of the secure processor 144. For this purpose, according to an example implementation, the hardware processor 124 provides an API call 248 to the secure processor 144 to save the loaded cryptographic key. In one example, assuming the secure processor 144 processes requests according to the TPM 2.0 specification, the API call 248 can be a TPM2_EvictControl() API request that passes a transient key handle as a parameter and an authentication value as an option. The authentication value acts as the password for the cryptographic key. As depicted at 252, the secure processor 144 saves the cryptographic key and returns a persistent key handle 256 in the corresponding API response.

[0076] After saving the cryptographic key, as depicted at 260, the hardware processor 124 can invoke the operation of the secure processor 144 to hash the new password 208 based on the associated cryptographic key stored in the secure processor 144. For this purpose, the hardware processor 124 can provide a key hash API call 264 to the secure processor 144. In one example, assuming the secure processor 144 processes requests according to the TPM 2.0 specification, the API call 264 can be a TPM2_HMAC() API call that passes the new password 208 as a parameter and an authentication value, a persistent key handle, and a cryptographic hash algorithm identifier as options. As depicted at 268, in response to the API call 264, the secure processor 144 provides an API response that returns a digest or hash 272 corresponding to the new password 208.

[0077] At this point, the hardware processor 124 has the new key handle 256 and the new hash 272 of the new password 208. The hardware processor 124 can then create a new authentication record, as depicted at 276, or can update an existing authentication record (depending on whether the authentication record exists) with the new key handle 256 and the new reference hash 272, as depicted at 280.

[0078] In another example, if an existing password is being changed to the new password 208, according to some implementations, the existing key handle and the corresponding existing cryptographic key can be reused. For this change, sequence 200 omits actions 212 to 252 and begins with invoking the operation to hash the new password 208 at 260. As depicted at 268, the secure processor 144 can then generate a new reference hash 272. As depicted at 276, the hardware processor 144 can then update the authentication record with the new reference hash 272 without modifying or replacing the existing key handle of the authentication record.

[0079] Figure 3 is a sequence flow chart 300 depicting the actions and communications involved in authenticating a password according to an example implementation. Figure 3 Specifically depicts actions and communications associated with the hardware processor 124 and the security processor 144. In one example, to perform actions and communicate, the hardware processor 124 may run machine-readable instructions associated with a password authentication engine (such as Figure 1 the password authentication engine 168).

[0080] Referring Figure 3 to, in accordance with sequence flow chart 300, the hardware processor 124 accesses the user name 304 and password 308 for verification. In one example, the user name 304 and password 308 may be associated with a password verification request. As depicted at 312, the hardware processor 124 may read data corresponding to the user name from the authentication records of the password authentication file 141. As Figure 3 depicted, this data may represent a reference hash 316 of the password associated with the user account and a key handle 320.

[0081] As depicted at 330, the hardware processor 124 may invoke a key hash operation of the security processor 144 to apply a key hash algorithm to the input corresponding to the password 308 and the cryptographic key referenced by the key handle 320. This operation produces a reference hash 342, and then, to verify the password 308, the reference hash 342 may be compared with the reference hash 316. To generate the hash 342, the hardware processor 124 may provide a key hash API call 334 to the security processor 144. In one example, assuming the security processor 144 processes requests according to the TPM 2.0 specification, the API call 334 may be a TPM2_HMAC() API call that passes the password 308 as a parameter and passes the corresponding authentication value, key handle 320, and cryptographic hash algorithm identifier as options. As depicted at 338, in response to the API call 334, the security processor 144 performs the key hash operation and returns the hash 342 in the corresponding API response.

[0082] As depicted at 336, the hardware processor 124 may then determine whether the hash 342 matches the reference hash 316. If the hash does not match, the hardware processor 124 may then provide one or more response actions, including providing a verification failure response (as depicted at 350) and recording the verification failure (as depicted at 354). If, as depicted at 346, the hardware processor 124 determines that the hash matches, then, as depicted at 360, the hardware processor 124 may provide a verification passed response.

[0083] ReferringFigure 4 The computer platform 400 includes a security processor 404 and a hardware processor 420. The security processor 404 includes a memory 408 and a key hash generator 412. The memory 408 stores cryptographic keys, and the security processor 404 associates the cryptographic keys with key handles. 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 installed on the motherboard of the computer 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, the key hash generator 412 may be configured to apply the Secure Hash Algorithm version 2 (SHA-2). In one example, the cryptographic keys may be stored in the security processor 404. In one example, the key handle may be a persistent key handle.

[0084] In response to a request to access the computer platform 400, the hardware processor 420 accesses a password and a user identifier associated with the request. In one example, the request may be generated by a program running on the computer platform 400. In one example, the program may be a utility. In one example, the program may be an application. In one example, the program may be launched in response to a command submitted to the operating system of the computer platform 400. In one example, the request may originate from another computer platform remotely located relative to the computer platform 400. In one example, the request may be associated with a server daemon running on the computer platform 400 and communicating with a remote client. The hardware processor 420 further accesses an authentication record corresponding to the user identifier. 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 identifier may be a user name.

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

[0086] The hardware processor 420 provides the key handle and the password to the security processor 404 and initiates the operation of the security processor, where the key hash generator 412 generates a second cryptographic hash based on the password and the cryptographic key. In one example, the hardware processor 420 can provide an API call to the security processor 404 as the key hash generator 412 of the security processor 404 generates the second cryptographic hash. In one example, the hardware processor 420 can pass the key handle as a parameter of the API call. As an example, the hardware processor 420 can pass the password as a parameter of the API call. In one example, the hardware processor 420 can pass the identity of the hash algorithm to be used by the key hash generator 412 as a parameter of the API call. In one example, the security processor 404 can return the second cryptographic hash in an API response to the API call.

[0087] The hardware processor 420 regulates whether to allow the request based on the comparison of the second cryptographic hash with the first cryptographic hash. In one example, the hardware processor 420 can reject the request in response to the first cryptographic hash being different from the second cryptographic hash. In one example, the hardware processor 420 can regulate access to the resources of the computer platform 400 in response to determining whether the second cryptographic hash matches the first cryptographic hash. In one example, in response to determining that the second cryptographic hash is the same as the first cryptographic hash, the hardware processor 420 can determine the access level to the resources of the computer platform 400 based on one or more other criteria. In one example, the criteria can include one or more permissions or privileges associated with the user identity.

[0088] Reference Figure 5, according to an example implementation, the non-transitory machine-readable storage medium 500 stores machine-readable instructions 504. When run by a network device, the instructions 504 cause the network device to store a cryptographic key in the secure processor of the network device in response to creating a password for a user identity, and to determine a handle used by the secure processor to reference the cryptographic key. In one example, the network device can be a network switch. In one example, the network device can be a managed network device. In one example, when run by the network device, the instructions 504 cause the network device to provide an API call to the secure processor to import the cryptographic key into the secure processor. In one example, the API call can cause the secure processor to load the cryptographic key as a temporary object and provide a temporary handle as the output returned in response to the API call to the temporary object. In one example, the instructions 504 can cause the network device to provide an API call to the secure processor to cause the secure processor to save the cryptographic key. In one example, the secure processor can save the cryptographic key by returning a persistent key handle corresponding to the handle used by the secure processor to reference the cryptographic key in response to the API call. In one example, the instructions 504 can cause the network device to perform one or more actions to generate a cryptographic key. In one example, the instructions 504 can cause the network device to provide an API call to the secure processor to cause the secure processor to generate a random number and return the random number as part of the API response to the API call. In one example, the network device can use the returned random number as the cryptographic key.

[0089] When run by the network device, the instructions 504 also cause the network device to access a reference cryptographic digest determined based on the cryptographic key and the password, and to create an authentication record corresponding to the user identity. In one example, the cryptographic digest can be determined based on the application of a key hashing algorithm with an input derived from the cryptographic key and the password. In one example, the key hashing algorithm can be an HMAC algorithm. In one example, the authentication record can be an entry in a shadow file.

[0090] When run by a network device, instruction 504 also causes the network device to store data representing a user identifier, a reference password digest, and a handle in an authentication record. When run by a network device, instruction 504 also causes the network device to access the authentication record in response to a request associated with the user identifier for accessing the network device, and process the request based on the reference password digest and the handle. In one example, processing the request can include verifying a password associated with the request based on the reference password digest and the handle. In one example, processing the request can include verifying the password and further evaluating one or more other criteria that regulate the degree of access. In one example, the criteria can include privileges associated with a user name. In one example, the criteria can include usage restrictions associated with a user account. In one example, processing the request can include denying the request in response to a failure to verify the password based on the reference password digest and the handle.

[0091] Reference Figure 6 , according to an example implementation, process 600 includes receiving (block 604) by an authorization engine of a computer platform credentials associated with a request for accessing the computer platform. The credentials include a password and a user identifier. Process 600 includes determining (block 608) by the authorization engine a key handle corresponding to the user identifier, and determining (block 612) by the authorization engine a reference password digest corresponding to the user identifier. In one example, determining the key handle includes identifying an authentication record corresponding to the user identifier and reading data from the authentication record corresponding to the key handle. In one example, determining the reference password digest includes identifying an authentication record corresponding to the user identifier and reading data from the authentication record corresponding to the reference password digest. In one example, the authentication record can be one of multiple entries of a shadow file. In one example, the authorization engine can be a Pluggable Authentication Module (PAM). In one example, the user identifier can be a user name.

[0092] Process 600 includes determining (block 616) a second password digest corresponding to a user identification. Determining the second password digest includes: providing, by an authorization engine, a key handle and a passphrase to a security processor of a computer platform; and initiating, by the authorization engine, an operation of the security processor to apply a key hash function to the passphrase based on a cryptographic key corresponding to the key handle to provide the second password 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 computing operations according to the Trusted Platform Module 2.0 specification. In one example, the security processor may include a key hash generator. In one example, the key hash generator may be configured to apply Secure Hash Algorithm version 2 (SHA-2). In one example, the cryptographic key may be stored in the security processor. In one example, the key handle may be a persistent key handle.

[0093] Process 600 includes regulating (block 620), by the authorization engine, access to the computer platform based on a comparison of the second password digest with a reference password digest. In one example, regulating access to the computer platform includes regulating access to resources of the computer platform. In one example, regulating access to the computer platform includes allowing or denying access to the computer platform. In one example, regulating access to the computer platform includes allowing access based on the result of a comparison of the second password digest with the reference password digest and further regulating the degree of access based on one or more other criteria (such as privileges or resource usage limits associated with the user identification).

[0094] According to an example implementation, in response to the creation of a passphrase, a hardware processor initiates an operation of the security processor to load an object into a secure storage device and passes the cryptographic key as the object to the operation. A particular advantage is that passphrase-related information can be generated, stored, and accessed in a secure manner without being compromised by security attacks (such as dictionary-based attacks and rainbow table-based attacks).

[0095] According to an exemplary implementation, the operation of the security processor to load an object into a secure storage device 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 passphrase-related information can be generated, stored, and accessed in a secure manner without being compromised by security attacks (such as dictionary-based attacks and rainbow table-based attacks).

[0096] According to an example implementation, the hardware processor further initiates an operation of the security processor to cause the security processor to designate a cryptographic key as a persistent object and return a persistent handle to which the security processor associates the cryptographic key. The hardware processor stores the persistent handle as a key handle in the authentication record. A particular advantage is that password-related information can be generated, stored, and accessed in a secure manner without being compromised by security attacks such as dictionary-based attacks and rainbow table-based attacks.

[0097] According to an example implementation, the security processor further includes a random number generator. In response to the creation of a password, the hardware processor further initiates an operation of the security processor, wherein the random number generator generates a number. In response to the creation of a password, the hardware processor further designates the number as a cryptographic key, initiates an operation of the security processor to load an object into the secure storage device, and passes the cryptographic key as the object to the operation to load the object into the secure storage device. A particular advantage is that password-related information can be generated, stored, and accessed in a secure manner without being compromised by security attacks such as dictionary-based attacks and rainbow table-based attacks.

[0098] According to an example implementation, in response to the password being changed to a second password, the hardware processor further provides the key handle and the second password to the security processor and initiates an operation of the security processor, wherein the key hash generator generates a third cryptographic hash based on the second password and the cryptographic key. In response to the password being changed to a second password, the hardware processor further modifies the authentication record in response to the password change, including replacing the first cryptographic hash with the third cryptographic hash. A particular advantage is that password-related information can be generated, stored, and accessed in a secure manner without being compromised by security attacks such as dictionary-based attacks and rainbow table-based attacks.

[0099] According to an example implementation, the security processor includes a Trusted Platform Module (TPM). A particular advantage is that password-related information can be generated, stored, and accessed in a secure manner without being compromised by security attacks such as dictionary-based attacks and rainbow table-based attacks.

[0100] The detailed description set forth herein refers to the accompanying drawings. Wherever possible, the same reference numbers are used in the drawings and the preceding description to refer to the same or like parts. However, it should be clearly understood that the drawings are for illustrative and descriptive purposes only. Although several examples are described herein, modifications, adaptations, and other implementations 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.

[0101] The terms used herein are for the purpose of describing particular examples only and are not intended to be limiting. As used herein, the singular forms "a", "an" and "the" are also intended to include the plural forms unless the context clearly dictates otherwise. The term "plurality" as used herein is defined as two or more than two. The term "another" as used herein is defined as at least a second or more. The term "connected" as used herein is defined as connected, whether directly without any intermediate element or indirectly with at least one intermediate element, unless otherwise indicated. Two elements may be mechanically, electrically coupled together, or communicatively linked together via a communication channel, path, network or system. The term "and / or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It will also be understood that although the terms first, second, third, etc. may be used herein to describe various elements, these elements should not be limited by these terms, as these terms are only used to distinguish one element from another, unless the context otherwise states or indicates. As used herein, the term "comprising" means including but not limited to. The term "based on" means at least partially based on.

[0102] Although the present disclosure has been described with respect to a limited number of implementations, those skilled in the art who benefit from the present disclosure will appreciate many modifications and variations therefrom. The appended claims are intended to cover all such modifications and variations.

Claims

1. A computer platform comprising: A security processor comprising: a memory to store a cryptographic key, wherein the security processor associates the cryptographic key with a key handle; and a key hash generator; and Hardware processors to: In response to a request to access the computer platform, accessing a password and a user identification associated with the request; accessing an authentication record corresponding to the user identifier; determining a key handle and a first cryptographic hash from the authentication record; providing the key handle and the password to the security processor and initiating operation of the security processor wherein the key hash generator generates a second cryptographic hash based on the password and the cryptographic key; and Whether the request is allowed is regulated based on a comparison of the second cryptographic hash to the first cryptographic hash.

2. The computer platform of claim 1, wherein the hardware processor is further configured to, in response to creation of the password: initiating an operation of the secure processor to load an object into the secure storage device; and The cryptographic key is passed as the 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 device 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.

4. The computer platform of claim 3, wherein the hardware processor is further configured to: initiating operations of the security processor to cause the security processor to designate the cryptographic key as a persistent object and return a persistent handle to the security processor associated with the cryptographic key; and The persistent handle is stored as the key handle in the authentication record.

5. The computer platform of claim 1, wherein: The security processor also includes a random number generator; The hardware processor is further configured to, in response to the creation of the password: initiating operation of the security processor, wherein the random number generator generates a number; designating said number as said cryptographic key; initiating an operation of the secure processor to load an object into the secure storage device; as well as The cryptographic key is passed as the object to the operation to load the object into the secure storage.

6. The computer platform of claim 1, wherein the hardware processor is further configured to, 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 operation of the security processor wherein the keyed hash generator generates a third cryptographic hash based on the second password and the cryptographic key; and Modifying the authentication record in response to the password change includes 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 storing machine-readable instructions that, when executed by a network device, cause the network device to: In response to creating a password for the user identification: storing a cryptographic key in a security processor of the network device; determining a handle used by the security processor to reference the cryptographic key; accessing a reference cryptographic digest determined based on the cryptographic key and the password; and creating an authentication record corresponding to the user identifier; storing data representing the user identification, the reference password digest, and the handle in the authentication record; as well as In response to a request associated with the user identification to access the network device: accessing the authentication record; as well as The request is processed based on the reference cryptographic digest and the handle.

9. The storage medium of claim 8, wherein the instructions, when executed by the network device, in response to the request, further cause the network device to: transmitting an application programming interface (API) call to the security processor to cause the security processor to provide a second cryptographic digest based on the handle and a password associated with the request; and The request is denied or allowed based on a comparison of the second cryptographic digest to 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 by the security module, wherein the security module determines the second cryptographic hash by applying a keyed cryptographic hashing 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: transmitting a first application programming interface (API) call to the security processor so that the processor loads the cryptographic key as a temporary object into a platform layer of the processor and receives a temporary handle to the cryptographic key; and A second API call is transmitted to the processor to cause the processor to store the cryptographic key as a persistent object and receive the persistent key handle.

14. The storage medium of claim 8, wherein the instructions, when executed by the network device, further cause the network device to: transmit to the processor, via the first API call, an authorization value for the processor to associate with the cryptographic key.

15. A method comprising: receiving, by an authorization engine of a computer platform, credentials associated with a request to access the computer platform, wherein the credentials include a password and a user identification; Determining, by the authorization engine, a key handle corresponding to the user identifier; Determining, by the authorization engine, a reference password digest corresponding to the user identifier; determining a second cryptographic digest corresponding to the user identification, wherein determining the second cryptographic digest comprises: providing, by the authorization engine, the key handle and the password to a security processor of the computer platform; and initiating, by the authorization engine, an operation of the security processor to apply a keyed hash function to the password based on a cryptographic key corresponding to the key handle to provide the second cryptographic digest, wherein the security processor stores the cryptographic key; and Access to the computer platform is regulated by the authorization engine based on a comparison of the second cryptographic digest to the reference cryptographic digest.

16. The method of claim 15, wherein determining the second cryptographic digest further comprises: An authorization value corresponding to the cryptographic key is provided by the authentication engine to the security processor.

17. The method of claim 15, wherein determining the key handle comprises: An authentication record corresponding to the user identification is identified, and data representing the key handle is read from the authentication record.

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 includes the authentication engine reading the shadow file as a root user.

19. The method of claim 15, wherein determining the key handle comprises: An authentication record corresponding to the user identification is identified, and data representing the reference cryptographic digest is read from the authentication record.

20. The method of claim 15, wherein: The security processor includes a trusted platform module TPM; The cryptographic key is associated with a platform level of the TPM; and Determining the second password digest includes: passing the key handle by the authentication engine to a hash application programming interface API as an option of the API, and passing the file path corresponding to the password by the authentication engine as a parameter of the API.

Images