Patent ID: 12223053

DETAILED DESCRIPTION

FIG.1is an illustration of a process for generating a distributed secret for a security credential, according to embodiments of the present disclosure.

As shown inFIG.1, a security credential102is provided to a system100. System100may be a threshold encryption system. System100may include a processor (not shown) and a machine-readable, non-transitory medium (not shown). The medium may include instructions that, when loaded and executed by the processor, may cause system100to perform the functionality as described herein. Moreover, the functionality described herein may be implemented in any suitable manner, such as by analog circuitry, digital circuitry, control logic, instructions for execution by a processor, digital logic circuits programmed through hardware description language, application specific integrated circuits (ASIC), field programmable gate arrays (FPGA), programmable logic devices (PLD), or any suitable combination thereof, whether in a unitary device or spread over several devices.

System100may be configured to convert a security credential102using threshold encryption function circuit104.

Security credential102may include any suitable information for authentication. Security credential102may include, for example, a cryptographic key. The key may be symmetric or asymmetric, and public or private. In other cases, security credential102may include, for example, a cryptographic hash, password, or passcode.

Function circuit104may be implemented in any suitable manner, such as by instructions in the medium for execution by the processor, a function, library call, subroutine, shared library, software as a service, analog circuitry, digital circuitry, control logic, digital logic circuits programmed through hardware description language, ASIC, FPGA, PLD, or any suitable combination thereof, or any other suitable mechanism, whether in a unitary device or spread over several devices.

Function circuit104may be used for use cases wherein N=TN. As discussed above, when N=TN, simple sharding may be used, wherein all shards are needed to reconstitute the original security credential. Function circuit104may be configured to convert security credential102into multiple shards 1 (108A) through N (108N). Although a shard is shown as the derivative of security credential102, any suitable derivative of security credential102may be used. Function circuit104may be performed in such a way that the number of shards created by function circuit104is equal to the number of shards required to reconstitute security credential102. Therefore, if N derivatives are created by the application of function circuit104security credential102, and TNderivatives are needed to reconstitute security credential102, then N=TN. Function circuit104may perform this in any suitable manner. Function circuit104may perform this by splitting an initial copy of security credential102into subsets of the original data by using filters to generate shards108A-108N. Once shards108A-108N are created, the original copy of security credential102may be completely destroyed by, for example, being overwritten.

Next, threshold encryption P≥TPfunction circuit110and threshold encryption Q≥TQfunction circuit114may be configured to create derivatives from each of shards108A,108N. More functions, not shown, may be used to create derivates from the intervening shards between shards108A,108N. Each such function may have its own quantity of derivates created (such as P or Q) and corresponding threshold values (such as TPor TQ). Function circuits110,114and other functions not shown for creating derivatives from shards108may be implemented in any suitable manner, such as by instructions in the medium for execution by the processor, a function, library call, subroutine, shared library, software as a service, analog circuitry, digital circuitry, control logic, digital logic circuits programmed through hardware description language, ASIC, FPGA, PLD, or any suitable combination thereof, or any other suitable mechanism, whether in a unitary device or spread over several devices. Function circuits110,114and other functions not shown for creating derivatives from shards108may create derivatives such that fewer derivatives, given by T, are needed to reconstitute the original input. For function circuits110,114, the original input is given by P and Q, respectively. Thus, function circuits110,114may be referred to as P≥TPand Q≥TQ, respectively. Function circuit110may be configured to generate a quantity (P) of secrets112A-112P from shard108A. Similarly, function circuit114may be configured to generate a quantity (Q) of secrets116A-116Q from shard108N. Other functions not shown for creating derivatives from shards108may similar quantities of secrets from respective shards108that are greater than the number of derivatives needed to reconstitute the respective shard108. Function circuits110,114may use, for example, Shamir's Secret Sharing Scheme to generate the secrets from the shards. The secrets may be implemented in any suitable information representation. The actual value for P or Q, or for the other functions not shown, can differ with each function. Furthermore, P, Q, and T can be different for different instances or applications of a given function.

Thus, P secrets112may be generated for shard108A, and Q secrets116may be generated for shard108N. Not shown are secrets generated for each of the intervening shards108(not shown). Secrets112,116, and those not shown may be considered to be local secrets or external secrets. A local secret may be stored locally to system100for retrieval upon reconstitution of security credential102. An external secret may be stored externally to system100for retrieval upon reconstitution of security credential102. Secrets112,116, and those not shown may be stored in any suitable manner.

In one example, secrets112,116, and those not shown may be distributed securely to a remote location using a secure communications channel. Each of secrets112,116, and those not shown that are exported may sent to a different remote location. For example, secret116A may be sent to a remote location 1124A. Furthermore, external secret116Q may be sent to remote location124Q. Local copies of secrets116A-116Q may destroyed once they have been successfully deposited in remote locations. Remote locations124may include any suitable sever, storage, or other system for storing data or information.

In another example, secrets112,116, and those not shown may be stored locally. These may be stored in an encrypted manner. For example, secrets112may be stored locally in system100. Each of secrets112A-112P may have an individual instance of a public key120A-120P associated with it. There may be a corresponding private key for each public key, as discussed further below. Using asymmetric encryption circuit118, public keys120may be used to create encrypted copies122of respective secrets112. Asymmetric encryption circuit118may be implemented in any suitable manner, such as by instructions in the medium for execution by the processor, a function, library call, subroutine, shared library, software as a service, analog circuitry, digital circuitry, control logic, digital logic circuits programmed through hardware description language, ASIC, FPGA, PLD, or any suitable combination thereof, or any other suitable mechanism, whether in a unitary device or spread over several devices. Respective ones of secrets112may be destroyed once respective ones of encrypted copies122have been created.

FIG.2is an illustration of a process for recovering or reconstituting a distributed secret for a security credential, according to embodiments of the present disclosure. The security credential may have been securely destroyed. Illustrated inFIG.2for recovering or reconstituting a distributed secret for a security credential is a threshold decryption system130. System130may be implemented within system100, or implemented in a manner that is communicatively coupled and will work with system100. Threshold decryption system130may be implemented in any suitable manner, such as by instructions in the medium for execution by the processor, a function, library call, subroutine, shared library, software as a service, analog circuitry, digital circuitry, control logic, digital logic circuits programmed through hardware description language, ASIC, FPGA, PLD, or any suitable combination thereof, or any other suitable mechanism, whether in a unitary device or spread over several devices.

First, any encrypted copies of secrets that were created as shown inFIG.1may be restored. As discussed above, it was shown that N shards were created. Then, secrets were created for each shard. The number of secrets created for each shard depended upon the threshold encryption used. A set of quantity P secrets was created by threshold encryption P≥TPfunction circuit110and a set of quantity Q secrets was created by threshold encryption function Q≥TQcircuit114. Since creation of secrets was done, for example, using threshold encryption (P≥TP, Q≥TQ), only a subset T (which may vary from function to function, such as TPor TQ) of the original quantity of secrets are needed to recreate the shard. For example, inFIG.1, shard 1108A was split by threshold encryption P≥TPfunction circuit110into a set of P external secrets112. Even though a total number of P secrets of secrets112were generated, only a total number of TPsecrets of secrets112are required to regenerate shard 1108A. Similarly, a total number of Q secrets of secrets116were generated from shard N108N, and only a total number of TPsecrets of secrets116are required to regenerate shard N108N. Since in threshold encryption circuit104, N=TN, all shards 1 through N are required to reconstitute security credential102.

