Pattern for secure store

A computer system, computer product, and method for accessing a secure store, which includes receiving a request to access a secure store, checking the file path of the request to make sure it exists in the secure store, verifying security parameters from the process at the file system filter layer, saving the PID of the process by the file system filter layer, comparing the saved PID to the process's PID, and allowing the process to access the path in the secure store specified in the request.

FIELD OF INVENTION

The present invention provides a secure system and method for determining whether an item is warranty-eligible.

BACKGROUND OF INVENTION

Companies, including manufacturers and vendors of products, warranty their products, including but not limited to hardware and software components. The warranties for products are often handled by an “after-sales” department, such as customer support. When a product requires replacement or maintenance, the validity of the warranty determines whether the expense is covered by the guarantor of the warranty. To determine whether a product is under warranty, it is not enough to track only the warranty period, for example, by correlating the warranty number to its validity period. However, many products, including but not limited to, hardware components, have maximum usage numbers that contribute to whether an item is covered under a warranty. If the maximum usage has been exceeded, a unit may not be covered.

Although a warranty number is public, the maximum usage number is often confidential so that a user cannot access it and manipulate it.

A need therefore exists for a system and method of storing confidential warranty-related information, including but not limited to, the maximum usage number for a given component.

SUMMARY OF INVENTION

An object of the present invention is to provide a secure system and method for determining whether an item is warranty-eligible.

In an embodiment of the present information, warranty information, including but not limited to the maximum usage number and the warranty number and term, is protected in a secure store. This security store is queried by an application executed on a processor, which satisfies the security credentials of the server housing the security store.

In an embodiment of the present invention, the security credentials are not known to the user of an application that checks confidential data in the secure store. Disseminating security credentials beyond authorized personnel represents a security risk. Further, the security credentials are not entered by the user, even an authorized user, and in an embodiment of the present invention, embedded in the application itself that accesses the secure store.

In a further embodiment of the present invention, the license key is embedded in the device manufacture data. The application accesses the license key from the manufacture data via a private interface. The license key is then encrypted to security parameters by a mathematical algorithm familiar to one of skill in the art, including but not limited to SHA, MDS, and/or CRC. When the encrypted security parameters are passed to the file system layer, they are decrypted to the license key using the same algorithm(s). Thus, in this embodiment, at both the license key and the mathematical algorithm are needed in order to access to pass through this level of verification to the secure store.

Additionally, in an embodiment of the present invention, the ability for a user to unmount or format the secure partition where the secure store is housed, is disabled from the user perspective. Disabling this functionality enhances security because the uninterrupted and unchanged connection to the secure partition enables the processor on the client making this connection to log all activity because this partition will be continuously “watched” by the system.

In an embodiment of the present invention, because the secure partition cannot be unmounted or formatted by a user, for the purposes of in-house maintenance, the partition can be formatted through a developer's bootload. Thus, for example, if the secure partition becomes corrupted and must be formatted to restore the integrity of the data, a developer can modify the partition can modify the partition via the bootloader when the operating system is launched.

In an embodiment of the present invention, the secure store is accessed by an application that is verified both by the security parameters that it passes the file system filter, and by the PID assigned to the application (program). In an embodiment of the present invention, this application encrypts the license key embedded in the device manufacture data and this encrypted value comprises the security parameters that are passed to the file system filter. At this level, the security parameters are decrypted to access the license key, which is verified by the file system filter.

In an embodiment of the present invention, the application, the program, that accesses the security store is comprised of computer-readable code and is executed on a processor on a client. The computer code is stored on one or more memory resources that are/is accessible to the client processor. The location of the resource(s) can be internal and/or external to the client.

In an embodiment of the present invention, before accessing the stored data in the secure store, the application, i.e., the program, initiates a security process. First, the security parameters passed by the program are verified by a file system filter layer on the secure partition. If the parameters pass the verification by the file system filter layer on this file system level, the file system filter layer saves the application's process identification (PID).

In an embodiment of the present invention, when the application, the originating program, after completion of the security sub-program, requests access to confidential information, including the warranty information in the secure store, the file system filter layer first checks that the PID has been saved. The application can continue if and only if the PID is saved. Otherwise, the information request is rejected. This originating program cannot run without a PID.

