US20170149565A9 - Format-preserving cryptographic systems - Google Patents
Format-preserving cryptographic systems Download PDFInfo
- Publication number
- US20170149565A9 US20170149565A9 US13/517,513 US201213517513A US2017149565A9 US 20170149565 A9 US20170149565 A9 US 20170149565A9 US 201213517513 A US201213517513 A US 201213517513A US 2017149565 A9 US2017149565 A9 US 2017149565A9
- Authority
- US
- United States
- Prior art keywords
- string
- format
- block cipher
- key
- encrypted
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/22—Payment schemes or models
-
- H04L9/28—
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6209—Protecting access to data via a platform, e.g. using keys or access control rules to a single file or object, e.g. in a secure envelope, encrypted and accessed using a key, or with access control rules appended to the object itself
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
- H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
- H04L9/0625—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation with splitting of the data block into left and right halves, e.g. Feistel based algorithms, DES, FEAL, IDEA or KASUMI
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/088—Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
- H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
- H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/24—Key scheduling, i.e. generating round keys or sub-keys for block encryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/34—Encoding or coding, e.g. Huffman coding or error correction
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
Definitions
- This invention relates to cryptography and more particularly, to preserving data formats during encryption and decryption operations.
- Cryptographic systems are used to secure data in a variety of contexts. For example, encryption algorithms are used to encrypt sensitive information such as financial account numbers, social security numbers, and other personal information. By encrypting sensitive data prior to transmission over a communications network, the sensitive data is secured, even if it passes over an unsecured communications channel. Sensitive data is also sometimes encrypted prior to storage in a database. This helps to prevent unauthorized access to the sensitive data by an intruder.
- AES Advanced Encryption Standard
- DES Data Encryption Standard
- Encrypting entire files of data can be an effective technique for securing large quantities of data.
- bulk encryption of files can be inefficient and cumbersome because it is not possible to selectively access a portion of the encrypted data in an encrypted file. Even if an application only needs to have access to a portion of the data, the entire file must be decrypted. Without the ability to selectively decrypt part of a file, it can be difficult to design a data processing system that provides different levels of data access for different application programs and for different personnel.
- Conventional encryption techniques can, however, significantly alter the format of a data item. For example, encryption of a numeric string such as a credit card number may produce a string that contains non-numeric characters or a string with a different number of characters. Because the format of the string is altered by the encryption process, it may not be possible to store the encrypted string in the same type of database table that is used to store unencrypted versions of the string. The altered format of the encrypted string may therefore disrupt software applications that need to access the string from a database. The altered format may also create problems when passing the encrypted string between applications. Because of these compatibility problems, organizations may be unable to incorporate cryptographic capabilities into legacy data processing systems.
- format-preserving encryption and decryption algorithms are provided.
- a plaintext string such as a string of letters and digits can be encrypted to produce ciphertext composed of letters and digits in the same format as the original plaintext string.
- ciphertext can be converted into plaintext in the same format as the ciphertext.
- the format-preserving encryption and decryption algorithms may be implemented using a block cipher.
- the block cipher may be applied to a plaintext string. If the resulting block cipher output does not correspond to a string that is in the same format as the original string, the block cipher can be applied one or more additional times. Once the block cipher output is format-compliant, the block cipher output can be used to produce the encrypted string. The block cipher may also be applied in this fashion during format-preserving decryption operations.
- Strings may be made up of characters. During format-preserving encryption and decryption operations, the strings may be converted to numeric values using an index. During these encoding operations, unique binary values may be produced for each string using a binary encoding function. The binary values that are produced may be operated upon using the block cipher.
- a string may have first and second plaintext parts.
- the first plaintext part may be encrypted using a first cryptographic key to produce first ciphertext.
- the first ciphertext may have the same format as the first plaintext part.
- Both the second plaintext part and the first ciphertext may be encrypted together using format-preserving encryption and a second cryptographic key to produce second ciphertext that is in the same format as first ciphertext and the second plaintext part.
- the ciphertext has the same format as the original string that is composed of the first and second plaintext parts.
- a first user may be provided with the first and second keys and a second user may be provided with the second key but not the first key. This allows the second user to access the second plaintext part but not the first plaintext part and allows the first user to access both the first and second plaintext parts.
- FIG. 1 is a diagram of an illustrative system environment in which cryptographic tools with format-preserving encryption and decryption features may be used in accordance with an embodiment of the present invention.
- FIG. 2 is a diagram showing how encryption and decryption engines preserve the format of a string in accordance with an embodiment of the present invention.
- FIG. 3 is a diagram of an illustrative format-preserving block cipher that may be used during data encryption and decryption in accordance with an embodiment of the present invention.
- FIG. 4 is a flow chart of illustrative steps that may be used in setting up format-preserving encryption and decryption engines for use in a data processing system of the type shown in FIG. 1 in accordance with an embodiment of the present invention.
- FIG. 5 is a flow chart of illustrative steps involved in using a format-preserving encryption engine to encrypt a data string in accordance with an embodiment of the present invention.
- FIG. 6 is a flow chart of illustrative steps involved in using a format-preserving decryption engine to decrypt a data string in accordance with an embodiment of the present invention.
- FIG. 7A is a flow chart of illustrative steps involved in generating a key that is based on an identifier in accordance with an embodiment of the present invention.
- FIG. 7B is a flow chart of illustrative steps involved in generating a key and storing the generated key with an association between the stored key and an identifier in accordance with an embodiment of the present invention.
- FIG. 8 is a flow chart of illustrative steps involved in requesting and obtaining a key from a key server in accordance with an embodiment of the present invention.
- FIG. 9 is a flow chart of illustrative steps involved in requesting and obtaining a key from a key server in accordance with another embodiment of the present invention.
- FIG. 10 is a flow chart of illustrative steps involved in requesting and obtaining a key from a key server in accordance with yet another embodiment of the present invention.
- FIG. 11 is a diagram showing how different parts of a data item can be divided into different plaintext parts and selectively encrypted in accordance with an embodiment of the present invention.
- FIG. 12 is a diagram showing how multiple keys may be used to provide selective access to different parts of a data item in accordance with an embodiment of the present invention.
- FIG. 13 is a flow chart of illustrative steps involved in using multiple keys to provide selective access to different part of a data item in accordance with an embodiment of the present invention.
- FIG. 14 is a diagram showing how a string may be represented as a unique binary value in accordance with an embodiment of the present invention.
- FIG. 15 is a diagram showing how a string format may be preserved when converting a string to a binary value in accordance with an embodiment of the present invention.
- FIG. 16 a flow chart of illustrative steps involved in using a format-preserving encryption engine to encrypt a data string represented using a unique binary value in accordance with an embodiment of the present invention.
- FIG. 17 is a flow chart of illustrative steps involved in using a format-preserving decryption engine to decrypt a data string represented using a unique binary value in accordance with an embodiment of the present invention.
- System 10 includes computing equipment 12 and communications network 14 .
- the computing equipment 12 may include one or more personal computers, workstations, computers configured as servers, mainframe computers, portable computers, etc.
- the communications network 14 may be a local area network or a wide area network such as the internet.
- System 10 may be used in processing data for one or more organizations.
- Computing equipment 12 may be used to support applications 16 and databases 18 .
- applications and databases may communicate with each other directly.
- applications 16 can communicate with each other and with databases 18 remotely using communications network 14 .
- an application 16 that is run on a computer in one country may access a database 18 that is located in another country or an application 16 running on one computer may use network 14 to transmit data to an application 16 that is running on another computer.
- Applications 16 may be any suitable applications, such as financial services applications, governmental record management applications, etc.
- the data that is handled by system 10 includes sensitive items such as individuals' addresses, social security numbers and other identification numbers, license plate numbers, passport numbers, financial account numbers such as credit card and bank account numbers, telephone numbers, email addresses, etc.
- sensitive items such as individuals' addresses, social security numbers and other identification numbers, license plate numbers, passport numbers, financial account numbers such as credit card and bank account numbers, telephone numbers, email addresses, etc.
- information such as individuals' names may be considered sensitive.
- a credit card company maintains a database 18 of account holders.
- the database lists each account holder's name, address, credit card number, and other account information. Representatives of the credit card company may be located in many different geographic locations.
- the representatives may use various applications 16 to access the database. For example, a sales associate may retrieve telephone numbers of account holders to make sales calls using one application, whereas a customer service representative may retrieve account balance information using another application. Automated applications such as error-checking housekeeping applications may also require access to the database.
- sensitive data may need to be encrypted. Encryption operations may be performed before data is passed between applications 16 or before data is stored in a database 18 . Because various applications may need to access different types of data, the system 10 preferably allows data to be selectively encrypted. As an example, each of the telephone numbers and each of the credit card numbers can be individually encrypted using separate cryptographic keys. With this type of selective encryption arrangement, applications that require access to telephone numbers need not be provided with access to credit card numbers and vice versa.
- applications 16 may be provided with encryption and decryption engines.
- an application 16 that accesses a database 18 over a communications network 14 may have an encryption engine for encrypting sensitive data before it is provided to the database 18 and stored and may have a decryption engine for use in decrypting encrypted data that has been retrieved from database 18 over communications network 14 .
- a first application may have an encryption engine for encrypting sensitive data before passing the encrypted data to a second application.
- the second application may have a decryption engine for decrypting the encrypted data that has been received from the first application.
- any suitable technique may be used to provide applications 16 with encryption and decryption capabilities.
- the encryption and decryption engines may be incorporated into the software code of the applications 16 , may be provided as stand-alone applications that are invoked from within a calling application, or may be implemented using a distributed arrangement in which engine components are distributed across multiple applications and/or locations.
- Key server 20 may be used to generate and store cryptographic keys that are used by the encryption and decryption engines.
- Key server 20 may include policy information 22 that key server 20 uses in determining whether to fulfill key requests.
- policy information 22 may include a set of policy rules that dictate that keys should only be released if they have not expired and if the key requester's authentication credentials are valid.
- an application requests a key from key server 22 .
- the application provides authentication credentials to the key server 20 .
- the key server 20 provides the authentication credentials to authentication server 24 .
- Authentication server 24 verifies the authentication credentials and provides the results of the verification operation to the key server over communications network 14 . If the key requester is successfully authenticated and if the key server determines that the expiration period has not yet expired, the key server can satisfy the key request by providing the requested key to the application over a secure path in network 14 (e.g., over a secure sockets layer link). Other authentication techniques and key request arrangements may be used if desired.
- the data handled by the applications 16 and databases 18 of system 10 is represented digitally.
- the data includes strings of characters (i.e., names, addresses, account numbers, etc.).
- an encryption engine 26 encrypts unencrypted strings of characters (sometimes referred to as plaintext) into encrypted strings of characters (sometimes referred to as ciphertext).
- a decryption engine 28 decrypts encrypted strings of characters to form unencrypted strings of characters.
- the data strings that are handled in a typical data processing system have defined formats. For example, an identification number may be made up of three letters followed by ten digits.
- the encryption and decryption engines of the present invention are able to encrypt and decrypt strings without changing a string's format (i.e., so that a plaintext identification number made up of three letters followed by ten digits would be encrypted to form corresponding ciphertext make up of three letters and ten digits).
- the ability to preserve the format of a data string greatly simplifies system operations and allows systems with legacy applications to be provided with cryptographic capabilities that would not be possible using conventional techniques.
- Conventional encryption algorithms can alter the format of a string during encryption, so that it becomes difficult or impossible to use the encrypted version of the string. For example, it may be impossible to store a conventionally-encrypted credit card number in a database table that has been designed to handle strings that contain only digits.
- data stings can be encrypted and decrypted while preserving the format of the strings.
- Credit card numbers generally have between 13 and 18 digits.
- the format for a particular valid credit card number might require that the credit card number have 16 digits. This type of credit card number will be described as an example.
- an unencrypted credit card number such as “4408 0412 3456 7890” may be transformed into credit-card-formatted ciphertext such as “4417 1234 5678 9114” and during decryption, the ciphertext “4417 1234 5678 9114” may be transformed back into the unencrypted credit card number “4408 0412 3456 7890”.
- the value of a valid sixteenth digit in a credit card number is formed by performing a checksum operation on the first 15 digits using the so-called Luhn algorithm. Any single-digit error in the credit card number and most adjacent digit transpositions in the credit card number will alter the checksum value, so that data entry errors can be identified.
- the encryption engine 26 can compute a new checksum value using the first 15 digits of the ciphertext.
- the new checksum digit can be used in the ciphertext or, if desired, policy information such as a validity period may be embedded within the checksum digit by adding an appropriate validity period index value to the new checksum value.
- a validity period is embedded within a checksum digit, the resulting modified checksum value will generally no longer represent a valid checksum for the string.
- applications in system 10 will be able to retrieve the validity period information from the checksum digit and will be able to use the extracted validity period information in obtaining a decryption key from key server 20 ( FIG. 1 ).
- This type of embedding operation may be used to store any suitable information within encrypted data.
- the use of credit card numbers and, more particularly, the use of validity period information that has been embedded within the checksum digits of credit card numbers are described herein as examples.
- encryption and decryption engines 26 and 28 of FIG. 2 can preserve a desired format for a string during encryption and decryption operations, sensitive data can be secured without requiring entire files to be encrypted.
- the encryption and decryption engines 26 and 28 preferably use index mappings to relate possible character values in a given string position to corresponding index values in an index. By mapping string characters to and from a corresponding index, the encryption and decryption engines 26 and 28 are able to perform encryption and decryption while preserving string formatting.
- an index mapping may be formed using a table having two columns and a number of rows.
- the first column of the mapping corresponds to the potential character values in a given string position (i.e., the range of legal values for characters in that position).
- the second column of the mapping corresponds to an associated index.
- Each row in the mapping defines an association between a character value and a corresponding index value.
- the string being encrypted has first, fifth, sixth, and seventh string characters that are digits and second, third, and fourth characters that are uppercase letters.
- the possible character values in the first, fifth, sixth, and seventh character positions within the plaintext version of the string might range from 0 to 9 (i.e., the first character in the string may be any digit from 0 through 9, the fifth character in the string may be any digit from 0 to 9, etc.).
- the possible character values in the second, third, and fourth positions in the string range from A to Z (i.e., the second character in the unencrypted version of the string may be any uppercase letter in the alphabet from A to Z, the third character in the unencrypted version of the string may be any uppercase letter from A through Z, etc.).
- the index mapping in this type of situation may map the ten possible digit values for the first, fifth, sixth, and seventh string characters into ten corresponding index values (0 . . . 9).
- 26 possible uppercase letter values (A . . . Z) may be mapped to 26 corresponding index values (0 . . . 25).
- not all characters have the same range of potential character values. If there are two ranges of potential character values, two index mappings may be used, each of which maps a different set of possible character values to a different set of index values. If there are three ranges of potential character values within the string, three index mappings may be used. For example, a first index mapping may relate a digit character to a first index, a second index mapping may relate a uppercase letter character to a second index, and a third index mapping may relate an alphanumeric character to a third index. In strings that contain a larger number of different character types, more index mappings may be used.
- a string contains a number of characters N.
- the potential character values in the string are related to corresponding index values using index mappings.
- An index mapping is created for each character.
- the indexes used to represent each character may have any suitable size. For example, an index containing 52 index values may be associated with string characters with character values that span both the uppercase and lowercase letters. Because not all of the characters typically have the same range of potential character values, there are generally at least two different index mappings used to map character values in the string to corresponding index values. In a string with N characters, N index mappings are used, up to N of which may be different index mappings.
- Any suitable cryptographic formulation may be used for the format-preserving encryption and decryption engines 26 and 28 , provided that the cryptographic strength of the encryption algorithm is sufficiently strong.
- encryption engine 26 and decryption engine 28 use a cryptographic algorithm based on the well known Luby-Rackoff construction.
- the Luby-Rackoff construction is a method of using pseudo-random functions to produce a pseudo-random permutation (also sometimes referred to as a block cipher).
- a diagram showing how encryption engine 26 and decryption engine 28 may be implemented using the Luby-Rackoff construction is shown in FIG. 3 .
- an unencrypted string is divided into two portions.
- the unencrypted string may be divided into two portions using any suitable scheme.
- the string may be divided into odd and even portions by selecting alternating characters from the string for the odd portion and for the even portion.
- the unencrypted string is divided into two portions by splitting the string into left and right halves.
- the first half of the unencrypted string is labeled “L 1 ” and the second half of the unencrypted string is labeled “R 1 ”.
- the unencrypted string halves L 1 and R 1 are processed to form corresponding encrypted string halves L 3 and R 2 .
- decryption operations with decryption engine 28 processing flows from the bottom of FIG. 3 towards the top, so that encrypted string halves L 3 and R 2 are decrypted to produce unencrypted halves L 1 and R 1 . Processing occurs in three rounds 40 , 42 , and 44 .
- the operations of round 40 are performed first, the operations of round 42 are performed second, and the operations of round 44 are performed third.
- the operations of round 44 are performed first, the operations of round 42 are performed second, and the operations of round 40 are performed third.
- the operations of FIG. 3 may, if desired, be implemented using four or more rounds. For example, eight rounds of a block cipher may be performed.
- the block cipher structure of FIG. 3 encrypts (or decrypts) a string of a particular known size to produce an output string of the same size.
- plaintext is converted to ciphertext (i.e., the block cipher of FIG. 3 is operated from top to bottom).
- ciphertext is converted to plaintext (i.e., the block cipher of FIG. 3 is operated from bottom to top).
- the block cipher uses a subkey generation algorithm 38 .
- the subkey generation algorithm 38 may be a function H′ that is based on a cryptographic hash function H and that takes as an input S, C, and K. With one suitable approach, the subkey generation algorithm H′ is given by equation 1.
- H′ H ( S
- ” represents the concatenation function.
- the cryptographic hash function H is preferably chosen so that the subkey generation algorithm has a suitable cryptographic strength.
- Illustrative cryptographic hash functions that can be used for hash function H include the SHA1 hash function and the AES algorithm used as a hash function.
- the value of the key K is the same for rounds 40 , 42 , and 44 .
- the value of the constant C is different for each round.
- the constant C 1 that is used in round 40 is equal to 1
- the constant C 2 that is used in round 42 is 2
- the constant C 3 that is used in round 44 is 3.
- the value of S varies in each round. In round 40 , S 1 is equal to the first half of the unencrypted string R 1 . In round 42 , S 2 is equal to the L 2 . In round 44 , S 3 is equal to R 2 .
- the output of the subkey generation algorithm is subkey SK 1 , as shown in equation 2.
- Equations 1-4 involve the use of a cryptographic hash function for the subkey generation algorithm.
- the subkey generation algorithm may be implemented using a cryptographic message authentication code (MAC) function.
- a cryptographic message authentication code function is a keyed hash function.
- An example of a message authentication code function is CMAC (cipher-based MAC), which is a block-cipher-based message authentication code function.
- the cryptographic message authentication code function AES-CMAC is a CMAC function based on the 128-bit advanced encryption standard (AES).
- a format-preserving combining operation (labeled “+” in FIG. 3 ) is used to combine the subkeys SK 1 , SK 2 , and SK 3 with respective string portions.
- format-preserving combining operation 46 combines SK 1 with string L 1 to produce string L 2 .
- format-preserving combining operation 46 combines SK 1 with string L 2 to produce string L 1 .
- Format-preserving combining operation 48 combines SK 2 with string R 1 to produce string R 2 during encryption operations and combines SK 2 with string R 2 to produce string R 1 during decryption operations.
- Format-preserving combining operation 50 is used to process subkey SK 3 .
- format-preserving combining operation 50 combines SK 3 with string L 2 to produce string L 3 .
- format-preserving combining operation 50 combines SK 3 with string L 3 to produce string L 2 .
- the format-preserving combining operation + preserves the format of the strings L 1 , L 2 , L 3 , R 1 , and R 2 as they are combined with the subkeys SK 1 , SK 2 , and SK 3 .
- the string L 2 that is produced by combining string L 1 and subkey SK 1 has the same format as the string L 1 .
- the format-preserving combining operation + may be based on any suitable mathematical combining operation.
- the format-preserving combining function + may be any reversible logical or arithmetic operation that preserves the format of its string input when combined with the subkey.
- step 52 Illustrative steps involved in setting up the encryption engine 26 and decryption engine 28 are shown in FIG. 4 .
- step 52 the desired formatting to be used for the encrypted and decrypted strings is defined.
- unencrypted strings may be social security numbers that follow the format ddd-dd-dddd, where d is a digit from 0 to 9.
- the encryption engine 26 may produce corresponding encrypted strings with the identical format.
- the string format may be dddd ddddd ddddddddddc, where d is a digit from 0 to 9 and where c is a checksum digit (a digit from 0 to 9).
- the block cipher may be applied to the leading 15 digits of the credit card number and a checksum value may be recomputed from the encrypted version of the leading 15 digits using the Luhn algorithm.
- Validity period information may be embedded into the checksum digit by adding a validity period index to the recomputed checksum value.
- the index may, as an example, specify that an index value of 1 corresponds to the year 2006, an index value of 2 corresponds to the year 2007, an index value of 3 corresponds to the year 2008, etc. If the recomputed checksum is 3 (as an example), and the validity period for the encryption operation is 2006, the index value of 1 (corresponding to year 2006) may be added to the checksum value of 3 to produce a checksum digit of 4 for the ciphertext. In this situation, the final version of the encrypted string has the form dddd ddddddddddddddddddc, where the value of c is 4.
- the overall encryption process implemented by the encryption engine 26 maintains the digit format of the string, because both the unencrypted and encrypted versions of the string contain 16 digits.
- step 52 a user decides which of these ancillary constraints are to be included in the definition of the required format for the string.
- an index mapping is created by defining a set of legal character values and a corresponding index of sequential values that is associated with the legal characters values. For example, if the legal characters for a particular character position in a string include the 10 digits (0.9) and the 26 lowercase letters (a . . . z), a suitable indexing scheme associates digits 0 through 9 with index values 1 through 10 and associates letters a through z with index values 11-36. In this index mapping, the index values that are created are all adjacent. Because there are no gaps in the indices, index value 10 is adjacent to index value 11 (in the present example). If the string contains more than one type of character, there will be more than one index mapping associated with the characters in the string.
- a value for key K is obtained.
- the value of K may be obtained, for example, by generating K from a root secret and other information using a key generation algorithm in key server 20 .
- the format-preserving combining operation “+” is defined.
- the format-preserving combining operation may be addition modulo x, multiplication modulo x, or any other suitable logical or arithmetic operation that preserves the format of the string when combining the string with a subkey and that is reversible.
- a block cipher structure is selected for the encryption engine 26 and decryption engine 28 .
- the block cipher structure may, for example, by a Luby-Rackoff construction of the type described in connection with FIG. 3 .
- Other suitable block cipher structures may be used if desired.
- a subkey generation algorithm is selected.
- Suitable subkey generation algorithms include those based on cryptographic hash functions such the SHA1 hash function and AES algorithm used as a hash function.
- Suitable subkey generation algorithms also include those built on cryptographic message authentication code functions such as AES-CMAC.
- the encryption engine 26 and decryption engine 28 can be implemented in system 10 and sensitive data can be secured.
- FIGS. 5 and 6 Illustrative steps involved in using the encryption engine 26 and decryption engine 28 when processing strings of data in system 10 are shown in FIGS. 5 and 6 .
- the encryption engine 26 and decryption engine 28 may be called by an application or may be part of an application 16 that is running on data processing system 10 .
- the data strings that are encrypted and decrypted may be strings that are retrieved from and stored in fields in a database 18 or may be strings that are passed between applications 16 (e.g., applications 16 that are running on the same computing equipment 12 or that are communicating remotely over a communications network 14 ).
- the flow chart of FIG. 5 shows steps involved in encrypting a data string.
- the data string is preprocessed at step 64 , encrypted at step 72 , and postprocessed at step 74 .
- the encryption engine obtains the unencrypted string.
- the string may be retrieved from a database 18 or received from an application 16 .
- the string is processed to identify relevant characters.
- dashes spaces, checksums, and other undesired characters can be removed from the string and the relevant characters in the string can be retained.
- the string can be processed to remove the dashes.
- the dashes could be left in the string, there is no purpose in encrypting a dash character in the unencrypted string to produce a corresponding dash character in the encrypted string (as would be required to preserve the format of the entire string).
- the string being processed is a credit card number containing 16 digits and three spaces
- the spaces can be removed.
- the checksum portion of the 16 digit credit card can be ignored by extracting the 15 leading digits of the credit card number as the relevant characters to be processed further.
- the encryption engine 26 uses the index mappings that were created during step 54 of FIG. 4 to convert the processed string (i.e., the string from which the irrelevant characters have been removed) into an encoded unencrypted string. For example, consider a license plate number in which the first, fifth, sixth, and seventh character positions contain digits (i.e., numbers from 0 through 9) and the second, third, and fourth character positions contain uppercase letters. An index mapping may be used to convert the character values in the first, fifth, sixth, and seventh character positions into corresponding index values ranging from 0 through 9. Another index mapping may be used to convert the character values in the second, third, and fourth character positions into corresponding index values ranging from 0 through 25. The index values used in each index mapping may be sequential. Once the characters have been encoded using the sequential index values, processing can continue at step 72 .
- the encryption engine 26 encrypts the encoded string using the format-preserving block cipher that was established during the operations of FIG. 4 .
- the encryption engine 26 can perform the Luby-Rackoff encryption operations described in connection with FIG. 3 .
- the subkey generation algorithm that was selected at step 62 of FIG. 4 and the format-preserving combining algorithm + that was defined at step 58 of FIG. 4 are used to transform the unencrypted encoded string into an encrypted encoded string.
- step 76 the same index mappings that were used during the encoding operations of step 70 are used to convert the index values of the encrypted string back into characters (i.e., characters in the legal set of character values that were defined for each character position at step 54 ). Decoding the encoded version of the string using the index mappings returns the string to its original character set.
- the decoded encrypted string is processed to restore elements such as dashes and spaces that were removed at step 68 .
- a new valid checksum value can be computed from the encrypted version of the string and validity period information or other suitable information can be embedded within the checksum digit (e.g., by adding a validity period index to the new valid checksum value to produce a checksum digit for the decoded encrypted string).
- the decoded encrypted string is ciphertext that corresponds to the plaintext unencrypted string that was obtained at step 66 . If desired, the entire string can be encrypted. With this type of arrangement, the checksum removal operation of step 68 and the checksum digit computation operation of step 78 can be omitted.
- the extraneous elements of the string that were removed at step 68 are inserted back into the string. Because the extraneous elements are reinserted into the string and because a format-preserving block cipher was used in step 72 , the encrypted string that is produced will have the same format as the original unencrypted string. This allows the encrypted string to be used by applications 16 and databases 18 that require that the original string's format be used.
- the encrypted string is provided to an application 16 or database 18 .
- Legacy applications and databases that require a specific string format may be able to accept the encrypted string.
- FIG. 6 Illustrative steps involved in using decryption engine 28 to decrypt a string that has been encrypted using the process of FIG. 5 are shown in FIG. 6 .
- the decryption engine 28 may be invoked by an application 16 or may be part of an application 16 that is running on data processing system 10 .
- the data string that is being decrypted in the process of FIG. 6 may be an encrypted string that has been retrieved from a database 18 or may be a string that has been retrieved from an application.
- the encrypted data string is preprocessed at step 82 , is decrypted at step 90 , and postprocessed at step 92 .
- the decryption engine obtains the encrypted string.
- the encrypted string may be retrieved from a database 18 or received from an application 16 .
- the encrypted string is processed to identify relevant characters.
- dashes spaces, checksums, and other extraneous elements can be removed from the string.
- the relevant characters in the string are retained.
- the process of removing extraneous characters during step 86 is the same as that used during the processing of the unencrypted string that was performed during step 68 of FIG. 5 .
- the encrypted string can be processed to remove the dashes.
- the string being processed during step 86 is a credit card number containing 16 digits and three spaces
- the spaces can be removed prior to decryption.
- the checksum digit of the 16 digit credit card can be ignored by extracting the 15 leading digits of the encrypted credit card number as the relevant characters to be decrypted. If information is embedded in the checksum digit (e.g., validity period information), the checksum digit may be processed to extract this information during step 86 .
- the decryption engine 26 uses the index mappings that were defined at step 54 of FIG. 4 and that were used during the encryption operations of FIG. 5 to convert each of the characters of the processed encrypted string (i.e., the encrypted string from which the extraneous characters have been removed) into an encoded encrypted string. If, as an example, the legal set of characters associated with the first character of the encrypted string is defined as the set of 10 digits, a 10 digit index may be used to encode the first character of the encrypted string. If the legal set of characters associated with the second character of the encrypted string is defined as the set of 26 uppercase letters, a 26-digit index may be used to encode the second character of the encrypted string. During step 88 , each character of the string is converted to a corresponding index value using an appropriate index mapping.
- the encoded version of the encrypted string is decrypted.
- the decryption engine 28 decrypts the string using the format-preserving block cipher that was established during the operations of FIG. 4 .
- the decryption engine 26 can perform the Luby-Rackoff decryption operations described in connection with FIG. 3 .
- the subkey generation algorithm that was selected at step 62 of FIG. 4 and the format-preserving combining algorithm + that was defined at step 58 of FIG. 4 are used to transform the encrypted encoded string into a decrypted encoded string.
- the index mappings that were used during the encoding operations of step 88 are used to convert the index values of the decrypted string back into their associated characters (i.e., characters in the legal set of character values that were defined for each character position at step 54 ). This returns the decrypted string to its original character set.
- multiple different index mappings are used.
- the decoded decrypted string is processed to restore elements such as dashes, spaces, and checksum values that were removed at step 88 .
- elements such as dashes, spaces, and checksum values that were removed at step 88 .
- a new valid checksum value may be computed from the decrypted version of the string. This ensures that the decrypted version of the string will be returned to its original valid state.
- step 96 the extraneous elements of the string that were removed at step 88 are inserted back into the string. This restores the string to its original unencrypted state (i.e., the state of the string when obtained at step 66 of FIG. 5 ).
- the decrypted string is provided to an application 16 or database 18 .
- legacy applications and databases and other applications and databases can be provided with cryptographic capabilities without disrupting their normal operation.
- the key K that is used by encryption and decryption engines 26 and 28 may be produced using any suitable technique.
- key K may be supplied to key server 20 manually and may be distributed to encryption and decryption engines 26 and 28 in satisfaction of valid key requests.
- key K is derived mathematically from a secret.
- the secret which is sometimes referred to as a root secret, may be maintained at key server 20 .
- the root secret may be supplied to key server 20 manually or may be produced using a pseudo-random number generator.
- each key K may be advantageous to mathematically compute each key K from policy information 22
- key K may be computed by key server 20 using equation 5.
- the parameter IDEN is an identifier
- the parameter RSECRET is a root secret
- the function f is a one-way function such as a hash function.
- An example of a hash function that may be used for function f is the SHA1 hash function. If desired, other hash functions and one-way functions may be used for function f.
- the identifier IDEN may include information that identifies an individual, a group, a policy, or an application.
- the identifier may be based on the name of an individual, the name of an organization, the name of a group, or any other suitable user name.
- the identifier may also be based on the name of a policy (e.g., “PCI” indicating that cryptographic operations should be performed in accordance with payment card industry standards) or may be based on the name of an application.
- PCI indicating that cryptographic operations should be performed in accordance with payment card industry standards
- the key server 20 may use all or part of the value of IDEN in determining whether the key requester is authorized to receive K. If the key requester is authorized, the function of equation 5 may be used to generate K.
- Identity and key expiration may be implemented by requiring that a validity period be included in each identity IDEN.
- the validity period indicates the dates on which the key K is valid.
- Validity periods can be expressed in terms of absolute dates, abbreviated dates, version numbers that relate to valid date ranges or key versions, etc.
- a validity period for IDEN may be made up of a year of expiration (e.g., 2007), may be made up of a week of expiration (e.g., week number 45), may be made up of a month and year of expiration (e.g., 03/2007 or 03/07), etc.
- Validity periods may also be constructed using a date range (e.g., 2006-2007) during which key K is valid.
- the validity period in an identity IDEN may be a credit card expiration date (e.g., 05/08).
- the credit card expiration date or other such information may be combined with information that labels the identity IDEN as being associated with credit cards and the payment card industry (PCI).
- the value of IDEN might be formed, for example, by combining the strings “Joe Smith” (the name of a holder of a credit card), “PCI” (indicating the payment card industry), and a credit card expiration date to form (as an example) a value for IDEN of “JOE_SMITH_PCI_05/08.”
- FIG. 7A Illustrative steps involved in forming a key K using equation 5 are shown in FIG. 7A .
- key server 20 obtains the parameter RSECRET (e.g., using a pseudorandom number generator operating at key server 20 , by retrieving RSECRET from a cache at key server 20 , etc.).
- RSECRET e.g., using a pseudorandom number generator operating at key server 20 , by retrieving RSECRET from a cache at key server 20 , etc.
- the key server 20 obtains the parameter IDEN.
- the parameter IDEN may be provided to key server 20 as part of a key request (e.g., in a single transmission requesting a key or in a series of related transmissions requesting a key).
- Information such as a user identity (e.g., a username or part of a username, a group identity, etc.), validity period (e.g., an expiration date, a valid date range, a version number, or a combination of such validity period information), and industry/key type (e.g., “PCI” for the payment card industry) may be included in the value of the IDEN string.
- components of the IDEN string may be represented using multiple strings or additional information may be included in the IDEN string.
- key server 20 may use function f of equation 5 (e.g., a SHA1 hash function or other one-way function) to compute K from the known values of the root secret RSECRET and the identifier IDEN.
- function f of equation 5 e.g., a SHA1 hash function or other one-way function
- Keys may be generated using the operations of FIG. 7A at any suitable time.
- key server 20 may generate a key K whenever a valid key request is received.
- key server 20 may maintain a key cache in which previously generated keys are stored. Use of a key cache may reduce the processing burden on key server 20 .
- FIG. 7B A flow chart of illustrative steps involved in generating key K using an approach in which generated key K is persistently stored is shown in FIG. 7B .
- key K is generated randomly at step 105 .
- key K may be generated using a pseudorandom number generator at key server 20 when a key is requested in a key request containing an identifier IDEN.
- the key K is stored in persistent storage (e.g., a key cache maintained at key server 20 ).
- Key server 20 also stores an association between the key K that has been generated and the value of identifier IDEN from the key request. The association may be provided by making an entry in a database that contains the key and the related identifier IDEN (as an example).
- key server 20 can retrieve the correct key K from storage to satisfy the request using the value of the identifier IDEN that is provided in the key (step 109 ).
- the approach of FIG. 7B therefore allows the key generator 20 to obtain the key K by generating the key K randomly (if no key value has been cached) or by retrieving a previously stored version of key K using the identity value IDEN.
- Key server 20 also preferably maintains policy information 22 ( FIG. 1 ).
- Policy information 22 includes policy rules that may be used in determining which key requests should be granted and which key requests should be denied.
- An example of a policy rule is a rule that requires that a key requester authenticate successfully as part of a PCI LDAP (Lightweight Directory Access Protocol) group whenever the parameter IDEN includes the industry type “PCI.”
- a policy rule might specify that key requests should only be satisfied if made at date that falls within the validity period specified in the IDEN parameter.
- Key server 20 may maintain a clock or may otherwise obtain trustworthy external information on the current date. External information such as this may be used by key server 20 in evaluating whether the policy rules have been satisfied for a particular key request.
- the policy rules at key server 20 will specify multiple criteria that must be satisfied (e.g., proper authentication of a given type must be performed, a validity period restriction must be satisfied, etc.).
- authentication server 24 is used in authenticating key requesters.
- key server 20 may perform authentication.
- Key requests may be made by encryption engine 26 when a copy of a key K is needed to perform an encryption operation or by decryption engine 28 when a copy of key K is needed to perform a decryption operation.
- any suitable technique may be used to process key requests. Flow charts presenting three illustrative ways in which key requests for key K may be handled in system 10 are shown in FIGS. 8, 9, and 10 .
- an encryption engine or decryption engine associated with an application 16 makes a key request to key server 20 at step 106 .
- Key requests such as the key request of step 106 may be made in a single transmission over network 14 between the computing equipment 12 on which the requesting application resides or may be made in multiple associated transmissions.
- the key request may include authentication credentials and an identifier such as the identifier parameter IDEN described in connection with FIGS. 7A and 7B .
- the identifier that is associated with the key request may include information such as a validity period (e.g., a credit card expiration date), user name, etc. Different types of keys may require different levels of authentication.
- the authentication credentials that are provided as part of the key request are preferably provided in a form that is suitable for the type of key being requested.
- One example of authentication credentials is a userID and password. Biometric authentication credentials may also be used (as an example).
- key server 20 forwards the authentication credentials that have been received from the key requester to authentication server 24 over communications network 14 .
- authentication server 24 verifies the authentication credentials. For example, if the authentication credentials include a userID and password, authentication server 24 may compare the userID and password to a list of stored valid userIDs and passwords.
- authentication server 24 determines that the authentication credentials are not valid, the authentication process fails.
- a suitable response to this failure may be generated at step 112 .
- authentication server 24 can notify key server 20 that the authentication credentials are not valid and can generate suitable alert messages for entities in system 10 .
- Other suitable actions include generating an error message that prompts key server 20 and/or the key requester to resubmit the credentials (e.g., to avoid the possibility that the authentication failure was due to mistyped authentication credentials).
- the authentication server 24 determines that the authentication credentials are valid, the authentication server 24 notifies the key server 20 accordingly.
- the authentication server provides the key server 20 with an “assertion” indicating that the credentials are valid.
- the assertion may include information on group membership and roles and rights for the authenticated party.
- key server 20 applies policy rules 22 to the key request.
- Information such as the identity information IDEN, the authentication results from authentication server 24 (e.g., the assertion), and external information such as the current date may be used by the key server 20 in enforcing the policy rules.
- identity information, authentication results, and external information may be used in determining which policy rules should be applied.
- Certain policy rules may be applied when IDEN indicates that the key requester is making a “PCI” key request. Such rules may, as an example, require a particular level of authentication.
- Certain policy rules may also be applied when a key request is made on particular times and dates (e.g., more stringent authentication may be required for evening and weekend key requests).
- Certain policy rules may apply to particular groups of users, etc.
- key server 20 may also use identity information, authentication results, and external information in determining whether the applicable policy rules have been satisfied. For example, during step 114 , key server 20 may determine whether the key request includes valid validity period information (e.g., whether an expiration period has expired). Key server 20 may also check to make sure that appropriate valid authentication results have been received from authentication server 24 , may check the key requester's membership in a directory group, etc.
- valid validity period information e.g., whether an expiration period has expired.
- Key server 20 may also check to make sure that appropriate valid authentication results have been received from authentication server 24 , may check the key requester's membership in a directory group, etc.
- the key request fails and appropriate error notifications may be generated or other actions may be taken at step 116 .
- key server 20 may generate a key K to satisfy the key request at step 118 .
- the key K may be generated using operations of the type shown in FIG. 7A or may be generated or retrieved using operations of the type shown in FIG. 7B .
- the key K may then be supplied to the key requester over a secure path in communications network 14 .
- key server 20 applies the applicable policy rules to the key request following successful verification of the authentication credentials by authentication server 24 .
- the policy rules can be applied between steps 106 and 108 .
- the key server need not submit the authentication credentials to the authentication server if the policy rules are not satisfied (e.g., if validity period information indicates that an expiration date has passed).
- FIG. 9 Another illustrative technique that may be used by an encryption engine or decryption engine associated with an application to obtain key K is shown in FIG. 9 .
- authentication is performed using authentication server 24 before the key request is made to key server 20 .
- an application 16 that desires a key K provides authentication credentials to authentication server 24 for verification. If desired, the application may also provide an identifier (e.g., parameter IDEN) to authentication server 24 , which may use this information to determine what type of assertion to provide to the application following successful verification of the authentication credentials.
- an identifier e.g., parameter IDEN
- authentication server 24 verifies the authentication credentials. If the authentication credentials are not valid, an appropriate response may be made at step 124 (e.g., by providing the application with another chance to provide valid credentials, by issuing an alert, etc.).
- the authentication server If the authentication credentials are determined to be valid, the authentication server provides the application with an assertion over communications network 14 .
- the assertion may be, for example, a Kerberos ticket.
- the application uses the assertion that has been received from the authentication server in making a key request to key server 20 .
- the key request may include the assertion from authentication server 24 and an identifier (e.g., parameter IDEN).
- the key server applies policy rules 22 to the key request to determine whether the key request should be satisfied.
- Key server 20 may use identity information (e.g., parameter IDEN, which may include a validity period), authentication results (e.g., the assertion), and external information (e.g., the current date) in determining which policy rules should be applied to the key request.
- the key server may also use this information in determining whether the applicable policy rules have been satisfied.
- key server 20 may determine whether the key request includes valid validity period information during step 128 and may check to determine whether the assertion is valid and sufficient to satisfy the policy rules.
- the key server 20 may request that the application issue a new request or may take other suitable actions in response to the failure (step 130 ).
- the key server may retrieve key K from cache or may generate an appropriate key K, as discussed in connection with FIGS. 7A and 7B .
- the key K may be provided from key server 20 to the requesting application over communications network 14 .
- authentication operations are performed by key server 20 , so authentication server 24 need not be used.
- an application that needs key K makes a key request to key server 20 .
- the key request may include an identifier (e.g., parameter IDEN) and shared secret information.
- the shared secret information may be, for example, a shared secret (i.e., a secret known by the application and by the key server) or shared secret information that is derived from the shared secret (e.g., by hashing the shared secret with an identifier such as parameter IDEN).
- the key server verifies the shared secret information.
- the key server may, as an example, compare the shared secret information from the key request to previously generated and stored shared secret information or to shared secret information that is generated in real time based on the received identity (e.g., IDEN). If the shared secret information is valid, the key server can determine which key access policy rules are to be applied to the key request (e.g., using external information such as the current date, using identity information IDEN, etc.). After determining which policy rules to use, key server 20 applies the appropriate policy rules to the key request.
- the key request fails and appropriate actions can be taken at step 138 .
- the key server can retrieve key K from cache or may generate key K in real time (e.g., using the operations of FIGS. 7A and 7B ).
- the requested key may then be provided to the key requester over communications network 12 (step 140 ).
- key server 20 helps to avoid problems that might otherwise arise when storing keys in local cache on computing equipment 12 . If keys are only maintained in local storage, it may be difficult to recreate a key when needed to resurrect a server that has crashed. By using key server 20 , keys can be regenerated as needed at the key server.
- Systems such as system 10 of FIG. 1 may use validity periods to control when keys are valid.
- a first application may encrypt plaintext using a cryptographic key that is based on a given validity period.
- the resulting ciphertext may then be stored in a database and retrieved by a second application or may be provided directly to the second application over network 14 .
- the second application must obtain a copy of key K to decrypt the ciphertext.
- the key K must be generated using the given validity period. If an incorrect validity period is used in generating K, the value of K will be incorrect and the second application will not be able to use that value of K to decrypt the ciphertext.
- a sixteen digit credit card number may include three parts.
- the leading six digits of the credit card number are sometimes referred to as the bank identification number (BIN).
- the next six digits of the credit card number are sometimes referred to as the account number core and form part of the credit card holder's account number.
- the last four digits of the credit card number are sometimes referred to as user account number information and are used with the account number core to identify a credit card holder's account.
- Different parties may be entitled to access different parts of the credit card number. Some parties may only need access to the BIN. Other parties may require access to the entire credit card number. As a result, it may be desirable to selectively grant access to different portions of the credit card number to different parties.
- Selective access may be provided to different portions of a data item using format-preserving cryptography.
- Users individuals, organizations, applications, etc.
- Users that require access to one part of a data item, may be provided with appropriate cryptographic key(s) to access that part of the data item, whereas users that require access to another portion of the data item may be provided with appropriate key(s) to access that portion.
- a first user might, for example, be provided with access to an entire social security number, whereas a second user might only be provided with access to the last four digits of a social security number.
- a first user might be provided with access to the first or last four digits of a credit card number, whereas a second user might be provided with access to the entire credit card number.
- each user may likewise be provided with access to different portions of a social security number, credit card number, or other data item.
- plaintext P may be made up of two parts: plaintext P 1 and plaintext P 2 .
- plaintext P might be a credit card number and plaintext portion P 2 might be the last four digits of the credit card number.
- plaintext P 1 would represent the leading twelve digits of the credit card number.
- plaintext P 1 can be converted into ciphertext C 1 and ciphertext C 1 can be converted into plaintext P 1 , as shown in FIG. 12 .
- a second format-preserving cryptographic algorithm e.g., a block-cipher-based algorithm of the type described in connection with FIG. 3
- a second cryptographic key K 2 may be used to convert ciphertext C 1 and plaintext portion P 2 into ciphertext C and may be used to convert ciphertext C into ciphertext portion C 1 and plaintext portion P 2 .
- format-preserving encryption algorithm E 1 and cryptographic key K 1 are used to encrypt plaintext P 1 to produce corresponding ciphertext C 1 , whereas plaintext portion P 2 is left unencrypted.
- format-preserving encryption algorithm E 2 and cryptographic key K 2 are used to encrypt ciphertext C 1 and plaintext P 2 to produce ciphertext C.
- Encryption algorithm E 1 is a format-preserving encryption algorithm that maps plaintext P 1 to ciphertext C 1 that is in the same format as plaintext P 1 .
- Encryption algorithm E 2 is a format-preserving encryption algorithm that maps input (C 1 , P 2 ) to ciphertext C that is in the same format as (C 1 , P 2 ).
- input (C 1 , P 2 ) serves as “plaintext” corresponding to output ciphertext C.
- a decryption algorithm D 2 may perform decryption operations with key K 2 to produce ciphertext C 1 and plaintext part P 2 .
- Decryption algorithm D 2 is a format-preserving decryption algorithm, so output (C 1 , P 2 ) is in the same format as input C.
- decryption algorithm D 1 (corresponding to encryption algorithm E 1 ) may perform decryption operations on C 1 using key K 1 to produce plaintext P 1 .
- Decryption algorithm D 1 is a format-preserving decryption algorithm, so output P 1 is in the same format as input C 1 .
- a first user may be provided with key K 1 and key K 2 .
- a second user may be provided with only key K 2 .
- USER 1 has both keys, USER 1 can decrypt C with decryption function D 2 and key K 2 to produce C 1 and P 2 and can decrypt C 1 with decryption function D 1 and K 1 to produce P 1 .
- Plaintext P 1 and plaintext P 2 can be assembled to produce plaintext P, so USER 1 can access all of P.
- USER 2 has only key K 2
- USER 2 can only use decryption function D 2 to decrypt C and produce ciphertext C 1 and plaintext P 2 . USER 2 is therefore able to access only plaintext P 2 , not plaintext P 1 .
- key server 20 or other suitable entity may be used to selectively distribute keys to users (i.e., to software applications or parts of applications that are associated with individuals, organizations, etc.). Different keys may be distributed to different users depending on the level of access that it is desired to grant each user.
- first and second keys such as keys K 1 and K 2 of FIG. 12 may be provided to a first user USER 1 , as described in connection with FIG. 12 .
- second key K 2 may be provided to a second user USER 2 , as described in connection with FIG. 12 .
- keys K 1 and K 2 are used in encrypting different portions of the data item P.
- key K 1 may be used to encrypt plaintext part P 1 of P to produce corresponding ciphertext C 1
- key K 2 may be used in encrypting both C 1 and plaintext part P 2 of P to produce corresponding ciphertext C.
- the selective encryption operations of step 148 may be performed at any suitable time (e.g., before, after, or during the key distribution operations of step 142 ). Each encryption step may use a unique encryption algorithm such as encryption algorithms E 1 and E 2 of FIG. 12 .
- Encryption algorithm E 1 which may be used to encrypt plaintext P 1 , may be a format-preserving encryption algorithm that is suitable for encrypting the last four digits of a credit card number (as an example).
- Encryption algorithm E 2 may be a format-preserving encryption algorithm that is suitable for encrypting a 16 digit credit card number (as an example).
- step 150 format-preserving decryption algorithms (e.g., decryption algorithm D 2 corresponding to encryption algorithm E 2 and decryption algorithm D 1 corresponding to encryption algorithm E 1 ) may be used to reverse the encryption operations of step 142 .
- decryption algorithm D 2 and key K 2 may be used by USER 2 to decrypt C to produce ciphertext C 1 and plaintext P 2 , thereby providing USER 2 with access to plaintext part P 2 of plaintext P, but not access to plaintext part P 1 of plaintext P.
- USER 1 Because USER 1 obtained both keys K 1 and K 2 during step 142 , USER 1 is able to decrypt C with D 2 using key K 2 to produce C 1 and plaintext P 2 and is able to decrypt C 1 with D 1 and key K 1 to produce P 1 . This allows USER 1 to access all parts of P (i.e., both P 1 and P 2 in this example).
- plaintext P may be divided into three or more portions Pi, three or more format-preserving encryption algorithms Ei and three or more corresponding keys Ki may be used to encrypt each portion in a successive operation as described in connection with FIGS. 12 and 13 .
- a corresponding number (i.e., three or more) matching decryption algorithms Di may be used to provide these users with selective access to the different plaintext portions Pi.
- step 70 of FIG. 5 and step 88 of FIG. 6 it may be desirable to convert characters into unique binary values. These unique binary values may then be encrypted (as described in connection with the format-preserving encryption operations of step 72 of FIG. 5 ) or decrypted (as described in connection with the format-preserving decryption operations of step 90 of FIG. 6 ).
- FIG. 14 One type of technique that may be used when encoding strings as unique binary values is illustrated in FIG. 14 .
- an unencoded (plaintext) string P is converted into a unique binary value UBV.
- String P (in this example) is made up of characters P 4 , P 3 , P 2 , P 1 , and P 0 .
- Characters P 4 , P 2 , and P 1 are digits and may therefore have any value between 0 and 9 (i.e., 0 1, 2, 3, . . . 9).
- Characters P 3 and P 0 are letters and may have any letter value (i.e., A, B, C, D, . . . Z). Each digit character may have one of ten values and each letter character may have one of 26 values.
- a formula such as formula 152 may be used.
- P 0 represents a numeric value for letter P 0 .
- “A” corresponds to 0, “B” corresponds to 1, . . . and “Z” corresponds to 25, so if P 0 is the letter “B,” the numeric value for P 0 in equation 152 will be 1.
- P 1 is a digit.
- 0 corresponds to 0, 1 corresponds to 1, . . . and 9 corresponds to 9, so if P 1 is the digit “3,” the value of P 1 will be 3.
- character P 2 will have a numeric value of 0 to 9
- P 3 will have a numeric value of 0 to 25
- P 4 will have a numeric value of 0 to 9.
- the numeric values of the characters P 0 , P 1 , P 2 , P 3 , and P 4 are multiplied by respective coefficients 154 , 156 , 158 , and 160 (the coefficient of P 0 is “1”).
- the value of each multiplicative coefficient in formula 152 represents the number of possible values of the previous character.
- the numeric value of character P 1 is multiplied by coefficient 154 .
- the value of coefficient 154 is 26, because P 0 (the character that is just prior to character P 1 in string P) may have any one of 26 possible values.
- Coefficient 156 of numeric value P 2 has a value of 260, because the combination of preceding characters P 0 and P 1 could have any of 260 possible values.
- the value of coefficient 158 of P 3 is 2600 because there are 2600 possible combinations of numeric values for preceding characters P 0 , P 1 , and P 2 and the value of coefficient 160 of P 4 is 67600 because there are 67600 possible combinations of numeric values for preceding characters P 0 , P 1 , P 2 , and P 3 .
- the base 10 numeric values of the coefficients and the numeric values of the encoded characters are represented in binary (i.e., in base 2, as “1s” and “0s”).
- the mapping provided by unique binary value encoding function 152 is unique in that no two character strings PA and PB will map to the same binary value UBV, when PA is not the same as PB.
- the encrypted version of the binary-encoded string that is produced at the output of step 72 in FIG. 5 should be format compliant to ensure that the postprocessed string that is produced at the output of step 74 of FIG. 5 is in the same format as the string originally obtained at step 66 .
- the decrypted version of the binary-encoded string that is produced at the output of step 90 of FIG. 6 should be format compliant to ensure that the postprocessed string produced following the operations of step 92 of FIG. 6 is in the same format as the string originally obtained at step 84 .
- Encoded binary values are considered to be format compliant when their unencoded form lies within the same range of values as their original form.
- the character “9” This character is a digit and can be numerically represented by the base 10 number “9.” In binary, the number 9 is 1001.
- encryption operations may be performed that transform the unencrypted binary value 1001 to an encrypted value of 1111 (as an example).
- This binary value is not format compliant, because it corresponds to a base 10 value of “15,” which is not within the permissible range for a single digit (i.e., “15” does not lie within the range of “0,” “1”, “2,” . . . . “9”).
- the same type of problem can occur during decryption if the decrypted version of a binary-encoded value at the output of step 90 is not format compliant.
- step 72 ( FIG. 5 ) and step 90 ( FIG. 6 ) can be repeated while checking the output of the cipher for format compliance.
- Each iteration of the block cipher will modify the binary output.
- the binary output of the block cipher will be format compliant, at which point no further iterations of the block cipher are performed.
- FIG. 15 This type of arrangement is shown in FIG. 15 .
- an unencrypted string P is being encrypted.
- the string P in the FIG. 15 example is the digit “9.”
- the string P is converted to a numeric value of 9.
- the unencrypted encoded version of string P is 1001.
- the left half of the binary-encoded version of P (“10”) is used as the input L 1 to the block cipher of FIG. 3
- the right half of the binary-encoded version of P (“01”) is used as the input R 1 to the block cipher of FIG. 3 .
- a certain number of rounds of the block cipher may be used to perform an initial encryption operation on the binary-encoded value 1001.
- this initial encoding operation results in the binary value of 1111. If this value were format compliant, the encryption process would be complete.
- the binary value of 1111 is not format compliant, because it corresponds to a base 10 numeric value of 15, which is not within the permissible range numeric values for a digit (i.e., 15 does not lie within the range of 0-9, so the string “15” is not in the same format as the original string “9”).
- additional rounds of the block cipher are performed (e.g., an additional eight rounds).
- Decryption operations may be performed in the same way. If, following an initial application of a given number of rounds of the block cipher, the initial binary value of a string that is produced is not format compliant, additional decryption operations can be performed. As soon as a binary output is produced that is format compliant, the block cipher operations may be terminated and the binary value may be converted into an appropriately formatted string of characters (e.g., letters and digits), as described in connection with step 92 .
- an appropriately formatted string of characters e.g., letters and digits
- FIG. 16 Illustrative steps involved in performing format-preserving encryption operations on a string using one or more repeated iterations of a block cipher to ensure format compliance are shown in FIG. 16 .
- a data string may be preprocessed at step 64 , encrypted at step 162 , and postprocessed at step 74 .
- encryption engine 26 may obtain the unencrypted string from a database 18 or an application 16 and may process the string to identify relevant characters. Dashes spaces, checksums, and other undesired characters can be removed from the string and the relevant characters in the string can be retained. Encryption engine 26 may then use the index mappings that were created during step 54 of FIG. 4 to convert the processed string (i.e., the string from which the irrelevant characters have been removed) into an encoded unencrypted string.
- each digit in the string may be converted into a corresponding numeric value from 0-9, each letter in the string may be converted into a corresponding numeric value from 0-25, etc.
- encryption engine 26 may use a formula such as formula 152 of FIG. 14 to encode the string to a unique binary value.
- the actual formula that is used during encoding depends on the nature of the string's format.
- the values used for coefficients 154 , 156 , 158 , and 160 in FIG. 14 are applicable to a situation in which the string has the format “digit, letter, digit, digit, and letter,” as shown at the top of FIG. 14 .
- different coefficients may be used in the unique binary value encoding function represented by formula 152 .
- block cipher format-preserving encryption operations may be performed at step 162 .
- the binary-encoded string may be processed using a block cipher such as a block cipher of the type shown in FIG. 3 .
- the block cipher may be applied to the binary-encoded string at step 164 .
- the operations of step 164 may involve any suitable number of rounds of the block cipher. For example, during step 164 , eight rounds of the block cipher may be performed. The use of eight rounds of the block cipher is, however, merely illustrative. Any suitable number of rounds of the block cipher may be performed at step 164 if desired.
- the binary value obtained from step 64 is converted to an encrypted binary value.
- the encrypted binary value that is produced at step 164 is analyzed to determine whether it is format compliant. As described in connection with FIG. 15 , when a binary value is operated on by the block cipher, the resulting binary value at the output of the block cipher may not match the format of the original input string. If it is determined at step 166 that the format of the string no longer matches the format of the original string (e.g., if a digit has been transformed into a value that no longer falls within its allowed range of 0-9 as described in connection with FIG.
- processing can loop back to step 164 , as indicated by line 165 .
- the current block cipher can again be applied to the binary value.
- the block cipher can update the current block cipher output. This loop can continue until it is determined during step 166 that the format of the encrypted binary value (the current block cipher output) matches the format of the original string obtained at step 64 .
- processing may proceed to step 74 .
- step 74 the same unique binary value encoding function that was used during the encoding operations of step 64 and the same index mappings that were used during the encoding operations of step 64 are used to convert the encrypted string back into characters (i.e., characters in the legal set of character values that were defined for each character position). Decoding the encoded version of the string using the unique binary value encoding function and index mappings returns the string to its original character set.
- the decoded encrypted string may then be processed to restore elements such as dashes and spaces that were removed during the preprocessing operations of step 64 .
- a new valid checksum value can be computed from the encrypted version of the string and validity period information or other suitable information can be embedded within the checksum digit (e.g., by adding a validity period index to the new valid checksum value to produce a checksum digit for the decoded encrypted string).
- the decoded encrypted string is ciphertext that corresponds to the plaintext unencrypted string that was obtained at step 64 . If desired, the entire string can be encrypted. With this type of arrangement, the checksum removal operation and the checksum digit computation operation of can be omitted.
- the extraneous elements of the string that were removed during step 64 may be inserted back into the string. Because the extraneous elements are reinserted into the string and because a format-preserving block cipher encryption process was used during step 162 , the encrypted string that is produced will have the same format as the original unencrypted string. This allows the encrypted string to be used by applications 16 and databases 18 that require that the original string's format be used. When the encrypted string is provided to an application 16 or database 18 , legacy applications and databases that require a specific string format may be able to accept the encrypted string.
- FIG. 17 Illustrative steps involved in performing format-preserving decryption operations on a string using one or more repeated iterations of a block cipher to ensure format compliance are shown in FIG. 17 .
- a data string may be preprocessed at step 82 , decrypted at step 168 , and postprocessed at step 92 .
- the decryption engine obtains the encrypted string.
- the encrypted string may be retrieved from a database 18 or received from an application 16 .
- the encrypted string is processed to identify relevant characters. For example, dashes spaces, checksums, and other extraneous elements can be removed from the string, whereas relevant characters in the string can be retained.
- the process of removing extraneous characters during step 82 is the same as that used during the processing of the unencrypted string that was performed during step 68 of FIG. 5 (step 64 of FIG. 16 ).
- decryption engine 28 may use the index mappings that were defined at step 54 of FIG.
- decryption engine 28 may use a formula such as formula 152 of FIG. 14 to encode the string to a unique binary value.
- the formula that is used during the encoding of step 82 depends on the nature of the string's format. The values used for coefficients 154 , 156 , 158 , and 160 in the FIG. 14 example are merely illustrative.
- format-preserving decryption operations may be performed at step 168 .
- the binary-encoded string may be processed using a block cipher such as a block cipher of the type shown in FIG. 3 .
- the block cipher may be applied to the binary-encoded string at step 170 .
- the operations of step 170 may involve any suitable number of rounds of the block cipher. For example, eight rounds of the block cipher may be performed during step 170 .
- step 170 the binary value obtained from step 82 is converted to another binary value. If only one pass through loop 165 of FIG. 16 was used during encryption, a single pass through decryption step 170 will be sufficient to convert the binary value from step 82 into a decrypted binary value. If more passes through loop 165 were used to produce the format-compliant encrypted string, a correspondingly increased number of passes through loop 171 will be required during decryption operations.
- the binary value that was produced at step 170 by application of the decrypting block cipher is analyzed to determine whether the binary value is format compliant.
- the resulting updated binary value at the output of the block cipher may not match the format of the original input string. If it is determined at step 172 that the format of the data string represented by the current binary value (i.e., the current version of the block cipher output) does not match its original format (e.g., if a digit has been transformed into a value that no longer falls within its allowed range of 0-9), processing can loop back to step 170 , as indicated by line 171 .
- the decrypting block cipher can again be applied to the binary value at step 170 to update the block cipher output.
- This loop can continue until it is determined during step 172 that the format of the current binary value produced at the output of the decrypting block cipher matches the format of the original encrypted string obtained at step 82 .
- the encrypted string has been successfully decrypted and processing may proceed to step 92 .
- the index mappings and unique binary encoding scheme that were used during the encoding operations of step 82 may be used to convert the index values of the decrypted string back into their associated characters (i.e., characters in the legal set of character values that were defined for each character position). This returns the decrypted string to its original character set.
- multiple different index mappings may be used.
- the decoded decrypted string may then be processed to restore elements such as dashes, spaces, and checksum values that were removed. When replacing a checksum value, a new valid checksum value may be computed from the decrypted version of the string. This ensures that the decrypted version of the string will be returned to its original valid state.
- step 92 the extraneous elements of the string that were removed at step 82 are inserted back into the string. This restores the string to its original unencrypted state, so that the decrypted string may be provided to an application 16 or database 18 .
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Business, Economics & Management (AREA)
- Health & Medical Sciences (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- General Health & Medical Sciences (AREA)
- Bioethics (AREA)
- Accounting & Taxation (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Storage Device Security (AREA)
Abstract
Description
- This patent application claims the benefit of provisional patent application No. 61/050,160, filed May 2, 2008, and patent application Ser. No. 12/432,258, filed Apr. 29, 2009, which are hereby incorporated by reference herein in their entireties.
- This invention relates to cryptography and more particularly, to preserving data formats during encryption and decryption operations.
- Cryptographic systems are used to secure data in a variety of contexts. For example, encryption algorithms are used to encrypt sensitive information such as financial account numbers, social security numbers, and other personal information. By encrypting sensitive data prior to transmission over a communications network, the sensitive data is secured, even if it passes over an unsecured communications channel. Sensitive data is also sometimes encrypted prior to storage in a database. This helps to prevent unauthorized access to the sensitive data by an intruder.
- Commonly used encryption algorithms include the Advanced Encryption Standard (AES) encryption algorithm and the Data Encryption Standard (DES) encryption algorithm. Using these types of algorithms, an organization that desires to secure a large quantity of sensitive information can place the sensitive information in a data file. The data file can then be encrypted in its entirety using the AES or DES algorithms.
- Encrypting entire files of data can be an effective technique for securing large quantities of data. However, bulk encryption of files can be inefficient and cumbersome because it is not possible to selectively access a portion of the encrypted data in an encrypted file. Even if an application only needs to have access to a portion of the data, the entire file must be decrypted. Without the ability to selectively decrypt part of a file, it can be difficult to design a data processing system that provides different levels of data access for different application programs and for different personnel.
- To avoid the difficulties associated with encrypting entire files of sensitive data, it would be desirable to be able to apply cryptographic techniques such as the AES and DES encryption algorithms with a finer degree of granularity. For example, it might be desirable to individually encrypt social security numbers in a database table, rather than encrypting the entire table. This would allow software applications that need to access information in the table that is not sensitive to retrieve the desired information without decrypting the entire table.
- Conventional encryption techniques can, however, significantly alter the format of a data item. For example, encryption of a numeric string such as a credit card number may produce a string that contains non-numeric characters or a string with a different number of characters. Because the format of the string is altered by the encryption process, it may not be possible to store the encrypted string in the same type of database table that is used to store unencrypted versions of the string. The altered format of the encrypted string may therefore disrupt software applications that need to access the string from a database. The altered format may also create problems when passing the encrypted string between applications. Because of these compatibility problems, organizations may be unable to incorporate cryptographic capabilities into legacy data processing systems.
- It would therefore be desirable to be able to provide cryptographic tools that are capable of encrypting and decrypting data without altering the format of the data.
- In accordance with the present invention, format-preserving encryption and decryption algorithms are provided. Using format-preserving encryption, a plaintext string such as a string of letters and digits can be encrypted to produce ciphertext composed of letters and digits in the same format as the original plaintext string. During format-preserving decryption, ciphertext can be converted into plaintext in the same format as the ciphertext.
- The format-preserving encryption and decryption algorithms may be implemented using a block cipher. During encryption, the block cipher may be applied to a plaintext string. If the resulting block cipher output does not correspond to a string that is in the same format as the original string, the block cipher can be applied one or more additional times. Once the block cipher output is format-compliant, the block cipher output can be used to produce the encrypted string. The block cipher may also be applied in this fashion during format-preserving decryption operations.
- Strings may be made up of characters. During format-preserving encryption and decryption operations, the strings may be converted to numeric values using an index. During these encoding operations, unique binary values may be produced for each string using a binary encoding function. The binary values that are produced may be operated upon using the block cipher.
- Different users (applications) may be provided with selective access to different portions of a string that has been encrypted using format-preserving encryption. For example, a string may have first and second plaintext parts. The first plaintext part may be encrypted using a first cryptographic key to produce first ciphertext. By using format-preserving encryption, the first ciphertext may have the same format as the first plaintext part. Both the second plaintext part and the first ciphertext may be encrypted together using format-preserving encryption and a second cryptographic key to produce second ciphertext that is in the same format as first ciphertext and the second plaintext part. With this type of arrangement, the ciphertext has the same format as the original string that is composed of the first and second plaintext parts.
- To provide selective access to the different portions of plaintext, a first user may be provided with the first and second keys and a second user may be provided with the second key but not the first key. This allows the second user to access the second plaintext part but not the first plaintext part and allows the first user to access both the first and second plaintext parts.
- Further features of the invention, its nature and various advantages will be more apparent from the accompanying drawings and the following detailed description of the preferred embodiments.
-
FIG. 1 is a diagram of an illustrative system environment in which cryptographic tools with format-preserving encryption and decryption features may be used in accordance with an embodiment of the present invention. -
FIG. 2 is a diagram showing how encryption and decryption engines preserve the format of a string in accordance with an embodiment of the present invention. -
FIG. 3 is a diagram of an illustrative format-preserving block cipher that may be used during data encryption and decryption in accordance with an embodiment of the present invention. -
FIG. 4 is a flow chart of illustrative steps that may be used in setting up format-preserving encryption and decryption engines for use in a data processing system of the type shown inFIG. 1 in accordance with an embodiment of the present invention. -
FIG. 5 is a flow chart of illustrative steps involved in using a format-preserving encryption engine to encrypt a data string in accordance with an embodiment of the present invention. -
FIG. 6 is a flow chart of illustrative steps involved in using a format-preserving decryption engine to decrypt a data string in accordance with an embodiment of the present invention. -
FIG. 7A is a flow chart of illustrative steps involved in generating a key that is based on an identifier in accordance with an embodiment of the present invention. -
FIG. 7B is a flow chart of illustrative steps involved in generating a key and storing the generated key with an association between the stored key and an identifier in accordance with an embodiment of the present invention. -
FIG. 8 is a flow chart of illustrative steps involved in requesting and obtaining a key from a key server in accordance with an embodiment of the present invention. -
FIG. 9 is a flow chart of illustrative steps involved in requesting and obtaining a key from a key server in accordance with another embodiment of the present invention. -
FIG. 10 is a flow chart of illustrative steps involved in requesting and obtaining a key from a key server in accordance with yet another embodiment of the present invention. -
FIG. 11 is a diagram showing how different parts of a data item can be divided into different plaintext parts and selectively encrypted in accordance with an embodiment of the present invention. -
FIG. 12 is a diagram showing how multiple keys may be used to provide selective access to different parts of a data item in accordance with an embodiment of the present invention. -
FIG. 13 is a flow chart of illustrative steps involved in using multiple keys to provide selective access to different part of a data item in accordance with an embodiment of the present invention. -
FIG. 14 is a diagram showing how a string may be represented as a unique binary value in accordance with an embodiment of the present invention. -
FIG. 15 is a diagram showing how a string format may be preserved when converting a string to a binary value in accordance with an embodiment of the present invention. -
FIG. 16 a flow chart of illustrative steps involved in using a format-preserving encryption engine to encrypt a data string represented using a unique binary value in accordance with an embodiment of the present invention. -
FIG. 17 is a flow chart of illustrative steps involved in using a format-preserving decryption engine to decrypt a data string represented using a unique binary value in accordance with an embodiment of the present invention. - An
illustrative cryptographic system 10 in accordance with the present invention is shown inFIG. 1 .System 10 includescomputing equipment 12 andcommunications network 14. Thecomputing equipment 12 may include one or more personal computers, workstations, computers configured as servers, mainframe computers, portable computers, etc. Thecommunications network 14 may be a local area network or a wide area network such as the internet.System 10 may be used in processing data for one or more organizations. -
Computing equipment 12 may be used to supportapplications 16 anddatabases 18. Incomputing equipment 12 in which multiple applications run on the same computer platform, applications and databases may communicate with each other directly. If desired,applications 16 can communicate with each other and withdatabases 18 remotely usingcommunications network 14. For example, anapplication 16 that is run on a computer in one country may access adatabase 18 that is located in another country or anapplication 16 running on one computer may usenetwork 14 to transmit data to anapplication 16 that is running on another computer.Applications 16 may be any suitable applications, such as financial services applications, governmental record management applications, etc. - The data that is handled by
system 10 includes sensitive items such as individuals' addresses, social security numbers and other identification numbers, license plate numbers, passport numbers, financial account numbers such as credit card and bank account numbers, telephone numbers, email addresses, etc. In some contexts, information such as individuals' names may be considered sensitive. - In a typical scenario, a credit card company maintains a
database 18 of account holders. The database lists each account holder's name, address, credit card number, and other account information. Representatives of the credit card company may be located in many different geographic locations. The representatives may usevarious applications 16 to access the database. For example, a sales associate may retrieve telephone numbers of account holders to make sales calls using one application, whereas a customer service representative may retrieve account balance information using another application. Automated applications such as error-checking housekeeping applications may also require access to the database. - To prevent unauthorized access to sensitive data and to comply with data privacy regulations and other restrictions, sensitive data may need to be encrypted. Encryption operations may be performed before data is passed between
applications 16 or before data is stored in adatabase 18. Because various applications may need to access different types of data, thesystem 10 preferably allows data to be selectively encrypted. As an example, each of the telephone numbers and each of the credit card numbers can be individually encrypted using separate cryptographic keys. With this type of selective encryption arrangement, applications that require access to telephone numbers need not be provided with access to credit card numbers and vice versa. - To support encryption and decryption operations in
system 10applications 16 may be provided with encryption and decryption engines. For example, anapplication 16 that accesses adatabase 18 over acommunications network 14 may have an encryption engine for encrypting sensitive data before it is provided to thedatabase 18 and stored and may have a decryption engine for use in decrypting encrypted data that has been retrieved fromdatabase 18 overcommunications network 14. As another example, a first application may have an encryption engine for encrypting sensitive data before passing the encrypted data to a second application. The second application may have a decryption engine for decrypting the encrypted data that has been received from the first application. - Any suitable technique may be used to provide
applications 16 with encryption and decryption capabilities. For example, the encryption and decryption engines may be incorporated into the software code of theapplications 16, may be provided as stand-alone applications that are invoked from within a calling application, or may be implemented using a distributed arrangement in which engine components are distributed across multiple applications and/or locations. -
Key server 20 may be used to generate and store cryptographic keys that are used by the encryption and decryption engines.Key server 20 may includepolicy information 22 thatkey server 20 uses in determining whether to fulfill key requests. As an example,policy information 22 may include a set of policy rules that dictate that keys should only be released if they have not expired and if the key requester's authentication credentials are valid. - In a typical scenario, an application requests a key from
key server 22. When requesting the key, the application provides authentication credentials to thekey server 20. Thekey server 20 provides the authentication credentials toauthentication server 24.Authentication server 24 verifies the authentication credentials and provides the results of the verification operation to the key server overcommunications network 14. If the key requester is successfully authenticated and if the key server determines that the expiration period has not yet expired, the key server can satisfy the key request by providing the requested key to the application over a secure path in network 14 (e.g., over a secure sockets layer link). Other authentication techniques and key request arrangements may be used if desired. - The data handled by the
applications 16 anddatabases 18 ofsystem 10 is represented digitally. The data includes strings of characters (i.e., names, addresses, account numbers, etc.). As shown inFIG. 2 , during encryption operations, anencryption engine 26 encrypts unencrypted strings of characters (sometimes referred to as plaintext) into encrypted strings of characters (sometimes referred to as ciphertext). During decryption operations, adecryption engine 28 decrypts encrypted strings of characters to form unencrypted strings of characters. - The data strings that are handled in a typical data processing system have defined formats. For example, an identification number may be made up of three letters followed by ten digits. The encryption and decryption engines of the present invention are able to encrypt and decrypt strings without changing a string's format (i.e., so that a plaintext identification number made up of three letters followed by ten digits would be encrypted to form corresponding ciphertext make up of three letters and ten digits). The ability to preserve the format of a data string greatly simplifies system operations and allows systems with legacy applications to be provided with cryptographic capabilities that would not be possible using conventional techniques.
- Conventional encryption algorithms can alter the format of a string during encryption, so that it becomes difficult or impossible to use the encrypted version of the string. For example, it may be impossible to store a conventionally-encrypted credit card number in a database table that has been designed to handle strings that contain only digits.
- In accordance with the present invention, data stings can be encrypted and decrypted while preserving the format of the strings. Consider, as an example, the encryption and decryption of credit card numbers. Credit card numbers generally have between 13 and 18 digits. The format for a particular valid credit card number might require that the credit card number have 16 digits. This type of credit card number will be described as an example.
- In a 16-digit credit card number, the digits are typically organized in four groups of four each, separated by three spaces. During a format-preserving encryption operation, an unencrypted credit card number such as “4408 0412 3456 7890” may be transformed into credit-card-formatted ciphertext such as “4417 1234 5678 9114” and during decryption, the ciphertext “4417 1234 5678 9114” may be transformed back into the unencrypted credit card number “4408 0412 3456 7890”.
- The value of a valid sixteenth digit in a credit card number is formed by performing a checksum operation on the first 15 digits using the so-called Luhn algorithm. Any single-digit error in the credit card number and most adjacent digit transpositions in the credit card number will alter the checksum value, so that data entry errors can be identified.
- During encryption operations, the
encryption engine 26 can compute a new checksum value using the first 15 digits of the ciphertext. The new checksum digit can be used in the ciphertext or, if desired, policy information such as a validity period may be embedded within the checksum digit by adding an appropriate validity period index value to the new checksum value. When a validity period is embedded within a checksum digit, the resulting modified checksum value will generally no longer represent a valid checksum for the string. However, applications insystem 10 will be able to retrieve the validity period information from the checksum digit and will be able to use the extracted validity period information in obtaining a decryption key from key server 20 (FIG. 1 ). - This type of embedding operation may be used to store any suitable information within encrypted data. The use of credit card numbers and, more particularly, the use of validity period information that has been embedded within the checksum digits of credit card numbers are described herein as examples.
- Because encryption and
decryption engines FIG. 2 can preserve a desired format for a string during encryption and decryption operations, sensitive data can be secured without requiring entire files to be encrypted. - The encryption and
decryption engines decryption engines - In a typical scenario, an index mapping may be formed using a table having two columns and a number of rows. The first column of the mapping corresponds to the potential character values in a given string position (i.e., the range of legal values for characters in that position). The second column of the mapping corresponds to an associated index. Each row in the mapping defines an association between a character value and a corresponding index value.
- Consider, as an example, a situation in which the string being encrypted has first, fifth, sixth, and seventh string characters that are digits and second, third, and fourth characters that are uppercase letters. In this situation, the possible character values in the first, fifth, sixth, and seventh character positions within the plaintext version of the string might range from 0 to 9 (i.e., the first character in the string may be any digit from 0 through 9, the fifth character in the string may be any digit from 0 to 9, etc.). The possible character values in the second, third, and fourth positions in the string range from A to Z (i.e., the second character in the unencrypted version of the string may be any uppercase letter in the alphabet from A to Z, the third character in the unencrypted version of the string may be any uppercase letter from A through Z, etc.).
- The index mapping in this type of situation may map the ten possible digit values for the first, fifth, sixth, and seventh string characters into ten corresponding index values (0 . . . 9). For the second, third, and fourth character positions, 26 possible uppercase letter values (A . . . Z) may be mapped to 26 corresponding index values (0 . . . 25).
- In a typical string, not all characters have the same range of potential character values. If there are two ranges of potential character values, two index mappings may be used, each of which maps a different set of possible character values to a different set of index values. If there are three ranges of potential character values within the string, three index mappings may be used. For example, a first index mapping may relate a digit character to a first index, a second index mapping may relate a uppercase letter character to a second index, and a third index mapping may relate an alphanumeric character to a third index. In strings that contain a larger number of different character types, more index mappings may be used.
- In general, a string contains a number of characters N. The potential character values in the string are related to corresponding index values using index mappings. An index mapping is created for each character. The indexes used to represent each character may have any suitable size. For example, an index containing 52 index values may be associated with string characters with character values that span both the uppercase and lowercase letters. Because not all of the characters typically have the same range of potential character values, there are generally at least two different index mappings used to map character values in the string to corresponding index values. In a string with N characters, N index mappings are used, up to N of which may be different index mappings.
- Any suitable cryptographic formulation may be used for the format-preserving encryption and
decryption engines encryption engine 26 anddecryption engine 28 use a cryptographic algorithm based on the well known Luby-Rackoff construction. The Luby-Rackoff construction is a method of using pseudo-random functions to produce a pseudo-random permutation (also sometimes referred to as a block cipher). A diagram showing howencryption engine 26 anddecryption engine 28 may be implemented using the Luby-Rackoff construction is shown inFIG. 3 . - During encryption operations, an unencrypted string is divided into two portions. The unencrypted string may be divided into two portions using any suitable scheme. For example, the string may be divided into odd and even portions by selecting alternating characters from the string for the odd portion and for the even portion. With another suitable approach, the unencrypted string is divided into two portions by splitting the string into left and right halves.
- In
FIG. 3 , the first half of the unencrypted string is labeled “L1” and the second half of the unencrypted string is labeled “R1”. During encryption operations withencryption engine 26, the unencrypted string halves L1 and R1 are processed to form corresponding encrypted string halves L3 and R2. During decryption operations withdecryption engine 28, processing flows from the bottom ofFIG. 3 towards the top, so that encrypted string halves L3 and R2 are decrypted to produce unencrypted halves L1 and R1. Processing occurs in threerounds round 40 are performed first, the operations ofround 42 are performed second, and the operations ofround 44 are performed third. During decryption, the operations ofround 44 are performed first, the operations ofround 42 are performed second, and the operations ofround 40 are performed third. - As indicated by
dots 51 inFIG. 3 , the operations ofFIG. 3 may, if desired, be implemented using four or more rounds. For example, eight rounds of a block cipher may be performed. - The block cipher structure of
FIG. 3 encrypts (or decrypts) a string of a particular known size to produce an output string of the same size. During encryption, plaintext is converted to ciphertext (i.e., the block cipher ofFIG. 3 is operated from top to bottom). During decryption, ciphertext is converted to plaintext (i.e., the block cipher ofFIG. 3 is operated from bottom to top). - The block cipher uses a
subkey generation algorithm 38. Thesubkey generation algorithm 38 has three inputs: a key K, a constant C (C1 forround 40, C2 forround 42, and C3 for round 44), and a string S (S1=R1 forround 40, S2=L2 forround 42, and S3=R2 for round 44). - The
subkey generation algorithm 38 may be a function H′ that is based on a cryptographic hash function H and that takes as an input S, C, and K. With one suitable approach, the subkey generation algorithm H′ is given byequation 1. -
H′=H(S|C|K) (1) - In
equation 1, the symbol “|” represents the concatenation function. The cryptographic hash function H is preferably chosen so that the subkey generation algorithm has a suitable cryptographic strength. Illustrative cryptographic hash functions that can be used for hash function H include the SHA1 hash function and the AES algorithm used as a hash function. - The value of the key K is the same for
rounds round 40 is equal to 1, the constant C2 that is used inround 42 is 2, and the constant C3 that is used inround 44 is 3. The value of S varies in each round. Inround 40, S1 is equal to the first half of the unencrypted string R1. Inround 42, S2 is equal to the L2. Inround 44, S3 is equal to R2. - In
round 40, the output of the subkey generation algorithm is subkey SK1, as shown inequation 2. -
SK1=H(S 1 |C 1 |K) (2) - In
round 42, the output of the subkey generation algorithm is subkey SK2, as shown inequation 3. -
SK2=H(S 2 |C 2 |K) (3) - In
round 44, the output of the subkey generation algorithm is subkey SK3, as shown inequation 4. -
SK3=H(S 3 |C 3 |K) (4) - Equations 1-4 involve the use of a cryptographic hash function for the subkey generation algorithm. If desired, the subkey generation algorithm may be implemented using a cryptographic message authentication code (MAC) function. A cryptographic message authentication code function is a keyed hash function. Using a cryptographic message authentication code function,
equation 1 would become H′=MACF(S|C,K), where MACF is the message authentication code function. An example of a message authentication code function is CMAC (cipher-based MAC), which is a block-cipher-based message authentication code function. The cryptographic message authentication code function AES-CMAC is a CMAC function based on the 128-bit advanced encryption standard (AES). - A format-preserving combining operation (labeled “+” in
FIG. 3 ) is used to combine the subkeys SK1, SK2, and SK3 with respective string portions. - During encryption operations, format-preserving
combining operation 46 combines SK1 with string L1 to produce string L2. During decryption operations, format-preservingcombining operation 46 combines SK1 with string L2 to produce string L1. Format-preservingcombining operation 48 combines SK2 with string R1 to produce string R2 during encryption operations and combines SK2 with string R2 to produce string R1 during decryption operations. Format-preservingcombining operation 50 is used to process subkey SK3. During encryption, format-preservingcombining operation 50 combines SK3 with string L2 to produce string L3. During decryption, format-preservingcombining operation 50 combines SK3 with string L3 to produce string L2. - The format-preserving combining operation + preserves the format of the strings L1, L2, L3, R1, and R2 as they are combined with the subkeys SK1, SK2, and SK3. For example, the string L2 that is produced by combining string L1 and subkey SK1 has the same format as the string L1.
- The format-preserving combining operation + may be based on any suitable mathematical combining operation. For example, the function + may be addition mod x or the function + may be multiplication mod x, where x is an integer of an appropriate size (i.e., x=yz, where z is equal to the length of the string S, and where y is equal to the number of possible character values for each character in the string S). If, as an example, the string S contains 16 digits (each digit having one of 10 possible values from 0 to 9), x would be 1016. If the string S contains three uppercase letters (each uppercase letter having one of 26 possible values from A to Z), x would be 263. These are merely illustrative examples. The format-preserving combining function + may be any reversible logical or arithmetic operation that preserves the format of its string input when combined with the subkey.
- Illustrative steps involved in setting up the
encryption engine 26 anddecryption engine 28 are shown inFIG. 4 . Atstep 52, the desired formatting to be used for the encrypted and decrypted strings is defined. - For example, unencrypted strings may be social security numbers that follow the format ddd-dd-dddd, where d is a digit from 0 to 9. The
encryption engine 26 may produce corresponding encrypted strings with the identical format. - As another example, the string format may be dddd dddd dddd dddc, where d is a digit from 0 to 9 and where c is a checksum digit (a digit from 0 to 9). The block cipher may be applied to the leading 15 digits of the credit card number and a checksum value may be recomputed from the encrypted version of the leading 15 digits using the Luhn algorithm. Validity period information may be embedded into the checksum digit by adding a validity period index to the recomputed checksum value. The index may, as an example, specify that an index value of 1 corresponds to the year 2006, an index value of 2 corresponds to the year 2007, an index value of 3 corresponds to the year 2008, etc. If the recomputed checksum is 3 (as an example), and the validity period for the encryption operation is 2006, the index value of 1 (corresponding to year 2006) may be added to the checksum value of 3 to produce a checksum digit of 4 for the ciphertext. In this situation, the final version of the encrypted string has the form dddd dddd dddd dddc, where the value of c is 4. The overall encryption process implemented by the
encryption engine 26 maintains the digit format of the string, because both the unencrypted and encrypted versions of the string contain 16 digits. - The inclusion of additional constraints on the format of the encrypted string may be necessary to ensure that the encrypted strings are fully compliant with legacy applications. During
step 52, a user decides which of these ancillary constraints are to be included in the definition of the required format for the string. - At
step 54, for each character in the string, an index mapping is created by defining a set of legal character values and a corresponding index of sequential values that is associated with the legal characters values. For example, if the legal characters for a particular character position in a string include the 10 digits (0.9) and the 26 lowercase letters (a . . . z), a suitable indexingscheme associates digits 0 through 9 withindex values 1 through 10 and associates letters a through z with index values 11-36. In this index mapping, the index values that are created are all adjacent. Because there are no gaps in the indices,index value 10 is adjacent to index value 11 (in the present example). If the string contains more than one type of character, there will be more than one index mapping associated with the characters in the string. - At
step 56, a value for key K is obtained. The value of K may be obtained, for example, by generating K from a root secret and other information using a key generation algorithm inkey server 20. - At
step 58, the format-preserving combining operation “+” is defined. As described in connection withFIG. 3 , the format-preserving combining operation may be addition modulo x, multiplication modulo x, or any other suitable logical or arithmetic operation that preserves the format of the string when combining the string with a subkey and that is reversible. - At
step 60, a block cipher structure is selected for theencryption engine 26 anddecryption engine 28. The block cipher structure may, for example, by a Luby-Rackoff construction of the type described in connection withFIG. 3 . Other suitable block cipher structures may be used if desired. - At
step 62, a subkey generation algorithm is selected. Suitable subkey generation algorithms include those based on cryptographic hash functions such the SHA1 hash function and AES algorithm used as a hash function. Suitable subkey generation algorithms also include those built on cryptographic message authentication code functions such as AES-CMAC. - After performing the setup steps of
FIG. 4 , theencryption engine 26 anddecryption engine 28 can be implemented insystem 10 and sensitive data can be secured. - Illustrative steps involved in using the
encryption engine 26 anddecryption engine 28 when processing strings of data insystem 10 are shown inFIGS. 5 and 6 . As described in connection withFIGS. 1 and 2 , theencryption engine 26 anddecryption engine 28 may be called by an application or may be part of anapplication 16 that is running ondata processing system 10. The data strings that are encrypted and decrypted may be strings that are retrieved from and stored in fields in adatabase 18 or may be strings that are passed between applications 16 (e.g.,applications 16 that are running on thesame computing equipment 12 or that are communicating remotely over a communications network 14). - The flow chart of
FIG. 5 shows steps involved in encrypting a data string. - As shown in
FIG. 5 , the data string is preprocessed atstep 64, encrypted atstep 72, and postprocessed atstep 74. - At
step 66, the encryption engine obtains the unencrypted string. The string may be retrieved from adatabase 18 or received from anapplication 16. - At
step 68, the string is processed to identify relevant characters. Duringstep 68, dashes spaces, checksums, and other undesired characters can be removed from the string and the relevant characters in the string can be retained. - For example, if the string is a social security number that contains nine digits separated by two dashes, the string can be processed to remove the dashes. Although the dashes could be left in the string, there is no purpose in encrypting a dash character in the unencrypted string to produce a corresponding dash character in the encrypted string (as would be required to preserve the format of the entire string).
- As another example, if the string being processed is a credit card number containing 16 digits and three spaces, the spaces can be removed. The checksum portion of the 16 digit credit card can be ignored by extracting the 15 leading digits of the credit card number as the relevant characters to be processed further.
- At
step 70, theencryption engine 26 uses the index mappings that were created duringstep 54 ofFIG. 4 to convert the processed string (i.e., the string from which the irrelevant characters have been removed) into an encoded unencrypted string. For example, consider a license plate number in which the first, fifth, sixth, and seventh character positions contain digits (i.e., numbers from 0 through 9) and the second, third, and fourth character positions contain uppercase letters. An index mapping may be used to convert the character values in the first, fifth, sixth, and seventh character positions into corresponding index values ranging from 0 through 9. Another index mapping may be used to convert the character values in the second, third, and fourth character positions into corresponding index values ranging from 0 through 25. The index values used in each index mapping may be sequential. Once the characters have been encoded using the sequential index values, processing can continue atstep 72. - At
step 72, theencryption engine 26 encrypts the encoded string using the format-preserving block cipher that was established during the operations ofFIG. 4 . For example, theencryption engine 26 can perform the Luby-Rackoff encryption operations described in connection withFIG. 3 . Duringstep 72, the subkey generation algorithm that was selected atstep 62 ofFIG. 4 and the format-preserving combining algorithm + that was defined atstep 58 ofFIG. 4 are used to transform the unencrypted encoded string into an encrypted encoded string. - At
step 76, the same index mappings that were used during the encoding operations ofstep 70 are used to convert the index values of the encrypted string back into characters (i.e., characters in the legal set of character values that were defined for each character position at step 54). Decoding the encoded version of the string using the index mappings returns the string to its original character set. - At
step 78, the decoded encrypted string is processed to restore elements such as dashes and spaces that were removed atstep 68. When replacing a checksum value, a new valid checksum value can be computed from the encrypted version of the string and validity period information or other suitable information can be embedded within the checksum digit (e.g., by adding a validity period index to the new valid checksum value to produce a checksum digit for the decoded encrypted string). The decoded encrypted string is ciphertext that corresponds to the plaintext unencrypted string that was obtained atstep 66. If desired, the entire string can be encrypted. With this type of arrangement, the checksum removal operation ofstep 68 and the checksum digit computation operation ofstep 78 can be omitted. - By processing the string at
step 78, the extraneous elements of the string that were removed atstep 68 are inserted back into the string. Because the extraneous elements are reinserted into the string and because a format-preserving block cipher was used instep 72, the encrypted string that is produced will have the same format as the original unencrypted string. This allows the encrypted string to be used byapplications 16 anddatabases 18 that require that the original string's format be used. - At
step 80, the encrypted string is provided to anapplication 16 ordatabase 18. Legacy applications and databases that require a specific string format may be able to accept the encrypted string. - Illustrative steps involved in using
decryption engine 28 to decrypt a string that has been encrypted using the process ofFIG. 5 are shown inFIG. 6 . Thedecryption engine 28 may be invoked by anapplication 16 or may be part of anapplication 16 that is running ondata processing system 10. The data string that is being decrypted in the process ofFIG. 6 may be an encrypted string that has been retrieved from adatabase 18 or may be a string that has been retrieved from an application. - As shown in
FIG. 6 , the encrypted data string is preprocessed atstep 82, is decrypted atstep 90, and postprocessed atstep 92. - At
step 84, the decryption engine obtains the encrypted string. The encrypted string may be retrieved from adatabase 18 or received from anapplication 16. - At
step 86, the encrypted string is processed to identify relevant characters. Duringstep 86, dashes spaces, checksums, and other extraneous elements can be removed from the string. The relevant characters in the string are retained. The process of removing extraneous characters duringstep 86 is the same as that used during the processing of the unencrypted string that was performed duringstep 68 ofFIG. 5 . - If the string being decrypted is a social security number that contains nine digits separated by two dashes, the encrypted string can be processed to remove the dashes.
- As another example, if the string being processed during
step 86 is a credit card number containing 16 digits and three spaces, the spaces can be removed prior to decryption. The checksum digit of the 16 digit credit card can be ignored by extracting the 15 leading digits of the encrypted credit card number as the relevant characters to be decrypted. If information is embedded in the checksum digit (e.g., validity period information), the checksum digit may be processed to extract this information duringstep 86. - At
step 88, thedecryption engine 26 uses the index mappings that were defined atstep 54 ofFIG. 4 and that were used during the encryption operations ofFIG. 5 to convert each of the characters of the processed encrypted string (i.e., the encrypted string from which the extraneous characters have been removed) into an encoded encrypted string. If, as an example, the legal set of characters associated with the first character of the encrypted string is defined as the set of 10 digits, a 10 digit index may be used to encode the first character of the encrypted string. If the legal set of characters associated with the second character of the encrypted string is defined as the set of 26 uppercase letters, a 26-digit index may be used to encode the second character of the encrypted string. Duringstep 88, each character of the string is converted to a corresponding index value using an appropriate index mapping. - At
step 90, the encoded version of the encrypted string is decrypted. Thedecryption engine 28 decrypts the string using the format-preserving block cipher that was established during the operations ofFIG. 4 . For example, thedecryption engine 26 can perform the Luby-Rackoff decryption operations described in connection withFIG. 3 . Duringstep 90, the subkey generation algorithm that was selected atstep 62 ofFIG. 4 and the format-preserving combining algorithm + that was defined atstep 58 ofFIG. 4 are used to transform the encrypted encoded string into a decrypted encoded string. - At
step 94, the index mappings that were used during the encoding operations ofstep 88 are used to convert the index values of the decrypted string back into their associated characters (i.e., characters in the legal set of character values that were defined for each character position at step 54). This returns the decrypted string to its original character set. In strings that contain more than one different type of character, multiple different index mappings are used. - At
step 96, the decoded decrypted string is processed to restore elements such as dashes, spaces, and checksum values that were removed atstep 88. When replacing a checksum value, a new valid checksum value may be computed from the decrypted version of the string. This ensures that the decrypted version of the string will be returned to its original valid state. - During the string processing operations of
step 96, the extraneous elements of the string that were removed atstep 88 are inserted back into the string. This restores the string to its original unencrypted state (i.e., the state of the string when obtained atstep 66 ofFIG. 5 ). - At
step 98, the decrypted string is provided to anapplication 16 ordatabase 18. - By incorporating format-preserving encryption and
decryption engines data processing system 10, legacy applications and databases and other applications and databases can be provided with cryptographic capabilities without disrupting their normal operation. - The key K that is used by encryption and
decryption engines key server 20 manually and may be distributed to encryption anddecryption engines key server 20. The root secret may be supplied tokey server 20 manually or may be produced using a pseudo-random number generator. - To ensure that keys are only distributed to authorized
applications 16, it may be advantageous to mathematically compute each key K frompolicy information 22 - (
FIG. 1 ). As an example, key K may be computed bykey server 20 usingequation 5. -
K=f(RSECRET,IDEN) (5) - In
equation 5, the parameter IDEN is an identifier, the parameter RSECRET is a root secret, and the function f is a one-way function such as a hash function. An example of a hash function that may be used for function f is the SHA1 hash function. If desired, other hash functions and one-way functions may be used for function f. - The identifier IDEN may include information that identifies an individual, a group, a policy, or an application. As an example, the identifier may be based on the name of an individual, the name of an organization, the name of a group, or any other suitable user name. The identifier may also be based on the name of a policy (e.g., “PCI” indicating that cryptographic operations should be performed in accordance with payment card industry standards) or may be based on the name of an application. When an application requests key K from
key server 20, thekey server 20 may use all or part of the value of IDEN in determining whether the key requester is authorized to receive K. If the key requester is authorized, the function ofequation 5 may be used to generate K. - To support version-based functions in
system 10, it may be desirable to allow identities and their associated keys K to expire. Identity and key expiration may be implemented by requiring that a validity period be included in each identity IDEN. The validity period indicates the dates on which the key K is valid. Validity periods can be expressed in terms of absolute dates, abbreviated dates, version numbers that relate to valid date ranges or key versions, etc. - One suitable format for the validity period is an expiration date. For example, a validity period for IDEN may be made up of a year of expiration (e.g., 2007), may be made up of a week of expiration (e.g., week number 45), may be made up of a month and year of expiration (e.g., 03/2007 or 03/07), etc. Validity periods may also be constructed using a date range (e.g., 2006-2007) during which key K is valid. With one suitable arrangement for use when encrypting and decrypting credit cards, the validity period in an identity IDEN may be a credit card expiration date (e.g., 05/08).
- The credit card expiration date or other such information (e.g., a record locator, cardholder name, etc.) may be combined with information that labels the identity IDEN as being associated with credit cards and the payment card industry (PCI). The value of IDEN might be formed, for example, by combining the strings “Joe Smith” (the name of a holder of a credit card), “PCI” (indicating the payment card industry), and a credit card expiration date to form (as an example) a value for IDEN of “JOE_SMITH_PCI_05/08.”
- Illustrative steps involved in forming a key
K using equation 5 are shown inFIG. 7A . - At
step 100,key server 20 obtains the parameter RSECRET (e.g., using a pseudorandom number generator operating atkey server 20, by retrieving RSECRET from a cache atkey server 20, etc.). - At
step 102, thekey server 20 obtains the parameter IDEN. The parameter IDEN may be provided tokey server 20 as part of a key request (e.g., in a single transmission requesting a key or in a series of related transmissions requesting a key). Information such as a user identity (e.g., a username or part of a username, a group identity, etc.), validity period (e.g., an expiration date, a valid date range, a version number, or a combination of such validity period information), and industry/key type (e.g., “PCI” for the payment card industry) may be included in the value of the IDEN string. If desired, components of the IDEN string may be represented using multiple strings or additional information may be included in the IDEN string. - At
step 104,key server 20 may use function f of equation 5 (e.g., a SHA1 hash function or other one-way function) to compute K from the known values of the root secret RSECRET and the identifier IDEN. - Keys may be generated using the operations of
FIG. 7A at any suitable time. For example,key server 20 may generate a key K whenever a valid key request is received. If desired,key server 20 may maintain a key cache in which previously generated keys are stored. Use of a key cache may reduce the processing burden onkey server 20. - A flow chart of illustrative steps involved in generating key K using an approach in which generated key K is persistently stored is shown in
FIG. 7B . With the approach ofFIG. 7B , key K is generated randomly atstep 105. For example, key K may be generated using a pseudorandom number generator atkey server 20 when a key is requested in a key request containing an identifier IDEN. - At
step 107, the key K is stored in persistent storage (e.g., a key cache maintained at key server 20).Key server 20 also stores an association between the key K that has been generated and the value of identifier IDEN from the key request. The association may be provided by making an entry in a database that contains the key and the related identifier IDEN (as an example). At a later time, when key K is requested,key server 20 can retrieve the correct key K from storage to satisfy the request using the value of the identifier IDEN that is provided in the key (step 109). The approach ofFIG. 7B therefore allows thekey generator 20 to obtain the key K by generating the key K randomly (if no key value has been cached) or by retrieving a previously stored version of key K using the identity value IDEN. -
Key server 20 also preferably maintains policy information 22 (FIG. 1 ).Policy information 22 includes policy rules that may be used in determining which key requests should be granted and which key requests should be denied. An example of a policy rule is a rule that requires that a key requester authenticate successfully as part of a PCI LDAP (Lightweight Directory Access Protocol) group whenever the parameter IDEN includes the industry type “PCI.” As another example, a policy rule might specify that key requests should only be satisfied if made at date that falls within the validity period specified in the IDEN parameter.Key server 20 may maintain a clock or may otherwise obtain trustworthy external information on the current date. External information such as this may be used bykey server 20 in evaluating whether the policy rules have been satisfied for a particular key request. In a typical scenario, the policy rules atkey server 20 will specify multiple criteria that must be satisfied (e.g., proper authentication of a given type must be performed, a validity period restriction must be satisfied, etc.). - In some situations,
authentication server 24 is used in authenticating key requesters. In other situations,key server 20 may perform authentication. Key requests may be made byencryption engine 26 when a copy of a key K is needed to perform an encryption operation or bydecryption engine 28 when a copy of key K is needed to perform a decryption operation. In general, any suitable technique may be used to process key requests. Flow charts presenting three illustrative ways in which key requests for key K may be handled insystem 10 are shown inFIGS. 8, 9, and 10 . - In the example of
FIG. 8 , an encryption engine or decryption engine associated with anapplication 16 makes a key request tokey server 20 atstep 106. Key requests such as the key request ofstep 106 may be made in a single transmission overnetwork 14 between thecomputing equipment 12 on which the requesting application resides or may be made in multiple associated transmissions. The key request may include authentication credentials and an identifier such as the identifier parameter IDEN described in connection withFIGS. 7A and 7B . The identifier that is associated with the key request may include information such as a validity period (e.g., a credit card expiration date), user name, etc. Different types of keys may require different levels of authentication. The authentication credentials that are provided as part of the key request are preferably provided in a form that is suitable for the type of key being requested. One example of authentication credentials is a userID and password. Biometric authentication credentials may also be used (as an example). Atstep 108,key server 20 forwards the authentication credentials that have been received from the key requester toauthentication server 24 overcommunications network 14. - At
step 110,authentication server 24 verifies the authentication credentials. For example, if the authentication credentials include a userID and password,authentication server 24 may compare the userID and password to a list of stored valid userIDs and passwords. - If the
authentication server 24 determines that the authentication credentials are not valid, the authentication process fails. A suitable response to this failure may be generated atstep 112. For example,authentication server 24 can notifykey server 20 that the authentication credentials are not valid and can generate suitable alert messages for entities insystem 10. Other suitable actions include generating an error message that promptskey server 20 and/or the key requester to resubmit the credentials (e.g., to avoid the possibility that the authentication failure was due to mistyped authentication credentials). - If the
authentication server 24 determines that the authentication credentials are valid, theauthentication server 24 notifies thekey server 20 accordingly. In a typical scenario, the authentication server provides thekey server 20 with an “assertion” indicating that the credentials are valid. The assertion may include information on group membership and roles and rights for the authenticated party. - At step 114,
key server 20 applies policy rules 22 to the key request. Information such as the identity information IDEN, the authentication results from authentication server 24 (e.g., the assertion), and external information such as the current date may be used by thekey server 20 in enforcing the policy rules. - As an example, identity information, authentication results, and external information may be used in determining which policy rules should be applied. Certain policy rules may be applied when IDEN indicates that the key requester is making a “PCI” key request. Such rules may, as an example, require a particular level of authentication. Certain policy rules may also be applied when a key request is made on particular times and dates (e.g., more stringent authentication may be required for evening and weekend key requests). Certain policy rules may apply to particular groups of users, etc.
- In addition to determining which policy rules should be applied,
key server 20 may also use identity information, authentication results, and external information in determining whether the applicable policy rules have been satisfied. For example, during step 114,key server 20 may determine whether the key request includes valid validity period information (e.g., whether an expiration period has expired).Key server 20 may also check to make sure that appropriate valid authentication results have been received fromauthentication server 24, may check the key requester's membership in a directory group, etc. - If the criteria set forth in the applicable policy rules are not satisfied, the key request fails and appropriate error notifications may be generated or other actions may be taken at
step 116. - If the applicable policy rules are satisfied,
key server 20 may generate a key K to satisfy the key request atstep 118. The key K may be generated using operations of the type shown inFIG. 7A or may be generated or retrieved using operations of the type shown inFIG. 7B . The key K may then be supplied to the key requester over a secure path incommunications network 14. - In this example,
key server 20 applies the applicable policy rules to the key request following successful verification of the authentication credentials byauthentication server 24. If desired, the policy rules can be applied betweensteps - Another illustrative technique that may be used by an encryption engine or decryption engine associated with an application to obtain key K is shown in
FIG. 9 . With this technique, authentication is performed usingauthentication server 24 before the key request is made tokey server 20. - At
step 120, anapplication 16 that desires a key K provides authentication credentials toauthentication server 24 for verification. If desired, the application may also provide an identifier (e.g., parameter IDEN) toauthentication server 24, which may use this information to determine what type of assertion to provide to the application following successful verification of the authentication credentials. - At
step 122,authentication server 24 verifies the authentication credentials. If the authentication credentials are not valid, an appropriate response may be made at step 124 (e.g., by providing the application with another chance to provide valid credentials, by issuing an alert, etc.). - If the authentication credentials are determined to be valid, the authentication server provides the application with an assertion over
communications network 14. The assertion may be, for example, a Kerberos ticket. - At
step 126, the application uses the assertion that has been received from the authentication server in making a key request tokey server 20. The key request may include the assertion fromauthentication server 24 and an identifier (e.g., parameter IDEN). - At
step 128, the key server applies policy rules 22 to the key request to determine whether the key request should be satisfied.Key server 20 may use identity information (e.g., parameter IDEN, which may include a validity period), authentication results (e.g., the assertion), and external information (e.g., the current date) in determining which policy rules should be applied to the key request. The key server may also use this information in determining whether the applicable policy rules have been satisfied. As an example,key server 20 may determine whether the key request includes valid validity period information duringstep 128 and may check to determine whether the assertion is valid and sufficient to satisfy the policy rules. - If the applicable policy rules are not satisfied, the
key server 20 may request that the application issue a new request or may take other suitable actions in response to the failure (step 130). - If the key server determines that the applicable key access policy rules have been satisfied, the key server may retrieve key K from cache or may generate an appropriate key K, as discussed in connection with
FIGS. 7A and 7B . Atstep 132, the key K may be provided fromkey server 20 to the requesting application overcommunications network 14. - With the approach of
FIG. 10 , authentication operations are performed bykey server 20, soauthentication server 24 need not be used. - At
step 134, an application that needs key K makes a key request tokey server 20. The key request may include an identifier (e.g., parameter IDEN) and shared secret information. The shared secret information may be, for example, a shared secret (i.e., a secret known by the application and by the key server) or shared secret information that is derived from the shared secret (e.g., by hashing the shared secret with an identifier such as parameter IDEN). - At
step 136, the key server verifies the shared secret information. The key server may, as an example, compare the shared secret information from the key request to previously generated and stored shared secret information or to shared secret information that is generated in real time based on the received identity (e.g., IDEN). If the shared secret information is valid, the key server can determine which key access policy rules are to be applied to the key request (e.g., using external information such as the current date, using identity information IDEN, etc.). After determining which policy rules to use,key server 20 applies the appropriate policy rules to the key request. - If the criteria set forth in the policy rules are not satisfied, the key request fails and appropriate actions can be taken at
step 138. - If the policy rules are satisfied, the key server can retrieve key K from cache or may generate key K in real time (e.g., using the operations of
FIGS. 7A and 7B ). The requested key may then be provided to the key requester over communications network 12 (step 140). - One of the potential advantages of using
key server 20 is that it helps to avoid problems that might otherwise arise when storing keys in local cache oncomputing equipment 12. If keys are only maintained in local storage, it may be difficult to recreate a key when needed to resurrect a server that has crashed. By usingkey server 20, keys can be regenerated as needed at the key server. - Systems such as
system 10 ofFIG. 1 may use validity periods to control when keys are valid. A first application may encrypt plaintext using a cryptographic key that is based on a given validity period. The resulting ciphertext may then be stored in a database and retrieved by a second application or may be provided directly to the second application overnetwork 14. The second application must obtain a copy of key K to decrypt the ciphertext. The key K must be generated using the given validity period. If an incorrect validity period is used in generating K, the value of K will be incorrect and the second application will not be able to use that value of K to decrypt the ciphertext. - It may be desirable to selectively grant applications access to different parts of a data string. Consider the example of a credit card number. As shown in
FIG. 11 , a sixteen digit credit card number may include three parts. The leading six digits of the credit card number are sometimes referred to as the bank identification number (BIN). The next six digits of the credit card number are sometimes referred to as the account number core and form part of the credit card holder's account number. The last four digits of the credit card number are sometimes referred to as user account number information and are used with the account number core to identify a credit card holder's account. - Different parties may be entitled to access different parts of the credit card number. Some parties may only need access to the BIN. Other parties may require access to the entire credit card number. As a result, it may be desirable to selectively grant access to different portions of the credit card number to different parties.
- Selective access may be provided to different portions of a data item using format-preserving cryptography. Users (individuals, organizations, applications, etc.) that require access to one part of a data item, may be provided with appropriate cryptographic key(s) to access that part of the data item, whereas users that require access to another portion of the data item may be provided with appropriate key(s) to access that portion. Using this type of arrangement, a first user might, for example, be provided with access to an entire social security number, whereas a second user might only be provided with access to the last four digits of a social security number. As another example, a first user might be provided with access to the first or last four digits of a credit card number, whereas a second user might be provided with access to the entire credit card number. In scenarios with three or more users, each user may likewise be provided with access to different portions of a social security number, credit card number, or other data item.
- Consider, as an example, a plaintext data item P. As shown in
FIG. 12 , plaintext P may be made up of two parts: plaintext P1 and plaintext P2. As an example, plaintext P might be a credit card number and plaintext portion P2 might be the last four digits of the credit card number. In this type of example, plaintext P1 would represent the leading twelve digits of the credit card number. - Using a first format-preserving cryptographic algorithm (e.g., a block-cipher-based algorithm of the type described in connection with
FIG. 3 ) and a first cryptographic key K1, plaintext P1 can be converted into ciphertext C1 and ciphertext C1 can be converted into plaintext P1, as shown inFIG. 12 . A second format-preserving cryptographic algorithm (e.g., a block-cipher-based algorithm of the type described in connection withFIG. 3 ) and a second cryptographic key K2 may be used to convert ciphertext C1 and plaintext portion P2 into ciphertext C and may be used to convert ciphertext C into ciphertext portion C1 and plaintext portion P2. - During a first set of encryption operations, format-preserving encryption algorithm E1 and cryptographic key K1 are used to encrypt plaintext P1 to produce corresponding ciphertext C1, whereas plaintext portion P2 is left unencrypted. During a second set of encryption operations, format-preserving encryption algorithm E2 and cryptographic key K2 are used to encrypt ciphertext C1 and plaintext P2 to produce ciphertext C. Encryption algorithm E1 is a format-preserving encryption algorithm that maps plaintext P1 to ciphertext C1 that is in the same format as plaintext P1. Encryption algorithm E2 is a format-preserving encryption algorithm that maps input (C1, P2) to ciphertext C that is in the same format as (C1, P2). In this context, input (C1, P2) serves as “plaintext” corresponding to output ciphertext C.
- When decrypting ciphertext C, a decryption algorithm D2 (corresponding to encryption algorithm E2) may perform decryption operations with key K2 to produce ciphertext C1 and plaintext part P2. Decryption algorithm D2 is a format-preserving decryption algorithm, so output (C1, P2) is in the same format as input C. Following decryption operations with decryption algorithm D2, decryption algorithm D1 (corresponding to encryption algorithm E1) may perform decryption operations on C1 using key K1 to produce plaintext P1. Decryption algorithm D1 is a format-preserving decryption algorithm, so output P1 is in the same format as input C1.
- A first user (USER1) may be provided with key K1 and key K2. A second user (USER2) may be provided with only key K2. Because USER1 has both keys, USER1 can decrypt C with decryption function D2 and key K2 to produce C1 and P2 and can decrypt C1 with decryption function D1 and K1 to produce P1. Plaintext P1 and plaintext P2 can be assembled to produce plaintext P, so USER1 can access all of P. Because USER2 has only key K2, USER2 can only use decryption function D2 to decrypt C and produce ciphertext C1 and plaintext P2. USER2 is therefore able to access only plaintext P2, not plaintext P1.
- Illustrative steps involved in using format-preserving encryption and decryption algorithms to selectively provide access to different parts of a data item are shown in
FIG. 13 . Atstep 142,key server 20 or other suitable entity may be used to selectively distribute keys to users (i.e., to software applications or parts of applications that are associated with individuals, organizations, etc.). Different keys may be distributed to different users depending on the level of access that it is desired to grant each user. For example, atstep 144, first and second keys such as keys K1 and K2 ofFIG. 12 may be provided to a first user USER1, as described in connection withFIG. 12 . Atstep 146, second key K2 may be provided to a second user USER2, as described in connection withFIG. 12 . - At
step 148, keys K1 and K2 are used in encrypting different portions of the data item P. For example, key K1 may be used to encrypt plaintext part P1 of P to produce corresponding ciphertext C1, whereas key K2 may be used in encrypting both C1 and plaintext part P2 of P to produce corresponding ciphertext C. The selective encryption operations ofstep 148 may be performed at any suitable time (e.g., before, after, or during the key distribution operations of step 142). Each encryption step may use a unique encryption algorithm such as encryption algorithms E1 and E2 ofFIG. 12 . Encryption algorithm E1, which may be used to encrypt plaintext P1, may be a format-preserving encryption algorithm that is suitable for encrypting the last four digits of a credit card number (as an example). Encryption algorithm E2 may be a format-preserving encryption algorithm that is suitable for encrypting a 16 digit credit card number (as an example). - During
step 150, format-preserving decryption algorithms (e.g., decryption algorithm D2 corresponding to encryption algorithm E2 and decryption algorithm D1 corresponding to encryption algorithm E1) may be used to reverse the encryption operations ofstep 142. In particular, decryption algorithm D2 and key K2 may be used by USER2 to decrypt C to produce ciphertext C1 and plaintext P2, thereby providing USER2 with access to plaintext part P2 of plaintext P, but not access to plaintext part P1 of plaintext P. Because USER1 obtained both keys K1 and K2 duringstep 142, USER1 is able to decrypt C with D2 using key K2 to produce C1 and plaintext P2 and is able to decrypt C1 with D1 and key K1 to produce P1. This allows USER1 to access all parts of P (i.e., both P1 and P2 in this example). - If desired, more than two levels of encryption may be provided. For example, plaintext P may be divided into three or more portions Pi, three or more format-preserving encryption algorithms Ei and three or more corresponding keys Ki may be used to encrypt each portion in a successive operation as described in connection with
FIGS. 12 and 13 . Following selective key distribution to three or more users, a corresponding number (i.e., three or more) matching decryption algorithms Di may be used to provide these users with selective access to the different plaintext portions Pi. The arrangement ofFIGS. 12 and 13 in which a string P was divided into two portions and in which two users were provided with selective access to different portions of the string is merely illustrative. - During string preprocessing operations (e.g., the encoding operations of
step 70 ofFIG. 5 and step 88 ofFIG. 6 ), it may be desirable to convert characters into unique binary values. These unique binary values may then be encrypted (as described in connection with the format-preserving encryption operations ofstep 72 ofFIG. 5 ) or decrypted (as described in connection with the format-preserving decryption operations ofstep 90 ofFIG. 6 ). - One type of technique that may be used when encoding strings as unique binary values is illustrated in
FIG. 14 . In the example ofFIG. 14 , an unencoded (plaintext) string P is converted into a unique binary value UBV. String P (in this example) is made up of characters P4, P3, P2, P1, and P0. Characters P4, P2, and P1 are digits and may therefore have any value between 0 and 9 (i.e., 0 1, 2, 3, . . . 9). Characters P3 and P0 are letters and may have any letter value (i.e., A, B, C, D, . . . Z). Each digit character may have one of ten values and each letter character may have one of 26 values. To uniquely convert string P to binary, a formula such asformula 152 may be used. - In
formula 152, P0 represents a numeric value for letter P0. In a typical indexing scheme for letters, “A” corresponds to 0, “B” corresponds to 1, . . . and “Z” corresponds to 25, so if P0 is the letter “B,” the numeric value for P0 inequation 152 will be 1. P1 is a digit. In a typical encoding scheme for digits, 0 corresponds to 0, 1 corresponds to 1, . . . and 9 corresponds to 9, so if P1 is the digit “3,” the value of P1 will be 3. Using an encoding scheme of this type, character P2 will have a numeric value of 0 to 9, P3 will have a numeric value of 0 to 25, and P4 will have a numeric value of 0 to 9. - As shown in
formula 152, the numeric values of the characters P0, P1, P2, P3, and P4 are multiplied byrespective coefficients formula 152 represents the number of possible values of the previous character. For example, informula 152, the numeric value of character P1 is multiplied bycoefficient 154. The value ofcoefficient 154 is 26, because P0 (the character that is just prior to character P1 in string P) may have any one of 26 possible values.Coefficient 156 of numeric value P2 has a value of 260, because the combination of preceding characters P0 and P1 could have any of 260 possible values. Likewise, the value ofcoefficient 158 of P3 is 2600 because there are 2600 possible combinations of numeric values for preceding characters P0, P1, and P2 and the value ofcoefficient 160 of P4 is 67600 because there are 67600 possible combinations of numeric values for preceding characters P0, P1, P2, and P3. Although the numbers in the coefficients inFIG. 14 are represented inbase 10 for clarity, when computing the unique binary value UBV, the base 10 numeric values of the coefficients and the numeric values of the encoded characters (e.g., the numeric values of the digits and letters of string P) are represented in binary (i.e., inbase 2, as “1s” and “0s”). The mapping provided by unique binaryvalue encoding function 152 is unique in that no two character strings PA and PB will map to the same binary value UBV, when PA is not the same as PB. - To ensure that the operation of the format-preserving encryption and decryption functions of
FIGS. 5 and 6 are successful at preserving the format of a binary-encoded string, care should be taken that the binary values that are produced during encryption and decryption operations are format compliant. The encrypted version of the binary-encoded string that is produced at the output ofstep 72 inFIG. 5 should be format compliant to ensure that the postprocessed string that is produced at the output ofstep 74 ofFIG. 5 is in the same format as the string originally obtained atstep 66. Similarly, the decrypted version of the binary-encoded string that is produced at the output ofstep 90 ofFIG. 6 should be format compliant to ensure that the postprocessed string produced following the operations ofstep 92 ofFIG. 6 is in the same format as the string originally obtained atstep 84. - Encoded binary values are considered to be format compliant when their unencoded form lies within the same range of values as their original form. Consider, as an example, the character “9”. This character is a digit and can be numerically represented by the base 10 number “9.” In binary, the
number 9 is 1001. Using a block cipher of the type described in connection withFIG. 3 , encryption operations may be performed that transform the unencrypted binary value 1001 to an encrypted value of 1111 (as an example). This binary value is not format compliant, because it corresponds to a base 10 value of “15,” which is not within the permissible range for a single digit (i.e., “15” does not lie within the range of “0,” “1”, “2,” . . . . “9”). The same type of problem can occur during decryption if the decrypted version of a binary-encoded value at the output ofstep 90 is not format compliant. - To ensure that encrypted and decrypted values are format compliant, the block cipher operations of step 72 (
FIG. 5 ) and step 90 (FIG. 6 ) can be repeated while checking the output of the cipher for format compliance. Each iteration of the block cipher will modify the binary output. Eventually, the binary output of the block cipher will be format compliant, at which point no further iterations of the block cipher are performed. - This type of arrangement is shown in
FIG. 15 . In the example ofFIG. 15 , an unencrypted string P is being encrypted. The string P in theFIG. 15 example is the digit “9.” Using an index in which digits are mapped to corresponding numeric values (i.e., “0” is mapped to “0,” “1” is mapped to “1,” . . . and “9” is mapped to “9), the string P is converted to a numeric value of 9. In binary-encoded format, the unencrypted encoded version of string P is 1001. As shown inFIG. 15 , the left half of the binary-encoded version of P (“10”) is used as the input L1 to the block cipher ofFIG. 3 and the right half of the binary-encoded version of P (“01”) is used as the input R1 to the block cipher ofFIG. 3 . - As described in connection with
FIG. 3 , a certain number of rounds of the block cipher (e.g., eight rounds) may be used to perform an initial encryption operation on the binary-encoded value 1001. In theFIG. 15 example, this initial encoding operation results in the binary value of 1111. If this value were format compliant, the encryption process would be complete. However, in the present example, the binary value of 1111 is not format compliant, because it corresponds to a base 10 numeric value of 15, which is not within the permissible range numeric values for a digit (i.e., 15 does not lie within the range of 0-9, so the string “15” is not in the same format as the original string “9”). As a result, additional rounds of the block cipher are performed (e.g., an additional eight rounds). This produces the encrypted binary value 1000 (in theFIG. 15 example). Because the binary value 1000 corresponds to a base 10 numeric value of 8, which lies within the permissible digit numeric values of 0-9, the binary value 1000 forms a proper format-compliant encrypted binary-encoded version of string P. No further rounds of the block cipher need be performed. - Decryption operations may be performed in the same way. If, following an initial application of a given number of rounds of the block cipher, the initial binary value of a string that is produced is not format compliant, additional decryption operations can be performed. As soon as a binary output is produced that is format compliant, the block cipher operations may be terminated and the binary value may be converted into an appropriately formatted string of characters (e.g., letters and digits), as described in connection with
step 92. - Illustrative steps involved in performing format-preserving encryption operations on a string using one or more repeated iterations of a block cipher to ensure format compliance are shown in
FIG. 16 . - As shown in
FIG. 16 , a data string may be preprocessed atstep 64, encrypted atstep 162, and postprocessed atstep 74. - As described in connection with
steps FIG. 5 , duringstep 64,encryption engine 26 may obtain the unencrypted string from adatabase 18 or anapplication 16 and may process the string to identify relevant characters. Dashes spaces, checksums, and other undesired characters can be removed from the string and the relevant characters in the string can be retained.Encryption engine 26 may then use the index mappings that were created duringstep 54 ofFIG. 4 to convert the processed string (i.e., the string from which the irrelevant characters have been removed) into an encoded unencrypted string. For example, each digit in the string may be converted into a corresponding numeric value from 0-9, each letter in the string may be converted into a corresponding numeric value from 0-25, etc. During these encoding operations,encryption engine 26 may use a formula such asformula 152 ofFIG. 14 to encode the string to a unique binary value. The actual formula that is used during encoding depends on the nature of the string's format. The values used forcoefficients FIG. 14 . For strings with other formats, different coefficients may be used in the unique binary value encoding function represented byformula 152. - After preprocessing the string so that the string is represented as a unique encoded binary value, block cipher format-preserving encryption operations may be performed at
step 162. During the operations ofstep 162, the binary-encoded string may be processed using a block cipher such as a block cipher of the type shown inFIG. 3 . As shown inFIG. 16 , the block cipher may be applied to the binary-encoded string atstep 164. The operations ofstep 164 may involve any suitable number of rounds of the block cipher. For example, duringstep 164, eight rounds of the block cipher may be performed. The use of eight rounds of the block cipher is, however, merely illustrative. Any suitable number of rounds of the block cipher may be performed atstep 164 if desired. - As a result of the block cipher operations of
step 164, the binary value obtained fromstep 64 is converted to an encrypted binary value. Atstep 166, the encrypted binary value that is produced atstep 164 is analyzed to determine whether it is format compliant. As described in connection withFIG. 15 , when a binary value is operated on by the block cipher, the resulting binary value at the output of the block cipher may not match the format of the original input string. If it is determined atstep 166 that the format of the string no longer matches the format of the original string (e.g., if a digit has been transformed into a value that no longer falls within its allowed range of 0-9 as described in connection withFIG. 15 ), processing can loop back to step 164, as indicated byline 165. In this situation, the current block cipher can again be applied to the binary value. By applying the block cipher to the current block cipher output, the block cipher can update the current block cipher output. This loop can continue until it is determined duringstep 166 that the format of the encrypted binary value (the current block cipher output) matches the format of the original string obtained atstep 64. When it is determined duringstep 166 that the encrypted binary value output by the block cipher is format compliant, processing may proceed to step 74. - During the operations of
step 74, the same unique binary value encoding function that was used during the encoding operations ofstep 64 and the same index mappings that were used during the encoding operations ofstep 64 are used to convert the encrypted string back into characters (i.e., characters in the legal set of character values that were defined for each character position). Decoding the encoded version of the string using the unique binary value encoding function and index mappings returns the string to its original character set. - The decoded encrypted string may then be processed to restore elements such as dashes and spaces that were removed during the preprocessing operations of
step 64. When replacing a checksum value, a new valid checksum value can be computed from the encrypted version of the string and validity period information or other suitable information can be embedded within the checksum digit (e.g., by adding a validity period index to the new valid checksum value to produce a checksum digit for the decoded encrypted string). The decoded encrypted string is ciphertext that corresponds to the plaintext unencrypted string that was obtained atstep 64. If desired, the entire string can be encrypted. With this type of arrangement, the checksum removal operation and the checksum digit computation operation of can be omitted. - By processing the string during
step 74, the extraneous elements of the string that were removed duringstep 64 may be inserted back into the string. Because the extraneous elements are reinserted into the string and because a format-preserving block cipher encryption process was used duringstep 162, the encrypted string that is produced will have the same format as the original unencrypted string. This allows the encrypted string to be used byapplications 16 anddatabases 18 that require that the original string's format be used. When the encrypted string is provided to anapplication 16 ordatabase 18, legacy applications and databases that require a specific string format may be able to accept the encrypted string. - Illustrative steps involved in performing format-preserving decryption operations on a string using one or more repeated iterations of a block cipher to ensure format compliance are shown in
FIG. 17 . - As shown in
FIG. 17 , a data string may be preprocessed atstep 82, decrypted atstep 168, and postprocessed atstep 92. - During
step 82, the decryption engine obtains the encrypted string. The encrypted string may be retrieved from adatabase 18 or received from anapplication 16. The encrypted string is processed to identify relevant characters. For example, dashes spaces, checksums, and other extraneous elements can be removed from the string, whereas relevant characters in the string can be retained. The process of removing extraneous characters duringstep 82 is the same as that used during the processing of the unencrypted string that was performed duringstep 68 ofFIG. 5 (step 64 ofFIG. 16 ). After extraneous characters have been removed,decryption engine 28 may use the index mappings that were defined atstep 54 ofFIG. 4 to convert the processed string (i.e., the string from which the irrelevant characters have been removed) into an encoded encrypted string. For example, each digit in the string may be converted into a corresponding numeric value from 0-9, each letter in the string may be converted into a corresponding numeric value from 0-25, etc. During these encoding operations,decryption engine 28 may use a formula such asformula 152 ofFIG. 14 to encode the string to a unique binary value. As with the encoding operations performed during preprocessingstep 64 ofFIG. 16 , the formula that is used during the encoding ofstep 82 depends on the nature of the string's format. The values used forcoefficients FIG. 14 example are merely illustrative. - After preprocessing the string so that the string is represented as a unique encoded binary value, format-preserving decryption operations may be performed at
step 168. During the operations ofstep 168, the binary-encoded string may be processed using a block cipher such as a block cipher of the type shown inFIG. 3 . The block cipher may be applied to the binary-encoded string atstep 170. The operations ofstep 170 may involve any suitable number of rounds of the block cipher. For example, eight rounds of the block cipher may be performed duringstep 170. - As a result of the block cipher operations of
step 170, the binary value obtained fromstep 82 is converted to another binary value. If only one pass throughloop 165 ofFIG. 16 was used during encryption, a single pass throughdecryption step 170 will be sufficient to convert the binary value fromstep 82 into a decrypted binary value. If more passes throughloop 165 were used to produce the format-compliant encrypted string, a correspondingly increased number of passes throughloop 171 will be required during decryption operations. - At each
step 172, the binary value that was produced atstep 170 by application of the decrypting block cipher is analyzed to determine whether the binary value is format compliant. When the block cipher is applied to a binary value, the resulting updated binary value at the output of the block cipher may not match the format of the original input string. If it is determined atstep 172 that the format of the data string represented by the current binary value (i.e., the current version of the block cipher output) does not match its original format (e.g., if a digit has been transformed into a value that no longer falls within its allowed range of 0-9), processing can loop back to step 170, as indicated byline 171. In this situation, the decrypting block cipher can again be applied to the binary value atstep 170 to update the block cipher output. This loop can continue until it is determined duringstep 172 that the format of the current binary value produced at the output of the decrypting block cipher matches the format of the original encrypted string obtained atstep 82. When it is determined duringstep 172 that the binary value output by the block cipher is format compliant, the encrypted string has been successfully decrypted and processing may proceed to step 92. - During
step 92, the index mappings and unique binary encoding scheme that were used during the encoding operations ofstep 82 may be used to convert the index values of the decrypted string back into their associated characters (i.e., characters in the legal set of character values that were defined for each character position). This returns the decrypted string to its original character set. In strings that contain more than one different type of character, multiple different index mappings may be used. The decoded decrypted string may then be processed to restore elements such as dashes, spaces, and checksum values that were removed. When replacing a checksum value, a new valid checksum value may be computed from the decrypted version of the string. This ensures that the decrypted version of the string will be returned to its original valid state. - During the string processing operations of
step 92, the extraneous elements of the string that were removed atstep 82 are inserted back into the string. This restores the string to its original unencrypted state, so that the decrypted string may be provided to anapplication 16 ordatabase 18. - The foregoing is merely illustrative of the principles of this invention and various modifications can be made by those skilled in the art without departing from the scope and spirit of the invention.
Claims (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/517,513 US11488134B2 (en) | 2008-05-02 | 2012-06-13 | Format-preserving cryptographic systems |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US5016008P | 2008-05-02 | 2008-05-02 | |
US12/432,258 US8208627B2 (en) | 2008-05-02 | 2009-04-29 | Format-preserving cryptographic systems |
US13/517,513 US11488134B2 (en) | 2008-05-02 | 2012-06-13 | Format-preserving cryptographic systems |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/432,258 Continuation US8208627B2 (en) | 2008-05-02 | 2009-04-29 | Format-preserving cryptographic systems |
Publications (3)
Publication Number | Publication Date |
---|---|
US20130339252A1 US20130339252A1 (en) | 2013-12-19 |
US20170149565A9 true US20170149565A9 (en) | 2017-05-25 |
US11488134B2 US11488134B2 (en) | 2022-11-01 |
Family
ID=49756817
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/517,513 Active 2033-06-12 US11488134B2 (en) | 2008-05-02 | 2012-06-13 | Format-preserving cryptographic systems |
Country Status (1)
Country | Link |
---|---|
US (1) | US11488134B2 (en) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10148424B2 (en) * | 2016-09-26 | 2018-12-04 | Bank Of America Corporation | Progressive key rotation for format preserving encryption (FPE) |
US10157289B2 (en) | 2016-09-26 | 2018-12-18 | Bank Of America Corporation | Progressive key rotation for format preserving encryption (FPE) |
US20200053181A1 (en) * | 2015-06-30 | 2020-02-13 | Iheartmedia Management Services, Inc. | Servicing asset requests via proxy |
Families Citing this family (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR101989813B1 (en) * | 2012-06-29 | 2019-06-18 | 펜타시큐리티시스템 주식회사 | Generating and verifying the alternative data in a specified format |
US20140019586A1 (en) * | 2012-07-13 | 2014-01-16 | Infosys Limited | Methods for format preserving and data masking and devices thereof |
US9875369B2 (en) * | 2013-01-23 | 2018-01-23 | Evernote Corporation | Automatic protection of partial document content |
US9553721B2 (en) * | 2015-01-30 | 2017-01-24 | Qualcomm Incorporated | Secure execution environment communication |
SG11201804419UA (en) * | 2016-01-11 | 2018-06-28 | Visa Int Service Ass | Fast format-preserving encryption for variable length data |
CN106131049A (en) * | 2016-08-15 | 2016-11-16 | 福建中金在线信息科技有限公司 | A kind of method of data transmission encryption and decryption |
CN110637301B (en) * | 2017-05-18 | 2024-02-02 | 维萨国际服务协会 | Reducing disclosure of sensitive data in virtual machines |
WO2019096837A1 (en) * | 2017-11-14 | 2019-05-23 | Pii Guard Aps | A computer-implemented method of performing format-preserving encryption of a data object of variable size |
WO2019109003A1 (en) | 2017-11-30 | 2019-06-06 | Visa International Service Association | Blockchain system for confidential and anonymous smart contracts |
WO2019232692A1 (en) * | 2018-06-05 | 2019-12-12 | Ebay Inc. | Automated key and encryption system |
US20220286446A1 (en) * | 2018-08-16 | 2022-09-08 | Cyberark Software Ltd. | Authentication credential with embedded authentication information |
US10984115B2 (en) * | 2018-12-04 | 2021-04-20 | Bank Of America Corporation | System for triple format preserving encryption |
US11139969B2 (en) | 2018-12-04 | 2021-10-05 | Bank Of America Corporation | Centralized system for a hardware security module for access to encryption keys |
CN109657769B (en) * | 2018-12-29 | 2021-11-19 | 安徽大学 | Two-dimensional code information hiding method based on run length coding |
CN113726501A (en) * | 2021-04-02 | 2021-11-30 | 京东数字科技控股股份有限公司 | Method and device for preserving format encrypted data, electronic equipment and storage medium |
CN113079010B (en) * | 2021-06-07 | 2022-01-04 | 深圳奥联信息安全技术有限公司 | Security enhancement method and device based on reserved format algorithm |
CN114338021B (en) * | 2022-03-15 | 2022-07-19 | 阿里云计算有限公司 | Ciphertext mixed operation method and device |
CN115361124A (en) * | 2022-08-19 | 2022-11-18 | 京东方科技集团股份有限公司 | Product verification method and device, electronic equipment and computer-readable storage medium |
CN116192365B (en) * | 2023-01-18 | 2024-03-22 | 无锡航天江南数据***科技有限公司 | PPP-B2B signal transmission method and system based on text service system |
CN116707804B (en) * | 2023-08-07 | 2023-10-31 | ***量子科技有限公司 | Method and equipment for enhancing FF1 format reserved encryption security |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030084003A1 (en) * | 2001-04-20 | 2003-05-01 | Intertrust Technologies Corporation | Systems and methods for conducting transactions and communications using a trusted third party |
US20050149739A1 (en) * | 2003-12-31 | 2005-07-07 | Hewlett-Packard Development Company, L.P. | PIN verification using cipher block chaining |
US20080181395A1 (en) * | 2006-12-14 | 2008-07-31 | Fujitsu Limited | Cryptographic operation apparatus |
Family Cites Families (36)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4229818A (en) * | 1978-12-29 | 1980-10-21 | International Business Machines Corporation | Method and apparatus for enciphering blocks which succeed short blocks in a key-controlled block-cipher cryptographic system |
US5365589A (en) * | 1992-02-07 | 1994-11-15 | Gutowitz Howard A | Method and apparatus for encryption, decryption and authentication using dynamical systems |
US5727065A (en) | 1994-11-14 | 1998-03-10 | Hughes Electronics | Deferred billing, broadcast, electronic document distribution system and method |
US20030191719A1 (en) | 1995-02-13 | 2003-10-09 | Intertrust Technologies Corp. | Systems and methods for secure transaction management and electronic rights protection |
US5784461A (en) | 1996-05-23 | 1998-07-21 | Eastman Kodak Company | Security system for controlling access to images and image related services |
AU4237497A (en) | 1996-08-27 | 1998-03-19 | Ronald E. Hill | Audit and verification system |
US7127741B2 (en) | 1998-11-03 | 2006-10-24 | Tumbleweed Communications Corp. | Method and system for e-mail message transmission |
CA2302784A1 (en) | 1997-09-17 | 1999-03-25 | Frank C. Luyster | Improved block cipher method |
US6230269B1 (en) | 1998-03-04 | 2001-05-08 | Microsoft Corporation | Distributed authentication system and method |
US6636833B1 (en) | 1998-03-25 | 2003-10-21 | Obis Patents Ltd. | Credit card system and method |
US6289450B1 (en) | 1999-05-28 | 2001-09-11 | Authentica, Inc. | Information security architecture for encrypting documents for remote access while maintaining access control |
US6885748B1 (en) | 1999-10-23 | 2005-04-26 | Contentguard Holdings, Inc. | System and method for protection of digital works |
US6836765B1 (en) | 2000-08-30 | 2004-12-28 | Lester Sussman | System and method for secure and address verifiable electronic commerce transactions |
US8176563B2 (en) | 2000-11-13 | 2012-05-08 | DigitalDoors, Inc. | Data security system and method with editor |
SE518166C2 (en) | 2000-11-27 | 2002-09-03 | Protegrity Res & Dev | Data type encryption |
US7418098B1 (en) * | 2000-11-27 | 2008-08-26 | Protegrity Corporation | Data type preserving encryption |
US7412519B2 (en) | 2000-12-08 | 2008-08-12 | Xerox Corporation | Authorized document usage including rendering a protected document |
GB2370471B (en) | 2000-12-20 | 2004-06-23 | Director Government Comm Headq | Directoryless Public Key Cryptographic System and Method |
JP3965126B2 (en) | 2002-03-20 | 2007-08-29 | 松下電器産業株式会社 | Playback device for playing content |
US7195194B2 (en) * | 2002-07-08 | 2007-03-27 | Superba S.A.S. | Process for automatic removal of packages |
US7337176B1 (en) | 2003-08-29 | 2008-02-26 | Sprint Communications Company L.P. | Data loading tool for loading a database |
US7353388B1 (en) | 2004-02-09 | 2008-04-01 | Avaya Technology Corp. | Key server for securing IP telephony registration, control, and maintenance |
SG138452A1 (en) | 2004-05-18 | 2008-01-28 | Victor Company Of Japan | Content presentation |
US7624269B2 (en) | 2004-07-09 | 2009-11-24 | Voltage Security, Inc. | Secure messaging system with derived keys |
EP1637954A1 (en) | 2004-09-15 | 2006-03-22 | Ubs Ag | Generation of anonymized data sets from productive applications |
WO2006034428A2 (en) | 2004-09-20 | 2006-03-30 | Pgp Corporation | Apparatus and method for identity-based encryption within a conventional public-key infrastructure |
US7769168B2 (en) * | 2005-03-31 | 2010-08-03 | Microsoft Corporation | Locally interative encryption generating compliant ciphertext for general syntax specifications |
US20070262138A1 (en) * | 2005-04-01 | 2007-11-15 | Jean Somers | Dynamic encryption of payment card numbers in electronic payment transactions |
US7864952B2 (en) | 2006-06-28 | 2011-01-04 | Voltage Security, Inc. | Data processing systems with format-preserving encryption and decryption engines |
US9361617B2 (en) | 2008-06-17 | 2016-06-07 | Verifone, Inc. | Variable-length cipher system and method |
US8958562B2 (en) | 2007-01-16 | 2015-02-17 | Voltage Security, Inc. | Format-preserving cryptographic systems |
US7925009B2 (en) * | 2007-05-25 | 2011-04-12 | Red Hat, Inc. | Hybrid data encryption |
EP2301185B1 (en) | 2008-05-02 | 2019-06-26 | EntIT Software LLC | Format-preserving cryptographic systems |
US7522723B1 (en) | 2008-05-29 | 2009-04-21 | Cheman Shaik | Password self encryption method and system and encryption by keys generated from personal secret information |
US8948375B2 (en) | 2009-05-05 | 2015-02-03 | Voltage Security, Inc. | Systems for embedding information in data strings |
US8938067B2 (en) * | 2009-10-30 | 2015-01-20 | Voltage Security, Inc. | Format preserving encryption methods for data strings with constraints |
-
2012
- 2012-06-13 US US13/517,513 patent/US11488134B2/en active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030084003A1 (en) * | 2001-04-20 | 2003-05-01 | Intertrust Technologies Corporation | Systems and methods for conducting transactions and communications using a trusted third party |
US20050149739A1 (en) * | 2003-12-31 | 2005-07-07 | Hewlett-Packard Development Company, L.P. | PIN verification using cipher block chaining |
US20080181395A1 (en) * | 2006-12-14 | 2008-07-31 | Fujitsu Limited | Cryptographic operation apparatus |
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20200053181A1 (en) * | 2015-06-30 | 2020-02-13 | Iheartmedia Management Services, Inc. | Servicing asset requests via proxy |
US10855790B2 (en) * | 2015-06-30 | 2020-12-01 | Iheartmedia Management Services, Inc. | Servicing asset requests via proxy |
US11102321B2 (en) | 2015-06-30 | 2021-08-24 | Iheartmedia Management Services, Inc. | Selectively transforming assets returned by a proxy device |
US11418615B2 (en) | 2015-06-30 | 2022-08-16 | Iheartmedia Management Services, Inc. | Proxy device that selectively dispatches resource requests |
US11627198B2 (en) | 2015-06-30 | 2023-04-11 | Iheartmedia Management Services, Inc. | Resource access based on supervisory-subordinate relationship |
US11943312B2 (en) | 2015-06-30 | 2024-03-26 | Iheartmedia Management Services, Inc. | Custom reference tag for versioning |
US10148424B2 (en) * | 2016-09-26 | 2018-12-04 | Bank Of America Corporation | Progressive key rotation for format preserving encryption (FPE) |
US10157289B2 (en) | 2016-09-26 | 2018-12-18 | Bank Of America Corporation | Progressive key rotation for format preserving encryption (FPE) |
US10839094B2 (en) | 2016-09-26 | 2020-11-17 | Bank Of America Corporation | Progressive key rotation for format preserving encryption (FPE) |
US11468187B2 (en) | 2016-09-26 | 2022-10-11 | Bank Of America Corporation | Progressive key rotation for format preserving encryption (FPE) |
US11669629B2 (en) | 2016-09-26 | 2023-06-06 | Bank Of America Corporation | Progressive key rotation for format preserving encryption (FPE) |
Also Published As
Publication number | Publication date |
---|---|
US20130339252A1 (en) | 2013-12-19 |
US11488134B2 (en) | 2022-11-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8208627B2 (en) | Format-preserving cryptographic systems | |
US11488134B2 (en) | Format-preserving cryptographic systems | |
US9208491B2 (en) | Format-preserving cryptographic systems | |
US9489521B2 (en) | Format preserving encryption methods for data strings with constraints | |
US7864952B2 (en) | Data processing systems with format-preserving encryption and decryption engines | |
US8855296B2 (en) | Data processing systems with format-preserving encryption and decryption engines | |
US11516201B2 (en) | Encryption and decryption techniques using shuffle function | |
CN106534092B (en) | The privacy data encryption method of key is depended on based on message | |
US9514330B2 (en) | Meta-complete data storage | |
CN100432889C (en) | System and method providing disconnected authentication | |
US8600048B1 (en) | Format-translating encryption systems | |
US9698974B2 (en) | Method for creating asymmetrical cryptographic key pairs | |
US11979500B2 (en) | Data format-preserving encryption, tokenization, and access control for vaultless systems and methods | |
GB2479074A (en) | A key server selects policy rules to apply to a key request based on an identifier included in the request | |
CN116108410A (en) | Identity credential generation method and device | |
CN110365468A (en) | Anonymization processing method, device, equipment and storage medium | |
US10853502B1 (en) | Systems and methods for reducing computational difficulty of cryptographic operations | |
CN114862388B (en) | Identity management method based on digital wallet, computer equipment and storage medium | |
Schroeder | Pad and Chaff: secure approximate string matching in private record linkage | |
US20210250337A1 (en) | Method and device for matching evaluation of structured data sets protected by encryption | |
Rexha et al. | Using Record Level Encryption for Securing Information in Classified Information Systems |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: VENTURE LENDING & LEASING VII, INC., CALIFORNIA Free format text: SECURITY AGREEMENT;ASSIGNOR:VOLTAGE SECURITY, INC.;REEL/FRAME:032170/0273 Effective date: 20140131 Owner name: VENTURE LENDING & LEASING VI, INC., CALIFORNIA Free format text: SECURITY AGREEMENT;ASSIGNOR:VOLTAGE SECURITY, INC.;REEL/FRAME:032170/0273 Effective date: 20140131 |
|
AS | Assignment |
Owner name: VOLTAGE SECURITY, INC., CALIFORNIA Free format text: RELEASE BY SECURED PARTY;ASSIGNORS:VENTURE LENDING & LEASING VI, INC.;VENTURE LENDING & LEASING VII, INC.;REEL/FRAME:035110/0726 Effective date: 20150227 |
|
AS | Assignment |
Owner name: ENTIT SOFTWARE LLC, CALIFORNIA Free format text: MERGER;ASSIGNOR:VOLTAGE SECURITY, LLC;REEL/FRAME:047253/0802 Effective date: 20170301 Owner name: VOLTAGE SECURITY, LLC, DELAWARE Free format text: ENTITY CONVERSION AND CHANGE OF NAME;ASSIGNOR:VOLTAGE SECURITY, INC.;REEL/FRAME:047276/0434 Effective date: 20150325 |
|
AS | Assignment |
Owner name: VOLTAGE SECURITY, LLC, DELAWARE Free format text: CHANGE OF NAME;ASSIGNOR:VOLTAGE SECURITY, INC.;REEL/FRAME:051198/0611 Effective date: 20150325 Owner name: ENTIT SOFTWARE LLC, NORTH CAROLINA Free format text: MERGER AND CHANGE OF NAME;ASSIGNORS:VOLTAGE SECURITY, LLC;ENTIT SOFTWARE LLC;REEL/FRAME:051199/0074 Effective date: 20170301 |
|
STCV | Information on status: appeal procedure |
Free format text: APPEAL BRIEF (OR SUPPLEMENTAL BRIEF) ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STCV | Information on status: appeal procedure |
Free format text: NOTICE OF APPEAL FILED |
|
STCV | Information on status: appeal procedure |
Free format text: APPEAL BRIEF (OR SUPPLEMENTAL BRIEF) ENTERED AND FORWARDED TO EXAMINER |
|
STCV | Information on status: appeal procedure |
Free format text: EXAMINER'S ANSWER TO APPEAL BRIEF MAILED |
|
STCV | Information on status: appeal procedure |
Free format text: ON APPEAL -- AWAITING DECISION BY THE BOARD OF APPEALS |
|
STCV | Information on status: appeal procedure |
Free format text: BOARD OF APPEALS DECISION RENDERED |
|
AS | Assignment |
Owner name: MICRO FOCUS LLC, CALIFORNIA Free format text: CHANGE OF NAME;ASSIGNOR:ENTIT SOFTWARE LLC;REEL/FRAME:058569/0152 Effective date: 20190528 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NOTICE OF ALLOWANCE MAILED -- APPLICATION RECEIVED IN OFFICE OF PUBLICATIONS |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: PUBLICATIONS -- ISSUE FEE PAYMENT RECEIVED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: PUBLICATIONS -- ISSUE FEE PAYMENT VERIFIED |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |