Secure stores, such as Public Key Cryptography Standards (PKCS) SafeBags and Oracle Wallets, may be used to store sensitive information. By way of example, secure stores may be used to store Public Key Infrastructure (PKI) certificates, private keys, certificate revocation lists (CRLs), and other types of secret information. The secrecy of the information may be maintained by using various security mechanisms. At the lowest level, the security of a secure store may be protected by obfuscation. An additional level of security may be had by requiring a password to access the secure store. The password may be used to generate an encryption key, which in turn may be used to encrypt the contents of the secure store
Currently, secure stores are administered through graphical user interfaces (GUIs) or command line tools. These tools may be used for basic provisioning and administration of the secure stores. However, these tools do not provide a convenient way for users of a DBMS to access the secure stores.
Methods, systems, and machine-readable mediums are disclosed for administration of secure stores using a DBMS. In one embodiment, the method comprises receiving, at a DBMS, a command to access a secure store (e.g., a PKCS SafeBag or an Oracle Wallet). In some embodiments, the command may be a structured query language (SQL) command. In response to the command, the DBMS loads at least a portion of the contents of the secure store in a memory structure. For instance, the memory structure may be a virtual table. The DBMS may enable access to at least a subset of the memory structure contents by creating a fixed view of the contents.
The method may further comprise receiving a second command (e.g., an SQL command) at the DBMS to view a subset of the memory structure contents. In response to the second command, a fixed view of the memory structure contents may be displayed. Commands to alter the contents of the secure store may alternately or additionally be received by the DMBS. These commands may be SQL commands, such as insert, update, delete, or alter commands. The DBMS may alter the contents of the secure store in response to the received commands.
In another aspect, the method may additionally comprise receiving a second command at the DBMS to set a master encryption key. A new master key and a key identifier for the new master key are obtained at the DBMS. The new master key may be generated. Alternately, in some embodiments, a certificate identification may be received as part of the second command and the new master key may be obtained by retrieving a key value associated with the certificate identification from the secure store or another secure store. The new master key is encrypted and they are stored in either the secure store or a second secure store.
In another embodiment, a method is disclosed which comprises receiving, at a DBMS, a SQL command to alter the contents of a secure store. In response to the SQL command, the DBMS alters the secure store.
In a third embodiment, a DBMS system is disclosed. The DBMS system comprises a first communications interface configured to receive a command and a second communications interface to access a secure store. Logic is communicatively coupled with the first and second communications interface. The logic is configured to process a first set of commands to manipulate data in a database associated with the DBMS. The logic is further configured to process a second set of commands to access at least a portion of the contents in one or more secure stores using the second communications interface. In some aspects, the logic may also be configured to alter the contents of the one or more secure stores using the second communications interface.
Illustrative embodiments in accordance with the invention are illustrated in the drawings in which:
In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without some of these specific details. In other instances, well-known structures and devices are shown in block diagram form.
In some embodiments, the system 100 may also include a network 120. The network may be any type of network familiar to those skilled in the art that can support data communications using any of a variety of commercially-available protocols, including without limitation TCP/IP, SNA, IPX, AppleTalk, and the like. Merely by way of example, the network 120 maybe a local area network (“LAN”), such as an Ethernet network, a Token-Ring network and/or the like; a wide-area network; a virtual network, including without limitation a virtual private network (“VPN”); the Internet; an intranet; an extranet; a public switched telephone network (“PSTN”); an infra-red network; a wireless network (e.g., a network operating under any of the IEEE 802.11 suite of protocols, the Bluetooth™ protocol known in the art, and/or any other wireless protocol); and/or any combination of these and/or other networks.
The system may also include one or more server computers 125, 130. One server may be a web server 125, which may be used to process requests for web pages or other electronic documents from user computers 105, 110, and 120. The web server can be running an operating system including any of those discussed above, as well as any commercially-available server operating systems. The web server 125 can also run a variety of server applications, including HTTP servers, FTP servers, CGI servers, database servers, Java servers, and the like.
The system 100 may also include one or more file and or/application servers 130, which can, in addition to an operating system, include one or more applications accessible by a client running on one or more of the user computers 105, 110, 115. The server(s) 130 may be one or more general purpose computers capable of executing programs or scripts in response to the user computers 105, 110 and 115. As one example, the server may execute one or more web applications. The web application may be implemented as one or more scripts or programs written in any programming language, such as Java™, C, C#™ or C++, and/or any scripting language, such as Perl, Python, or TCL, as well as combinations of any programming/scripting languages. The application server(s) 130 may also include database management system (DBMS) servers, including without limitation those commercially available from Oracle, Microsoft, Sybase™, IBM™ and the like, which can process requests from database clients running on a user computer 105.
In some embodiments, an application server 130 may create web pages dynamically for displaying information. The web pages created by the web application server 130 may be forwarded to a user computer 105 via a web server 125. Similarly, the web server 125 can receive web page requests and/or input data from a user computer 105 and can forward the web page requests and/or input data to the web application server 130.
In further embodiments, the server 130 may function as a file server. Although for ease of description,
The system 100 may also include a database 135. The database 135 may reside in a variety of locations. By way of example, database 135 may reside on a storage medium local to (and/or resident in) one or more of the computers 105, 110, 115, 125, 130. Alternatively, it may be remote from any or all of the computers 105, 110, 115, 125, 130, and in communication (e.g., via the network 120) with one or more of these. In a particular set of embodiments, the database 135 may reside in a storage-area network (“SAN”) familiar to those skilled in the art. Similarly, any necessary files for performing the functions attributed to the computers 105, 110, 115, 125, 130 may be stored locally on the respective computer and/or remotely, as appropriate. In one set of embodiments, the database 135 may be a relational database, that is adapted to store, update, and retrieve data in response to SQL-formatted commands.
The computer system 200 may additionally include a computer-readable storage media reader 225; a communications system 230 (e.g., a modem, a network card (wireless or wired), an infra-red communication device, etc.); and working memory 240, which may include RAM and ROM devices as described above. In some embodiments, the computer system 200 may also include a processing acceleration unit 235, which can include a DSP, a special-purpose processor and/or the like.
The computer-readable storage media reader 225 can further be connected to a computer-readable storage medium, together (and, optionally, in combination with storage device(s) 220) comprehensively representing remote, local, fixed, and/or removable storage devices plus storage media for temporarily and/or more permanently containing computer-readable information. The communications system 230 may permit data to be exchanged with a network and/or any other computer.
The computer system 200 may also comprise software elements, shown as being currently located within a working memory 240, including an operating system 245 and/or other code 150, such as an application program. It should be appreciate that alternate embodiments of a computer system 200 may have numerous variations from that described above. For example, customized hardware might also be used and/or particular elements might be implemented in hardware, software (including portable software, such as applets), or both. Further, connection to other computing devices such as network input/output devices may be employed.
As will be described in further detail below, some of the commands that may be processed by the DBMS 302 may include commands to access and manipulate the contents of one or more secure stores 310, 312, 314. Thus, the DBMS 302 may include an interface that may be communicatively coupled with secure stores 310, 312, 314. Secure stores 310, 312, 314 may be used to store sensitive information, such as PKI certificates, private keys, certificate revocations, and other types of secret information (e.g., user passwords, logon information, and other types of secret information, which may in some instances be stored as name/value pairs). The secure stores 310, 312, 314 may be any type of structure suitable for holding the sensitive information, such as a file or a memory structure. By way of example, the secure stores 310, 312, 314 may be PKCS SafeBags or Oracle Wallets. In some embodiments, each secure store 310, 312, 314 may be designated to hold certain types of information. For example a first secure store 310 may be used to hold PKI certificates while another secure store 314 may be used to hold private key information. In some instances, a secure store 310 may contain multiple secure stores of different types. It should be appreciated that additional or fewer secure stores 310, 312, 314 may be communicatively coupled with an interface of DBMS 302. Additionally, in some instances, a secure store 310 may contain multiple secure stores of different types.
In the configuration described above, different components were described as being communicatively coupled to other components. A communicative coupling is a coupling that allows communication between the components. This coupling may be by means of a bus, cable, network, wireless mechanism, program code call (e.g., modular or procedural call) or other mechanism that allows communication between the components. Thus, it should be appreciated that DBMS 302, database 304, application server 306, user interface 308, and secure stores 310, 312, 314 may reside on the same or different physical devices. Additionally, it should be appreciated that in alternate embodiments, the system described in
Secure stores different than that illustrated in
After the DBMS receives 502 the command to open the secure store, the DBMS may then attempt to open 504 the secure store. The DBMS may open 504 the secure store using the appropriate interface to the secure store. In one embodiment, the interface may be an interface such as that described by the PKCS #11 standard. The attempt to open the secure store may fail for a variety of reasons, such as an invalid password or the secure store cannot be located. If the attempt fails, an error may be returned 506 to the user or application. Additional details on the reason of the failure may be provided with the returned error.
If the secure store can be opened 506, the contents of the secure store may be loaded 506 by the DBMS into a memory structure, such as a virtual table. In some embodiments, the DBMS may go through a translator which translates the contents to a format recognizable by the DBMS. The DBMS may not load all of the contents of the secure store into the memory structure. For example, private keys may not be loaded.
To protect sensitive data, the DBMS may limit the data in the memory structure that may be viewed by a user. In one embodiment, a fixed view may be provided by the DBMS to view the authorized content. The user may view the designated contents of a secure store by issuing commands to the DBMS to access the information. For example, the command may be an SQL select command that operates on the fixed view. In response to the command, the DBMS may display or return the requested contents. Before returning the contents, the DBMS may verify the requesting user has privileges to view the information.
The DBMS may also process commands to alter the contents of secure stores. By way of example, the contents of a secure store may be altered by issuing SQL commands, such as insert, update, and delete. The DBMS may respond to these commands by altering the contents of the secure store in accordance with the received command. It should be appreciated that the DBMS may also process other types of commands that may assist in the administration of a secure store, such as commands to create a secure store or commands to delete or remove the secure store from the memory structure.
Some of the commands that may be issued to a DBMS may not explicitly request that the contents of a secure store be altered, but execution of the command may result in changes being made to a secure store. One such command may be a command to set a new master key used for encryption.
The method may begin by the DBMS receiving 602 a command (e.g., an SQL command) to set a master key value or other key value. Merely by way of example, the command may take the format “alter system set [certificate_id] [authenticated by password]”, where the brackets indicate optional parameters. Thus, in some instances, the DBMS may generate or request the generation of the master key and in other instances, the user may specify a certificate having a private key value that may be used for the master key.
If an identifier is specified 604, the DBMS may locate 606 the certificate. This may be done by accessing a secure store holding certificates to verify the certificate exists and the status of the certificate. If the status indicates the certificate may be used, the DBMS may alter the status to indicate the certificate is now in use. The DBMS may additionally change the status of a certificate that was previously in use to “used” or other appropriate status. After the certificate has been located 606 and the status verified, a key value associated with the certificate may be retrieved 608 and used as the master key value. For example, this may be accomplished by the DBMS accessing the secure store or a second secure store (e.g., a secure store containing private keys) to obtain the private key value associated with the certificate. Processing may then continue at block 614, which will be described below.
If a certificate identification is not specified 604, the method may continue by generating 610 a new master key value. In some instances, the DBMS may call a random number generator to generate a key value of appropriate length. The DBMS may also generate 612 a key identifier. The key identifier generated may be a universally unique identifier. The method may then continue with block 614.
At block 614, the master key value is encrypted 614 for security. The DBMS may perform the encryption or may request the encryption from an encryption service. The key identifier, which in the case of a key associated with a certificate may be the certificate identification, and the encrypted key may then be stored 616 secure store, such as a PKCS SecretStore or other type of secure store for secret information. The secret store may be a part of the secure store holding certificate and/or private key contents or it may be a third secure store. In some cases, the secret store may not yet exist or may not be initialized, and thus, the DBMS may first create and/or initialize the secret store. After the information has been stored 618, the DBMS may initiate a backup 618 of the secure store to protect the data. The new master key value (or other requested key value) may be used by the DBMS to encrypt data or other purpose. Thus, it should be appreciated that the contents of one or more secure stores were altered by the DBMS.
An exemplary usage of a DBMS to administer a secure store will now be discussed. The user may first request that the DBMS open a secure store. As described in
In the foregoing description, for the purposes of illustration, methods were described in a particular order. It should be appreciated that in alternate embodiments, the methods may be performed in a different order than that described. Additionally, the methods may contain additional or fewer steps than described above. It should also be appreciated that the methods described above may be performed by hardware components or may be embodied in sequences of machine-executable instructions, which may be used to cause a machine, such as a general-purpose or special-purpose processor or logic circuits programmed with the instructions to perform the methods. These machine-executable instructions may be stored on one or more machine readable mediums, such as CD-ROMs or other type of optical disks, floppy diskettes, ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards, flash memory, or other types of machine-readable mediums suitable for storing electronic instructions. Alternatively, the methods may be performed by a combination of hardware and software.
While illustrative and presently preferred embodiments of the invention have been described in detail herein, it is to be understood that the inventive concepts may be otherwise variously embodied and employed, and that the appended claims are intended to be construed to include such variations, except as limited by the prior art.