Making Data Better
Making Data Better is a podcast about data quality and the impact it has on how we protect, manage, and use the digital data critical to our lives. Through conversation and examination, George Peabody and Stephen Wilson look at data's role in risk management, at use cases like identification, lending, age verification, healthcare, and more personal concerns. Privacy and data ownership are topics, as are our data failures.
Making Data Better
EP4: Redemption after data disaster: Heartland Payments breach spurs card data innovation
In October 2008 Heartland Payment Systems discovered it had been breached. Albert Gonzalez and several other individuals hacked their way through an external company website using SQL injection — an attack that too often still works — to the core of Heartland’s systems. They were able to copy credit and debit card numbers and other data used in payment authorization.
At the time, that data enabled those who bought it to create new magstripe cards.
Some stats about the hack:
- Heartland’s stock price fell by 77% in the months following the attack.
- Some 130 million card numbers were exposed.
- Heartland paid $60 million in fines to Visa, over $40M to Mastercard, $5M to Discover, and $3.6M to AMEX.
- The business of signing up merchants to accept cards using Heartland’s services took a big hit.
To me, this is also something of a hero story. Because Heartland’s leadership, led by CEO Bob Carr, got angry. Yes, at the hackers. But more important they took that anger and frustration and used it to fill a gaping hole in card system security, way out in front of what the card systems themselves required.
I was fortunate enough to play a minor part in Heartland’s response. As an analyst, I got to know some key players who will tell their part of the story in this episode.
Welcome to Making Data Better, a podcast about data quality and the impact it has on how we protect, manage and use the digital data critical to our lives. I'm George P Bidi, partner at Lockstep Consulting, and thanks for joining us. Today we're going to tell the first of a series of Making Data Better stories. This one, like so many others, arose out of need and will point to how difficult making data better can be. In October 2008, heartland payment systems discovered it had been breached. Albert Gonzalez and several individuals hacked their way through an external company website using SQL injection, an attack that often, or rather too often, still works into the core of Heartland's payment systems. They were able to copy credit and debit card numbers and other data used in payment authorization. At the time, that data enabled those who bought it to create new MagStrape cards. It was disastrous.
Speaker 1:Some stats about the hack Heartland's stock price fell by 77% in the months following the attack. Some 130 million card numbers were exposed. Heartland paid 60 million in fines to Visa, over 40 million in fines to Mastercard, 5 million to Discover and 3.6 to American Express. And, of course, there was a big hit to the business of signing up merchants to accept cards using Heartland services To me. However, to me, this is also something of a hero story, because Heartland's leadership, led by CEO Bob Carr, got angry yes, they got angry at the hackers. But, more important, they took that anger and frustration and used it to fill a gaping hole in card system security, way out in front of what the card systems of cells required. I was fortunate to play a very minor part in Heartland's response. As an analyst, I got to know some of the key players who will, in this episode, tell their part of the story. We'll start with then CTO Steve Elephant, who, as you'll hear, joined Heartland to help lead the recovery. Steve, welcome.
Speaker 2:Thanks.
Speaker 1:George. Steve, your CV is very long. I want to ask you just to give a couple of highlights here about your time in the payments industry.
Speaker 2:So I've been doing payments since before Fintech was a term. I started a company called IC Verify which is the first PC-based payments software in the 1980s. I merged that with CyberCache where it became a public company, went on and did several other companies in the online auction space using genetic algorithms In the micro payment space, spent some time with some big companies like Google and Heartland and Ford Adventure Capital Company along the way and starting a new venture capital called Soaring Ventures.
Speaker 1:Right now, so you mentioned a firm called Heartland Payment Systems, and that's actually where this story begins and comes together. Heartland is a payment processor serving merchants or was it the time, serving merchants largely in the physical point of sale domain, had a big footprint of merchants, many of them in the restaurant space and retail, and they were selling basically merchant services card processing services to those merchants. So what happened?
Speaker 2:I hardly had a little problem. Before I got there. We had a major breach at the time. It was the largest breach in US history. They exposed card numbers mostly through snippers. The attackers got into the systems through a innocuous server that just served up web pages, but they got their credentials to then get into the payment servers and mapped it out for 18 months and figured out how it all worked even better than Heartland knew, I think from what I was able to look at the records. Then they start cycling out card numbers.
Speaker 1:Wow, so it was a SQL injection kind of a classic hacker tool. Yes exactly and what was the impact on Heartland when the breach happened?
Speaker 2:You know the company had a pretty difficult time. It was a public company. Heartland was one of the top 10 processors in the US. The stock went on the NASDAQ from 30 down to 3. The card brands were threatening to put them out of business. They had to figure out how they were going to come back from very large breach.
Speaker 1:This is an existential event for the company.
Speaker 2:Yes, very much so. It had been around for 20 plus years. Bob Carr did a great job starting it from scratch and now they had to figure out how to bring it back. I had known Bob for a long time through the industry and the industry events. He asked me to come in as a consultant and see what I could figure out. I had been a CEO, so I had a CEO's 30,000 foot view of security and how to deal with that and how to take a deep dive into the weeds and really learn a lot more about encryption and tokenization and best practices in security. Because of the breach it was such big news. We literally had every major security company in the world come into us saying we have a solution for you and we can fix it. We had to sort through all those and figure out what was real, what we could use and what was practical. That took a little bit of time but we ultimately came up with a solution we called end-to-end encryption.
Speaker 1:Back then, card numbers were encoded on MagStripes in the clear no encryption whatsoever.
Speaker 2:Yeah, there were no chips on cards for validations, so it was just MagStripes.
Speaker 1:So data in the clear. When you swipe your card in the terminal, it was entered in the clear into the terminal. Then pass it on up the wire, if you will, to Harland.
Speaker 2:Yeah, who sort it and pass it on to the card grants like all the other processors did. What happened to Harland? We shared a lot of the best practices and what we learned with the other major processors through various industry groups, because it was bad for the industry. We learned a lot and they were just as exposed as Harland was.
Speaker 1:We tried to help them grab solutions as well, so what was the solution that you put together?
Speaker 2:How did you make the?
Speaker 1:data better.
Speaker 2:We looked a lot at different things. We ultimately settled on working with a company called Voltage for the encryption part of the solution. They had a very elegant solution, brilliant Stanford engineers, and it had already been proven. It was used in major banks like Wells Fargo and they had a stellar list of clients and customers. We did a lot of reference, checking, a lot of validation on the solution.
Speaker 2:Then, through a contact that I had back in the IC Verify days in the early 90s, a company called Uniform Industrial out of Taiwan. They had made MagStripe readers for me when I started IC Verify and I thought they made terminals or they could. It turned out they hadn't made a terminal yet. So I went to them and the principals were still there and they reached out to some of their friends in Taiwan and came up with terminals. We ultimately put this into Verify and Hypercom terminals.
Speaker 2:But we created a tamper-resistant security module at TRSM. That was literally like a mission impossible. If you tried to open it or crack it it would self-destruct. That tamper-resistant security module was attached to the MagStripe head. So from the time you swipe the card all the way through the terminal, through the operating system of the terminal, when it goes over the wires, over the phone lines. The internet was still young in the payments world, so a lot of the stuff went out over phone lines, which are very easy to tap into as well. It went into Heartland systems and all the way through the Heartland networks until we passed it off to the card brands. It stayed encrypted with a very elegant solution that at the time was unbreakable.
Speaker 1:So you had the private key, if you will, at Heartland decrypted it just before you sent it on to the card brand, so the card brands didn't have to make any changes to their system Meanwhile. You'd secured it from the moment the customer swipes the card to pass us up through Heartland.
Speaker 2:Yeah, part of the challenge was we were dealing with these fairly antiquated terminals that had been around for a long time. They didn't have a lot of memory, they didn't have a lot of real estate, and so we had to figure out how to get very tight, complex encryption code into a chip on a terminal. So that took a bit of time and the Bolshevik people were brilliant about how to write tight code and UIC figured out how to physically get it in there and we came up with this e3 portal.
Speaker 1:Did it change how Heartland, or did the experience change how Heartland stored card data thereafter?
Speaker 2:Yeah, we used it for not only data in flight I was it, as we call it but data that we stored because we had to provide reporting to Merchants and on their sales and their transactions. So we need to store static information and we need to store the information was a flight? How to just change how you store the static information and we went from everything being in the clear to everything.
Speaker 1:So it was all encrypted that thereafter as well. Yeah, so you really had. Unless the hacker had a tap on the private circuit between you and visa and you and Mastercard, there was nothing to steal inside of the Heartland servers.
Speaker 2:Yeah which is very difficult. I'm like, the card brands are, you know, pretty, pretty hard and they've never been Reached knock on wood and we had a dedicated circuit, you know, from our back into their, their finance. So yeah, that would have been really, really hard.
Speaker 2:Yeah ultimately, we got a couple of the card brands that started doing some tests with us and and we started passing on encrypted data to them. But they were very, very reticent at first because, you know, they really did want to point out the fact that so so much of this was out the clear.
Speaker 2:That mode of operating with the data that clear, has been around since the first, first card, which is literally a piece of cardboard and that had just gotten automated in the 1960s, I mean when I got into the industry, when I started getting getting to retail, when I got out of college in 1980, they still had nothing but sirs, you know Zips, that machine so that you were physically taken an imprint of the, of the Loray's letters on the numbers on the card and you had charts lips and you took those to the bank bank like a deposit every day. It was a very, it was not not elegant but it was functional.
Speaker 1:There are a lot of now a lot of folks listening to this like trust, who have don't even know what an embossed card looks like.
Speaker 1:One of the interfaces changes that have been made along with EMV chips which is provides a bit of transaction unique, encrypted data that runs along with the card number all the way back to the issuing bank, so that helps that bank know that they're dealing with a card that in fact they issued and put into the hands of their account holder. And Another change that's happened to make data better, since what you did, steve, with your you and your team, was really the EMV code tokenization Specification. That's the approach that Apple uses, where actually what's Transmitted over the wire or am I saying transmitted over the air between the iPhone and the contactless reader in the terminal? That number isn't in fact the number that's is your funding account number. It's just a token that's been provisioned by your bank into the Apple wallet. It's the bank at the back end that more or less figures out the mapping between the two. A couple of examples there of Making data better.
Speaker 2:I've had a lot of friends who have me being saying I'm not comfortable putting my credit card in my Apple wallet because that's a cure, and I'm saying you know I'm really insecure. This is a very well designed so you don't have to worry about your card getting compromised from your iPhone.
Speaker 1:I wonder to that extent that that that reticence has been one of the reasons why it's it's taken. It took Apple a long time to start reaching the hockey stick uptick in the use of Apple pay.
Speaker 2:Yeah, well, the community factor of it. I mean I rarely pull my credit card out of my wallet anymore. I tap with my phone and more often I tap with my Apple watch and I pay, pay with NFC through through my, my watch, in my phone and I never have to pull out a card.
Speaker 1:Some someone, merchant doesn't have a NFC reader, all right, and those are the most secure car transactions that are out there hasn't reached that.
Speaker 2:I'm gonna see it happen.
Speaker 1:Well, steve, thanks very much, appreciate you. Setting the way back machine To the year was a 2007, 2008, when 2008 when the breach happened which is not that long ago, 15 years ago. Yeah, so the industry's done a lot of work to Make car data better and make it make it more resilient in the transaction contexts where card numbers are showing up today.
Speaker 2:Yeah, we got a lot of pushback in the day from PCI DSS, which was just starting out the payment card industry data Security standards. They didn't like the fact that we called it and an encryption. They wanted to call point-to-point.
Speaker 1:We says not point-to-point, it's from one end of our network to the other end of the network as a matter of perspective, true, but to your credit, what you did, the design that you put in place and put into the market, that galvanized not only the security standards development but it also galvanized other terminal manufacturers and other processors in the industry to adopt. And then encryption.
Speaker 2:Yeah, and you know we. We had processors and trouble manufacturers coming to us and though we trademarked it and patented, we got a patent around it. We shared it because we thought it was important for the industry to not have another breach like Harlan had. So we tried to help them out through through a number of different avenues and for Harlan it was a two-part solution. One part was, you know this, physical security with the TRSM and the terminal. The other part was the psychological part that people needed to have confidence in in Harlan again. So we actually offered a warranty to the merchant that said if you get breached will pay any fines or fees or anything happens to you. And that was a part of bringing the company back. And we brought the stock from three back in them like 40s or 50s, and it ultimately got sold to global payments for billions. So, but it took. It was on the break, the me other car brands were not happy, the it was teetering.
Speaker 1:Okay, safe. Well, one last question who done it?
Speaker 2:bad guys in Eastern Europe, the, the three letter agencies. Ultimately, when I got my Security clearance, you know kind of reveal a little bit more that they were very, very sophisticated. Very smart Is that they have better. They're just grammatics. From what I saw, the Harlan system then Harlan's engineers did well. They knew how long ran they'd had plenty time to 18 months. They said that the system just watched and listened and waited until the time to bust it out.
Speaker 1:Yeah, I think at the time the value of a credit card number Was in the 25 to $50 range.
Speaker 2:Yeah, same old by that time. Just three million cards, that's a real bank.
Speaker 1:That was worth. That was worth the month, a year and a half for weight.
Speaker 2:The patients pays on probably pretty good pity.
Speaker 1:That's a value book today because of these tools and other controls.
Speaker 2:Yeah, the industry's changed and you know, ultimately I got elected to the PCI board, which I mean it was kind of a you know a coup because we were the bad guys in the industry and you know, people started to see, see that really, really was a sophisticated, robust, secure solution, and we tried to work with a lot of different insurer organizations. There's there's a thing called the FSI sack the financial services industry to treat you some brother, and so all the banks and all the process was blood, that all the security people on the CIOs and CTOs, and so we shared as much knowledge and, you know, told the one hand and try to help them avoid it.
Speaker 1:All right, well, thanks very much, steve, really appreciate it.
Speaker 2:You're welcome, george, my pleasure.
Speaker 1:To be clear, getting card data encrypted before it entered the network required new hardware support. The old gear couldn't be upgraded because running encryption software in the terminals operating system was insecure. Hacking in OS is doable. You have to trust the data coming into the network and the only way to do that in this case was to encrypt it before it touched. Software Security oftentimes requires hardware support. So to add some depth to the hardware side of the story, let's bring in Tom Sigler, who ran the effort for Taiwan's uniform industrial corporation. Let's get right to it. One of the things that jumped out at me from a conversation with Steve was About the challenge of getting Voltages code, and he was really complimentary about the size and efficiency of that software. But I also know that a TRSM is a microcontroller, so there's usually not a lot of space there. What was that process like for you as the, as the hardware integrator?
Speaker 4:I still remember the first meeting with Terence spies and the rest of the guys when they were talking about their code which revolutionized remote key management and the encryption process, and they were expecting megabytes of RAM and memory to put their code, and when we told them that it was going to be tens of K bytes, there was a silence in the room and they kind of looked at each other and we'll have to take a look at that. They did do it. They got it in to our security chip processor with Literally bytes to spare there was. There was no left over space at all. I used to write code in my youth and I was more impressed with this than anything I've ever seen. Wow, to go from something that usually was 10 megabytes down to a few hundred K bytes and have it still work, that was impressive.
Speaker 1:Did they rewrite in assembler or they divide and conquer the functionality?
Speaker 4:They had to go low level on the code. They were basically in assembler language, so they had to rewrite their high level language code to fit into the specific code structure of these security chip microprocessors that we used.
Speaker 1:So that's called right programming right down on the metal. So that's indeed indeed. And that's not a skill. Everybody has right and we've no, absolutely not.
Speaker 4:Especially this. 10, 15 years ago people were already starting to just reuse code bundles. You know, if you wanted to do encryption, you just grab a public domain DES routine or whatever I called it, glue where, because you just glue stuff together and nobody cared how big it was or how inefficient in terms of memory. But that was a huge issue with these terminals because they were never designed to operate that kind of code. The microprocessor that we used in the first terminal was different from the subsequent chips.
Speaker 4:That terminal was not actually a UIC original. We were partnering with a company in Hong Kong I don't remember their full name, but it was icon, a four man shop including their CEO and founder, and they had a terminal that was not even in alpha or beta. I mean, it was basically a laboratory exercise at that point and our CEO made a deal with them because, to go back a little bit, when Steve Elephant called UIC because he had done business with them in the past, he expected someone else to answer. I was about six months in the VP chair and though I knew Steve from his past, when he had been at the forefront of POS based payment systems, he came to the bank I was working at in their credit card division and pitched that.
Speaker 4:So I remembered Steve. He's hard to forget and when we talked, I'm not the kind of guy who would say no, we can't do that when I'm talking to somebody like Cardlin Payments. At that time I think they were the eighth biggest processor in the country and for UIC that would have been a huge piece of business, which it was. So I immediately thought of this icon terminal that we were working with the Hong Kong company on, because he wanted a desktop, the traditional thing with the card, swipe and the printer and all that. That would either be dial up or IP.
Speaker 1:Classic stand beside terminal.
Speaker 4:Exactly that's where they wanted to start. We ended up doing a couple other products for them, but we went there and after I hung up, of course, what I thought was how the hell are we going to do this on the timeframe that Hartman wants it done? They basically wanted it in six to nine months, which nobody was going to provide, and, a little sidebar, the good folks at Verifone and Steve talked I don't know if he mentioned that, but they wanted to be the exclusive provider of E3 terminals and either Steve or Bob Carr probably said no, you can have a part of the business, but not all of it. They wanted to cut us out. I think at that time they saw UIC as not a big threat but somebody that was coming up and might be a competitor. More on that later.
Speaker 4:There was an interesting little side issue that occurred. So we worked with ICON, paid them a bunch of money and their engineer worked with our engineers and they kept developing it and then within a few weeks we had some test units in our shop in Fremont, california, where we did a lot of testing. They also had some in Taipei, of course, a lot of problems early on because really the device was not ready for prime time, we had to pretty much re-engineer the boards. The mechanical aspect of it had a lot of problems. The printer didn't work right. But with a lot of hard work and overtime the UIC engineers did a very good job putting together a usable terminal, though it still did have some issues, one of which was do you remember AmEx came out with that blot Black metal credit card?
Speaker 2:Yeah, caused us some problems.
Speaker 4:When someone carried a static charge and they would swipe that through the card reader, it was blowing up our security chip. So we had to spend a few weeks figuring that one out. So there's always issues and hiccups, but the pressure was on. Hartland wanted that terminal. Though we didn't promise an exact due date, we were shooting for one. I got to say our engineers and the voltage people and a fair amount of help from the Hartland engineering team. We did get a good product to market. It, I think, helped change and make data better.
Speaker 1:Thanks for that. It became the new benchmark. It was the new model that then was adopted by Payment Card Industry, data Security Standards and a whole new certification process built up around the model that you guys pioneered.
Speaker 4:We did two other devices for them, also with the voltage security software embedded in there. One was a handheld pin pad that was an existing UIC product, so that one we got to market in just a short time, a ruggedized, really high quality product that had a MagStripe reader. And the one that I thought was really exciting was the standalone MagStripe reader, or a wedge as a lot of people called it. We converted and built a whole new hardware and software architecture to make a little MagStripe reader, you know, like three inch by one inch, a secure device. So we even sent a early prototype over to Infoguard to have them evaluate it. They pointed out there is no PCI standard for MagStripe readers because nobody had considered doing this.
Speaker 4:It's something that I suggested to Hartland that would be a good supplement to the product line. We had the stand-beside terminal, the pin pad that you'd integrate into your either terminal or your PC, and yet there were still a lot of merchants that wanted just a simple MagStripe that you'd stick on the side of their display. Infoguard gave us some really good advice, helped make the product better and we got it to the point where I thought we could legitimately claim that that little magstripe reader for a couple hundred dollars was equivalent to a PCI approved device for security, physical, logical, et cetera. If you opened it up it zeroed itself out, had a little micro operating system in it that monitored a secure web of mesh around it. It was a pretty cool little product.
Speaker 1:That's great. And now, of course, it's morphed into the square dongle.
Speaker 4:Yeah.
Speaker 1:Does encryption. It's 15 bucks. That has staples. Of course. Now it's orphaned, since we don't have IOJACs anymore. Mostly it's 45 bucks or something like that for the Bluetooth one.
Speaker 4:Of course, all three of the products that we made had very strong encryption of the data and fit into the E3 and with Voltage's key management system we could keep rotating keys as needed depending on the volume of data or timing or whatever. They had a pretty slick product. I was skeptical at first, having grown up, so to speak, in the industry, but I was impressed when I dug into that a little bit and read some of their patents and some of the other information that they could provide.
Speaker 1:Well, obviously you were the right guy for gluing software and hardware together into a product. I suspect it must have been really satisfying to see that go out the door and get used.
Speaker 4:Oh yeah, once we got rid of some of the issues like the AmEx cart, esd, once everything was production worthy and in the field and being deployed, we had several thousand of those terminals out there. The feeling was tremendous. I threw a party for our team at UIC to celebrate what they'd accomplished and they worked so hard. There were several people that, though I won't name, they know who they are and they did phenomenal work.
Speaker 1:Well, Tom, thanks so much. Great to catch up with you on this.
Speaker 4:You're welcome.
Speaker 1:As Steve and Tom said, getting sophisticated encryption software into the Tampa-resistant security module built into the MagStrike breeder wasn't easy. Here's Mark Bauer, now VP of Product Management at Confidential Computing Leader and Juno Security, who was one of the leaders at the time at Voltage Security, to talk in more detail about their making data better technique. So, mark, could you just quickly give us a top level on Voltage's expertise and how it fit into the overall Heartland story about making its data better?
Speaker 3:Yeah, absolutely so.
Speaker 3:At the time, voltage was a pioneer in what was called data-centric security and that was essentially protecting data by neutralizing it from risk and allowing the data to still largely be used and to flow through systems.
Speaker 3:So this was really really important in the Heartland scenario, which was a breach of payment environments.
Speaker 3:How did you do that? So, if you looked at the nature of the breach, essentially attackers had got into the back end systems of Heartland through a front door with classical SQL injection database compromise, and we were talking a good decade or so ago now when this actually happened. And really fundamentally, what the attackers did was they got into the back end systems and then stole card data, in particular track data, if you recall, back then you could manufacture own cards and then the rest is history in terms of the threat to consumer cards in that regard. So what Heartland did, working with Voltage at the time, was to take what is now actually kind of reemerging as an interesting technology, but to combine hardware and software so that you had a heartland environment in the store where the data was captured, so that even under duress and under compromise, things like keys and data couldn't be exposed after it was read, and to keep that data flowing in a protected form all through those complicated payment systems that are often put together with different mishmashes of interfaces and IT mess underneath.
Speaker 1:Given their vintage. Some of them, no doubt, are assembled with, as we used to say, spit and bailing wire. Absolutely.
Speaker 3:A little bit like that.
Speaker 1:Yeah, and they're definitely intolerant of perturbation. What did you do to the data? I mean there's a 16-digit card numbers typically Check that data and still not perturb the intermediary systems.
Speaker 3:When you think about data that's coming from those read heads, essentially in the device, and back at the time you swiped your card or you did the chip, what comes out of that is track one and track two magnetic data or its EMV equivalent in the case of a chip card. To all intents and purposes it's essentially a bunch of characters, numbers and symbols that have to be in an exact format to convey from that device all the way to some back end system so that you could verify the card and so on and essentially process it. The problem was that traditional encryption would break all of that. So if you encrypted a card or a track, you'd get some data but it wouldn't pass through the cash register, the payment systems, the gateways, the clearing systems, everything.
Speaker 3:So voltage came up with technology that sort of appears on the market probably three years before Hartland, and it was called format preserving encryption technology and this was a way that you could encrypt data without changing the appearance and the utility of that data.
Speaker 3:So a credit card could be encrypted to something that looked like a credit card, including the first digits, the checksums. But when you start to get into the track data, you've got start sentinels, you've got everything that's encoded in very fine-grained ways and we managed to create a mechanism that could encrypt the data so it still flowed through all of those ancient spit and chewing gum systems without breaking them, so you could go from the device all the way through to the Hartland system, end to end, and that was the encryption piece. What was on top of that was the key management pace to make that super easy without having to do things like key injection or persistence keys. In the end point, which is always a point of potential attack, it was a hybrid technology of encryption and key management that solved that problem and changed the way the industry behaved.
Speaker 1:Say a little bit more about the key management, because the key is injected at some point at manufacture, I guess in the read head at the terminal.
Speaker 3:In the old way, yeah, and remember too, back in the day when these kinds of breaches happened, you didn't even have encryption of that data. It flowed in the clear over things like internet channels and modems and things like that. So fundamentally, you had to figure out a way to encrypt the data without breaking it and still retaining strength. That was a very hard problem to solve, but when you think about how people manage terminals today, even today when you handle debit cards, for instance, at a manufacturer, you have to inject keys into that device, which is itself a very expensive process. It was in $1,500 per device to inject a key.
Speaker 3:So we solved for that problem by using a technology called identity based encryption and, to sum it up, essentially what it allowed you to do was to create random keys in the device, securely, exchange them with that secure interchange of data along with the track up to the host, and the host could recover the key. And you didn't ever have to inject a symmetric key into the device, which is vulnerable, it's expensive and requires you to have extra hardware in there. So by combining these technologies and you know Heartland shoehorn this into their device when you swiped your card in the stores where this was implemented like Home Depot and other places. Essentially, you were going from that device all the way to this backend system encrypted, and so the only point of compromise was the actual physical card itself.
Speaker 1:As I recall, one of the part of the magic of the format of preservation was that for routing reasons we needed the first six characters in that 16 to be able to identify the issuing bank. That the authorization request has to go to that in the clear, and I think you left the last four in the clear for receding.
Speaker 3:Correct, because you also have the check somewhere you have to maintain to let the intervening characters, a term numeral rather.
Speaker 1:That was where the encryption took place.
Speaker 3:Yeah Well, the thing is too, all of that data is encoded in tracks. So what you see on a receipt of your last four digits, there's a different encoded version of that in the track. And so there's all sorts of mechanics that you had to do mathematically to make sure that that track stayed looking like a track, which is much harder than you think about, because track is also encoded with. It's not asking, it's kind of a, I think it's like a 64 character set, so it's different again. So there was much more going on under the covers.
Speaker 3:But at the end of the day, what Heartland were able to do which was powerful for the industry, was give guarantees to their merchants to say you use us, which uses that technology, which is our hardware, with the voltage software and our infrastructure, and we will guarantee that if you have a breach, we will pay out all of the consequences of that. And that was a game changer, because it became a technology problem with a technology solution but with a massive business advantage to them. So they went from being breached to being a leader, which is a. That's exactly the way you should respond to a breach make change, embrace things that are different, disrupt industry, but in a very positive way, and the outcome is better security for consumers and better security for merchants.
Speaker 1:And a 10X increase in your stock price.
Speaker 3:Exactly, and the rest is history. Now They've been acquired by global payments who continue using this. And what I love about this too, George, is that I'm able to walk into stores or gas stations and whether it was what was voltage did or whether the rest of the industry responded I know there are certain devices where I know the software is going to do its trick with good hardware and I know my card's not going to get breached. And I have personal confidence and a little bit of satisfaction from seeing that transition in industry, which is now almost a given end to end security.
Speaker 1:The model that you all put into place has now become a standard model and, underneath the payment card industry, data security standards and comparatively open ecosystem, following that model that you all pioneered.
Speaker 3:Exactly and NIST did approve that standard.
Speaker 1:We worked very closely with NIST on getting format preserving encryption through as a mode of AES and it's withstood heavy, heavy scrutiny Of course, encryption is a major tool here, but at the same time and it was happening both online and offline environments where, at least to protect data at rest, merchants were using a technique called a tokenization, which is simply storing something of low value and almost outsourcing the storage of the high value data to a service provider. Did Voltage have any play in that? We?
Speaker 3:did. We did so, obviously, getting the data up. You're rotating keys automatically so that merchants don't have to do anything and so that if there is a key compromise it doesn't affect the whole system, etc. But merchants often did things like refunds, their own analytics and so on, and they needed a reference value, which in the past, they used the credit card for that, and in fact, the credit card is really important to merchants because that's often the identifier that you know about who your customer is.
Speaker 3:It's the only thing that's consistent, and so being able to replace that with something that's not valuable but still performs that function was important, and the old ways of doing that were to have these huge databases of tokens, and so where we went with Voltage was to disrupt that again, create a mechanism to give you tokens that could reduce the burden of managing and storing credit cards, but to do that without the burden also going back up the chain to the payment processors, and so, beyond Heartland, many of the payment processors also utilized this technology. We saw adoption across nearly all the acquirers in the United States and abroad of this technique of sometimes of their own making, but often with Voltage and to the merchants this became a superpower, because now you could run analytics without having the burden of compliance. No cards were in the system. The only time the card is present is in that consumer's hand, and that goes to the back end, and then a token would come back. So this got the merchants off the hook of PCI compliance, which was a really big deal.
Speaker 1:I'm laughing. Here's an example of making data better by making data worse, at least as far as hackers concerned.
Speaker 3:Yeah, but in this world we live in today, this technology is out there in the physical payments world, but the thing that's still left over is the soft world of e-commerce and so on. That still is an area that is ripe, I think, for additional disruption, and I bring this to you because I know we're going to talk about something on a future conversation that might be related to this confidential computing.
Speaker 1:Yes, absolutely. We will be coming back to you and the Anjuna security story, but we'll leave this history lesson at this point. So, mark, thanks very much. We really appreciate it. Thanks, george.
Speaker 1:What was the impact of all this work? To make, in this case, card data better? Well, for Heartland, it was huge. Within a couple of years, heartland's stock price recovered from $3 to over $30. In 2015, heartland was acquired by Global Payments for $4.3 billion at $100 per share.
Speaker 1:As we heard from Steve, some industry cooperation among competitors was begun, with Heartland helping establish the Payments Processing Information Sharing Council, a forum for banks and payment processors to share information about breaches. Far more important, heartland's card data encryption model was adopted and updated by the card systems themselves through their Security Standards Organization, emvco, with certification developed by the Payments Card Industry Security Standards Council. This made MagStripe card entry far safer. It took the target breach in 2013, however, to kick the US card business into adopting the EMV chip card approach, already in wide use in other parts of the world. It's another example of hardware's role in data security, and that's where our main players well, bob Carr went on to found another payment processing company, getbeyond. Steve Aliphond is a venture capitalist. Mark Bauer's work in confidential computing is about making private environments built on public cloud infrastructure secure, and Tom Siggler spends as many days and nights as he can out hiking in North Carolina. Oh, albert Gonzalez. He scheduled for release September 9th from federal prison.
Speaker 1:Since the Heartland breach, much has changed. We've gone, as I said, to chip cards that have their own hardware approach to data generation and encryption. In an upcoming story we'll talk about the technique employed by Apple Pay to make data better and its use of metadata that makes finer grained transaction analysis possible. Well, that's it for this episode. If you have ideas about topics for the podcast, drop me a line at George at Making Data Better. Until next time, I hope all is well. Thanks for listening and for your work in Making Data Better. My data story is I am sick to death of buying products and then seeing the advertisement for the product I just bought for the next month. Really, we can't do better than this.
Speaker 4:Yeah.
Speaker 1:It just speaks to the low quality of ad tech.
Speaker 4:Well, I'm sure AI is going to fix all of that.
Speaker 1:Oh, absolutely yeah. We've only got a system now to produce bullshitted industrial scale at zero cost. What could go wrong?