Encrypted external secret stored locally122A was generated using asymmetric encryption circuit118A and public key120A on secret112A. To restore the locally encrypted secrets, for example, an external secret stored locally132A may be decrypted off-site. Secret132A may be sent to an external asymmetric decryption circuit134A from threshold decryption system130.

At external asymmetric decryption circuit134A, using private key136A, external secret138A may be decrypted and sent back to threshold decryption system130. Decryption circuit134A may use the same algorithm as was used in the asymmetric encryption (such as encryption circuit118A) used to create secret132A. Secret138A may be the reconstitution of one of secrets112, such as secret112A. Similarly, encrypted external secret stored locally132T may be sent to an external asymmetric decryption circuit134T from threshold decryption system130. Here, using private key136T, secret138T may be decrypted and sent back to threshold decryption system130. Secret138T may be the reconstitution of one of secrets112, such as secret112P. Moreover, additional intervening encrypted external secrets stored locally132(not shown) may be reconstituted using respective asymmetric decryption circuits134(not shown) using respective private keys136(not shown). There may be TPsecrets138to reconstitute the original shard using threshold decryption function P≥TPcircuit142. If threshold decryption function P≥TPcircuit142reconstitutes secrets generated by function threshold encryption function P≥T function circuit110, then threshold decryption function P≥TPcircuit142may use a threshold of TPsecrets138. Again, TPmay be less than P, the total number of secrets derived from the original shard. P

Because the set of TPsecrets138that are reconstituted from encrypted external secrets stored locally132may be smaller or equal than the number of P secrets112that were originally generated, secret138A might not necessarily correspond, specifically, to secret112A, and vice-versa; encrypted external secret stored locally122A might not necessarily correspond, specifically, to encrypted external secret stored locally132A, and vice-versa; asymmetric decryption circuit134A might not necessarily correspond, specifically, to asymmetric encryption circuit118A, and vice-versa; public key120A might not necessarily correspond, specifically, to private key136A, and vice-versa. However, each of secrets112will correspond to one or more of secrets138; each of asymmetric encryption circuit118will correspond to one or more of asymmetric decryption circuit134; each of encrypted external secrets stored locally122will correspond to one or more of encrypted external secrets stored locally132; each of private keys136will correspond to one or more of public keys120; each of secrets138will correspond to one or more of secrets112; each of asymmetric decryption circuit134will correspond to one or more of asymmetric encryption circuit118; each of encrypted external secrets stored locally132will correspond to one or more of encrypted external secrets stored locally122; and each of public keys120will correspond to one or more of private keys136. The “one or more” correspondence between the elements ofFIGS.1and2depends upon whether any keys or encryption/decryption routines are reused for multiple secrets.

Next, using secrets138A-138T (which are a subset of a total number of secrets138A-138P), a shard 1146A can be reconstituted using threshold decryption P≥TPfunction circuit142. Shard 1146A may correspond to shard 1108A inFIG.1. Once shard 1146ahas been created, secrets138A-138T used to reconstitute may be securely destroyed.

Other secrets that have been remotely stored may be retrieved from various external locations138where they are stored. Note only T locations might need to return secrets, wherein T corresponds to the threshold of the function used to generate the secrets stored in external locations. Therefore, remote locations138A-138T may supply secrets140A-140T to threshold decryption system130. These may be provided through a secure or encrypted communications channel. Using secrets140, the original shard N146N can be reconstituted using threshold decryption function Q≥TQcircuit144. Once shard N146N has been created, all secrets140used to reconstitute may be securely destroyed. There may be TQsecrets140to reconstitute the original shard using threshold decryption function Q≥TQcircuit144. If threshold decryption function Q≥TQcircuit144reconstitutes secrets generated by function threshold encryption function Q≥TQcircuit114, then threshold decryption function Q≥TQcircuit144may use a threshold of TQsecrets140.

Because only a subset of secrets (such as quantity TQ) is needed to reconstitute the shard, only a subset of remote locations138(quantity TQ) need to yield the remotely stored secrets. Accordingly, remote locations124may correspond to various ones of remote locations138, though not necessarily in a1:1manner. Each of remote locations124may correspond to one or more of remote locations138, and vice-versa. Each of secrets140may correspond to one or more of secrets116, and vice-versa.

Although generation of shard 1146A through use of locally stored secrets132and shard N146N through use of remotely stored secrets140are shown, generation of shards146may be performed through any suitable combination of locally or remote stored secrets. These are provided as a mere example. Generation of other shards146are not shown inFIG.2but may be performed in any suitable manner. N shards146may be reconstituted, corresponding to shards108.

Shards146may be used by threshold decryption N=TNfunction circuit148to reconstitute a security credential149. Security credential149, if correctly reconstituted, may be the same as security credential102. All of the N shards108that were created inFIG.1by threshold encryption function circuit104may be presented to threshold decryption N=TNfunction circuit148to successfully reconstitute security credential149. Once security credential149has been created, shards146may be securely destroyed.

It can be seen from the examples above that there are different methods to distribute the secrets. Although locally encrypted versions and remote storage were used, any other suitable methods may be employed. In one embodiment, the type of distribution may be common to a given shard. For example, secrets112derived from shard 1108A may be encrypted and stored locally, while secrets116derived from shard N108N may be stored remotely. As such a given shard and its associated secrets can be grouped in a “zone.” The shard for each zone can be named the zone shard for that particular zone.

Circuits134,142,144,148may be implemented in any suitable manner, such as by instructions in the medium for execution by the processor, a function, library call, subroutine, shared library, software as a service, analog circuitry, digital circuitry, control logic, digital logic circuits programmed through hardware description language, ASIC, FPGA, PLD, or any suitable combination thereof, or any other suitable mechanism, whether in a unitary device or spread over several devices.

FIG.3is an illustration of systems for generating and recovering a distributed secret for a security credential, according to embodiments of the present disclosure.FIG.3illustrates two distribution mechanisms. One such distribution may be performed with public key infrastructure (PKI), and another such distribution may be to distribute the secrets to multiple servers. The multiple servers may be in remote storage locations. Shown inFIG.3are two zones, one for each of the example distribution mechanisms. Although there are only two zones shown for the sake of clarity, there is no limit to the number, type, and combination of zones that can be implemented.

Illustrated inFIG.3are two example servers150. Each of servers150may be implemented in any suitable manner, such as by a blade server, computer, stand-alone machine, virtual machine, or any other suitable electronic device. Servers150may each implement, fully or in part, system100fromFIG.1and system120fromFIG.2. Two servers, server 1150A and server 2150B are shown, though any suitable number and kind of servers may be used.

A set of zone shards may be generated for a given security credential. As a result, multiple shards and multiple secrets derived from each shard may be tied to the original security credential.

