DEVICE AUTHENTICATION

An authenticatable device includes a substrate and a computing device with encryption capability affixed to the substrate. The computing device is to receive a challenge value and a first value from a host device, generate a second value based on at least the first value, and generate a response value based on the challenge value and the second value.

DETAILED DESCRIPTION

Disclosed are embodiments for device authentication. In particular, embodiments disclosed therein address the dilemma created by black market or look-alike devices. For example, black market drive carriers are increasingly appearing in the marketplace and cause customer confusion because they purport to be authentic or genuine manufacturer drive carrier. Indeed, some black market drive carriers include all of the manufacturer markings and are virtually indistinguishable to ordinary customers. Customers order such drive carriers believing that they are receiving a genuine manufacturer drive carriers when in fact they are from one of the various black market vendors. This ultimately costs customers unnecessary down time, harms the manufacturer's brand name, and diminishes manufacturer revenue.

In embodiments, an authenticatable drive carrier is provided. The authenticatable drive carrier comprises a substrate and a computing device with encryption capability affixed to the substrate. The computing device resident on the drive carrier is configured to receive a challenge value and a first value from a host device, determine a second value based on at least the first value, and generate a response value based on the challenge value and the second value. This response value may be used by a host device to determine if the drive carrier is authentic, and therefor may help reduce the confusion, down time, brand name harm, and lost revenue created by black market drive carriers.

Additional embodiments provide a method for drive carrier authentication. The method comprises storing a challenge value, a fist value, and a first response value at a host device: transmitting the challenge value and the first value from the host device to a drive carrier via a communication medium; receiving a second response value at the host device from the drive carrier via the communication medium; comparing the first response value and the second response value; and, in response to a determination that the first response value and the second response value are not the same, transmitting from the host device an indication that the drive carrier is not authentic.

Further embodiments are also directed to an authentication method. The method comprises storing, at a computing device, a table comprising a plurality of key values, wherein the plurality of key values are referenced using an index: receiving, at the computing device, a challenge value and a key index value from a host device; selecting, by the computing device, one of the plurality of key values based on the received key index value; and generating, by the computing device, a response value based on the challenge value and the selected key value. This response value may be provided to a host device to assist with an authentication determination, and therefore may facilitate black market device reduction.

FIG. 1is a block diagram of a system100in accordance with some embodiments. The system100may comprise a drive carrier110communicating with a host drive120via network130. While only one drive carrier110, host device120, and network130is shown, it should be understood that the system100may include a plurality of drive carriers, host devices, and/or networks collaborating and communicating with one another in accordance with embodiments.

The drive carrier110may be constructed of plastic, metal, and/or other materials. It may include a front plate or bezel140, opposing sidewalls150, and a floor160. A drive (not shown), such as a hard disk drive (HDD), solid state drive (SSD), or hybrid drive, may be placed within and/or attached to the area formed by the opposing sidewalls150, floor160, and front plate140. The HDD may use spinning disks and movable read/write heads. The SSD may use solid state memory to store persistent data, and use microchips to retain data in non-volatile memory chips. The hybrid drive may combine features of the HDD and SSD into one unit containing a large HDD with a smaller SSD cache to improve performance of frequently accessed files. Other types of drives such as flash-based SSDs, enterprise flash drives (EFDs), etc. may also be used with the drive carrier110.

The host device120may be, for example, a disk array controller, RAID controller, disk controller, a host bus adapter, an expander, and/or a server. The host device may comprise a processor (not shown) which executes instructions stored on an associated computer-readable medium such as a memory (not shown) to effectuate the host device functionality described herein. The host device120may further comprise a communication interface (not shown) for communicating with, e.g., the computing device170on the drive carrier110or other devices via the network130.

Network130may interconnect the host device120and the computing device170. Network130may comprise a serial communication bus, a parallel communication bus, an Inter-Integrated Circuit (I2C) bus, a wired link, a wireless link, a local area network (LANs), a wide area network (WAN), a telecommunication network, the Internet, a computer network, a Bluetooth network, an Ethernet LAN, an token ring LAN, a serial advanced technology attachment (SATA), and/or a serial attached SCSI (SAS).

FIG. 2is a graphical representation of substrate180in accordance with embodiments. In particular,FIG. 2depicts a flexible printed circuit board210with a computing device170and multiple light sources220affixed thereon. In addition to providing authentication operations, the computing devices170may be configured to control the light sources220to provide, e.g., a drive locate indication, a do not remove indication, and/or a self-describing animated activity indication.

