U.S. patent number 8,892,868 [Application Number 12/242,746] was granted by the patent office on 2014-11-18 for hardening tokenization security and key rotation.
This patent grant is currently assigned to Amazon Technologies, Inc.. The grantee listed for this patent is Waylon Brunette, Jason Cetina, Hanson Char, Jason Jenks, Jesper Johansson, Brandon B. Low, Spencer Proffit, Tushaar Sethi. Invention is credited to Waylon Brunette, Jason Cetina, Hanson Char, Jason Jenks, Jesper Johansson, Brandon B. Low, Spencer Proffit, Tushaar Sethi.
United States Patent |
8,892,868 |
Jenks , et al. |
November 18, 2014 |
Hardening tokenization security and key rotation
Abstract
A method of using a hardware security module and an adjunct
application programming interface to harden tokenization security
and encryption key rotation is disclosed. In various embodiments,
the method comprises receiving encrypted data at a processor of a
computer system, decrypting the encrypted data to cleartext in the
processor, and issuing a unique token associated with the data.
Inventors: |
Jenks; Jason (Lynnwood, WA),
Sethi; Tushaar (Seattle, WA), Low; Brandon B. (Seattle,
WA), Cetina; Jason (Shoreline, WA), Johansson; Jesper
(Woodinville, WA), Brunette; Waylon (Seattle, WA), Char;
Hanson (Mercer Island, WA), Proffit; Spencer (Vashon,
WA) |
Applicant: |
Name |
City |
State |
Country |
Type |
Jenks; Jason
Sethi; Tushaar
Low; Brandon B.
Cetina; Jason
Johansson; Jesper
Brunette; Waylon
Char; Hanson
Proffit; Spencer |
Lynnwood
Seattle
Seattle
Shoreline
Woodinville
Seattle
Mercer Island
Vashon |
WA
WA
WA
WA
WA
WA
WA
WA |
US
US
US
US
US
US
US
US |
|
|
Assignee: |
Amazon Technologies, Inc.
(Reno, NV)
|
Family
ID: |
51870289 |
Appl.
No.: |
12/242,746 |
Filed: |
September 30, 2008 |
Current U.S.
Class: |
713/153; 713/185;
726/6; 713/182; 726/9 |
Current CPC
Class: |
G06Q
20/385 (20130101); H04L 9/0877 (20130101); H04L
63/06 (20130101); H04L 9/0866 (20130101); H04L
9/0894 (20130101); G06Q 20/3226 (20130101); G06Q
20/3823 (20130101); H04L 29/06 (20130101); H04L
2463/062 (20130101); G06Q 20/409 (20130101); H04L
2209/127 (20130101) |
Current International
Class: |
H04L
29/06 (20060101) |
Field of
Search: |
;713/150,153,168,172,182,185 ;726/6,9,10,20 |
References Cited
[Referenced By]
U.S. Patent Documents
Foreign Patent Documents
|
|
|
|
|
|
|
WO 2007034184 |
|
Mar 2007 |
|
WO |
|
Other References
Improving Memory Encryption Performance in Secure Processors; NIST
2001 ; William Mehuron. cited by examiner .
Improving Memory Encryption Performance in Secure Processors; IEEE
2005; Yang et al. cited by examiner .
Wikipedia--Bloom Filter. Last updated Apr. 8, 2010, Retrieved
online Apr. 20, 2010 at
http://en.wikipedia.org/wiki/Bloom.sub.--filter, 25 pages. cited by
applicant.
|
Primary Examiner: Holder; Bradley
Assistant Examiner: Kabir; Jahangir
Attorney, Agent or Firm: Lee & Hayes, PLLC
Claims
What is claimed is:
1. A method of tokenization of payment instrument data in a
hardware security module (HSM) implemented at least partially by a
computer, the method comprising: receiving, from a client computer
system, a first encrypted secret at a tokenization server, wherein
the first encrypted secret is an encryption of a cleartext secret
that comprises information associated with a user of the client
computer system; processing a request for tokenization using an
application programming interface (API) of the HSM; decrypting the
first encrypted secret inside the HSM to generate the cleartext
secret, such that the cleartext secret resulting from the
decryption is present only within the HSM; subsequent to decrypting
the first encrypted secret inside the HSM to generate the cleartext
secret, modifying the cleartext secret by marking up the cleartext
secret to incorporate information indicating that the cleartext
secret includes at least one of: (a) personal information related
with a financial account of the user, or (b) financial information
associated with the user; subsequent to modifying the cleartext
secret, encrypting the modified cleartext secret within the HSM
using an HSM key and a set of encryption rules to create a second
encrypted secret; assigning a token to the second encrypted secret,
wherein the token acts as a database record identifier of the
modified cleartext secret; sending the token to a storage device
external to the HSM; and sending the second encrypted secret to the
storage device external to the HSM.
2. The method of claim 1, wherein the personal information,
financial information, or both, associated with the user comprises
one of a credit card number, bank routing number, and a social
security number.
3. The method of claim 1, further comprising permitting data to be
cleartext only within the HSM.
4. The method of claim 1, wherein the HSM key used is based on a
category of data of the cleartext secret.
5. The method of claim 1, further comprising: generating the HSM
key from a combination of a hardware generated master key and an
externally input key.
6. A system comprising: a computer server having a processor and
memory; a dedicated processor within the server, wherein the
dedicated processor comprises dedicated memory to form a hardware
security module (HSM) within which encrypted data is decrypted to
generate cleartext, and wherein the dedicated processor is
configured to: decrypt the encrypted data into cleartext, such that
the cleartext resulting from the decryption is present only within
the HSM of the dedicated processor; subsequent to decrypting the
encrypted data into cleartext, modifying the cleartext by marking
up the cleartext to incorporate information indicating that the
cleartext secret includes at least one of: (a) personal information
related with a financial account of a user, or (b) financial
information associated with the user; based at least in part on a
category of data included in the cleartext, select a HSM key, and
subsequent to modifying the cleartext, encrypt the modified
cleartext using the selected key to create a second encrypted
secret; a token assignment module configured to receive data from
the dedicated processor and issue a token, wherein the token acts
as a database record identifier of the modified cleartext; and a
storage device external to the HSM is configured to store the token
and the second encrypted secret.
7. The system of claim 6, wherein the token assignment module is
outside the dedicated processor.
8. The system of claim 6, further comprising an application
programming interface executable by the computer server and
configured to access functions within the dedicated processor.
9. The system of claim 6, wherein the key is stored within the
dedicated processor, and wherein the key is generated for a
particular set of data being processed.
10. The system of claim 6, wherein the key comprises a combination
of a hardware generated master key and an externally provided
key.
11. The system of claim 6, wherein: the token assignment module is
outside the secured area.
12. The system of claim 11, wherein the secured area comprises the
dedicated processor.
13. A non-transitory computer-readable storage medium storing
instructions that when executed by one or more processor of a
computer system causes the system to: receive encrypted data at a
cryptographic processor of the computer system, decrypt the
encrypted data to cleartext in the cryptographic processor, wherein
the cleartext comprises information associated with a user of a
client computer system, wherein the cleartext resulting from the
decryption is present only within a hardware security module (HSM)
of the system, subsequent to decrypting the encrypted data to
cleartext, modifying the cleartext by marking up the cleartext to
incorporate information indicating that the cleartext secret
includes at least one of: (a) personal information related with a
financial account of the user, or (b) financial information
associated with the user based at least in part on a category of
data included in the cleartext, select a HSM key, subsequent to
modifying the cleartext, encrypt the modified cleartext using the
selected key to create a second encrypted secret, issue a unique
token associated with the cleartext, wherein the token acts as a
database record identifier of the modified cleartext, send the
token to a storage device external to the HSM, and send the second
encrypted secret to the storage device external to the HSM.
Description
BACKGROUND
Organizations utilize a variety of methods to safeguard
confidential information such as payment instrument data. Among
these are encryption of data and the use of tokens to represent
confidential information. However, current methods have
difficulties scaling to high availability systems with large
amounts of encrypted data. Rotating encryption keys for encrypted
data can require either taking a system offline or duplicating data
and taking the duplicate system offline while rotation occurs. With
large amounts of data in a high availability environment, taking
the system offline or utilizing duplicate hardware may not be
viable. Furthermore, cryptographic operations taking place on a
server may be vulnerable to compromise, rendering confidential
information accessible.
Given the rapid increase in online commerce, online organizations
demand hardened and more rapid processing of encryption functions
including encryption key rotation.
BRIEF DESCRIPTION OF THE DRAWINGS
The detailed description is set forth with reference to the
accompanying figures. In the figures, the left-most digit(s) of a
reference number identifies the figure in which the reference
number first appears. The use of the same reference numbers in
different figures indicates similar or identical items.
FIG. 1 is an illustrative schematic diagram of a client in
communication with an organization utilizing a hardware security
module (HSM) and an adjunct application programming interface
(API).
FIG. 2 is an illustrative schematic of an encryption server
comprising a computer server and an HSM.
FIG. 3 is a flowchart of an illustrative method of creating tokens
and encrypting data using the encryption server described in FIG.
2.
FIG. 4 is an illustrative schematic of the Adjunct API and the HSM
showing elements of both.
FIG. 5 is an illustrative schematic of a ciphertext-to-ciphertext
encryption function called by the adjunct API and implemented in
the HSM.
FIG. 6 is a flowchart of an illustrative method of
ciphertext-to-ciphertext encryption function using an Adjunct API
and an HSM.
FIG. 7 is a flowchart of an illustrative method of handling
insertion of new records during encryption key rotation utilizing a
ciphertext-to-ciphertext encryption function in an Adjunct API and
HSM.
DETAILED DESCRIPTION
Overview
Organizations with high availability servers seek to provide access
to their services and data with minimal or no downtime. Providing
that high availability while securing data using encryption or
tokens or both, using conventional techniques, can be highly
demanding of computational, financial, physical, and environmental
resources.
This disclosure describes a variety of techniques for using a
hardware security module (HSM) and an adjunct application
programming interface (API) to provide access to cryptographic and
tokenization functions within the HSM. Improvements in execution
time and accessibility of the cryptographic functions are realized,
and confidential data is present in cleartext only within the
hardened environment of the HSM, further enhancing security.
Illustrative System Architecture
FIG. 1 is an illustrative schematic diagram of a system 100,
including a client computer system ("client") 102 in communication
with an encryption server 104 utilizing a adjunct application
programming interface (API) 106 and a hardware security module
(HSM) 108.
The client computer system 102 may contain a processor or multiple
processors and a memory for executing a browser or other
application which accepts a cleartext secret 110 from the user.
Client computer system 102, while illustrated as a workstation and
separate physical device, may also be another computer server,
server cluster, or other information processing device or
virtualized implementation of an information processing device
which utilizes the services of the encryption server 104. Client
computer system 102 may also be located within organization 112.
Client computer system 102 may be an application or virtualized
computer executing on the encryption server itself.
In operation, a user enters a clear text secret 110, here the
example string "SARA." The client computer system 102 receives the
clear text secret 110.
The clear text secret is encrypted, and a client encrypted secret
114 is output from the client computer system 102, now with an
example ciphertext string of "$KA4." The client encrypted secret
114 may be encrypted using a variety of cryptographic methods
including, but not limited to, symmetric key and public-key
cryptography.
A network 116 communicates the client encrypted secret 114 to an
organization 112. The network 116 represents any one or combination
of multiple different types of networks, such as cable networks,
the Internet, wired, wireless, or other local or wide area
networks, as well as a physical exchange of data stored on
memory.
The organization 112 may range from for-profit endeavors to
government agencies, and may encompass a system ranging from a
single server at one geographic location to an array of many
servers distributed across the world.
An encryption server 104 of the organization 112 is depicted. The
encryption server 104 contains one or more processors and memory.
The encryption server 104 receives the client encrypted secret 114,
and utilizes an adjunct application programming interface (API) 106
to communicate with a HSM 108 of the encryption server.
An application programming interface (API) is a set of functions,
procedures or classes that an operating system, library or service
provides to support requests made by computer programs stored in
memory and executing on a processor. Here, the Adjunct API provides
the programs executing on the encryption server processor with
callable hooks to easily utilize the features available within the
HSM.
The hardware security module (HSM) may be implemented as a plug-in
card within a host computer system or a physically external device
(such as one connected via Universal Serial Bus (USB), Small
Computer System Interface (SCSI), fibre channel, Ethernet, and the
like). A HSM may include a tamper resistant physical package, a
general purpose processor executing cryptographic functions or
processor optimized for cryptographic operations. An HSM may have
dedicated memory onboard, provide secure storage of keys, and have
functionality for code signing to enforce access control lists
(ACL), or any combination of these. The HSM provides a hardened
environment for cryptographic operations. Among others, two
suitable HSMs include the nShield.TM. device from nCipher.TM.
Corporation Ltd of Cambridge, United Kingdom and the Luna.RTM.
device from SafeNet.RTM. Inc. of Belcamp, Md., United States.
Within the HSM 108, the client encrypted secret 114 is decrypted to
render cleartext secret 110. In this example, client encrypted
secret 114 having a ciphertext string of "$KA4" is decrypted to the
cleartext string "SARA." A more detailed description of the Adjunct
API functions and tokenization follow.
A database server 118 in communication with the encryption server
104 receives an HSM-encrypted secret 120 version of the cleartext
secret 110, and stores it along with a token 122 associated with
the cleartext secret 110. The database server 118 contains one or
more processors and memory. While shown as being external to the
encryption server 104, the database server 118 may be implemented
within the encryption server, or on the same physical device as the
encryption server using virtualization. Also, while database server
118 is described as being part of the organization 112, in other
instances, database servers may be located or administered by a
third party, or both, such as a credit card company, bank, or other
entity.
All of the computer systems described herein including client
computer system 102, encryption server 104, the HSM 108, and
database server 118 may contain a processor as well as memory
including, but not limited to, RAM, ROM, EEPROM, flash memory or
other memory technology, CD-ROM, digital versatile disks (DVD) or
other optical storage, magnetic cassettes, magnetic tape, magnetic
disk storage or other magnetic storage devices, or any other
computer-readable media which can be used to store the desired
information and which can be accessed by processor(s) of the
respective computing devices.
Illustrative Encryption Server
FIG. 2 is a schematic diagram 200 showing additional details of the
encryption server 104. As described above, a user enters a
cleartext secret 110, here with the example string "SARA." Computer
system 102 encrypts cleartext secret 110 to produce the client
encrypted secret 114. Cleartext secret 110 is communicated to the
encryption server 104.
The encryption server 104 contains several elements including an
operating system 202, Adjunct API 106, and HSM 108. Operating
system 202 may be any suitable operating system including, but not
limited to, Linux.RTM., UNIX.RTM., Microsoft Corporation's
Microsoft Windows.RTM., Apple Corporation's Mac OS.RTM., Apple
Corporation's Mac OS X.RTM., and Wind River Systems Inc.'s
VxWorks.RTM.. The operating system 202 manages the resources of the
computer and acts as a host to an application program. The HSM may
also have a dedicated operating system as well.
The Adjunct API 106 is in communication with the operating system
202 and the hardware security module 108. The Adjunct API 106, as
described above, provides the programs executing on the encryption
server processor with callable hooks to easily utilize the features
available within the HSM.
Decryption module 204 decrypts client encrypted secret 114, here
example ciphertext string "$KA4." Resulting cleartext secret 110
string "SARA" is processed. Processing of cleartext secret 110 may
include assigning a token, marking up the cleartext, encrypting, or
a combination of these elements.
A markup cleartext module 206 may add information regarding the
type of data the cleartext embodies, i.e., that this is a credit
card number, bank routing number, social security number, etc., to
the cleartext.
The HSM encryption module 208 receives the marked-up cleartext from
markup cleartext module 206.
An encryption rule module 210 selects and enforces pre-defined
cryptographic parameters for the encryption based on pre-defined
parameters including which of the available HSM private keys to
use.
After selection by the encryption rules module 210, the encryption
module 208 uses an HSM private key 212 to encrypt the marked-up
cleartext data to produce the HSM-encrypted secret 120. In this
example, the ciphertext string "#ti3rn@nL" results. HSM-encrypted
secret 120 may be sent out of the HSM for storage in the database
server 118.
The token assignment module 214 within the encryption server 104
assigns HSM-encrypted secret 120 a token 122. A token may also be
assigned to marked-up text or non-marked-up text. A token may be
used to refer to a piece of confidential data, but the token itself
is not necessarily confidential, and may not even be encrypted. For
example, a token may simply be a database record identifier, which
refers to a credit card number. Thus, loss or compromise of token
data does not necessarily lead to a release of confidential data.
While token assignment module 214 is shown outside the hardware
security module 108, it may also be located within the Adjunct API
106 or operating system 202. HSM 108 sends token 122 out of the HSM
for storage in database server 118.
FIG. 3 is a flowchart of an illustrative method 300 of creating
tokens 122 and encrypting data using an HSM 108, such as that
described in FIG. 2. The method 300 has been described in the
context of the systems of FIGS. 1 and 2. However, the method 300
need not necessarily be performed using the system described in
FIGS. 1 and 2 and may be formed using other systems. Moreover, the
systems described in FIGS. 1 and 2 are usable to perform different
methods.
At 302, an encryption server receives an encrypted secret 114. The
encrypted secret 114 may be received via a network 116 or from
another application or HSM 108 running on the encryption server
104.
At 304, the encryption server 104 processes a request for
tokenization 214 in the adjunct API 106. At 306, after passing the
encrypted secret 114 to the HSM 108, the HSM 108 decrypts 204 the
encrypted secret 114 within the HSM 108, producing cleartext 110 of
the secret.
At 308, the cleartext secret 110 may be marked up 206. Markup may
take place to provide additional information for later processing
about the nature of the cleartext secret 110. For example, the
cleartext secret 110 may be prepended with a particular string to
indicate that the cleartext secret 110 is a credit card number,
among other types of information. At 310, the cleartext secret 110
is encrypted 208 using encryption rules 210 present within the HSM
108 and using the HSM private key 212 set forth in those rules. The
encryption rules may set forth roles or define particular
categories of data that a requesting client may access. For
example, a rule may allow client Albert to access credit card
numbers encrypted with Albert's assigned encryption key, but not
bank account numbers encrypted with the same key. These rules and
their associated permissions may be stored within the HSM as
well.
At 312, the HSM-encrypted secret 120 is sent from the HSM 108 to
the database 118 for storage. While encrypted secret 120 is
depicted as being generated in the HSM, encrypted secret 120 may
also be generated by another HSM or by a non-HSM encryption
method.
At 314, a cleartext secret 110 is assigned a token 122. At 316, the
HSM sends the token 122 to the database 118 storing that
information. This database 118 may be on the encryption server 104,
or stored on a database server 118.
Certain acts in method 300 need not be performed in the order
described, may be modified and/or may be omitted entirely,
depending on the circumstances. For example, the assignment of a
token shown at 314 may occur before the markup of the cleartext
secret.
FIG. 4 is an illustrative schematic diagram 400 of the Adjunct API
106 and the HSM 108 showing elements of both.
In one example, FIG. 4 depicts functions available within the
Adjunct API 106. A token assignment module 214 is available. A
ciphertext-to-ciphertext encryption module 402 is available, and
may be used to rotate encryption keys, as described later. A
validation data module 404 is available for validation of payment
instrument data, such as credit card numbers. A get un-marked up
version of cleartext secret module 406 is available. This module
retrieves an encrypted secret, decrypts the encrypted secret within
the HSM and removes the markup data. This module may be used to
facilitate generating settlement data for third-party consumption.
For example, when sending credit card numbers to a bank or
processor for settlement, the markup information is irrelevant to
the bank as they assume they are receiving credit card numbers, and
not social security numbers. This module may provide cleartext to
the third party or re-encrypt the data using a key recognized by
the third party.
A get BIN range module 408 is available in the Adjunct API 106.
Several types of payment options may be used by an organization,
including credit cards, debit cards, charge cards, stored-value
cards, electronic benefit transfer cards, and the like. In the
example of credit cards, the first six digits of these payment
options denote the Bank Identification Number (BIN) which
identifies the institution that issued the card to the card holder.
In several card processing situations production of BIN values for
cards may be useful. For example, during pre-verification prior to
submission to a processor. The pre-verification may include data
validation such as Luhn/mod10 checks, checksums, BIN range checks,
or length checks.
The get BIN range module 408 may also be adapted to provide data
for use with other payment types. For example, it may provide the
International Bank Account Number (IBAN) values for bank account
numbers.
The HSM is depicted at 108. Several functions are available within
the HSM. For example, the markup cleartext secret for storage
module 206, the HSM encryption module 208, and the encryption rules
module 210 are available.
Also within the HSM is HSM private key 212. The HSM private key 212
may be composed of a hardware generated master key 410, or an
external key 412, or both. The hardware generated master key 410
may be present within the HSM. Typically each hardware generated
master key is unique among all other encryption keys, and is not
accessible outside of the HSM.
The external key 412 may be a physical device such as a smartcard,
USB device, or other memory containing a cryptographic key. For
example, a quorum of external key smartcards may be required at the
HSM to access administrative functions such as altering the
hardware generated master key 410. However, the external key may
also be a string entered into the HSM for use.
Encryption keys needed for cryptographic operations, or portions
thereof, may also be stored externally and loaded into the HSM.
Encryption keys need not be associated with a physical device
attached to the HSM, such as a smartcard.
FIG. 5 is an illustrative schematic diagram 500 of the
ciphertext-to-ciphertext encryption function in the adjunct API and
implemented in the HSM.
A ciphertext-to-ciphertext encryption function 502 is called within
the Adjunct API 106. Ciphertext-to-ciphertext encryption may be
used to rotate encryption keys, or translate between encryption
keys to enable exchange of data.
Rotation of encryption keys involves re-encrypting a secret with a
different encryption key. Best practices for safeguarding
confidential data in many organizations require changing encryption
keys on a regular schedule or in the event of a breach of an
encryption key.
The ciphertext-to-ciphertext encryption module 402 in the API
communicates with the HSM 108. An HSM-encrypted secret 120 with the
example ciphertext string of "#ti3rn@nL" is received 504 in the HSM
108. While encrypted secret 120 is depicted as being generated in
the HSM, encrypted secret 120 may also be generated by another HSM
or by a non-HSM encryption method.
The HSM-encrypted secret is decrypted 204 within the HSM 108,
resulting in cleartext secret 110, for example string "SARA." Once
in cleartext, the markup cleartext module 206 and encryption rules
module 210 may be utilized.
HSM encryption module 208 utilizes a first HSM private key 210 or a
second HSM private key 506, or both to encrypt the cleartext. The
selection of first HSM private key 210 or second HSM private key
506 is discussed in more depth below.
HSM encryption module 208 outputs second HSM-encrypted secret 508,
with an example ciphertext string of "2k@el*n". The token
assignment module 214 may also be utilized.
Second HSM-encrypted secret 508 is output 510 for storage in
database server 118. The database may maintain an association
between the HSM-encrypted secret and the second HSM-encrypted
secret in the database stored on the database server. Here
HSM-encrypted secret 120 and second HSM-encrypted secret 508 both
encrypt the same cleartext value, in this example string
"SARA."
A flag 512 maintained in the database indicates which secret is in
currently in use by the system. The flag may be implemented at a
system level.
FIG. 6 is a flowchart of an illustrative method 600 of
ciphertext-to-ciphertext encryption function using an Adjunct API
and an HSM.
At 602, a ciphertext-to-ciphertext encryption function 402 is
called 502 in the adjunct API 106. At 604, an encryption server 104
determines whether a first HSM-encrypted secret such as 120 is
present in a database 118. While encrypted secret 120 is depicted
as being generated in the HSM, encrypted secret 120 may also be
generated by another HSM or by a non-HSM encryption method.
If a first HSM-encrypted secret 120 is not present in the database
118 (for example, only a second HSM-encrypted secret 504 is
present), then the method 600 proceeds to 606. If a first
HSM-encrypted secret 120 is present in the database then the method
proceeds to 608.
At 606, no first HSM-encrypted secret 120 is present, and a second
HSM-encrypted secret 504 is read, decrypted 204, encrypted 208
using the first HSM private key 210, and the HSM-encrypted secret
120 is sent to the database to backfill the missing entry in the
database. If a first HSM-encrypted secret 120, at 608, the first
HSM-encrypted secret 120 is read from the database 118.
At 610 this first HSM-encrypted secret is decrypted within the HSM
to produce cleartext 110. At 612, the cleartext 110 is encrypted
208 using a second HSM private key 506. This encryption 208 may be
subject to the encryption rules module 210 discussed previously. At
614, the second HSM-encrypted secret 504 is sent from the HSM 108
to the database 118.
At 616, an encryption server, such as encryption server 104,
determines whether all encrypted secrets are encrypted using the
second HSM private key 506 and are stored in the database 118. If
not all encrypted secrets are encrypted using a second HSM private
key and stored in the database, then the method 600 proceeds to
602. If all encrypted secrets are encrypted using the second HSM
private key 506 and are stored in the database 118, then 618 takes
place.
At 618, all encrypted secrets are encrypted using the second HSM
private key 506 and are stored in the database 118, and a flag 512
indicating that the second HSM-encrypted secret 508 is in use is
updated.
At 620, the first HSM-encrypted keys 120 in the database 118 may be
wiped as they have all been superseded by the second HSM-encrypted
keys 508.
The first HSM-encrypted secret 120 and second HSM-encrypted secret
508 may be encrypted 208 by a different HSM, or may be encrypted by
a device or method which is not an HSM, but can be read by the
HSM.
Certain acts in method 600 need not be performed in the order
described, may be modified and/or may be omitted entirely,
depending on the circumstances. For example, the reading of the
first HSM-encrypted secret 120 from the database 118 in 608 may be
attempted before the determination at 604 is made.
FIG. 7 is a flowchart of an illustrative method 700 of handling
insertion of new records during encryption key rotation utilizing a
ciphertext-to-ciphertext encryption function 402 in an adjunct API
106 and HSM 108.
At 702, a new record has been added to the database while a
ciphertext-to-ciphertext encryption function 500 is in progress.
For example, this may occur during key rotation of a very large
database.
At 704, the new record is decrypted 204 within the HSM 108 if
necessary to obtain cleartext 110. At 706, the cleartext is
encrypted 208 within the HSM using the first HSM private key 210 to
create a first HSM-encrypted secret 120. This is necessary because
at this time, the flag 512 indicating which encrypted secret is in
use still refers to the first HSM-encrypted secret 120. At 708, the
first HSM-encrypted secret 120 is output to the database 118.
At 710, the cleartext 110 within the HSM 108 is encrypted 208 using
the second HSM private key 506 to create the second HSM-encrypted
secret 508. At 712, the second HSM-encrypted secret 508 is output
to the database 118.
Certain acts in method 700 need not be performed in the order
described, may be modified and/or may be omitted entirely,
depending on the circumstances. For example, the method 700 may
output both the first HSM-encrypted secret 120 and the second
HSM-encrypted secret 508 to the database 118 in a single
operation.
Moreover, any of the acts of any of the methods described herein
may be implemented at least partially by a processor or other
computing device based on instructions stored on one or more
computer-readable media. Computer-readable media can be any
available media that can be accessed by a preprocessing system,
display device, and/or digital work, as appropriate. By way of
example, and not limitation, computer-readable media may comprise
volatile and nonvolatile, removable and non-removable media
implemented in any method or technology for storage of information
such as computer-readable instructions, data structures, program
modules or other data. Computer-readable media includes, but is not
limited to, RAM, ROM, EEPROM, flash memory or other memory
technology, CD-ROM, digital versatile disks (DVD) or other optical
storage, magnetic cassettes, magnetic tape, magnetic disk storage
or other magnetic storage devices, or any other medium which can be
used to store the desired information and which can accessed by a
processor. Combinations of the any of the above should also be
included within the scope of computer-readable media.
CONCLUSION
Although the subject matter has been described in language specific
to structural features and/or methodological acts, it is to be
understood that the subject matter defined in the appended claims
is not necessarily limited to the specific features or acts
described. Rather, the specific features and acts are disclosed as
illustrative forms of implementing the claims. For example, the
methodological acts need not be performed in the order or
combinations described herein, and may be performed in any
combination of one or more acts.
* * * * *
References