Each server150may include any suitable number and kind of security credentials170. Security credentials170may be used to create shards by zone shard generation function circuit176. Zone shard generation function circuit176may be implemented in any suitable manner, such as by instructions in the medium for execution by the processor, a function, library call, subroutine, shared library, software as a service, analog circuitry, digital circuitry, control logic, digital logic circuits programmed through hardware description language, ASIC, FPGA, PLD, or any suitable combination thereof, or any other suitable mechanism, whether in a unitary device or spread over several devices. Zone shard generation function circuit176may implement, fully or in part, system100fromFIG.1and system120fromFIG.2. Zone shard generation function circuit176may be configured to generate shards into zones, according to how secrets will be derived from the shard and stored.

For a given security credential from security credentials170, zone shard generation function circuit176may be configured to generate a zone 1 shard172and a zone 2 shard178. These may be created using threshold encryption N=TNfunction circuit104. Next, secrets from the respective shards may be created and distributed. Once all zone shards have been generated, security credential170may be completely and securely destroyed.

Zone 1 shard172may be processed by an external secret generation function circuit166to create multiple secrets158,162. Although only 2 secrets158,162are shown for clarity, any suitable number of secrets may be generated using a threshold encryption X≥T function, such as function circuits110,114. Zone 1 shard172may be securely destroyed once secrets158,162have been created. Public and private keys may be created through any suitable process. Public keys152B,154B may be stored on servers150. Public key152B may be used by a PKI function circuit156to create an encrypted secret164from secret158. In server 1150A, this may refer to generating encrypted secret 1-1164A from secret 1-1158A. This may be performed by PKI function circuit156A using public key152B. In server 2150B, this may refer to generating encrypted secret 2-1164B from secret 2-1158B. This may be performed by PKI function circuit156B using public key152B. Notably, the same public key—public key152B—may be used by both server 1150A and server 2150B to encrypt secrets158therein to create encrypted secrets164. Once encrypted secret164has been created, secret158may be securely destroyed. Encrypted secret164may be stored locally.

Similarly, public key154B may be used by a PKI function circuit160to create an encrypted secret 2168from secret 2162. Once encrypted secret 2168has been created, secret 2162may be destroyed. In server 1150A, this may refer to generating encrypted secret 1-2168A from secret 1-2162A, performed by PKI function circuit160A using public key154B. In server 2150B, this may refer to generating encrypted secret 2-2168B from secret 2-2162B, performed by PKI function circuit160B using public key154B. Again, the same public key public key154B—may be used by both server 1150A and server 2150B to encrypt secrets162therein to create encrypted secrets168.

PKI function circuits156,160may be implemented in any suitable manner, such as by instructions in the medium for execution by the processor, a function, library call, subroutine, shared library, software as a service, analog circuitry, digital circuitry, control logic, digital logic circuits programmed through hardware description language, ASIC, FPGA, PLD, or any suitable combination thereof, or any other suitable mechanism, whether in a unitary device or spread over several devices.

Zone 2 shard178may be processed by an external secret generation function circuit182. External secret generation function circuit182may be implemented in any suitable manner, such as by instructions in the medium for execution by the processor, a function, library call, subroutine, shared library, software as a service, analog circuitry, digital circuitry, control logic, digital logic circuits programmed through hardware description language, ASIC, FPGA, PLD, or any suitable combination thereof, or any other suitable mechanism, whether in a unitary device or spread over several devices. External secret generation function circuit182may be an implementation of function circuit114. External secret generation function circuit182may be configured to generate multiple secrets, such as secret 3184and secret 4180. Although generation of only two such secrets is shown for clarity, multiple secrets can be generated using a threshold encryption X≥TXfunction such as function circuits110,114. Zone 2 shard178may be securely deleted once secret 3184and secret 4180have been created.

Secret 3184and secret 4180may be securely transmitted to remote storage locations. In one embodiment, secret 3184and secret 4180may be transmitted and stored on different remote storage locations. For example, secret 1-4180A may be securely transmitted and stored on remote storage location 1190, at location186A. Secret 1-3184A may be securely transmitted and stored on remote storage location 2192, at location188A. Once securely stored, secret 3184and secret 4180may be securely destroyed.

Servers150may reconstitute security credentials through use of keys to first reconstitute the zone shards. At least two external keys may be required to reconstitute zone shards172,178inFIG.3. However, any number of keys might be required to reconstitute a given shard, depending upon the encryption scheme.

Servers150may reconstitute zone 1 shard172. Encrypted secret164may be securely transmitted to an external PKI function circuit151. Private key152A may be used by external PKI function circuit151to create secret158from encrypted secret164. External PKI function circuit151may securely transmit secret158back to server150. External PKI function circuit151might require a decryption algorithm corresponding to the encryption function used on server150. For example, external PKI function circuit151may perform decryption corresponding to the encryption that was performed by PKI function circuit156. Similarly, encrypted secret168may be securely transmitted to external PKI function circuit153. Private key154A may be used by external PKI function circuit153to create secret162from encrypted secret168and securely transmit it back to server150. External PKI function circuit153might require a decryption algorithm corresponding to the encryption function used on server150. For example, external PKI function circuit153may perform decryption corresponding to the encryption that was performed by PKI function circuit160. Function circuits151,153may be implemented in any suitable manner, such as by instructions in the medium for execution by the processor, a function, library call, subroutine, shared library, software as a service, analog circuitry, digital circuitry, control logic, digital logic circuits programmed through hardware description language, ASIC, FPGA, PLD, or any suitable combination thereof, or any other suitable mechanism, whether in a unitary device or spread over several devices.

Subsequently, external secret generation function circuit166may use secret158and secret162to recreate zone 1 shard172. Secret158and secret162may be securely destroyed once zone 1 shard172has been recreated.

Servers150may reconstitute zone shard 2178. Server150may retrieve secret 4186from remote storage location 1190, and may store it locally. Secret 3188may be retrieved from remote storage location 2192and stored locally. Local secret 4180and local secret 3184may be used together by external secret generation function circuit182to generate zone 2 shard178. Local secret 4180and local secret 3184may be securely destroyed once zone 2 shard178has been created.

Servers150may then reconstitute the original security credential170. Zone 1 shard172and zone 2 shard178may be used together by zone shard generation function circuit176to reconstitute a corresponding security credential170. Once security credential170has been created, zone 1 shard172and zone 2 shard178may be securely destroyed.

InFIG.3, it can be seen that there are two zone class types. In one zone the secrets are stored externally to server150. In the second zone, the external secrets are stored locally in an encrypted state in sever150. In the second zone, the same public keys152B,154B may be each used on each server150A,150B to encrypt secrets. Consequently, private keys152A,154A can be used to decrypt secrets for either server150A,150B. Therefore, in this example, the private key is independent of the server and tied to the owner of that key. However, both private keys152A,154A may be required to regenerate zone 1 shard172and, consequently, a security credential170. A zone with this property may be referenced as a device-independent zone or server-independent zone.

However, secrets 1-4186A and 2-4186B on remote storage location 1190and secrets 1-3188A and 2-3188B on remote storage location 2192must be provided to their respective server,150A,150B. Secret 2-4186B from remote storage location 1190cannot be used on server150A. Moreover, secret 2-3188B from remote storage location 2192cannot be used on Server150A. Thus, a zone with this property may be referenced as a device-dependent zone or server-dependent zone.