FIG. 3is a graphical representation of how the flexible printed circuit board210ofFIG. 2may be affixed to the drive carrier110in accordance with embodiments. As shown, the flexible printed circuit board210may coupled to the rear of the drive carrier310, one of the opposing sidewalls320, and the front of the drive carrier330. Of course, alternate configurations may also be used in accordance with embodiments. For example, in embodiments, a rigid printed circuit board may be affixed to the rear of the drive carrier310, one of the opposing sides320, and/or the front of the drive carrier330.

FIG. 4is a process flow diagram of a portion of the authentication process with respect to the host device120in accordance with embodiments. More precisely,FIG. 4describes the authentication processes to initialize of program the host device120in accordance with embodiments. This process may begin at block410and may occur at the host device factory, manufacturing facility, or the like. The host device120may be a new host device, a refurbished host device, or another type of host device that will be entering or re-entering the marketplace. At block410, the host device120(e.g., an array controller) may receive a challenge value and a first value from a functional board test (FBT) application running on a server device. The challenge value and first value may be stored in, e.g., a non-volatile storage medium at the host device120. In embodiments, the challenge value and first value may be pseudo-random numbers generated by the FBT application or another server application. Furthermore, in embodiments, the challenge value may be a 16-byte number and the first value may be a 1-byte number. While other size values may also be used in accordance with embodiments (e.g., 32-byte, 64 bytes, etc. ), 16-byte and 1-byte for the challenge value and first value, respectively, will be used for the remainder of this example.

At block420, the host device120sends the stored challenge value and first value to a trusted device such as a trusted drive carrier. At block430, the trusted device generates a second value based on at least the first value. In embodiments, the computing device may generate the second value by inputting the first value into a function. In further embodiments, the first value may be a key index value and the second value my be one of a plurality of key values stored in a table. The plurality of key values may be referenced using an index, and therefore the computing device may determine the second value by identifying one of the plurality of key values stored in the table based on the key index value. For example, the key index value (i.e., first value) may be a 1-byte random number (i.e., 256 random combinations) and the table may store 256 key values. Based on the received 1-byte random number, the computing device may identify one of the 256 values from the table (i.e., the second value).

At block440, the trusted device generates a response value (e.g., a 16-byte response value) by encrypting the challenge value with the second value. That is, the trusted device inputs the challenge value and the second value into an encryption algorithm to arrive at a response value. The encryption algorithm may be one of the previously mentioned encryption algorithms. For example, in embodiments the trusted device may input a 16-byte second value and a 16-byte challenge value into the AES-128 encryption algorithm to arrive at a 16-byte response.

At block450, the trusted device provides the response value to the host device120. The host device120may then store this response value in a non-volatile storage medium along with the challenge value and first value. In embodiments, the host device120may conduct the above-mentioned process multiple times to confirm that the response value is the same for each iteration.

Following the above mentioned processes, the host device120may have stored thereon a challenge value, a first value, and a response value. As discussed in detail below with respect toFIG. 5, the host device120may then use these values to authenticate drive carriers in the marketplace. In particular, the host device120may conduct a challenge-response authentication process with various drive carriers to confirm that they are authentic and not black market or counterfeit drive carriers.

FIG. 5is a process flow diagram of the drive carrier authentication process in accordance with embodiments. The process may involve the drive carrier110and host device120as reference inFIG. 1. The process may begin at block510, when the host device powers-up or a drive is hot-added into a hot-plug drive bay.

At block520, in response to the host device powering-up or a drive being hot-added, the host device120transmits a challenge value (e.g., 16-byte challenge value) and a first value (e.g., a 1-byte value) to a computing device170on the drive carrier110. In embodiments, this challenge value and first value may be sent to a plurality of drive carriers in parallel for parallel authentication.

At block530, the computing device170generates a second value based at least on the first value. As discussed above, this may accomplished via a function and/or via a table with plurality of keys referenced with an index.

At block540, the computing device170generates a response value (e.g., a 16-byte response value) by encrypting the challenge value with the second value. That is, the computing device170inputs the challenge value and the second value into an encryption algorithm to arrive at a response value. The encryption algorithm may be one of the previously mentioned encryption algorithms. For example, in embodiments the computing device170may input a 16-byte second value and a 16-byte challenge value into the AES-128 encryption algorithm to arrive at a 16-byte response.

At block550, the computing device170provides the response value to the host device120. At block550, the host device120compares the received response value with the response value stored therein and as mentioned above. If the two response values match, the host device120, at block570, determines that the drive carrier is authentic. The host device120then continues normal operation/communication with the drive carrier110at block580. On the other hand, if the host device120determines that the two response value do not match, at block590, the host device120determines that the drive carrier is not authentic. In response to this determination, the host device120may stop writing to the computing device170at block592. Alternatively or in addition, the host device120may send a message indicating that the drive carrier could not be validated as genuine at block594.

