U.S. patent application number 14/994401 was filed with the patent office on 2016-07-14 for system and method for the protection of consumer financial data utilizing dynamic content shredding.
The applicant listed for this patent is Cyber Reliant Corporation. Invention is credited to Nathan Durant, Ermis Sfakiyanudis, John Michael Suit.
Application Number | 20160203479 14/994401 |
Document ID | / |
Family ID | 56367824 |
Filed Date | 2016-07-14 |
United States Patent
Application |
20160203479 |
Kind Code |
A1 |
Durant; Nathan ; et
al. |
July 14, 2016 |
SYSTEM AND METHOD FOR THE PROTECTION OF CONSUMER FINANCIAL DATA
UTILIZING DYNAMIC CONTENT SHREDDING
Abstract
Consumer Point-of-Sale (POS) systems are becoming a major target
for financial data loss within the commerce ecosystem. Privileged
information, such as account numbers, card information, and
transaction data are the primary targets during these data
breaches. This information, while resident on a point-of-sale
system, can be in plain text and susceptible to theft. The intent
of this document is to present a unique solution that reduces the
attack surface for these types of "hacks", and protects consumer
data through specialized cryptographic operations including data
level encryption with a cryptographic bitsplitting algorithm. This
makes the data useless to those who would take the data unlawfully.
The invention allows for the efficient and effective processing of
financial data while converting the data to a useless state for
those who would obtain it unlawfully.
Inventors: |
Durant; Nathan; (Annapolis,
MD) ; Suit; John Michael; (Mount Airy, MD) ;
Sfakiyanudis; Ermis; (Annapolis, MD) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Cyber Reliant Corporation |
Annapolis |
MD |
US |
|
|
Family ID: |
56367824 |
Appl. No.: |
14/994401 |
Filed: |
January 13, 2016 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
62102772 |
Jan 13, 2015 |
|
|
|
Current U.S.
Class: |
705/71 |
Current CPC
Class: |
G06Q 20/401 20130101;
G06Q 20/3829 20130101 |
International
Class: |
G06Q 20/38 20060101
G06Q020/38; G06Q 20/40 20060101 G06Q020/40 |
Claims
1. A computer-implemented method of protecting electronic financial
transaction data, the method comprising: providing a first
network-based computing device including at least one processor and
memory storing instructions, the at least one processor executing
the instructions to perform the operations of: performing a dynamic
key exchange between said first network-based computing device
operating in an encryption endpoint mode and a second network-based
computing device operating in a decryption endpoint mode; receiving
at said first network-based computing device electronic transaction
information associated with a financial transaction and including
at least a personal account number in non-persistent memory;
executing a computer software-implemented data protection module at
said first network-based computing device to (i) encrypt at least a
portion of said electronic financial transaction data, (ii) remove
said electronic financial transaction data from said non-persistent
memory, (iii) apply cryptographic bitsplitting to break said
encrypted electronic financial transaction data into a
predetermined number of discrete data splits; (iv) store said
predetermined number of discrete data splits across a plurality of
distinct memory locations, and (v) generate metadata including
routing and limited transaction information and excluding said
encrypted portion of electronic financial transaction data; and
transferring said plurality of discrete data splits and said
metadata to said second network-based computing device operating in
a decryption endpoint mode.
2. The method of claim 1, wherein said operation of performing a
dynamic key exchange further comprises: generating public/private
key pairs for said first network-based computing device operating
in an encryption endpoint mode and said second network-based
computing device operating in a decryption endpoint mode;
exchanging public keys between said first network-based computing
device and said second network-based computing device; and
generating a shared symmetric key configured for use in block
cypher encryption at said first network-based computing device.
3. The method of claim 2, wherein said shared symmetric key is
configured to expire after a predetermined amount of time.
4. The method of claim 2, further comprising the step of storing
said shared symmetric key within a secure data container at each of
said first network-based computing device and said second
network-based computing device.
5. The method of claim 1, wherein said first network-based
computing device further comprises a credit card reader.
6. The method of claim 1, wherein said first network-based
computing device further comprises a computer implementing a
merchant POS system.
7. The method of claim 1, wherein said operation of executing a
computer software-implemented data protection module at said first
network-based computing device to encrypt at least a portion of
said electronic financial transaction data further comprises
encrypting said portion using an AES-256 block cipher.
8. The method of claim 1, wherein said operation of executing a
computer software-implemented data protection module at said first
network-based computing device to apply cryptographic bitsplitting
to break said encrypted electronic financial transaction data into
a predetermined number of discrete data splits further comprises
applying an information dispersal algorithm to said portion of said
electronic financial transaction data.
9. The method of claim 1, wherein said metadata further comprises
one or more of an identification of an issuing bank, a transaction
total, an identification of a merchant, a listing of the last four
digits of a purchaser's account number, and a hash-based message
authentication code.
10. The method of claim 1, wherein said step of transferring said
plurality of discrete data splits and said metadata to said second
network-based computing device operating in a decryption endpoint
mode further comprises transferring said plurality of discrete data
splits and said metadata through one or more intermediate data
transfer points.
11. A computer-implemented method of protecting electronic
financial transaction data, the method comprising: providing a
first network-based computing device including at least one
processor and memory storing instructions, the at least one
processor executing the instructions to perform the operations of:
performing a dynamic key exchange between said first network-based
computing device operating in an decryption endpoint mode and a
second network-based computing device operating in an encryption
endpoint mode; receiving a plurality of discrete data splits and
metadata from said second network-based computing device operating
in an encryption endpoint mode, wherein said discrete data splits
and metadata further comprise discrete portions of data
corresponding to a single electronic financial transaction data set
that has been processed by said second network-based computing
device to (i) encrypt at least a portion of said electronic
financial transaction data, (ii) apply cryptographic bitsplitting
to break said encrypted electronic financial transaction data into
said discrete data splits, and (iii) generate said metadata,
wherein said metadata includes routing and limited transaction
information and excludes said encrypted portion of electronic
financial information; executing a computer software-implemented
data protection module at said first network-based computing device
to decrypt said electronic financial transaction data; and process
a financial transaction corresponding to said electronic financial
transaction data set.
12. The method of claim 11, wherein said operation of executing a
computer software-implemented data protection module at said first
network-based computing device to decrypt said electronic financial
transaction data further comprises consolidating said discrete data
splits into a single encrypted data file.
13. The method of claim 12, wherein said operation of executing a
computer software-implemented data protection module at said first
network-based computing device to decrypt said electronic financial
transaction data further comprises decrypting at least a portion of
said single encrypted data file.
14. The method of claim 13, wherein decrypting at least a portion
of said single encrypted data file further comprises using an
AES-236 block cipher.
15. The method of claim 13, further comprising the step of storing
said unencrypted data sets in memory for processing by said first
network-based computing device.
16. The method of claim 11, wherein said operation of performing a
dynamic key exchange further comprises: generating public/private
key pairs for said first network-based computing device operating
in a decryption endpoint mode and said second network-based
computing device operating in an encryption endpoint mode;
exchanging public keys between said first network-based computing
device and said second network-based computing device; and
generating a shared symmetric key configured for use in block
cypher decryption at said first network-based computing device.
17. The method of claim 16, wherein said shared symmetric key is
configured to expire after a predetermined amount of time.
18. The method of claim 16, further comprising the step of storing
said shared symmetric key within a secure data container at each of
said first network-based computing device and said second
network-based computing device.
19. The method of claim 11, wherein said metadata further comprises
one or more of an identification of an issuing bank, a transaction
total, an identification of a merchant, a listing of the last four
digits of a purchaser's account number, and a hash-based message
authentication code.
20. The method of claim 11, wherein said step of receiving a
plurality of discrete data splits and metadata from said second
network-based computing device operating in an encryption endpoint
mode further comprises receiving said plurality of discrete data
splits and said metadata through one or more intermediate data
transfer points.
Description
CROSS REFERENCE TO RELATED APPLICATION
[0001] This application is based upon co-pending and co-owned U.S.
Provisional Patent Application Ser. No. 62/102,772 entitled "System
and Method for the Protection of Consumer Financial Data Utilizing
Dynamic Content Shredding," filed with the U.S. Patent and
Trademark Office on Jan. 13, 2015, the specification of which is
incorporated herein by reference.
FIELD OF THE INVENTION
[0002] This invention relates generally to data level security, and
more particularly to systems and methods for providing data level
security in financial transactions, both in persistent and
non-persistent memory, for usage within the commerce ecosystem
including point-of-sale ("POS") systems.
BACKGROUND OF THE INVENTION
[0003] Financial data is a prime target for malicious users, and is
often sought after by "hackers" due to the obvious fiscal benefits
that might come through misappropriating such data. It has been
demonstrated that this data can be obtained from POS systems or
centralization servers. There are different methods that are being
used by hackers to obtain such financial data, including techniques
called memory scraping. Memory scraping is a method in which a
malicious program searches an application's or a full system's
non-persistent memory (RAM). The reasoning behind these attacks
deals with the traditional lack of protection of financial
information while it resides on the POS and other vendor systems
before being sent for processing with the financial
institutions.
[0004] Given the vulnerability of financial data when it is present
in the POS and other vendor systems, and the harm that
misappropriation of such data can cause to consumers and to the
merchants with whom consumers wish to do business, there remains a
need in the art for systems and methods capable of protecting such
information from misappropriation, and preferably that would render
such information wholly unusable by a would-be thief even if
successful in obtaining unauthorized access to such data.
SUMMARY OF THE INVENTION
[0005] Disclosed herein are systems and methods configured to
address and mitigate the data security risks commonly experienced
by prior POS systems and vendor and other computing systems
associated with such POS systems. The systems and methods disclosed
herein are configured to address the overwhelming lack of efficient
and effective methods for ensuring that data can be protected from
those that wish to exploit it for financial gain.
[0006] The systems and methods set forth herein particularly
provide for data conversion so that the data can be processed by
modified processing systems, but is useless to a would-be exploiter
of the data. If a breach occurs and a user or group of users is
able to exfiltrate data from a financial processing system, it
would be advantageous if that data had no value whatsoever to that
user or group of users.
[0007] The system and methods described herein provide protection
to data sets that can be applied at different locations depending
on configuration and vendor needs. Preferably, this protection may
in certain embodiments be applied at the time of a credit/debit
card swipe as the information is being put into the non-persistent
memory of the POS system. The data set remains in this protected
state throughout its lifespan on the vendor systems, and may remain
in this state until received at the intended endpoint (e.g., a
financial institution), and likewise may be removed entirely from
the vendor systems before being sent over a secure channel to the
necessary financial institutions.
[0008] In accordance with an embodiment of the invention, the
described "protected state" is a conjunction of two cryptographic
operations, namely, data level encryption and a cryptographic
bitsplitting operation that utilizes a keyed information dispersal
algorithm (IDA) to break up data into multiple splits. The data
level encryption in this system uses block ciphers to perform the
necessary encryption, with a rotating dynamic key exchange. This
key exchange insures that only the necessary components within the
system have access to the encrypted data, with all other components
only able to view necessary meta-data.
[0009] There are multiple options for where this key exchange
occurs, depending on the requirements of any given implementation.
If simple vendor protection is necessary, key exchange can be
conducted between the endpoint device (scanner/POS) and the vendor
centralized server, where the protection will be removed before
being sent to the financial institutions. Other available options
include a multi-step key exchange between the merchant (POS) and
acquiring bank, and the acquiring bank and issuing bank, thus
providing for secure data throughout the full extent of the
financial transaction.
[0010] The location of the key exchange determines where during the
transaction the confidential data can be accessed. By moving the
location at which this takes place, data can be protected longer
during the transaction process without being susceptible to theft.
Adding the components necessary for this exchange may not always be
feasible when dealing with multiple banks and vendors. Therefore,
this operation is standardized and can be migrated depending on the
needs of the system.
[0011] In accordance with certain aspects of an embodiment of the
invention, a computer-implemented method of protecting electronic
financial transaction data is provided, the method comprising: (1)
providing a first network-based computing device including at least
one processor and memory storing instructions, the at least one
processor executing the instructions to perform the operations of:
(a) performing a dynamic key exchange between the first
network-based computing device operating in an encryption endpoint
mode and a second network-based computing device operating in a
decryption endpoint mode; (b) receiving at the first network-based
computing device electronic transaction information associated with
a financial transaction and including at least a personal account
number in non-persistent memory; (c) executing a computer
software-implemented data protection module at the first
network-based computing device to (i) encrypt at least a portion of
the electronic financial transaction data, (ii) remove the
electronic financial transaction data from the non-persistent
memory, (iii) apply cryptographic bitsplitting to break the
encrypted electronic financial transaction data into a
predetermined number of discrete data splits; (iv) store the
predetermined number of discrete data splits across a plurality of
distinct memory locations, and (v) generate metadata including
routing and limited transaction information and excluding the
encrypted portion of electronic financial transaction data; and (2)
transferring the plurality of discrete data splits and the metadata
to the second network-based computing device operating in a
decryption endpoint mode.
[0012] In accordance with further aspects of an embodiment of the
invention, a computer-implemented method of protecting electronic
financial transaction data is provided, the method comprising:
providing a first network-based computing device including at least
one processor and memory storing instructions, the at least one
processor executing the instructions to perform the operations of:
(a) performing a dynamic key exchange between the first
network-based computing device operating in an decryption endpoint
mode and a second network-based computing device operating in an
encryption endpoint mode; (b) receiving a plurality of discrete
data splits and metadata from the second network-based computing
device operating in an encryption endpoint mode, wherein the
discrete data splits and metadata further comprise discrete
portions of data corresponding to a single electronic financial
transaction data set that has been processed by the second
network-based computing device to (i) encrypt at least a portion of
the electronic financial transaction data, (ii) apply cryptographic
bitsplitting to break the encrypted electronic financial
transaction data into the discrete data splits, and (iii) generate
the metadata, wherein the metadata includes routing and limited
transaction information and excludes the encrypted portion of
electronic financial information; (c) executing a computer
software-implemented data protection module at the first
network-based computing device to decrypt the electronic financial
transaction data; and (d) processing a financial transaction
corresponding to the electronic financial transaction data set.
BRIEF DESCRIPTION OF THE DRAWINGS
[0013] The numerous advantages of the present invention may be
better understood by those skilled in the art by reference to the
accompanying drawings in which:
[0014] FIG. 1 is a schematic view of an exemplary environment for
use with systems and methods configured in accordance with an
embodiment of the invention.
[0015] FIG. 2 is a schematic view of a dynamic key exchange on a
merchant's computing system in accordance with certain aspects of
an embodiment of the invention.
[0016] FIG. 3 provides a schematic view of the steps carried out
between system endpoints to perform a key exchange in accordance
with certain aspects of an embodiment of the invention.
[0017] FIG. 4 provides a schematic view of the steps carried out by
an encryption endpoint in accordance with certain aspects of an
embodiment of the invention.
[0018] FIG. 5 provides a schematic view of the steps carried out by
a decryption endpoint in accordance with certain aspects of an
embodiment of the invention.
[0019] FIG. 6 shows a schematic view of the flow of transaction
data as it is processed by the protection module in accordance with
certain aspects of an embodiment of the invention.
DETAILED DESCRIPTION
[0020] The following description is of a particular embodiment of
the invention, set out to enable one to practice an implementation
of the invention, and is not intended to limit the preferred
embodiment, but to serve as a particular example thereof. Those
skilled in the art should appreciate that they may readily use the
conception and specific embodiments disclosed as a basis for
modifying or designing other methods and systems for carrying out
the same purposes of the present invention. Those skilled in the
art should also realize that such equivalent assemblies do not
depart from the spirit and scope of the invention in its broadest
form.
[0021] The system and methods described herein provide data
security that can be utilized by commerce vendors and financial
institutions to increase security and grant a level of protection
for confidential and possibly damaging information. The system and
methods set forth herein protect the primary account numbers (PANs)
and other sensitive data, while granting access to metadata
necessary for information routing.
[0022] In a particularly preferred embodiment, the system is not
built as a user application, but as a security component that is
embedded with the current vendor and financial applications used
within the financial transactions industry. As these protections
are embedded in the financial applications, end user modifications
are kept to a minimum. There are multiple factors that are involved
with this system that are necessary for a strong security posture
to be upheld, which will be detailed step by step in consecutive
order, along with details of which systems/types of systems are
involved.
[0023] Before any encryption or cryptographic operations can be
conducted to protect the desired data sets, all endpoints must be
"keyed". This "keying" is the process of performing a dynamic key
exchange between endpoints, so that all endpoints have the
necessary symmetric encryption key to perform encryption and
decryption operations successfully. Prior to performing the key
exchange, it is necessary to generate public/private key pairs for
each endpoint. These key pairs serve as the bases for dynamic key
exchange. A public/private key pair is an asymmetric key pair, and
is used in asymmetric cryptography, specifically the necessary
operations of a dynamic key exchange. This public/private key pair
is generated for each endpoint.
[0024] FIG. 1 is a schematic view of an exemplary environment in
which the systems and methods described herein may be deployed. As
shown in FIG. 1, various computing devices may be provided and
serve as encryption endpoints. Possible encryption endpoints may
include a credit card reader 10, a POS system associated with a
merchant 20, and a financial processing system of an acquiring bank
30. In this configuration, the credit card reader 10 may have a
processor and an embedded operating system, the POS system may
operate on a computing system having a commonly used operating
system such as MICROSOFT WINDOWS, and the acquiring bank may employ
a computing system of any form suitable for handling its electronic
operations, all of which configurations are known to those of
ordinary skill in the art and are thus not described further here.
Similarly, possible decryption endpoints may include a mainframe
server or other computing system associated with the merchant 20,
the financial processing system of the acquiring bank 30, and the
financial processing system of the issuing bank 40 (which again may
comprise a computing system of any form suitable for handling its
electronic operations in a configuration well known to those
skilled in the art).
[0025] In this configuration, after financial data is captured by
credit card reader 10 and/or elements of the merchant's POS system,
information is captured by the POS system associated with the
merchant 20. A dynamic key exchange, as discussed in greater detail
below, may then be carried out between the processing system of the
merchant 20 and the financial processing system of the acquiring
bank 30, so as to allow secure data transfer between such
processing systems 20 and 30 as the merchant requests authorization
for the financial transaction from the acquiring bank (i.e., the
merchant's bank). Likewise, a dynamic key exchange may be carried
out between the processing system of the acquiring bank 30 and the
financial processing system of the issuing bank 40, so as to allow
secure data transfer between such processing systems 30 and 40 as
the acquiring bank submits a request to the issuing bank through
the credit card network 35. After receiving (and decrypting if
encrypted) the financial transaction data, the issuing bank 40 may
approve or decline the transaction, forward its response to
acquiring bank 30, and acquiring bank 30 may forward its response
to the computing system of the merchant 20 to either authorize or
decline the transaction.
[0026] As mentioned briefly above, certain configurations may
benefit from the system and methods set forth herein without
requiring specialized configuration of the computing systems of the
acquiring bank 30 and issuing bank 40. Rather, in those instances
in which only simple vendor protection is necessary, key exchange
can be conducted as shown in FIG. 2 between the endpoint device
(scanner 10 and/or POS terminal 15) and the vendor centralized
server 18, where the protection may be removed before being sent to
the financial institutions. Other available options include the
multi-step key exchange between the merchant (POS) and acquiring
bank, and the acquiring bank and issuing bank, all as shown in FIG.
1, thus providing for secure data throughout the full extent of the
financial transaction. As noted above, the location of the key
exchange determines where during the transaction the confidential
financial data can be accessed. Thus, by moving the location at
which this takes place, data can be protected longer during the
transaction process without being susceptible to theft.
[0027] In order to conduct such dynamic key exchange, the system
and methods described herein follow established security guidelines
for encryption, digital signatures, and key exchanges. These
guidelines are outlined in the Suite B Cryptography program
established by the National Security Agency (NSA). Suite B details
which cryptographic algorithms should be used when conducting
specific functions. The system and methods described herein adhere
to these algorithms. Those are detailed at
https://www.nsa.gov/ia/programs/suiteb_cryptography/, the
specifications of which are incorporated herein by reference in
their entireties.
[0028] When using asymmetric cryptography, it is established that
public keys are transferred between endpoints and used in the
encryption process when encrypting a symmetric key needed for block
ciphers. Because public keys are transferred, it is necessary to
verify and perform assurance that the public keys transferred are
actually from an authorized endpoint, and not from a malicious
user.
[0029] To grant the level of assurance, the public key for these
endpoints is stored within a certificate authority with network
access to the endpoints. The purpose of this certificate authority
(CA) is to validate the public keys of each endpoint in the system,
so that a malicious system cannot be inserted to perform
man-in-the-middle (MITM) attacks against the communication channels
between endpoints.
[0030] This CA serves as a trusted third party (TTP) and is used to
provide assurance of parameters. This assurance includes at least
two different steps. The first is the assurance that the public key
is from an authorized source. This involves the use of public key
certificates that have been signed by the CA. This is typical in
enterprise architectures.
[0031] The system uses an established public key infrastructure
(PKI) to handle these certificates.
[0032] Once a trusted public key certificate is established, there
is a level of trust between two endpoints and a key exchange can be
performed. In a particularly preferred embodiment, this dynamic key
exchange is implemented using a Suite B approved algorithm,
specifically Elliptic Curve Diffie-Hellman (ECDH). ECDH uses a
separate public/private key pair from digital signatures, and are
generated using Elliptic Curve Cryptography (ECC) instead of RSA.
To perform the key exchange, two endpoints use the CA to exchange
trusted public keys, with the CA performing the required arithmetic
assurance of the public key.
[0033] Once public keys are exchanged, the ECDH algorithm uses
discrete logarithm operations to generate a shared symmetric key
that is used in block cipher encryption algorithms at the
encryption endpoint. Once this key is established, it is used for a
limited interval before again being reestablished. This limited use
provides an additional layer of security within the block ciphers.
If the symmetric key is compromised, only data during the current
interval is compromised, and once a key is reestablished the
compromised key is useless.
[0034] FIG. 3 provides a schematic view of the steps carried out
between system endpoints to perform a key exchange in accordance
with certain aspects of an embodiment of the invention. At step
100, financial transaction system endpoints are provisioned with
public/private key pairs from a certificate authority, and at step
102, they receive those public/private key pairs. At step 104, the
encryption endpoint sends its public key to the desired decryption
endpoint with which it will share electronic transaction
information. At step 106, the decryption endpoint captures the
public key sent from the encryption endpoint, and at step 108, the
decryption endpoint verifies that public key with the certificate
authority. At step 110, the decryption endpoint then sends its
public key to the encryption endpoint, at step 112 the encryption
endpoint captures that public key, and at step 114 the encryption
endpoint verifies that public key with the certificate authority.
As mentioned above, after the exchange of public keys, at step 116
ECDH is performed at the encryption endpoint, and at step 118 the
endpoints establish the shared symmetric key. A timer registers the
time for which such shared symmetric key remains active, and at
step 120, a determination is made whether the time that such shared
symmetric key has been active has exceeded a predetermined
threshold. In the event that such time period has expired, the
method returns to step 104 to again being the dynamic key exchange
process.
[0035] The dynamic key exchange process takes place over computer
network communication, preferably through the use of (by way of
non-limiting example) the TCP/IP protocol. The shared secret key
established during the dynamic key exchange is stored within a
secure container on each endpoint, restricting access only to the
financial application, and with it the protection module.
[0036] Once a key exchange has taken place, each endpoint has a
shared symmetric key that can be used for block cipher
encryption/decryption. This encryption takes place when the
transaction information is first placed into non-persistent memory
on the POS systems (or card reader if possible). The saving of this
protected data is a multi-step process. The first is the
integration with the financial applications that read credit card
data from the hardware card reader or swiper. When this data is
read in, it is immediately processed by the protection module.
[0037] This protection module performs the following steps: (1)
encrypt the necessary data sets with an AES-256 block cipher as
specified in FIPS-197 under the Suite B program
(http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf); (2)
remove any trace of the original, unencrypted data that may be left
in non-persistent memory; (3) perform a specialized encryption
algorithm that breaks up the data into a desired amount of splits
(n number), preferably adding additional layers of security and
obfuscation around the transaction data; and (4) store the n number
of splits across n number of memory locations, managed by the
protection module.
[0038] The specialized encryption algorithm is a key information
dispersal algorithm (IDA). This algorithm takes a set of data, and
pseudo-randomly splits the file into a desired number of n pieces.
This splitting of data acts much like a second level of encryption,
and uses a generated key much in the same manner. The
reconstitution of these pieces can only be achieved if a
pre-specified number of the original shreds are available. This
achieves a cryptographic fault tolerance, allowing data to be
reconstructed without all of the original shreds, if that is the
desired configuration. Typically, this is described as an M:N
configuration, where N is the total number of shreds, and M is the
minimum number necessary to recombine the file.
[0039] As mentioned previously, metadata is joined with the
encrypted data components after encryption and the IDA have taken
place. This metadata contains the necessary routing and transaction
information required by the financial software without compromising
the account information such as credit card numbers and account
numbers. The metadata will contain information that preferably
includes at least issuing bank, transaction total, merchant, the
last four digits of the subject account number, and a hash-based
message authentication code (HMAC). HMACs are used to authenticate
that the data inside the message is correct. In this case, the HMAC
will be used to guarantee that the metadata and encrypted data has
not been tampered with during its lifespan. The logic behind this
deals with chosen cipher text attacks, where malicious users can
modify encrypted data, and gain knowledge through the decryption
process. Through the implementation of an HMAC, these attacks can
be prevented, and corrupted transaction data can be caught and
corrected.
[0040] FIG. 4 provides a schematic view of the steps carried out by
an encryption endpoint in accordance with certain aspects of an
embodiment of the invention. At step 150, a consumer's credit or
debit card or other payment device is swiped or otherwise read by a
card reader. At step 152, electronic financial transaction data is
captured, and at step 154, the memory location of such electronic
financial transaction data is passed to the financial software that
is to process such data. At step 156, the financial software then
executes the functions of the protection module on such data. At
step 158, the protection module builds the metadata header as
discussed above, and at step 160, the protection module encrypts
the data set with AES 256. Such encryption is carried out with the
symmetric key shared with and provided by the decryption endpoint
at step 118. The protection module overwrites the original
unencrypted data at step 162, and at step 164 performs a
cryptographic IDA algorithm on the encrypted data. Then, at step
166, an HMAC calculation is performed on the metadata and the
encrypted data, and at step 168, the calculated HMAC is inserted
into the metadata. At step 170, the protection module then saves
the IDA split data across multiple memory locations.
[0041] As the data is transferred between non-endpoint components,
it is packaged in a similar manner to that described above,
although with PAN and privileged information protected. When
transferring data, the financial applications will again access the
data through the protection module that is integrated into the
applications. This will format the data for routing through the
transaction process until it reaches a decryption endpoint.
[0042] When a decryption endpoint is reached, the protection module
must decrypt the data to plain text using the symmetric key
established during a key exchange. The protection module thus
performs the following decryption steps: (1) consolidate the n
number of splits back into a single encrypted data buffer using
cryptographic bitsplitting; (2) decrypt the necessary data using
AES-256 block cipher as specified in FIPS-197 under the Suite B
program
(http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf); and
(3) store the unencrypted data sets in memory for processing at
trusted endpoint.
[0043] FIG. 5 provides a schematic view of the steps carried out by
a decryption endpoint in accordance with certain aspects of an
embodiment of the invention. At step 172, the HMAC is calculated on
the data set, and at step 174 the HMAC is verified against the
metadata HMAC. At step 176, the protection module restores the
split data sets into an encrypted buffer, and at step 178 the
protection module decrypts the encrypted transaction data, using
the established symmetric key provided by the encryption endpoint
at step 118. Next, the protection module at step 180 copies the
restored data into program memory, and at step 182 the financial
software processes the transaction data as appropriate for the
particular transaction.
[0044] FIG. 6 shows a schematic view of the overall flow of
transaction data as it is processed by the protection module. As
shown in FIG. 6, during an encryption process 500, primary account
number ("PAN") data 200 is captured from the user's credit or debit
card or other payment device, and is passed to the POS software
202. Thereafter, the encryption processes 204 described above are
carried out, and the data 210 (particularly including the PAN) are
stored as split bits 212a, 212b, 212c and 212d in separate memory
storage devices 214a, 214b, 214c, and 214d with associated meta
data 216 as described above. Likewise, during the decryption
process 510, the stored data 210 are passed through the decryption
processes 206 described above so as to decrypt the PAN data 200 for
further processing by the financial software 208 at the decryption
endpoint.
[0045] The foregoing methods are implemented on computing hardware
of traditional configuration used in the processing of electronic
financial transactions, optimally including (as shown in FIG. 1)
computing hardware implementing a credit card reader, a merchant
POS system, a merchant's mainframe server or other element
executing financial and related software, and computing systems of
financial institutions, including those of acquiring banks and
credit card issuers, each of which may be configured as appropriate
to support their individual functions and in manners well known to
those skilled in the art. In each implementation, a system should
include at least a certificate authority, an encryption protection
module, and a decryption protection module. By way of summary, the
certificate authority provides the public key infrastructure and
public key validation in accordance with NIST Special Publication
800-56A. Likewise, each of the encryption protection module and the
decryption protection module provide ECDH implementation for
dynamic key exchange, a cryptographic engine for either AES
encryption or decryption and implantation of a specialized IDA, and
memory management/access API.
[0046] Moreover, the specific computing hardware may be configured
as appropriate by those of ordinary skill in the art to meet a
particular installation's requirements. Such computing hardware may
include by way of non-limiting example, storage I/O may be
accomplished over a TCP/IP network in virtual environments, and
includes the fiber, Ethernet, SCSII, NAS, or even SATA connection
from the physical host to the physical storage device. This is used
by the system to send and receive file content and metadata.
Likewise, network connectivity to storage is provided in the form
of a physical connection from the storage devices to the network
infrastructure. This is typically a TCP/IP, Fiber, or direct
Ethernet connection. Various data storage devices may be provided,
including physical storage devices and cloud storage devices
configured in such manner as may be deemed appropriate by a person
skilled in the art.
[0047] Those skilled in the art will recognize that the above
systems and methods may be modified or supplemented to best suit a
particular installation's requirements. For instance (and by way of
non-limiting example), additional security may be provided by
combining one or more functions of file encryption, parsing the
data files described herein into parts, parsing the key store into
parts, parsing file pointers into parts, applying software RAID,
and storing written data to varied storage locations, all as
described in copending and co-owned U.S. patent application Ser.
No. 14/935,834 titled "Systems and Methods for Providing File Level
Security," the specification of which is incorporated herein by
reference in its entirety.
[0048] The various embodiments have been described herein in an
illustrative manner, and it is to be understood that the
terminology used is intended to be in the nature of words of
description rather than of limitation. Any embodiment herein
disclosed may include one or more aspects of the other embodiments.
The exemplary embodiments were described to explain some of the
principles of the present invention so that others skilled in the
art may practice the invention. Obviously, many modifications and
variations of the invention are possible in light of the above
teachings. The present invention may be practiced otherwise than as
specifically described within the scope of the appended claims and
their legal equivalents.
* * * * *
References