Thus, in one embodiment, successful reconstitution of security credentials requires one or more server-independent keys and one or more server-dependent secrets to be provided to reconstitute the security credential. The server-independent keys can be realized as physical devices, such as a hardware dongle, smart card, or mobile device app. Thus, a remote credential (a server-independent physical device, for example) and a local credential (a server-dependent credential stored on the remotely located server, for example) may be required to reconstitute the security credentials. This may significantly improve the security of the system when compared to simply storing security credentials170themselves. Although server-dependent and server-independent external keys are shown in different zones, it is possible to mix both in the same zone. Doing so may alter the security level of the solution.

Server-independent secrets may allow the owner of the private key to decrypt a locally stored encrypted secret on a server that used the corresponding public key to encrypt it. For example, inFIG.3, owners of private keys152A,154A can successfully recreate zone 1 shard on either server150A,150B. However, such owners could not regenerate security credential170A or security credential170B unless the corresponding zone 2 shard is also recreated. Zone 2 shard recreation may require server-dependent authorization. An example of how this may be used is as follows. A server150may be hosted in a location not operated by the owner of server150. Private/public key pairs may be realized as a smart card for the private keys. One smart card may be presented to the server owner and a different smart card presented to the location manager. The public keys are used on each server to create locally stored encrypted secrets. These servers150may require the local application of the smart card of the owner and that of the location manager to decrypt them. Further, server-dependent secrets are created by the server owner system administrator and also by the location system administrator. These secrets are stored externally. To reconstitute security credential170, the system administrators must restore the zone 2 shard on a specific server150. The smart card users can then restore the zone 1 shard on that same server150. Neither the owners of the smart cards, who must be physically present to use them, or the system administrators working remotely, can reconstitute a security credential on their own. Additionally, the smart card owners need only carry one smart card to participate in the process since that card can decrypt secrets on any server that used corresponding public key to encrypt the secrets. The system prevents remote reconstitution of security credentials without the participation of a local smart card holder. That is, no unattended access is allowed. Similarly, local smart card users cannot reconstitute a security credential without the participation of the system administrators. That is, no unsupervised access might be allowed.

FIG.4represents a specific embodiment of the implementation of a smart card solution using Near Field Communications (NFC).

A server240can be implemented using two independent processing systems. Server240may be an implementation of server150. A baseboard motherboard controller (BMC)200may provide standard BMC functions, such as a server management interface. BMC200may be a standalone system and may include a processor210, embedded operating system202, random access memory (RAM)204, and wireless interface222. Wireless interface222may be implemented by analog circuitry, digital circuitry, control logic, instructions for execution by a processor, digital logic circuits programmed through hardware description language, ASIC, FPGA, PLD, or any suitable combination thereof, or any other suitable mechanism, whether in a unitary device or spread over several devices. Wireless interface222may be configured to provide a near field network, using NFC, to communicate with an NFC-enabled smart card226. Motherboard230may provide the main processing for server240using a System-on-A-Chip (SoC)234, I/O expanders238, and UEFI and firmware236. BMC200may communicate to UEFI and firmware236via a serial control interface218and I/O expanders238.

BMC processor210may have its own AES/RSA encryption function circuit216to provide cryptographic functions independently of motherboard230. Using AES/RSA encryption function circuit216, together with internal read-only memory (ROM)214and internal RAM212, processor210may provide asymmetric encryption, or PKI, functions. Consequently, processor210can, for example, implement PKI function circuits156,160for each server150. Processor210may store public keys152B,154B locally. Processor210may create and store encrypted secrets164,168. BMC200, using processor210and wireless interface222can then securely transmit a copy of encrypted secrets164,168to the NFC-enabled smart card226using near field network224. NFC-enabled smart card226may contain a private key152and decrypt encrypted secret164,168transmit it back to BMC200via near field network224. Secret158,162can then be used to compute zone 1 shard172. Processor210can also provide external secret generation166function circuit to create secrets158,162from the zone 1 shard172. Conversely, processor210can also provide external secret generation function circuit166to reconstitute zone 1 shard172from secrets158,162reconstituted using NFC-enabled Smart Card226.

Using the above embodiment may provide two distinct advantages. First, the owner of the public key might be required to be physically close—within a few inches—of wireless interface222, providing a physical layer of security. Second, generation of secrets158,162and creation and storage of encrypted secrets164,168may be isolated from motherboard SoC234. Motherboard SoC234can be used to process the server-dependent secrets and BMC200can process the server-independent secrets. This isolation may further prevent a remote administrator from accessing server-independent secrets, or a local smart card owner from access server-dependent secrets, thus preventing unattended and unsupervised access.

An instance of240may also include or be communicatively coupled to an intelligent storage media tray242, according to embodiments of the present disclosure. Tray242may be implemented in any suitable manner. Tray242may include caddies, bins, receptacles, or any other suitable mechanism (not shown) for holding storage devices (not shown) and providing communication interfaces for such storage devices. Moreover, tray242may be configured to provide any suitable data processing function for data to or from storage devices (not shown) therein, such as video transcoding, encryption, or decryption. As discussed further below, tray242may include its own processor or digital logic. As discussed further below, any suitable number and kind of storage devices may be hosted by tray242, whether a same or different kinds of storage devices on a given tray, and storage devices may be implemented by, for example, electromechanical storage such as hard disks, solid state storage such as flash memory, other types of storage media, or combinations of these. Tray242may reside within any suitable instance of a server240, which may include any suitable number or kind of trays242.

Each tray242may include a memory244communicatively coupled to a processor, such as a media tray processor248. Tray242may include a media tray manager246which may be implemented in any suitable manner, such as by analog circuitry, digital circuitry, control logic, instructions for execution by a processor such as media tray processor248, digital logic circuits programmed through hardware description language, ASICs, FPGA, PLDs, or any suitable combination thereof, whether in a unitary device or spread over several devices. Media tray manager246may be configured to provide the tray-side functionality described in more detail below.

Tray242may be implemented within an example server240. Moreover, tray242may be implemented within or communicatively coupled to a server internal unit such as processor210of BMC200or to a processor of motherboard230, such as SoC234. The server internal unit may include a motherboard or other mechanisms for attaching and communicating with various components such as multiple instances of tray242, or to other devices through any suitable protocol, such as wireless interface222or USB and Ethernet interface232. Tray242may be communicatively coupled to these other elements through bus250.

As discussed above, the functions, operations, circuits, and other elements of the servers100,130,150ofFIGS.1-3may be implemented in any suitable manner, such as by instructions in the medium for execution by the processor, a function, library call, subroutine, shared library, software as a service, analog circuitry, digital circuitry, control logic, digital logic circuits programmed through hardware description language, ASIC, FPGA, PLD, or any suitable combination thereof, or any other suitable mechanism, whether in a unitary device or spread over several devices. In particular, these may be implemented by any suitable components of a processor, a function, library call, subroutine, shared library, software as a service, analog circuitry, digital circuitry, control logic, digital logic circuits programmed through hardware description language, ASIC, FPGA, or PLD of BMC240, motherboard230, or tray242, or any combination thereof. For example, these may be implemented by processor210of BMC, a processor of motherboard230such as SoC234, or by media tray processor248, or execution of instructions therein.FIG.5illustrates an exemplary distributed storage architecture500or network in which various instances of an intelligent storage media tray504can be implemented, according to embodiments of the present disclosure.