The message may be a message to the system event log on a server. For example, the host device120may send a message indicating that the hard drive carrier located at, e.g., PCI Slot=W, Port=XX, Box=Y, and Bay=Z, could not be authenticated as a genuine manufacturer hard drive. The host device120may further indicate that it will not control the computing device170or not control the light sources(s)220associated therewith.

Alternatively or in addition, the message may be a message to OS Storage Agents (e.g., simple network message protocol (SNMP), Windows Management Instrumentation (WMI), etc) or agent that polls the host device120. The message may similarly indicate that the hard drive carrier located at, e.g., PCI Slot=W, Port=XX, Box=Y, and Bay=Z, could not be authenticated as a genuine manufacturer hard drive. Or, that the host device120will not control the computing device170or not control the light sources(s)220associated therewith.

Alternatively or in addition, the message may be a message to an array configuration utility (ACU). This message may be a failed authentication ACU message from controller status message or a failed authentication ACU message from hard drive more information message indicating, e.g., that the hard drive carrier located at PCI Slot=W, Port=XX, Box=Y, and Bay=Z, could not be authenticated as a genuine manufacturer hard drive. Or, that the host device120will not control the computing device170or not control the light sources220associated therewith. Alternatively or in addition, such messages may be sent to an array diagnostic utility (ADU).

Furthermore, the message may be a power-on self test (POST) message. If sent from a smart array controller or array controller type host device120, such a message may indicate that one or more attached hard drive carriers could not be authenticated as genuine manufacturer drives carriers and/or that the smart array controller or array controller will not control the light source(s) associated with these drive carriers. Moreover, the smart array controller or array controller may request that a ACU or ADU be run to learn which drives could not be validated as genuine. If sent from a HBA-type host devices, such a message may indicate that one or more attached hard drive carriers could not be authenticated as genuine manufacturer drives carriers and/or that the HBA will not control the light sources associated with these drive carriers. Furthermore, the HBA may request that the System Event Log be viewed to learn which drive could not be validated as genuine.

In some embodiments, a determination by the host device120that a drive carrier110is not authentic will not result in preventing input/output traffic from the physical drive. That is, even if a drive carrier is determined to be non-authentic, the drive associated therewith may nonetheless continue input/output operations via, e.g., a SAS fabric. However, light sources associated with the drive may be barred from illuminating.

FIG. 6is a block diagram showing a non-transitory, computer-readable medium that stores code for operating a host device120in accordance with embodiments. The non-transitory, computer-readable medium is generally referred to by reference number600and may be included in the host device120. The non-transitory, computer-readable medium600may correspond to any typical storage device that stores computer-implemented instructions, such as programming code or the like. For example, the non-transitory, computer-readable medium600may include one or more of a non-volatile memory, a volatile memory, and/or one or more storage devices. Examples of non-volatile memory include, but are not limited to, electronically erasable programmable read only memory (EEPROM), flash memory, and read only memory (ROM). Examples of volatile memory include, but are not limited to, static random access memory (SRAM) and dynamic random access memory (DRAM). Examples of storage devices include, but are not limited to, hard disk drives, compact disc drives, digital versatile disc drives, optical drive, and flash memory devices.

A processor610generally retrieves and executes the instructions stored in the non-transitory, computer-readable medium600to operate the host device120in accordance with embodiments. In an embodiment, the non-transitory computer-readable medium600can be accessed over a communication bus620. Furthermore, in embodiments, the non-transitory computer-readable medium600may be configured to store a first value630, a challenge value640, and a response value650, as described above with respect toFIGS. 4 and 5. Specifically, the host device120may store these values to use as part of the above-mentioned drive carrier110authentication process.

FIG. 7is a block diagram showing a non-transitory, computer-readable medium that stores code for operating a computing device170in accordance with embodiments. The non-transitory, computer-readable medium is generally referred to by reference number700and may be included or otherwise associated with the computing device170. The non-transitory, computer-readable medium700may correspond to any typical storage device that stores computer-implemented instructions, such as programming code or the like. For example, the non-volatile computer-readable medium700may include one or more of a non-volatile memory, a volatile memory, and/or one or more storage devices. Examples of non-volatile memory include, but are not limited to, electronically erasable programmable read only memory (EEPROM), flash memory, and read only memory (ROM). Examples of volatile memory include, but are not limited to, static random access memory (SRAM) and dynamic random access memory (DRAM). Examples of storage devices include, but are not limited to, hard disk drives, compact disc drives, digital versatile disc drives, optical drive, and flash memory devices.