In an embodiment of the present invention, once the originating program accesses the security store, the program terminates. If the application seeks to access the security store at another point, the security sub-process (verification of the security parameters in the program and logging of the program's PID and additional security check for the logged PID, must complete before the originating program can access the security store.

DETAILED DESCRIPTION OF THE INVENTION

The present invention provides a secure system and method for determining whether an item is warranty-eligible.

The present invention offers a tiered security approach to protecting information, including but not limited to, information regarding whether a warranty for a product is still valid, such as the usage information and warranty number and term. An application utilizing a traditional application programming interface (API) to access the secure store housing this information could present a security risk. A traditional API passes security parameters to access secure information and these parameters are entered by a user. Giving security parameters to a user adds a level of exposure to the secure store. Thus, as discussed later, in an embodiment of the present invention, the security parameters are embedded in an application. In an embodiment of the present invention, this security measure is not the only security measure the program passes to gain access to the secure store.

In an embodiment of the present invention, the interactions of the user with the system are further limited by disabling the ability of the user to format or dismount the secure partition that houses the security store. In fact, the partition cannot be dismounted or formatted from the application level. Limiting this access has at least two advantages: 1) the data in the secure store is further protected; and 2) the computer system upon which the secure store is mounted can accurately monitor and log the activity in the secure store. When a partition is unmounted, the client that later mounts the partition is unaware of the activities within the partition during the time that the partition was unmounted. This knowledge gap compromises the security of the system in cases where the secure partition is hacked when it is unmounted and the data and/or its integrity is compromised.

In an embodiment of the present invention, because the secure partition cannot be unmounted or formatted by a user, for the purposes of in-house maintenance, the partition can be formatted through a developer's bootload. Thus, for example, if the secure partition becomes corrupted and must be formatted to restore the integrity of the data, a developer can modify the partition can modify the partition via the bootloader when the operating system is launched.

FIG. 1depicts a technical architecture of an embodiment of the present invention. In this embodiment100, the secure partition where the secure store is location is represented by a server110. However, the secure partition is not limited to a single machine and can also be a partition of the same computer that executed the program that queries the secure store.

A client120executes a program to connect to the secure partition on server110. InFIG. 1, the network connection130between the server110and the client120is accomplished via a LAN. However, the client120can connect to the server110using any connection known to one of skill in the art, including but not limited to, a WAN, a VPN, a private frame relay, and/or the Internet.

FIG. 2illustrates a block diagram of a client, a computer system120, which is part of the technical architecture of certain embodiments of the present invention. (An embodiment of the server110, also a computer system, is illustrated inFIG. 2.) The system120may include a circuitry202that may in certain embodiments include a microprocessor204. The computer system200may also include a memory206(e.g., a volatile memory device), and storage208. The storage208may include a non-volatile memory device (e.g., EEPROM, ROM, PROM, RAM, DRAM, SRAM, flash, firmware, programmable logic, etc.), magnetic disk drive, optical disk drive, tape drive, etc. The storage208may comprise an internal storage device, an attached storage device and/or a network accessible storage device. The system200may include a program logic210including code212that may be loaded into the memory206and executed by the microprocessor204or circuitry202.

In certain embodiments, the program logic210including code212may be stored in the storage208. In certain other embodiments, the program logic210may be implemented in the circuitry202. Therefore, whileFIG. 2shows the program logic210separately from the other elements, the program logic210may be implemented in the memory206and/or the circuitry202.

Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus or device.

Using the processing resources of a client120to execute software, computer-readable code or instructions, does not limit where this code is can be stored. Referring toFIG. 3, in one example, a computer program product300includes, for instance, one or more non-transitory computer readable storage media302to store computer readable program code means or logic304thereon to provide and facilitate one or more aspects of the present invention.

The program code may execute entirely on one resource, such as the server110, the client120, or partly on various resources.

In one aspect of the present invention, an application may be deployed for performing one or more aspects of the present invention. As one example, the deploying of an application comprises providing computer infrastructure operable to perform one or more aspects of the present invention.

As a further aspect of the present invention, a computing infrastructure may be deployed comprising integrating computer readable code into a computing system, in which the code in combination with the computing system is capable of performing one or more aspects of the present invention.

As yet a further aspect of the present invention, a process for integrating computing infrastructure comprising integrating computer readable code into a computer system may be provided. The computer system comprises a computer readable medium, in which the computer medium comprises one or more aspects of the present invention. The code in combination with the computer system is capable of performing one or more aspects of the present invention.

Although the architectures depicted inFIGS. 1-2are non-limiting examples, for ease of understanding only, these figures are referenced throughoutFIG. 4, a workflow400of an embodiment of the present invention.