Tray504may be implemented in any suitable manner. Tray504may be an implementation of, or may be implemented by, tray242. Tray504may include caddies, bins, receptacles, or any other suitable mechanism (not shown) for holding storage devices (not shown) and providing communication interfaces for such storage devices. Moreover, tray104may be configured to provide any suitable data processing function for data to or from storage devices therein, such as video transcoding, encryption, or decryption. As discussed further below, tray504may include its own processor or digital logic. As discussed further below, any suitable number and kind of storage devices may be hosted by tray504, whether a same or different kinds of storage devices on a given tray, and storage devices may be implemented by, for example, electromechanical storage such as hard disks, solid state storage such as flash memory, other types of storage media, or combinations of these.

Tray504may reside in any suitable portion of distributed storage architecture500. Distributed storage architecture500may include any suitable number and kind of storage servers502. Servers502may be communicatively coupled via a network508. Each of servers502may include a plurality of trays504therein. It is to be understood that one or more trays504can reside on more, fewer or different storage servers502or other computing devices as desired. For example, trays504may also reside on intelligent storage arrays506or in a stand-alone configuration, connected by a storage area network (SAN) fabric510. Although a SAN fabric is shown as an example, any suitable connectivity protocol, such as iSCSI, may be used. It is to be understood that the number of intelligent storage media trays504residing on any given portion of architecture500is a variable design parameter, and different numbers of intelligent storage media trays504can be housed by different computing devices in different embodiments as desired. Any suitable number of clients512may access trays504through network508or SAN fabric510. Trays504may be housed in the form of rack mounted computing devices, in a datacenter comprising many large storage racks each housing a dozen or more storage servers502, trays504each housing multiple storage devices. It is also to be understood that distributed storage architecture500can be physically instantiated across multiple data centers in multiple locations, including different cities or continents.

Servers502, intelligent storage arrays504, and clients512may be implemented in any suitable manner, including by a server, computer, blade, or any other suitable electronic device. Servers502, clients512, and intelligent storage array506may be implementations of any of servers or systems100,130,150,240, discussed above. Moreover, in some embodiments, trays504may be implementations of any of servers or systems100,130,150,240. Servers502, arrays504, and clients512may be implementations of or implemented by server240.

FIG.6illustrates further details of possible implementations of systems in which tray504may be implemented, such as an instance of server502, according to embodiments of the present disclosure. As shown, each tray504may include a memory620communicatively coupled to a processor, such as media tray processor624. Tray504may include a media tray manager622which may be implemented in any suitable manner, such as by analog circuitry, digital circuitry, control logic, instructions for execution by a processor such as media tray processor624, digital logic circuits programmed through hardware description language, ASICs, FPGA, PLDs, or any suitable combination thereof, whether in a unitary device or spread over several devices. Media tray manager622may be configured to provide the tray-side functionality described in more detail below.

As shown inFIG.6, tray504may be implemented within an example server502. Moreover, tray504may be implemented within or communicatively coupled to a server internal unit604. Server internal unit604may include a motherboard or other mechanisms for attaching and communicating with various components such as multiple instances of tray505. These may be communicatively coupled with a bus616of any suitable communication protocol. Sever internal unit604may be communicatively coupled to an external display panel602, which may include any suitable number and kind of indicators602. Additionally, server internal unit604may include a server internal unit processor608, memory610, and other components. In one embodiment, a server-side media manager (SMM)612can reside in memory610and be executed by processor608to facilitate the server-side functionality described herein.

Server internal unit processor608may be implemented by, or may be an implementation of, processor210of BMC200or a processor of motherboard230such as SoC234. Memory610may be implemented by, or may be an implementation of, memories202,204,212,214of BMC200or memory (not shown) of motherboard230. SSMM612may be implemented by, such as by instructions in the medium for execution by the processor, a function, library call, subroutine, shared library, software as a service, analog circuitry, digital circuitry, control logic, digital logic circuits programmed through hardware description language, ASIC, FPGA, PLD, or any suitable combination thereof, or any other suitable mechanism, whether in a unitary device or spread over several devices. These may include instructions or circuitry on one or more of BMC200or motherboard230.

In one embodiment, at least one of indicators606may be a fault indicator. This fault indicator may be activated by SSMM612to visually indicate that a storage device (not shown) housed by a given tray504within server502verified for removal. A given storage device may be verified for removal when SSMM612receives a control signal that a specific storage device housed in a specific tray housed by a given server or other suitable computing device has failed, is expected to fail, is to be removed, upgraded, is in any other way to no longer be used, or is in any way inoperable. The control signal may reflect a determination by any suitable entity that such a storage device is verified to be removed. The control signal may be initiated, for example, by a user of the system, a technician activating an actuating member on a tray, a disk monitoring circuit or software, diagnostic software, or by a storage device itself. Moreover, the control signal may be generated by motherboard230or BMC200and provided to SSMM612, or generated on tray242and provided to SSMM612over bus250.

Further, another of indicators606may be activated to visually indicate the operational status of each or a group of storage devices within server502. It is to be understood that external display panel602, in some embodiments, is situated on a casing on the exterior of server502. When situated on the casing of server502, external display panel602can provide visual cues to a user (e.g., a datacenter administrator, or technician or the like), to readily identify a specific server502containing one or more storage devices verified for removal that may require attention. As described in more detail below, indicators606can be implemented in the form of light emitting diodes (“LEDs”), light pipes or other light generating hardware. Media tray manager622may transmit a control signal to SSMM612when a storage device (not shown) connected thereto to tray504is verified for removal. SSMM612may then activate indicators606as appropriate.

Server502may include a server communications unit614to send or receive information according to any suitable protocol. Server communications unit614may be implemented by or may be an implementation of, for example, wireless interface222or USB and Ethernet interface232.

Each tray504may, in some embodiments, contain a location sensor626. Locations sensors626may be implemented in any suitable manner, such as by a GPS receiver system, wireless phone receiver, or inertial position sensor. In the case of GPS and cell phone receivers, location sensors626may be configured to determine a specific location. This may arise from the triangulation of external radio signals, satellite stations, and terrestrial stations. In the case of inertial position sensors, location sensors626may be configured to detect the inertial change arising from movement of the server in which trays504are located. Such location sensors626might not provide an absolute position, but do not require an external signal to operate. Location sensors626can be configured to periodically determine the physical position of trays504. Location sensors626can use a rechargeable modular power unit, discussed below, to ensure physical location can be detected even if the system power is removed. This may allow the detection of a change in physical position if any tray504is removed from a server, or if the server itself is disconnected from a power source and physically moved.

FIG.7illustrates further details of possible implementations of systems in which tray504may be implemented, such as an instance of a server700and the use of indicators specific to tray504and indicators general to server700, according to embodiments of the present disclosure. Server700may be an implementation of any of servers or systems100,130,150,240,502,506,512described above. Shown inFIG.7is an instance of external display panel602and indicators606therein. Moreover, server700may include any suitable number of trays504.

