Verifying OEM components within an information handling system using original equipment manufacturer (OEM) identifier
A method validates whether a component/device installed within an information handling system (IHS) is an OEM (original equipment manufacturer) programmed device, by: reading identification (ID) data and an identifier code from the target device; generating a unique encrypted sequence using the ID data; providing a unique validation check code based on the ID data; generating a component validation code corresponding to the target device via a decryption process involving the unique encrypted sequence; and comparing the component validation code to the validation check code. The method further includes: in response to the component validation code matching the validation check code, identifying the target device as an OEM programmed device with a valid identifier code stored as the identifier code; and enabling certain processes reserved for only verified OEM programmed devices. The decryption process reverses an encryption process utilized when generating the unique OEM identifier code of the target device.
Latest Dell Products, L.P. Patents:
- Isolated environment provisioning in service mesh-based microservices systems
- Information handling system multi-stream cable throughput management
- Heater apparatus-integrated bezel for a computing device
- Heater apparatus and air circulation component-integrated bezel for a computing device
- Enabling dial home service requests from an application executing in an embedded environment
The present application is related to co-pending, commonly assigned application, Ser. No. 13/905,209, filed on the same date and having the same inventorship herewith. All content of the related application is incorporated herein by reference.
BACKGROUND1. Technical Field
The present disclosure generally relates to information handling systems (IHS) and in particular to component validation within information handling systems.
2. Description of the Related Art
As the value and use of information continue to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes, thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
Computer system developers spend an enormous amount of time and money developing, testing and validating commodities such as dual in-line memory modules (DIMMs) in their platforms in order to ensure compatibility and robustness of operation. However, in order to reduce costs, some customers choose to install commodities which are not validated by an original equipment manufacturer (OEM). These non-supported components may cause system instabilities, or lack the robustness required for OEM enhanced capabilities. These non-supported components also negatively impact product operational margin and increase system warranty costs.
As OEMs drive to offer differentiated capabilities, some depend on operating characteristics that are superior to the industry standard allowed range. An example is running a double data rate (DDR) channel frequency at “faster than standard” speed or “above industry standard validated” speed for a given topology and DIMM population, which is possible only with rigorous testing and validation of officially supported OEM validated DIMMs. As OEMs push the limits of frequency, it will be become critical to be able to determine if the installed DIMMs are truly OEM validated.
An easily identified or reverse engineered identification (ID) string is not sufficient to provide adequate security. Safeguards are required to prevent third parties from producing illegitimate DIMMs that appear to be OEM supported. Furthermore, DDR4 DIMM Electrically Erasable Programmable Read-Only Memory (EEPROM) serial presence detects (SPDs) no longer offer a permanent write protection mechanism found on prior generations of SPD EEPROMs, that was able to permanently lock the Joint Electron Device Engineering Council (JEDEC) standard contents of the SPD (DDR3 bytes 0-127). In addition, reversible software write protecting SPD content blocks requires serial address 0 (SAO) signal to be driven to a high level input voltage (VHV) (e.g., approximately 7-10 volts) which can only be accommodated in a programming fixture. Lack of permanently locking the JEDEC standard bytes, and need to keep the OEM area unlocked, leaves the DIMMs open to manipulation.
BRIEF SUMMARYDisclosed are a method and an information handling system (IHS) for validating an installed component within the information handling system using a securely generated unique identifier code associated with identifier data of the installed component. According to a first aspect of the disclosure, an IHS designed to support utilization of one or more of the programmable devices with unique identifier code, is configured with a secure version of an identifier generation and validation (IGV) controller, which interfaces with the basic input output system (BIOS) and/or the unified extensible firmware interface (UEFI) of the IHS, to implement a verification check of the unique identifier codes of the installed devices. In response to and/or during a system start-up or power on procedure, such as a POST (power on self test) operation, the IGV controller performs a validation check on a target programmable device to determine whether the target programmable device is an OEM validated device. In particular, the IGV controller reads from the target programmable device (a) second ID data and (b) a device-maintained identifier code. The IGV controller generates a unique encrypted sequence corresponding to the second ID data. In addition, the IGV controller generates a component validation code for the target programmable device by using the second reversible encryption-decryption component to perform a first decryption process using (a) the device identifier code read from the target programmable device and (b) the generated unique encrypted sequence corresponding to the second ID data. The first decryption process reverses a first encryption process that would have been performed using the same second ID data of the target device during generation of the OEM unique identifier code for a valid target device. The first decryption process enables the IGV controller to generate an OEM proprietary code which is associated with and/or corresponds to the second ID data. The IGV controller then compares the component validation code to the OEM/manufacturer proprietary code corresponding to the second ID data to determine whether the identifier code read from the target programmable device is a valid unique identifier code. In response to the component validation code not being identical to the OEM proprietary code, the IGV controller identifies the target programmable device as an invalid component having an invalid identifier code. However, in response to the component validation code being identical to the manufacturer proprietary code, the IGV controller identifies the target programmable device as an OEM programmed device having a valid identifier code.
According to one additional aspect of the disclosure, in response to identifying the target programmable device as a programmed device having a valid identifier code, the IGV controller determines whether a serial number of the target device is unique by comparing the ID data against information provided within an OEM central database. In response to the serial number being unique, the IGV controller identifies the target device as an OEM programmed device with a valid OEM-provided unique identifier code, stored as the retrieved identifier code. However, in response to the serial number not being unique, the IGV controller issues a notification of a serial number conflict.
According to another aspect of the disclosure where specific pre-identified capabilities involving use of the target programmable device are disabled pending an outcome of the device validation check, in response to the target programmable device being identified as a valid OEM programmed device, the IGV controller enables the pre-identified capabilities. However, in response to the target programmable device being identified as an invalid component, the IGV controller maintains a disabled state of the pre-identified capabilities for that installed device.
The above summary contains simplifications, generalizations and omissions of detail and is not intended as a comprehensive description of the claimed subject matter but, rather, is intended to provide a brief overview of some of the functionality associated therewith. Other systems, methods, functionality, features and advantages of the claimed subject matter will be or will become apparent to one with skill in the art upon examination of the following figures and detailed written description.
The description of the illustrative embodiments can be read in conjunction with the accompanying figures. It will be appreciated that for simplicity and clarity of illustration, elements illustrated in the figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements are exaggerated relative to other elements. Embodiments incorporating teachings of the present disclosure are shown and described with respect to the figures presented herein, in which:
The illustrative embodiments provide methods and information handling systems (IHS) that securely generate and validate unique identifier codes for an OEM original equipment manufacturer (OEM) (programmable) device. The illustrative embodiments further provide methods and information handling systems configured for validating an installed component using a securely generated unique identifier code associated with identifier data of the installed component. According to one embodiment of the unique identifier code generation, an identifier generation and validation (IGV) controller operating in an authorized IHS generates a unique encrypted sequence by encrypting identification (ID) data read from the OEM device. The IGV controller generates a unique OEM identifier code for the OEM device by further encrypting the encrypted sequence using a first OEM proprietary code. The IGV controller writes the first identifier code to a pre-specified storage location of the device. According to one embodiment of the unique identifier code validation, a locally-installed IGV controller performs a validation check on a target device by utilizing a decryption process yielding a component validation code and which reverses an associated encryption process for generating a unique OEM identifier code. The IGV controller identifies the target device as an OEM validated device if the component validation code matches a second OEM proprietary code corresponding to the target device.
In the following detailed description of exemplary embodiments of the disclosure, specific exemplary embodiments in which the disclosure may be practiced are described in sufficient detail to enable those skilled in the art to practice the disclosed embodiments. For example, specific details such as specific method orders, structures, elements, and connections have been presented herein. However, it is to be understood that the specific details presented need not be utilized to practice embodiments of the present disclosure. It is also to be understood that other embodiments may be utilized and that logical, architectural, programmatic, mechanical, electrical and other changes may be made without departing from general scope of the disclosure. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present disclosure is defined by the appended claims and equivalents thereof.
References within the specification to “one embodiment,” “an embodiment,” “embodiments”, or “one or more embodiments” are intended to indicate that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. The appearance of such phrases in various places within the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Further, various features are described which may be exhibited by some embodiments and not by others. Similarly, various requirements are described which may be requirements for some embodiments but not other embodiments.
It is understood that the use of specific component, device and/or parameter names and/or corresponding acronyms thereof, such as those of the executing utility, logic, and/or firmware described herein, are for example only and not meant to imply any limitations on the described embodiments. The embodiments may thus be described with different nomenclature and/or terminology utilized to describe the components, devices, parameters, methods and/or functions herein, without limitation. References to any specific protocol or proprietary name in describing one or more elements, features or concepts of the embodiments are provided solely as examples of one implementation, and such references do not limit the extension of the claimed embodiments to embodiments in which different element, feature, protocol, or concept names are utilized. Thus, each term utilized herein is to be given its broadest interpretation given the context in which that term is utilized.
Referring specifically to
IHS 100 further includes one or more input/output (I/O) controllers 120 which support connection to and processing of signals from one or more connected input device(s) 122, such as a keyboard, mouse, touch screen, or microphone. I/O controllers 120 also support connection to and forwarding of output signals to one or more connected output device(s) 124, such as a monitor or display device or audio speaker(s). In addition, IHS 100 includes universal serial bus (USB) 126 which is coupled to I/O controller 120. Additionally, in one or more embodiments, one or more device interface(s) 128, such as an optical reader, a universal serial bus (USB), a card reader, Personal Computer Memory Card International Association (PCMCIA) port, and/or a high-definition multimedia interface (HDMI), can be associated with IHS 100. Device interface(s) 128 can be utilized to enable data to be read from or stored to corresponding removable storage device(s) 130, such as a compact disk (CD), digital video disk (DVD), flash drive, or flash memory card. In one or more embodiments, device interface(s) 128 can also provide an integration point for connecting other device(s) to IHS 100.
IHS 100 also comprises identifier generation and validation (IGV) controller 114 which further comprises IGV module 115. While shown as a component within IGV controller 114, it is appreciated that IGV module 115 can be and is later described as a firmware module. IGV controller 114 is electronically and/or communicatively coupled to a number of original equipment manufacturer (OEM) programmable devices 116 via device interface(s) 128. In one implementation, device interface(s) 128 can further include General Purpose I/O interfaces such as I2C, SMBus, and peripheral component interconnect (PCI) buses to support such connections to OEM programmable devices 116. OEM programmable devices 116 respectively comprise OEM field(s) 118. As described herein, IGV controller 114 is able to generate a unique identifier code for each of OEM programmable devices 116. Also, IGV controller 114 can also determine whether a specific target device is an OEM validated device. As utilized herein, an OEM validated device and/or an OEM-programmed device refers to a device or component that was selected for use within an end-user IHS and which is programmed with its own unique identifier by IGV controller 114 while within a secure manufacturing or OEM environment.
IHS 100 comprises a network interface device (NID) 132. NID 132 enables IHS 100 to communicate and/or interface with other devices, services, and components that are located external to IHS 100. These devices, services, and components can interface with IHS 100 via an external network, such as example network 136, using one or more communication protocols. In particular, in one implementation, IHS 100 uses NID 132 to connect to server 140 via an external network, such as network 136. As illustrated, server 140 comprises central OEM database 145, whose functionality is later described. Network 136 can be a local area network, wide area network, personal area network, and the like, and the connection to and/or between network 136 and IHS 100 can be wired or wireless or a combination thereof. For purposes of discussion, network 136 is indicated as a single collective component for simplicity. However, it is appreciated that network 136 can comprise one or more direct connections to other devices as well as a more complex set of interconnections as can exist within a wide area network, such as the Internet.
Within the context of the unique identifier generation for programmable devices, IHS 100 can be an OEM or authorized manufacturer server operating within a secure environment and/or utilizing proprietary software. IHS 100 then performs the generation of the unique identifier for the various programmable components via one of an individualized (one-by-one) device processing for unique code generation and a serial, batch processing. For example, as shown in
IGV controller 114 enables an OEM to provide support for OEM Differentiated Memory capabilities to their customers. IGV controller 114 utilizes a unique OEM identifier code in order to: (1) detect, during target device validation, non-OEM installed memory or programmable devices and warn the user that the memory is not OEM supported; (2) detect, during target device validation, non-OEM installed memory and inform the user that OEM Advanced Memory Capabilities are disabled; (3) build statistics on OEM vs. Non-OEM memory installed in the field and/or at time of service for potential use in service and/or warranty actions, marketing or sales engagements; and (4) allow faster than industry standard DDR channel operation for numerous DIMM populations or modes.
The unique OEM identifier code may also be used to enable enhanced memory capabilities, including but not limited to: (1) rank margin test logging for enabling stretch goal operation; (2) memory measured and/or characterized power attributes for tuning power/performance and power management; (3) run-time telemetry and/or black box capture for enhanced failure analysis; (4) tracking a number of DIMM insertions/removals in a DIMM connector; (5) system-level data mining; (6) DIMM Enhanced Error Logging; and (7) advanced Reliability, Availability, and Serviceability (RAS) modes.
In general, in the DIMM implementation, IGV controller 114 generates a unique identifier code that is programmed into the OEM use area of OEM supported and validated server DIMMs or other programmable devices. The unique identifier code is generated utilizing an OEM “Secret” or proprietary code, the JEDEC DIMM supplier manufacturing date code field, and the JEDEC DIMM supplier Serial Number field, and a specially crafted and secret two-way (reversible) linear feedback shift register (LFSR) based scrambler and Exclusive-OR (XOR) scrambler. An alternative method for generating unique identifier codes involves use of Private/Public key encryption. However, the limited amount of space available in the SPD EEPROM to store the identifier code (e.g., approximately 4 bytes only) or environments where programming and/or checking the identifier code cannot accommodate standard key interchange may cause the alternative methods to be less frequently utilized.
The OEM Identifier Code (and potentially other SPD OEM fields) is only programmable using OEM test software. The OEM test software is made available to manufacturing sites, memory suppliers, repair depots, and other applicable sites, and executes only when running on an authorized/OEM server. Further, the OEM test software only executes in a system operating within a manufacturing mode. In various embodiments, the code may be stand-alone, built into the BIOS, or a Unified Extensible Firmware Interface (UEFI), or the code may use some other deployment mechanism or platform.
According to one aspect of the disclosure, JEDEC DIMM SPD EEPROMs define an area for OEM Use. On DDR3, for example, this area is the top 80 (out of 256) bytes, i.e., bytes 176-255. On DDR4, this area is the top 128 (out of 512) bytes, i.e., bytes 384-511. In one embodiment, a four-byte field is used for the unique identifier code, but in other embodiments, a greater number of bytes or a lower number of bytes may be utilized as long as the number utilized is large enough to maintain acceptable code strength.
For DDR3, the Module ID: Module Manufacturing Date is provided in bytes 120-121 and the Module Serial Number is presented in bytes 122-125. For DDR4, the equivalent bytes are 232-324, and 325-328. The module manufacturer includes a date code for the module. The JEDEC definitions for bytes 120 and 121 are year and week respectively. These bytes must be represented in Binary Coded Decimal (BCD). For example, week 47 in year 2003 would be coded as 0x03 (0000 0011) in byte 120 and 0x47 (0100 0111) in byte 121. Generally, the supplier must include a unique serial number for the module. The supplier may use whatever decoding method desired in order to maintain a unique serial number for each module.
Within the context of the unique identifier verification process for installed devices or components, IHS 100 can be a single user device, such as a personal computer or a server that has been shipped out of the manufacturing environment, such that the IHS 100 can be modified in the field to include non-OEM approved/authorized devices. Within this context, IHS 100 includes at least one and potentially a plurality of components or devices that can be targeted for verification. In the described embodiments, these components or devices are referred to as target device/s. As shown by
With specific reference now to
In one embodiment, IGV controller 201 and IGV module 215 are implemented as software and/or firmware components. However, in another embodiment, selected elements of IGV controller 201 and/or IGV module 215 are implemented using hardware elements.
Also illustrated in IGV environment 200 is Input/Output (I/O) port 236. When implemented within a secure and/or authorized manufacturing environment, IGV controller 201 executes on authorized IHS 100 during the manufacturing process and communicates with server IHS 140 (
In a first embodiment, as illustrated in
Referring again to
IGV controller 201 is able to trigger particular functions of IGV module 215 for a specific order of execution in order to generate a unique identifier code and/or validate an identifier code read from an OEM programmable device. A specifically ordered execution of functions represents one of multiple functional configurations that can be configured by IGV controller 201.
In one embodiment, the first encryption-decryption component is a multiple stage encryption-decryption component that yields encrypted sequence outputs for multiple stages, respectively. IGV controller 114/201 utilizes the multiple stage encryption-decryption component to provide further security. The multiple stage encryption-decryption component provides storage for the encrypted sequence outputs for the multiple stages using a corresponding number of fields that is greater than a number of fields utilized for a single stage encryption-decryption component.
IGV controller 114/201 provides additional security in the encryption/decryption processes by encrypting a source code for at least one of (a) the OEM/manufacturer proprietary code and (b) the coefficients utilized within the first reversible encryption-decryption component or LFSR to prevent access to proprietary code and coefficients by a third party. Furthermore, IGV controller 114/201 periodically updates at least one of (a) the manufacturer proprietary code and (b) the coefficients utilized within the first reversible encryption-decryption component to provide enhanced security. IGV controller 114/201 provides this enhanced security to respectively increase a difficulty in reverse engineering from information read from the OEM programmable device the manufacturer proprietary code and the coefficients utilized within the first reversible encryption-decryption component.
In a first example implementation, code “A” representing serialized OEM proprietary code 305 is received at the first input port of XOR scrambler 312. In addition, code “B” representing unique encrypted sequence 311 is received at the second input port of XOR scrambler 312. As a result, XOR scrambler 312 yields “A” XOR “B” as unique identifier code 314.
When IGV module 115 is implemented as configuration 300, IGV controller 114 generates a unique encrypted sequence by using a reversible parallel LFSR based scrambler (310), which utilizes a proprietary set of polynomial coefficients. Furthermore, IGV controller 114 generates the first unique OEM identifier code for the OEM programmable device using a second reversible encryption-decryption component that comprises an Exclusive-OR (XOR) scrambler (312). IGV controller 114 writes unique OEM identifier code 314 to a pre-identified location of and OEM programmable device (216). In one implementation, the pre-identified location occupies a specified number of bytes of a serial presence detect (SPD) OEM use area of an OEM programmable device.
In second UIG configuration 400, IGV controller 201 generates a hash which represents unique encrypted sequence 411. IGV controller 201 generates a unique OEM identifier code 414 for an OEM programmable device providing first ID data 404 by encrypting unique encrypted sequence 411 (i.e., the generated hash) using OEM proprietary code 403 as a private key.
Referring again to
According to one aspect of the disclosure, in response to the component validation code not being identical to the manufacturer proprietary code, IGV controller 201 identifies the target programmable device as an invalid component having an invalid identifier code. However, in response to the component validation code being identical to the manufacturer proprietary code, IGV controller 201 identifies the target programmable device as a programmed device having a valid identifier code.
In one embodiment, in response to identifying the target programmable device as a programmed device having a valid identifier code, IGV controller 214 determines whether a serial number of the target device is unique by comparing the ID data against information provided within an OEM central database. In response to the serial number being unique, IGV controller 214 identifies the target device as an OEM programmed device with a valid OEM-provided unique identifier code stored as the retrieved identifier code. However, in response to the serial number not being unique, IGV controller 201 issues a notification of a serial number conflict.
According to another aspect of the disclosure, in response to the target programmable device being identified as a valid OEM programmed device and pre-identified capabilities involving use of the target programmable device being disabled pending an outcome of a validation check, IGV controller 201 enables the pre-identified capabilities. However, in response to the target programmable device being identified as an invalid component and the pre-identified capabilities being disabled pending an outcome of a validation check, IGV controller 201 maintains a disabled state of the pre-identified capabilities.
Following system start-up or a power on procedure (or during a power on self test POST) process, IGV module 215 initiates a validation check of a target programmable device to determine whether the target programmable device includes a valid unique identifier code. The target programmable device yields component/second ID data 504. In one embodiment, IGV module 215 generates unique encrypted sequence 511 corresponding to second component ID data 504 by serializing second component ID data 504 using FIFO serializer_2 208 and encrypting the serialized second component ID data 504 using parallel LFSR based scrambler 510. In one implementation, component or second ID data 504 includes (a) a date of manufacture and (b) a serial number of the target programmable device. IGV module 215 concatenates the date of manufacture and the serial number of the target programmable device to provide second component ID data 504 and serializes second component ID data 504 using FIFO Serializer_2 208. IGV module 215 is able to generate unique encrypted sequence 511 by encrypting the serialized second component ID data. Using first UIV configuration 500 of IGV module 215, IGV controller 201 generates component validation code 515 corresponding to the target programmable device by using the second reversible encryption-decryption component (e.g., XOR scrambler 512) to perform encryption using (a) an identifier code read from the target programmable device and (b) the unique encrypted sequence.
IGV module 215 then compares component validation code 515 to validation check code 517 (i.e., the serialized OEM proprietary code corresponding to second component ID data 504) to determine whether identifier code 502 read from the target programmable device is a valid and unique OEM identifier code. In response to component validation code 515 not being identical to validation check code 517, IGV module 215 identifies the target programmable device as an invalid component having an invalid identifier code by setting validation status 520 to “FAIL” or “INVALID”. However, in response to component validation code 515 being identical to validation check code 517, IGV module 215 identifies the target programmable device as a valid component having a valid identifier code by setting validation status 520 to “PASS” or “VALID”. In one embodiment, as described in
In response to the target programmable device being identified as a valid component and pre-identified advanced capabilities involving use of the target programmable device being disabled during normal operation, IGV module 215 enables the pre-identified advanced capabilities during normal operation. However, in response to the target programmable device being identified as an invalid component and the pre-identified advanced capabilities being disabled during normal operation, IGV module 215 maintains a disabled state of the pre-identified advanced capabilities.
In a second example implementation associated with the first example implementation of
IGV module 215 performs additional compatibility checks on the target programmable device including comparing retrieved content within data fields from the target programmable device against stored content within corresponding fields on a platform Approved Vendor List (AVL), including one or more of: (a) a module manufacturer identifier code; (b) a module revision code; and (c) other associated revision codes. IGV module 215 can use a result of the additional compatibility checks to determine whether the target programmable device is an OEM programmed device.
IGV controller 214 configures IGV module 215 to provide second UIV configuration 600 by which IGV controller 214 decrypts, using a public encryption key stored within a BIOS of an IHS, an identifier code read from a target programmable device. In particular, if component or second ID data 604 matches first ID data 404, IGV controller 214 performs a decryption process that reverses an encryption process performed on unique encrypted sequence 511 (i.e., the generated hash) and which encryption process was provided by second encryption-decryption component 412 (
Those of ordinary skill in the art will appreciate that the hardware, firmware/software utility, and software components and basic configuration thereof depicted in
IGVC 114 generates a unique OEM identifier code for the OEM device as described in
IGVC 114 determines whether the identified, target OEM devices have been programmed with unique identifier codes (decision block 812). If IGVC 114 has not already programmed the target OEM devices with unique identifier codes, IGVC 114 initiates process to generate a unique identifier code for a next OEM programmable device (block 816). Method then returns to block 806. However, if IGVC 114 has already programmed the identified OEM devices with unique identifier codes, the process by which IGVC 114 generates and writes unique identifier codes terminates at end block.
IGVC 214 generates a component validation code for the target device by using second encryption-decryption component 212 to perform a second encryption using (a) an identifier code read from the target device and (b) the unique encrypted sequence corresponding to the ID data (block 906). IGVC 214 generates an OEM/manufacturer proprietary code corresponding to the ID data read from the target device (block 908). IGVC 214 determines whether the generated component validation code matches the OEM proprietary code (decision block 910). If IGVC 214 determines that the generated component validation code does not match the OEM proprietary code, IGVC 214 identifies the target device as an invalid device (block 912). If IGVC 214 determines that the generated component code matches the OEM proprietary code, IGVC 214 identifies the target device as an OEM-validated device (block 914). The process ends at end block.
In the above described flow charts, one or more of the methods may be embodied in a computer readable device containing computer readable code such that a series of functional processes are performed when the computer readable code is executed on a computing device. In some implementations, certain steps of the methods are combined, performed simultaneously or in a different order, or perhaps omitted, without deviating from the scope of the disclosure. Thus, while the method blocks are described and illustrated in a particular sequence, use of a specific sequence of functional processes represented by the blocks is not meant to imply any limitations on the disclosure. Changes may be made with regards to the sequence of processes without departing from the scope of the present disclosure. Use of a particular sequence is therefore, not to be taken in a limiting sense, and the scope of the present disclosure is defined only by the appended claims.
Aspects of the present disclosure are described above with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. Computer program code for carrying out operations for aspects of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language, without limitation. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, such as a service processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, performs the method for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
As will be further appreciated, the processes in embodiments of the present disclosure may be implemented using any combination of software, firmware or hardware. Accordingly, aspects of the present disclosure may take the form of an entirely hardware embodiment or an embodiment combining software (including firmware, resident software, micro-code, etc.) and hardware aspects that may all generally be referred to herein as a “circuit,” “module,” or “system.” Furthermore, aspects of the present disclosure may take the form of a computer program product embodied in one or more computer readable storage device(s) having computer readable program code embodied thereon. Any combination of one or more computer readable storage device(s) may be utilized. The computer readable storage device may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage device would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage device may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
While the disclosure has been described with reference to exemplary embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted for elements thereof without departing from the scope of the disclosure. In addition, many modifications may be made to adapt a particular system, device or component thereof to the teachings of the disclosure without departing from the essential scope thereof. Therefore, it is intended that the disclosure not be limited to the particular embodiments disclosed for carrying out this disclosure, but that the disclosure will include all embodiments falling within the scope of the appended claims. Moreover, the use of the terms first, second, etc. do not denote any order or importance, but rather the terms first, second, etc. are used to distinguish one element from another.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
The description of the present disclosure has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the disclosure in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope of the disclosure. The described embodiments were chosen and described in order to best explain the principles of the disclosure and the practical application, and to enable others of ordinary skill in the art to understand the disclosure for various embodiments with various modifications as are suited to the particular use contemplated.
Claims
1. A method for determining whether a target device installed within an information handling system (IHS) is an OEM (original equipment manufacturer) programmed device, the method comprising:
- reading identification (ID) data and an identifier code from the target device;
- generating, by a processor executing an identifier generation and validation (IGV) controller program, a unique encrypted sequence using the ID data read from the target device;
- providing a validation check code based on the ID data, where the validation check code is exclusive for that specific ID data;
- generating a component validation code corresponding to the target device by performing a decryption process involving the unique encrypted sequence, wherein said decryption process is a reverse process of an encryption process that is used during device manufacture within a secure OEM environment to generate a unique OEM identifier code that is assigned to an OEM programmed device having a same ID data as the ID data read from the target device;
- comparing the component validation code to the validation check code;
- in response to the component validation code not being identical to the validation check code, (a) identifying the target device as a non-OEM programmed device, having an invalid identifier code, (b) disabling one or more pre-identified capabilities related to use of the target device; and (c) displaying, on a display device of the IHS, a message indicating that access to execute software components is not authorized; and
- in response to the component validation code being identical to the validation check code, identifying the target device as an OEM programmed device having a valid identifier code stored therein as the identifier code read from the target device.
2. The method of claim 1, wherein:
- generating the unique encrypted sequence comprises generating the unique encrypted sequence using a first encryption-decryption component that comprises an LFSR based scrambler, which utilizes polynomial coefficients that are securely generated and maintained.
3. The method of claim 1, wherein:
- generating the component validation code for the target device comprises generating the first unique OEM identifier code using a second, reversible encryption-decryption component that comprises an Exclusive-OR (XOR) scrambler engine;
- said decryption process involves processing (a) the identifier code and (b) the unique encrypted sequence; and
- the validation check code is an OEM proprietary code generated using an OEM proprietary module and which can be generated to be exclusively associated with a corresponding single OEM programmed device.
4. The method of claim 1, wherein said identifying the target device as a programmed device further comprises:
- determining whether a serial number of the target device is unique by comparing the ID data against information provided within an OEM central database;
- in response to the serial number being unique, identifying the target device as an OEM programmed device with a valid OEM-provided identifier code which has a valid OEM-provide unique identifier code stored as the retrieved identifier code; and
- in response to the serial number not being unique, issuing a notification of a serial number conflict.
5. The method of claim 1, wherein the reading of the ID data and the identifier code from the target device is triggered by the basic input/output system (BIOS) during a power-on self test (POST) of the IHS, and the method further comprises:
- the BIOS triggering a device verification module to perform a validation check to determine whether a target device installed in the IHS is an OEM validated device having an OEM-provided unique identifier code;
- disabling one or more pre-identified capabilities related to use of the target device within the IHS pending an outcome of the validation check;
- in response to the target device being identified as a valid OEM programmed device having a valid unique OEM-provided unique identifier code, enabling the pre-identified capabilities; and
- in response to the target device not being identified as a valid component, maintaining a disabled state of the pre-identified capabilities.
6. The method of claim 1, further comprising:
- performing one or more additional compatibility checks on the target programmable device, including comparing retrieved content within data fields from the target programmable device against stored content within corresponding fields on a platform Approved Vendor List (AVL), the fields including one or more of: (a) a module manufacturer identifier code; (b) a module revision code; and (c) other associated revision codes; and
- determining whether the target programmable device is an OEM programmed device based on a result of one or more of the additional compatibility checks performed.
7. The method of claim 1, wherein said generating a validation check code further comprises:
- generating a hash of the ID data, wherein the generated hash is the unique encrypted sequence, wherein the generated hash is the validation check code.
8. The method of claim 1, wherein said generating a component validation code further comprises:
- generating the component validation code by decrypting the identifier code using a public encryption key stored within a BIOS of the IHS.
9. An information handling system (IHS) comprising:
- at least one processor;
- at least one memory communicatively coupled to the at least one processor and having stored thereon an operating system (OS) and a Basic Input/Output System (BIOS);
- a display device;
- a first encryption-decryption component;
- a second encryption-decryption component;
- an identifier generation and validation (IGV) controller electronically coupled to at least one OEM programmable device (target device) and which: reads identification (ID) data and an identifier code from the target device; generates a unique encrypted sequence using the ID data read from the target device; provides a validation check code based on the ID data; generates a component validation code corresponding to the target device by performing a decryption process involving the unique encrypted sequence, wherein said decryption process is a reverse process of an encryption process that is used during device manufacture within a secure OEM environment to generate a unique OEM identifier code that is assigned to an OEM programmed device having a same ID data as the ID data read from the target device; compares the component validation code to the validation check code; in response to the component validation code not being identical to the validation check code, (a) identifies the target device as a non-OEM programmed device having an invalid identifier code, (b) disables one or more pre-identified capabilities related to use of the target device; and (c) displays, on a display device of the IHS, a message indicating that access to execute software components is not authorized; and in response to the component validation code being identical to the validation check code, identifies the target device as an OEM programmed device having a valid identifier code stored therein as the identifier code read from the target device.
10. The IHS of claim 9, wherein the IGV controller:
- generates the unique encrypted sequence using a first reversible encryption-decryption component that comprises an LFSR based scrambler, which utilizes polynomial coefficients that are securely generated and maintained.
11. The IHS of claim 9, wherein:
- the IGV controller generates the first unique OEM identifier code using a second reversible encryption-decryption component that comprises an Exclusive-OR (XOR) scrambler engine;
- said decryption process involves processing (a) the identifier code and (b) the unique encrypted sequence; and
- the validation check code is an OEM proprietary code that IGV controller generates using an OEM proprietary module and which can be generated to be exclusively associated with a corresponding single OEM programmed device.
12. The IHS of claim 9, wherein the IGV controller identifies the target device as a programmed device by:
- determining whether a serial number of the target device is unique by comparing the ID data against information provided within an OEM central database;
- in response to the serial number being unique, identifying the target device as an OEM programmed device with a valid OEM-provided identifier code which has a valid OEM-provide unique identifier code stored as the retrieved identifier code; and
- in response to the serial number not being unique, issuing a notification of a serial number conflict.
13. The IHS of claim 9, wherein the reading of the ID data and the identifier code from the target device is triggered by the basic input/output system (BIOS) during a power-on self test (POST) of the IHS, wherein:
- the BIOS triggers a device verification module to perform a validation check to determine whether a target device installed in the IHS is an OEM validated device having an OEM-provided unique identifier code;
- the IGV controller: disables one or more pre-identified capabilities related to use of the target device within the IHS pending an outcome of the validation check; in response to the target device being identified as a valid OEM programmed device having a valid unique OEM-provided unique identifier code, enables the pre-identified capabilities; and in response to the target device not being identified as a valid component, maintains a disabled state of the pre-identified capabilities.
14. The IHS of claim 9, wherein the IGV controller:
- performs one or more additional compatibility checks on the target programmable device, including comparing retrieved content within data fields from the target programmable device against stored content within corresponding fields on a platform Approved Vendor List (AVL), the fields including one or more of: (a) a module manufacturer identifier code; (b) a module revision code; and (c) other associated revision codes; and
- determines whether the target programmable device is an OEM programmed device based on a result of one or more of the additional compatibility checks performed.
15. The IHS of claim 9, wherein the IGV controller generates a validation check code by generating a hash of the ID data, wherein the generated hash is the unique encrypted sequence, wherein the generated hash is the validation check code.
16. The IHS of claim 9, wherein the IGV controller generates the component validation code by decrypting the identifier code using a public encryption key stored within a BIOS of the IHS.
17. The method of claim 1, further comprising:
- in response to detecting, during target device validation, non-OEM installed memory or programmable devices, issuing a warning to a user that the memory or programmable device is not OEM supported.
18. The method of claim 1, further comprising:
- in response to detecting, during target device validation, non-OEM installed memory or programmable devices, informing a user that OEM Advanced Memory Capabilities are disabled.
19. The IHS of claim 9, wherein the IGV controller:
- in response to detecting, during target device validation, non-OEM installed memory or programmable devices, issues a warning to a user that the memory or programmable device is not OEM supported.
20. The IHS of claim 9, wherein the IGV controller:
- in response to detecting, during target device validation, non-OEM installed memory or programmable devices, informs a user that OEM Advanced Memory Capabilities are disabled.
5696825 | December 9, 1997 | Johnson |
5727061 | March 10, 1998 | Johnson |
5774544 | June 30, 1998 | Lee |
5799086 | August 25, 1998 | Sudia |
5933498 | August 3, 1999 | Schneck |
5970147 | October 19, 1999 | Davis |
6028936 | February 22, 2000 | Hillis |
6094702 | July 25, 2000 | Williams |
6112246 | August 29, 2000 | Horbal |
6213391 | April 10, 2001 | Lewis |
6227447 | May 8, 2001 | Campisano |
6269348 | July 31, 2001 | Pare, Jr. |
6549972 | April 15, 2003 | Berstis |
6971015 | November 29, 2005 | Falcon |
7380167 | May 27, 2008 | Shaw |
7392255 | June 24, 2008 | Sholtis |
7660998 | February 9, 2010 | Walmsley |
7702636 | April 20, 2010 | Sholtis |
7831518 | November 9, 2010 | Montgomery |
8050705 | November 1, 2011 | Sicher |
8559287 | October 15, 2013 | Foland, Jr. |
8589306 | November 19, 2013 | Morriss |
8788881 | July 22, 2014 | Salomon |
9081963 | July 14, 2015 | Sima |
9230137 | January 5, 2016 | Berke |
9612846 | April 4, 2017 | Puthillathe |
9652253 | May 16, 2017 | Narayanan |
9690943 | June 27, 2017 | Barkelew |
10057221 | August 21, 2018 | Narayanan |
20010050990 | December 13, 2001 | Sudia |
20020184111 | December 5, 2002 | Swanson |
20030037237 | February 20, 2003 | Abgrall |
20030065927 | April 3, 2003 | Penner |
20030163427 | August 28, 2003 | Fung |
20040066417 | April 8, 2004 | Anabuki |
20040174570 | September 9, 2004 | Plunkett |
20050172121 | August 4, 2005 | Risan |
20060047892 | March 2, 2006 | Lin et al. |
20060135121 | June 22, 2006 | Abedi |
20070180270 | August 2, 2007 | Kumagai et al. |
20080005586 | January 3, 2008 | Manguia |
20080091605 | April 17, 2008 | Hughes |
20080098380 | April 24, 2008 | Klusmeyer |
20080243704 | October 2, 2008 | Ruef |
20090217054 | August 27, 2009 | Haider |
20090237011 | September 24, 2009 | Shah |
20090296938 | December 3, 2009 | Devanand |
20090319802 | December 24, 2009 | Walmsley |
20110015935 | January 20, 2011 | Montgomery |
20120079279 | March 29, 2012 | Leclercq |
20120179615 | July 12, 2012 | Tang |
20120311249 | December 6, 2012 | Koya |
20130170645 | July 4, 2013 | Chang |
20130173484 | July 4, 2013 | Wesby |
20130185552 | July 18, 2013 | Steer |
20130198519 | August 1, 2013 | Marien |
20140026196 | January 23, 2014 | Hayat |
20140157000 | June 5, 2014 | Buer |
20140164785 | June 12, 2014 | Ochiai |
20140351891 | November 27, 2014 | Grube |
20140358792 | December 4, 2014 | Berke |
20150120536 | April 30, 2015 | Talker |
20150145680 | May 28, 2015 | Favier |
20150278505 | October 1, 2015 | Lu |
20150289944 | October 15, 2015 | Hoffman |
20160067639 | March 10, 2016 | Shimpi |
20180005230 | January 4, 2018 | Zovi |
- Greg Caswell, Counterfeit Detection Strategies: When to Do It / How to Do It (Year: 2010).
Type: Grant
Filed: May 30, 2013
Date of Patent: Jan 15, 2019
Patent Publication Number: 20140358792
Assignee: Dell Products, L.P. (Round Rock, TX)
Inventors: Stuart Allen Berke (Austin, TX), Mukund Purshottam Khatri (Austin, TX)
Primary Examiner: Mamon Obeid
Application Number: 13/905,227