To initiate the query process, the client120executes a program (application). The program is initiated (S410) and executes on a client120processor and is comprised of computer-readable code. The computer code is stored on one or more memory resources that are/is accessible to the client120processor. The location of the resource(s) can be internal and/or external to the client120.

First, the program registers on the file system layer and the security parameters are passed to the file system filter layer (S415). Once the security parameters are passed to the file system filter layer attempts to verify the passed security parameters (S420).

If these parameters are verified by the file system filter layer, the PID of the program is saved (S430a) on a memory resource in the physical machine where the file system filter layer resides and/or on a memory resource that is accessible to the file system filter layer via a communications connection. If the security parameters are incorrect or absent, the application fails to register at the file system filter layer (S430b).

An application may attempt to bypass the security at the file system filter layer and directly access the security store. Such an application is seen inFIG. 4(S430c). This application did not register at the file system filter layer (S415) and did not pass security parameters that were verified (S415). This application is included inFIG. 4to demonstrate the operation of the security features of the embodiment when an application fails to clear the security at the file system filter level before attempting to access the secure store.

The registration of the application to the file system filter layer may be handled as part of the security routine or as part of a subroutine. One of skill in the art will recognize that the use of a sub-routine to accomplish tasks that feed into the master routine is just a programming preference. Further embodiments of the present invention incorporate the security check by the file system filter layer into a single programming routine, and/or use a separate routine.FIG. 4is shows some steps as a part of the same routine that can be separated into sub-routines in further embodiments just for the sake of clarifying the different security measures involved in accessing the secure store. Additionally, the check for a logged PID, which is discussed later, is represented as a subroutine in this embodiment. However, one of skill is the art will recognize that this is one of many potential programming choices in structuring this workflow.

In an embodiment of the present invention, the security parameters are an encrypted license key. This license key is embedded in the device manufacture data, for example, for a hardware component. The program accesses the embedded data to retrieve the license key via a secure connection, including but not limited to, a private interface created by the executed computer code, the application. After the license key is retrieved, it is encrypted by a mathematical algorithm. Various mathematical encryption algorithms are known to one of skill in the art and can be employed by this process. Encryption algorithms that can be used to encrypt the license key include but are not limited to SHA, MDS, and/or CDC.

When the security parameters comprise an encrypted license key, the file system filter layer decrypts the security parameters to verify the license key. For decryption, the same algorithm that was used in encryption is employed. In this embodiment, only a program with both the correct encryption algorithm and the license can gain access to the secure store.

Returning toFIG. 4, after logging the PID (S430a), the program attempts to access (read/write) a file in the secure store (S440). The application that failed to register (S430b), and the application that bypassed registration (S430c) also attempts to access a file in the secure store (S440). First, the path of the file is checked to see if the file is in the secure store (S450). If the path is to the secure store, a security subroutine is executed (S460a) to check the PID of the application against the PID stored by the file system filter layer (S470a). The subroutine checks whether the PID of the application matches the stored PID (S480a). If the PIDs match, the query, for example, to retrieve warranty information, is given access to the secure store (S490a) and the program runtime executes (S495a). After the runtime is complete, the program terminates (S499b). Once the secure store's warranty information is retrieved by an application that passes the security, in order to complete a new query, the same security routine400repeats. Each instance of the application will have a different PID so for a match to occur, the PID of the new instance is logged at the file system filter layer.

If the PID of the application does not match the saved PID, which is the case both with the application that bypassed the security at the file system filter layer (S430c) and the application where the security parameters were not verified (S430b), the application fails to access the secure store (S490b). The program runs (S495b) and terminates without having accessed the secure store (S499b).

If the file that the application is attempting to access is not in the secure store, but located in a different partition, the file system layer check is bypassed (S460b). The application accesses another, non-secure partition (S470b), where the application runtime completes (S480b) and the program terminates (S485b).

Although the present invention has been described in relation to particular embodiments thereof, many other variations and modifications will become apparent to those skilled in the art. As such, it will be readily evident to one of skill in the art based on the detailed description of the presently preferred embodiment of the system and method explained herein, that different embodiments can be realized.

Although the present invention has been described in relation to securing warranty information, one of skill in the art will recognize that the security measures disclosed are applicable to protect access to sensitive information across different applications and industries. The use of the system and method is described relative to protecting warranty information but is not limited to this application.