At least one indicator of indicators606may be the fault indicator of the system or server described above, which is activated when612receives a signal from a tray504indicating that at least one storage device housed in the tray504is verified for removal. In some embodiments, at least one of indicators606may also be activated to visually indicate how many storage devices housed by the specific or any tray504is verified for removal.

Each tray504may also include one or more external visual indicators in an external visual panel706. These are described in more detail in the context ofFIG.8. Panel706may include indicators that are visible outside server700. In one embodiment, indicators of panel706may be visible when a casing of sever700is removed.

Moreover, server700may include a main circuit board702having modules such as processors, memories, or other components as described above. Cooling fans704may be used to dissipate heat across components such as trays504or main circuit board702.

FIG.8illustrates further details of implementations of tray504, according to embodiments of the present disclosure.

A given tray504may house any suitable number and kind of storage devices802. Tray504may include an actuating member806. In one embodiment, actuating member806may be a button that can be pressed. In other embodiments, actuating member806may be a latch, switch, or toggle. In still other embodiments, actuating member806may include an audio detection circuit configured to detect voice commands. A datacenter administrator or technician may actuate actuating member806to remove tray504from a server to replace an instance of storage device802that is failed, inoperable, to be upgraded, or otherwise requires attention from a technician. Such a storage device802may be verified for removal. The actuation of actuating member806by the user (e.g., the pressing of the button) can activate a first visual indicator810on tray504indicating that the actuation of the member has registered (e.g., the button press has been detected).

In response to pressing of the button, media tray manager622can transmit a signal to SSMM612which can programmatically classify all of storage devices802housed in the specific instance of tray504as being not included in architecture500. SSMM612may transmit a corresponding notification to the other elements of architecture500indicating the classification of storage device802, and upon receipt of an acknowledgment from the other elements of architecture500, a second visual indicator812on tray504may be activated, indicating that tray504may now be safely decoupled from the server in which it resides. In one embodiment, the first indicator810may be in the form of a red or yellow light and the second visual indicator812may be in the form of a green light indicating that it is safe to proceed with decoupling tray504that houses the instance of storage device802that is verified for removal. Indicators810,812may be implementations of external indicators of panel706.

Other embodiments may use a single indictor to implement indicators810,812by using an LED that changes colors. For instance, when actuating member806is actuated, the first visual indicator810may show a red or yellow light, which subsequently changes to a green light indicating that it is now safe for the technician to decouple tray504. It is to be understood that these are just examples, and in other embodiments, visual indicators810,812can be implemented in other ways as desired.

Referring back toFIG.7, indicators606of panel602may identify a specific instance of tray504that house one or more storage devices802that are verified for removal. For example, a datacenter administrator/technician may see an activated instance of indicator326and readily ascertain which tray504to decouple from its housing server since each indicator326, when activated, serves as a visual identifier indicating that the corresponding tray504contains at least one storage device802that is verified for removal. For instance, indicator606A may correspond to tray504A, indicator606B may correspond to tray504B, etc.

Returning toFIG.8, tray504may include any suitable number and kind of indicators808to identify a specific corresponding one of storage devices802. Storage devices802can be coupled to or housed in tray504by bays, hardware interfaces, or other mechanisms of the same or different types as desired. Some examples of types of storage devices802that may be housed in tray504are magnetic storage devices such as hard disks, and solid-state media such as flash disks, although other types of storage media not explicitly mentioned herein are also contemplated.

Indicators808may be situated in specific physical proximity to corresponding storage devices802housed in tray504. Each of indicators808may be configured to be activated when a corresponding one of storage devices802becomes verified for removal. Thus, a specific storage device802verified for removal can be identified by noting the activated indicator808to which the specific storage device802corresponds. In some embodiments, indicators808be embedded in a casing of or otherwise coupled to tray504. For example, indicators808may be proximate to the mounting screw or similar hardware of tray504, proximate to or configured as part of the bay or coupling mechanism of tray504, such that each storage device802housed in tray504has a corresponding visual indicator uniquely identifying it based on physical proximity. The exact implementation of the positioning of indicators808in physical proximity to their corresponding storage devices802may be a variable design parameter. In general, indicators808may be positioned in tray504so that it is clear to the technician which storage device802corresponds to which indicator808. Indicators808may be referred to as internal indicators, in that indicators808in various embodiments might be visible only when tray504is removed from server502, and may be covered or not visible when tray504is inserted into server502.

Tray504may include a rechargeable modular power unit804coupled to or included in tray504. In one embodiment, rechargeable modular power unit804is a modular uninterruptible power supply (UPS) that is coupled to tray504. In this case, rechargeable modular power unit804may be charged when tray504is coupled to its server. Because of this charging, rechargeable modular power unit804may provide an independent power source so that indicators808,810,812may persist in displaying storage device802operational status after decoupling the specific tray504from its server. In one embodiment, rechargeable modular power unit804may power other circuitry, such as memory or processors of tray504.

Furthermore, in some embodiments SSMM612or media tray manager622may provide power supply management. For example, SSMM612or media tray manager622may sequentially power up or power down individual storage devices802housed within tray504. This ensures that in-rush or power up current can be controlled so as not to overwhelm the power supply to the server to facilitate the reliability of the server. In other embodiments, the sequential powering allows an individual storage device802to be held in a completely “off” state where no power is applied to the individual storage device802in question. This allows the server to power up the individual storage device802as needed to either grow the size of the available storage of the server, or replace a storage device802verified for removal in the server to keep the storage capacity of the server static. In further embodiments, this sequential powering up and powering down of individual storage devices802may dynamically remove power individually from storage device802verified for removal to prevent the storage device802verified for removal from drawing power from the server unnecessarily. Moreover, media tray manager622may provide power supply management for the operation of indicators808,810,812, as well as any other suitable indicators. The intensity, duration, periodicity, color, or other operating parameters of indicators808,810,812may be adjusted depending upon whether or not tray504is disconnected from server502or connected to server502, and depending upon a battery voltage level of a power supply of tray504.

Indicators808,810,812may be implemented in any suitable manner, such as with LEDs, light pipes, or other forms of light generating hardware as desired.

It is to be understood that although SSMM612and media tray manager622are illustrated as single entities, these components represent collections of functionalities, which can be instantiated as a single or multiple modules as desired. It is to be understood that modules of SSMM612and media tray manager622can be instantiated (for example as object code or executable images) within the system memory (e.g., RAM, ROM, flash memory) of a computing device, such that when the processor of the computer system processes a module, the computing device executes the associated functionality. These modules may also be instantiated as control logic, hardware, firmware, or any combination of software, hardware and firmware. As used herein, the terms “computer system,” “computer,” “client,” “client computer,” “server,” “server computer” and “computing device” mean one or more computers configured and/or programmed to execute the described functionality. Additionally, program code to implement the functionalities of SSMM612and media tray manager622can be stored on computer-readable storage media. Any form of tangible computer readable storage medium can be used in this context, such as magnetic or optical storage media. As used herein, the term “computer readable storage medium” does not mean an electrical signal separate from an underlying physical medium.

