Security Management Strategies for the CIOHas the industry moved at all on standardizing the way the payment process is secured? There seems to be so many processors promoting different plans.
Secure payment processes:
Voltage, RSA spar over tokenization, data protection: Voltage cites performance issues and the creation of a repository of cardholder data an attractive target for attackers. RSA calls Voltage's claims unfounded.
First Data, RSA push tokenization for payment processing: The encryption-token service could compete against vendors offering format preserving encryption to secure payment transactions.
While the goals may be the same, the practical applications of [the protection plans] may be extremely different. We have been putting forward new standards with a number of groups to create language around what end-to-end encryption
Requires Free Membership to View
SearchSecurity.com members gain immediate and unlimited access to breaking industry news, virus alerts, new hacker threats, highly focused security newsletters, and more -- all at no cost. Join me on SearchSecurity.com today!
Michael S. Mimoso, Editorial Director
truly is. When we peel back the onion and look at the
so-called end-to-end solutions out there, we find that they're really point-to-point solutions.
They may be secure from a terminal to a store controller or from a store controller to a gateway,
but that's not end-to-end encryption, that's point-to-point encryption. That's where the bad guys
are really smart and they look for the weak links at the edges. … True end-to-end encryption to us,
and what we're putting forward as the standard, [starts] from the time the digits leave the
magstripe on the consumer's card, and is turned from analogue data into digital data, [and
continues] all the way through the terminal, through the wires, through our host processing network
until we securely deliver it to the brands. That's end-to-end encryption. Is there really such a
thing as end-to-end encryption? At some point that encrypted data has to be decrypted.The definitions are important. In our model, from the time the digits leave the card swipe there is never a clear text [personal account number] PAN outside of a [hardware security module] HSM, which is the trusted method which has been used for PIN security for 25 plus years throughout the entire process. Yes, the issuer and the brands may have to ultimately decrypt it, but our real goal here is to make it secure from the [time it leaves] consumer until it gets to the brands. The brands and the issuers have their own security issues, but they've been able to handle that with the hardness of their systems and the very few endpoints that are actually talking to them. @67376 Heartland E3 is a project that was brought on by Heartland CEO Robert Carr. What is the status of it? I understand there are merchants testing it out.
That's true. Bob Carr started talking about encryption at the start of 2008 shortly after he heard about the attack at [Hannaford Bros. Co]. I came on board about a year ago to start working on a new division within Heartland to provide end-to-end encryption solutions for all of our merchants. We looked exhaustively at all the different technologies out there and really started with a clean whiteboard. We have pilots that got out at the end of the second quarter in June and we've had those pilots continuing up to this very minute doing thousands of transactions already. We expect to commercially launch in this fourth quarter. How is it deployed by a merchant and how is a payment secured?
One of the things we found when looking at existing terminals was that they did not meet the level of security that we think is necessary to protect cards. As an example, most magnetic stripe readers don't have security between them and the tamper resistant security module [TRSM]. The TRSM, which sits inside the terminal, has been used for PIN debit for a number of years and is a very safe method, but there is an attack vector between the heads and this TRSM. One of the layers we put in is to secure the wires and the process between the magnetic stripe reader and the TRSM. We are producing our own Heartland E3 terminal and wedge and sitcap devices that have these levels of security that I am describing. The TRSM is tamper resistant and holds the keys. If you open the security module … if you try to get into it in any way, it will wipe out the keys and make the whole terminal inoperable.
Once the card swipe comes into the TRSM we then encrypt the data using AES encryption. … Another
new security layer that we've added is that we're signing the applications that are running on the
terminal. In the past, people have been able to put any applications they wanted onto their
terminals out there, so we've locked down the operating system and [every application] must have a
certificate and be tied into the operating system. The application then takes all the sale and
encrypted card data and bundles it all up with what we call identity-based encryption (IDE). …
We're now pushing the keys from the terminal to the host, rather than the other way around. That
enables us to change the key on a much more frequent basis; we're changing it after every batch. It
goes from the terminal, out over the processing wires into our authorization network; our host
security module is where the only decryption/encryption can happen. Then we securely deliver that
to the brands. It is never exposed throughout the entire process. Our storage has always been
encrypted, and settlements and funding are also encrypted the same way that I described the
authorization. The National Retail Federation has said publicly that some merchants are required
under their agreement with issuing banks to retain a certain amount of credit card data. Is that a
problem?
The specific part you are talking about is called post-processing or back-end tokenization. We've
identified a number of processes that had to have that credit card and once a transaction goes into
end-to-end encryption, a token is then created on the back-end to fulfill any of those charge
backs, reversals or other processes that have to be done. During E3 system and post-processing
tokenization a merchant never has to have access to a credit card number. I should point out here
that this is a differential issue. Back-end tokenization or post-processing tokenization is good.
Front-end tokenization, where you take a credit card number and send it up to a token server and
send it back to the terminal, is not good because you are totally exposed from the time you swipe
the card until it gets to the token server. There was another big solution announced recently which
includes tokenization. We believe you cannot secure credit cards properly within software. There's
just too much malware and too many sniffers. So, the bottom line here is back-end tokenization is
good; front-end tokenization is bad. Explain Heartland's tokenization process further. Who are you
using to provide the tokens?
The tokens are actually created by the brands when we send in the transaction. They give us back
what is called an automated reference number. We take that with the time and date and the last four
digits of the card and we have all the information we need to go into our encrypted data storage to
provide transaction data.
It's not clear how front-end tokenization is inherently weak. If the process is encrypted from
the payment terminal to the processor and that processor uses a secure process to issue a token to
the merchant, where is the inherent weakness there?
The inherent weakness is that if you do that in software instead of within a TRSM, you don't have
any security. I've seen countless terminals that have been hacked with paths between the swipe
reader and the TRSM, assuming that there is a TRSM with this tokenization model. If you are not
encrypting with very strong crypto and hardware you don't have security. Hackers can sniff it; they
can get at it.
Join the conversationComment
Share
Comments
Results
Contribute to the conversation