A processor710generally retrieves and executes the instructions stored in the non-transitory, computer-readable medium700to operate the computing device170in accordance with embodiments. In an embodiment, the non-transitory computer-readable medium700can be accessed over a communication bus720. Furthermore, in embodiments, the non-transitory computer-readable medium700may be configured to store a table with a plurality of keys referenced via an index730and an encryption algorithm470. As described above with respect toFIGS. 4 and 5, the computing device170may determine a second value from the table based on the first value630received from the host device120. The computing device170may then generate a response value based on the second value and challenge value640received from the host device120. More precisely, the computing device170may generate the response value by inputting the second value and challenge value640into an encryption algorithm (e.g., the AES-128 encryption algorithm). The host device120may compare this response value with the response value650stored therein to determine if the drive carrier110is authentic.

In embodiments, the authentication process may be the first process upon boot up or hot adding a drive and may be performed prior to any writes to update the Smart Carrier LEDs. The computing device170may input two values (the challenge value & the second value) to an AES-128 algorithm and receive one output (the response value). The host devices120may compare this response value with a response value stored therein via factory programming to determine if the drive carrier110is authentic.

With particular respect to host device120factory programming, FBT software may select a unique challenge value (e.g., a 16-byte random or pseudo-random number and a unique first value (e.g., a 1-byte random or pseudo-random number. The FBT software may then issue a special factory command to the host device120that provides the first value and challenge value. The host device120may then challenge a trusted drive carrier and learn the response value (e.g., a 16-byte response). In embodiments, the host device120may conduct this process twice to determine the response value twice. If both response values match, host device120may then program the first value, the challenge value, and the response value into its on-board memory with proper checksum. In embodiments, if the host device120is a controller of HBA, it may send the challenge value and first value to any expanders attached to allow the expander to also generate a response value and program its own on-board memory. Accordingly, each host device120(e.g., controller, HBA, expander, and/or server) stores therein a challenge value, a response value, and a first value that is to be used by the host device120to authenticate one or more drive carriers.

Specifically, the drive carrier authentication process may comprise the host device120transferring the the above-described challenge value and first value from an on-board memory to the drive carrier110. This may occur during the host device120power-up and/or after a drive carrier is hot-added into a hot-plug drive bay. Upon reception of the challenge value and the first value from the host device120, the drive carrier110may determine a second value (e.g., via a function or key look-up table). The computing device may then create a response value using an encryption algorithm (e.g., the AES-128 encryption algorithm) to encrypt the challenge value and the second value. The host device120may then read the response value from the drive carrier110or otherwise receive the response value and compare it with the expected response value stored therein. If the two responses match, the drive carrier110is determined to be authentic. If the two response values do not match, the drive carrier110is determined to be non-authentic. In embodiments, the host device110may repeat the challenge-response value multiple times before concluding that the drive carrier110is not authentic. Furthermore, in embodiments, if the host device120determines that the drive carrier110is not authentic, the host device110may stop performing all writes to the computing device170on the drive carrier110. However, in embodiments, hard drive input/output traffic may still be allowed. Further, host device110may transmit one or more messages to inform a user and/or administrator that a drive carrier could not be validated as genuine. The one ore more messages may further inform the user and/or administrator that the host device is no longer controlling drive carrier light sources220. Hence, embodiments described herein enable customers to determine whether or not drive carriers are authentic, and may therefore curtail the proliferation of non-authentic drive carriers in the marketplace.

In some embodiments, the authentication process may be used to authenticate devices other than drive carriers. For example, the host device may authenticate pluggable devices, memory devices, host bus adapter, power supplies, input/output modules, fans, network interface controllers, gigabit interface converters, peripherals (mouse, keyboard, scanners, speakers, webcams, etc.), transceivers, and/or mezzanine cards. Such devices may include a computing device which communicates with the host device to provide a response value based on a received challenge value and a first value, as described above.FIG. 8is a process flow diagram of such a device authentication process in accordance with embodiments. The process may involve a device and a host device110. The process may begin at block810, when a computing device of the device stores a table comprising a plurality of key values, wherein the plurality of key values are referenced using an index. At block820, the computing device may receive a challenge value and a key index value from the host device. At block830, the computing device may select one of the plurality of key values in the table based on the received key index value. At block840, the computing device may generate a response value based on the challenge value and the selected key value (e.g., by inputting the challenge value and the selected key value into an encryption algorithm). The computing device may then provide the response value to the host device in order for the host device to determine whether or not the device is authentic.