FIG.9is an illustration of an example of symmetric data encryption for storage devices, according to embodiments of the present disclosure. SDS data may be exchanged between SSMM612and media tray manager622. Media tray manager322may contain an encryption module902for each storage device802included in or communicatively coupled to tray504. Each encryption module902may have its own unique disk key904. Each of these disk keys904may be individually generated by media tray manager622. This may allow the SDS data from SSMM612to be encrypted with disk keys904before it is written to the respective storage device802. The data that is sent from each storage device802may be first decrypted with its respective disk key904before being sent to SSMM612. In addition to the advantage of data protection, the encryption may also useful when the instance of storage device802is decommissioned. A challenge when decommissioning storage device802may be that the data must not be recoverable once an individual media of storage device802has been permanently removed from tray504. One option may be to securely overwrite the data on the media. This can take a considerable amount of time. A second option may be to securely delete all copies of the encryption key, such as disk keys904. However, as a precaution, backup copies may be made of disk keys904and kept in a separate location from the media. In one embodiment, a process may be employed to ensure that all keys are destroyed. A second challenge may be to ensure a given storage device802has had its associated disk key904destroyed before storage device802is physically removed from the server.

In one embodiment, instead of storing copies of disk keys904, disk keys904can be securely reconstituted as shown above inFIGS.1-4. Disk key904may be implemented by the security credentials ofFIG.3. In this manner, disk keys904may be used to create a set of secrets such that only the original copy of the disk key exists. That is, no externally secured copies may be stored. The secrets can then be used to securely reconstitute a disk key if it is erroneously destroyed. Further, copies of the secrets from the remote storage locations190192and copies of the encrypted secrets164,168can be moved to a new storage server in the case where the original server has become inoperable, thus allowing the disk keys to be reconstituted on the new storage server.

Media tray manager622may request a unique identifier token, such as a storage server serial number, from SSMM612. Media tray processor624may store the unique identifier token in non-volatile memory provided by memory320. This may allow the intelligent storage media tray to retain information regarding the storage server from which it is removed.

FIG.10is an illustration of an example method1000for generating an initial or reference boot authorization code, according to embodiments of the present disclosure. Method1000may be performed by any suitable mechanism, such as by the systems, components, servers, or functions ofFIGS.1-9. Specifically, method1000may be performed by a control circuit. The control circuit may be implemented by instructions in the medium for execution by the processor, a function, library call, subroutine, shared library, software as a service, analog circuitry, digital circuitry, control logic, digital logic circuits programmed through hardware description language, ASIC, FPGA, PLD, or any suitable combination thereof, or any other suitable mechanism, whether in a unitary device or spread over several devices. The control circuit may be implemented by, for example, server100, server130, server150, server240, motherboard230, SoC234, BMC200, processor210, server502, server internal unit processor608, SSMM612, media tray processor624, or media tray manager622. Method1000may begin at any suitable step. Steps of method1000may be performed in any suitable order, repeated, rearranged, performed recursively, omitted, or performed in parallel.

At1005, an initial or reference boot authorization code may be generated. Server502, through operation of the control circuit, may generate the initial or reference boot authorization code. The initial or reference boot authorization code can be obtained directly from components of server502or generated from any suitable existing information. For example, the control circuit may use sensitive data, such as boot code, configuration files, operating system components, a checksum, signature, cryptographic product, or other suitable indicator can be generated. Moreover, two or more such elements may be combined. For example, the initial or reference boot authorization code may be a checksum of a combination of boot code or other elements. Boot code may include processor instructions stored for booting server502or a portion thereof, when the system is initially powered on. Furthermore, the initial or reference boot authorization code may be derived from other data or identifiers such as MAC addresses of network cards, system Globally Unique Identifier (GUID), or hardware serial numbers. The initial or reference boot authorization code, once determined, may be used to later authenticate operation of server502in subsequent boots. This authentication process may authenticate the existence of the underlying components or data that were used to generate the initial or reference boot authorization code. Moreover, multiple instances of the initial or reference boot authorization code may be generated based on various portions of sensitive data. Further, these may be combined to still more intricate authentication codes.

The initial or reference boot authorization code may be stored or used in any suitable manner. In one embodiment, the reference boot authorization code may be stored locally in memory, which may be in an encrypted format. In another embodiment, at1010, control circuit may initiate a process of sharding and secret generation, using the processes discussed above inFIG.1, wherein the initial or reference boot authorization code is the security credential102to be secured. In other examples, the processes described above inFIGS.3-4may be used. The process may begin by generating shards such as shards108using a function such as threshold encryption function104. The original initial or reference boot authorization code may be destroyed.

At1015, the control circuit may create secrets from the shards, such as creating external secrets112,116from shards108using functions such as threshold encryption functions110,114. The shards may be destroyed.

At1020, the control circuit may encrypt some of the secrets and store them locally, using functions such as using asymmetric encryption functions118and keys such as public keys120to generate secrets such as encrypted external secrets stored locally122from secrets112. These may be stored on, for example, server502.

At1025, the control circuit may store some of the secrets externally, such as distributing external secrets116over a secure channel to remote locations124. Once the secrets have been securely copies to remote locations124, local copies of external secrets116may be destroyed.

At1030, the control circuit may securely destroy any local copies of the authorization code, shards, and locally unencrypted secrets that might not yet be erased by, for example, writing all “0” or all “1” or random values of “0” or “1” t their respective memory locations.

FIG.11is an illustration of an example method1100for secure booting of a server, according to embodiments of the present disclosure. Method1100may be performed by any suitable mechanism, such as by the systems, components, servers, or functions ofFIGS.1-9. Specifically, method1100may be performed by a control circuit. The control circuit may be implemented by instructions in the medium for execution by the processor, a function, library call, subroutine, shared library, software as a service, analog circuitry, digital circuitry, control logic, digital logic circuits programmed through hardware description language, ASIC, FPGA, PLD, or any suitable combination thereof, or any other suitable mechanism, whether in a unitary device or spread over several devices. The control circuit may be implemented by, for example, server100, server130, server150, server240, motherboard230, SoC234, BMC200, processor210, server502, server internal unit processor608, SSMM612, media tray processor624, or media tray manager622. Method1100may begin at any suitable step. Steps of method1100may be performed in any suitable order, repeated, rearranged, performed recursively, omitted, or performed in parallel.

Method1100may be used to detect an invalid boot authorization code of a server502. The invalid code may result in any suitable correction action, such as a cryptographic erasure of encrypted storage media. An unauthenticated boot sequence may also trigger disk key destruction.

At block1105, server502may start a boot sequence. This may be performed by the control circuit.

At block1110, the control circuit may generate a boot authorization code. The generation of the boot authorization code may follow the same process as was followed inFIG.10, block1005, based upon a same set of parameters as were used therein. However, the underlying values represented by such parameters may have changed if, for example, components of server502have changed since the initial or reference boot authorization code was generated or, in another example, if server502is a different instance of a server than was used to generate the initial or reference boot authorization code.

At block1115, the control circuit may initiate a process of reconstituting a reference or initial boot authorization code such as the code generated in block1005, discussed above. In one example, the processes ofFIG.2may be used, while in other examples, the processes ofFIG.3or4may be used. For example, to reconstitute a security credential149embodying the reference or initial boot authorization code, the control circuit may obtain secrets stored remotely, such as secrets140stored in remote locations138. Moreover, the control circuit may decrypt locally stored secrets132. These secrets may be used with threshold encryption functions142,144to reconstitute shards146. Shards146may be used with threshold encryption function148to reconstitute the initial or reference boot authorization code generated in block1005ofFIG.10. The initial or reference boot authorization code that has been regenerated may be used as a reference to compare against the presently constituted boot authorization code generated in block1110. Once the reference or initial boot authorization code has been reconstituted, all secrets and shards may be securely erased. At block1120, the presently generated boot authorization code from block1115may be compared against the initial or reference boot authorization code from block1110. If they match, method1100may proceed to block1130. Otherwise, method1100may proceed to block1125.

At block1125, any suitable corrective action may be taken

In one embodiment, storage devices802may be erased. The erasure may be performed by a cryptographic erasure. For example, disk keys904for all storage devices802on all trays504may be securely destroyed. This may be performed by, for example, writing all “0” or all “1” or random values of “0” or “1” to the disk key904memory locations, destroying all disk keys904stored therein.

In one embodiment, a record of the destruction of disk keys904may be stored. This may include a list of the specific disk keys904that were destroyed. A list of storage devices802associated with the destroyed disk keys904may be added to the record such that the storage devices802can be uniquely identified. This may be done, for example, using a device serial number. The record may also include a unique identifier token as described earlier that may identify the instance of server502associated with the instance of tray504that includes the deleted storage devices802. Visual indicators may be updated to reflect a completed cryptographic erasure of storage devices802that were associated with the destroyed disk keys904.

In one embodiment, the control circuit through, for example, SSMM612may activate a visual fault indicator606on an external display panel602such as the external display panel602of server502. Indicator606may indicate that server502contains a cryptographically erased storage device802. This may enable a technician in a datacenter to easily identify those storage servers502that contain cryptographically erased storage devices802by, for example, traversing aisles of a datacenter and identifying activated visual fault indicators606. This is significant, given there could be thousands of servers502in the datacenter.

In one embodiment, the control circuit through, for example, media tray manager622may activate an external visual indicator706on the specific tray504containing the cryptographically erased storage devices802. Recall that indicator706may indicate that the specific tray504contains a cryptographically erased storage device802. This may enable a technician to easily identify specific trays504that contain cryptographically erased storage devices802.

In one embodiment, the control circuit through, for example, media tray manager622may activate an internal visual indicator808on the specific tray504within a specific physical proximity to the cryptographically erased storage device802.

In one embodiment, prior to removal from server502, the control circuit through, for example, media tray processor624may establish an access lock on tray504. This lock may prevent and data access to and from tray504by any other components of server502—such as SSMM612or server internal unit processor608—via bus616.

Method1100may proceed to block1130.

At block1130, the boot authentication codes, locally generated code from block1110and regenerated code from block1115, may be securely deleted. This may be performed by, for example, writing all “0” or all “1” or random values of “0” or “1” to the boot authorization code memory locations, destroying the boot authorization codes stored therein. Method1100may proceed to block1135.

In block1135, server502may continue its boot sequence. As some future point (not shown), server502may identify that disk encryption keys904have been destroyed if, for example, local and reconstituted keys do not match. Furthermore, server502may identify that all trays504have been locked (if, for example, block1130was executed) and access is prohibited. This may also prevent access to the information stored in storage devices802if the information used to generate the local copy of the boot authentication code had been modified in the time elapsed since secrets were created from the initial or reference boot authentication code.

Embodiments of the present disclosure may include an apparatus. The apparatus may include a cryptographic key for decrypting content to be read from a storage media. The media may include a control circuit. The control circuit may be implemented by instructions in a non-transitory medium for execution by a processor, a function, library call, subroutine, shared library, software as a service, analog circuitry, digital circuitry, control logic, digital logic circuits programmed through hardware description language, ASIC, FPGA, PLD, or any suitable combination thereof, or any other suitable mechanism, whether in a unitary device or spread over several devices. The control circuit may be configured to, upon a boot of a server, dynamically generate a new boot authentication code using a prescribed method, and to determine a reconstituted boot authentication code. The reconstituted boot authentication code may be reconstituted from an initial boot authentication code that was previously generated using the prescribed method. The control circuit may be configured to compare the new and reconstituted boot authentication codes, and, based on a determination that the new and reconstituted boot authentication codes do not match, take a corrective action.

In combination with any of the above embodiments, the new boot authentication code may be to be obtained using the prescribed method from one or more of a MAC address, system global unique identifier, hardware serial number, or sensitive data including boot code, configuration files, operating system components.

In combination with any of the above embodiments, the new boot authentication code may be a checksum, cryptographic product, or signature of the sensitive data that was subsequently generated upon the boot of the server.

In combination with any of the above embodiments, the control circuit may be further configured to determine the reconstituted boot authentication code from secrets generated from the reconstituted boot authentication code.

In combination with any of the above embodiments, the control circuit may be further configured to reconstitute the boot authentication code from the secrets that were generated by the initial boot authentication code.

In combination with any of the above embodiments, the control circuit may be further configured to, based on a determination that the new and reconstituted boot authentication codes match, continue a system boot sequence.

In combination with any of the above embodiments, the control circuit may be further configured to, based on a determination that the new and reconstituted boot authentication codes do not match, lock further access to the storage media tray and storage media contained therein.

In combination with any of the above embodiments, the control circuit may be further configured to, after comparing the new and reconstituted boot authentication codes match, delete the reconstituted boot authentication.

In combination with any of the above embodiments, 9 the control circuit may be further configured to, based on a determination that the new and reconstituted boot authentication codes do not match, take a corrective action of one or more of deletion of the cryptographic key, locking of a bus communicating with the tray, or erasure of the storage media.

In combination with any of the above embodiments, the control circuit may be further configured to generate the initial boot authentication code using the prescribed method, generate a plurality of secrets derived from the initial boot authentication code, store one or more the plurality of secrets locally in encrypted form or remotely from the apparatus, and delete the initial boot authentication code and any of the plurality of secrets that are unencrypted and local to the apparatus.

In combination with any of the above embodiments, the control circuit may be further configured to reconstitute the reconstituted boot authentication code from secrets derived from the initial boot authentication code, delete the secrets after reconstituting the reconstituted boot authentication code from the secrets, and delete the reconstituted boot authentication code after comparing the new and reconstituted boot authentication codes.

In combination with any of the above embodiments, the control circuit may be further configured to, after comparing the new and reconstituted boot authentication codes match, delete the reconstituted boot authentication.

In combination with any of the above embodiments, the control circuit may be further configured to, based on a determination that the new and reconstituted boot authentication codes do not match, take a corrective action of deletion of the cryptographic key.

In combination with any of the above embodiments, the control circuit may be further configured to, based on a determination that the new and reconstituted boot authentication codes do not match and upon a corrective action of deletion of the cryptographic key, generate a record of deletion of the cryptographic key.

In combination with any of the above embodiments, the control circuit may be further configured to, based on a determination that the new and reconstituted boot authentication codes do not match and upon a corrective action of deletion of the cryptographic key, set a display indicator to indicate that the storage media has been cryptographically erased.

Although example embodiments have been described above, other variations and embodiments may be made from this disclosure without departing from the spirit and scope of these embodiments.