00:00:22Payment Data Breach
00:15:24Development of Secure Payment Terminals
00:28:00Voltage's Encryption Solution for Heartland Breach
00:34:24Advancements in Encryption and Data Security
ABOUT THIS EPISODE
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.
English
United States
SHOW NOTES 🔗
TRANSCRIPT 🔗
WEBVTT
00:00:22.995 --> 00:00:32.450
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.
00:00:32.450 --> 00:00:37.411
I'm George P Bidi, partner at Lockstep Consulting, and thanks for joining us.
00:00:37.411 --> 00:00:42.466
Today we're going to tell the first of a series of Making Data Better stories.
00:00:42.466 --> 00:00:53.389
This one, like so many others, arose out of need and will point to how difficult making data better can be.
00:00:53.389 --> 00:01:00.685
In October 2008, heartland payment systems discovered it had been breached.
00:01:00.685 --> 00:01:17.492
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.
00:01:17.492 --> 00:01:24.391
They were able to copy credit and debit card numbers and other data used in payment authorization.
00:01:24.391 --> 00:01:30.924
At the time, that data enabled those who bought it to create new MagStrape cards.
00:01:30.924 --> 00:01:37.436
It was disastrous.
00:01:38.658 --> 00:01:45.671
Some stats about the hack Heartland's stock price fell by 77% in the months following the attack.
00:01:45.671 --> 00:01:50.302
Some 130 million card numbers were exposed.
00:01:50.302 --> 00:02:02.890
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.
00:02:02.890 --> 00:02:14.390
And, of course, there was a big hit to the business of signing up merchants to accept cards using Heartland services To me.
00:02:14.390 --> 00:02:31.308
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.
00:02:31.308 --> 00:02:43.085
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.
00:02:43.085 --> 00:02:47.919
I was fortunate to play a very minor part in Heartland's response.
00:02:47.919 --> 00:02:54.622
As an analyst, I got to know some of the key players who will, in this episode, tell their part of the story.
00:02:54.622 --> 00:03:05.115
We'll start with then CTO Steve Elephant, who, as you'll hear, joined Heartland to help lead the recovery.
00:03:05.115 --> 00:03:08.167
Steve, welcome.
00:03:08.508 --> 00:03:08.709
Thanks.
00:03:08.748 --> 00:03:08.969
George.
00:03:08.969 --> 00:03:11.039
Steve, your CV is very long.
00:03:11.039 --> 00:03:16.812
I want to ask you just to give a couple of highlights here about your time in the payments industry.
00:03:17.681 --> 00:03:20.288
So I've been doing payments since before Fintech was a term.
00:03:20.288 --> 00:03:25.939
I started a company called IC Verify which is the first PC-based payments software in the 1980s.
00:03:25.939 --> 00:03:46.723
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.
00:03:46.742 --> 00:03:53.745
Right now, so you mentioned a firm called Heartland Payment Systems, and that's actually where this story begins and comes together.
00:03:53.745 --> 00:04:16.666
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.
00:04:16.666 --> 00:04:18.612
So what happened?
00:04:19.201 --> 00:04:20.225
I hardly had a little problem.
00:04:20.225 --> 00:04:21.730
Before I got there.
00:04:21.730 --> 00:04:24.759
We had a major breach at the time.
00:04:24.759 --> 00:04:26.987
It was the largest breach in US history.
00:04:26.987 --> 00:04:31.571
They exposed card numbers mostly through snippers.
00:04:31.571 --> 00:04:47.887
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.
00:04:47.887 --> 00:04:50.607
Then they start cycling out card numbers.
00:04:50.766 --> 00:04:54.588
Wow, so it was a SQL injection kind of a classic hacker tool.
00:04:54.588 --> 00:04:58.949
Yes exactly and what was the impact on Heartland when the breach happened?
00:05:00.041 --> 00:05:03.569
You know the company had a pretty difficult time.
00:05:03.569 --> 00:05:04.632
It was a public company.
00:05:04.632 --> 00:05:08.250
Heartland was one of the top 10 processors in the US.
00:05:08.250 --> 00:05:11.749
The stock went on the NASDAQ from 30 down to 3.
00:05:11.749 --> 00:05:14.668
The card brands were threatening to put them out of business.
00:05:14.668 --> 00:05:18.129
They had to figure out how they were going to come back from very large breach.
00:05:18.701 --> 00:05:21.074
This is an existential event for the company.
00:05:21.576 --> 00:05:22.120
Yes, very much so.
00:05:22.120 --> 00:05:24.610
It had been around for 20 plus years.
00:05:24.610 --> 00:05:29.447
Bob Carr did a great job starting it from scratch and now they had to figure out how to bring it back.
00:05:29.447 --> 00:05:33.250
I had known Bob for a long time through the industry and the industry events.
00:05:33.250 --> 00:05:37.490
He asked me to come in as a consultant and see what I could figure out.
00:05:37.490 --> 00:05:52.230
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.
00:05:52.230 --> 00:05:54.865
Because of the breach it was such big news.
00:05:54.865 --> 00:06:01.127
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.
00:06:01.127 --> 00:06:07.351
We had to sort through all those and figure out what was real, what we could use and what was practical.
00:06:07.351 --> 00:06:13.281
That took a little bit of time but we ultimately came up with a solution we called end-to-end encryption.
00:06:14.079 --> 00:06:20.791
Back then, card numbers were encoded on MagStripes in the clear no encryption whatsoever.
00:06:21.312 --> 00:06:25.449
Yeah, there were no chips on cards for validations, so it was just MagStripes.
00:06:26.060 --> 00:06:27.908
So data in the clear.
00:06:27.908 --> 00:06:31.422
When you swipe your card in the terminal, it was entered in the clear into the terminal.
00:06:31.422 --> 00:06:36.091
Then pass it on up the wire, if you will, to Harland.
00:06:36.673 --> 00:06:42.031
Yeah, who sort it and pass it on to the card grants like all the other processors did.
00:06:42.031 --> 00:06:43.934
What happened to Harland?
00:06:43.934 --> 00:06:51.930
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.
00:06:51.930 --> 00:06:55.949
We learned a lot and they were just as exposed as Harland was.
00:06:56.980 --> 00:07:00.987
We tried to help them grab solutions as well, so what was the solution that you put together?
00:07:01.721 --> 00:07:02.404
How did you make the?
00:07:02.425 --> 00:07:02.927
data better.
00:07:03.819 --> 00:07:04.845
We looked a lot at different things.
00:07:04.845 --> 00:07:10.620
We ultimately settled on working with a company called Voltage for the encryption part of the solution.
00:07:10.620 --> 00:07:16.312
They had a very elegant solution, brilliant Stanford engineers, and it had already been proven.
00:07:16.312 --> 00:07:22.432
It was used in major banks like Wells Fargo and they had a stellar list of clients and customers.
00:07:22.432 --> 00:07:26.209
We did a lot of reference, checking, a lot of validation on the solution.
00:07:27.100 --> 00:07:35.264
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.
00:07:35.264 --> 00:07:41.930
They had made MagStripe readers for me when I started IC Verify and I thought they made terminals or they could.
00:07:41.930 --> 00:07:43.586
It turned out they hadn't made a terminal yet.
00:07:43.586 --> 00:07:50.086
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.
00:07:50.086 --> 00:07:53.968
We ultimately put this into Verify and Hypercom terminals.
00:07:54.028 --> 00:07:58.867
But we created a tamper-resistant security module at TRSM.
00:07:58.867 --> 00:08:01.158
That was literally like a mission impossible.
00:08:01.158 --> 00:08:04.584
If you tried to open it or crack it it would self-destruct.
00:08:04.584 --> 00:08:09.129
That tamper-resistant security module was attached to the MagStripe head.
00:08:09.129 --> 00:08:15.567
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.
00:08:15.567 --> 00:08:23.509
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.
00:08:23.509 --> 00:08:29.584
It went into Heartland systems and all the way through the Heartland networks until we passed it off to the card brands.
00:08:29.584 --> 00:08:34.725
It stayed encrypted with a very elegant solution that at the time was unbreakable.
00:08:35.181 --> 00:08:46.941
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.
00:08:46.941 --> 00:08:54.933
You'd secured it from the moment the customer swipes the card to pass us up through Heartland.
00:08:55.234 --> 00:08:59.576
Yeah, part of the challenge was we were dealing with these fairly antiquated terminals that had been around for a long time.
00:08:59.576 --> 00:09:08.293
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.
00:09:08.293 --> 00:09:19.206
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.
00:09:20.296 --> 00:09:26.408
Did it change how Heartland, or did the experience change how Heartland stored card data thereafter?
00:09:27.518 --> 00:09:37.875
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.
00:09:37.875 --> 00:09:42.106
So we need to store static information and we need to store the information was a flight?
00:09:42.106 --> 00:09:48.294
How to just change how you store the static information and we went from everything being in the clear to everything.
00:09:49.380 --> 00:09:51.634
So it was all encrypted that thereafter as well.
00:09:51.634 --> 00:09:53.578
Yeah, so you really had.
00:09:53.578 --> 00:10:03.289
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.
00:10:03.309 --> 00:10:04.355
Yeah which is very difficult.
00:10:04.355 --> 00:10:14.835
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.
00:10:14.835 --> 00:10:17.087
So yeah, that would have been really, really hard.
00:10:17.107 --> 00:10:24.235
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.
00:10:24.235 --> 00:10:31.046
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.
00:10:31.995 --> 00:11:03.154
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.
00:11:03.154 --> 00:11:06.686
It was a very, it was not not elegant but it was functional.
00:11:06.956 --> 00:11:12.628
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.
00:11:20.636 --> 00:11:42.131
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.
00:11:42.131 --> 00:11:54.356
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.
00:11:54.356 --> 00:12:08.960
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?
00:12:08.960 --> 00:12:14.109
That number isn't in fact the number that's is your funding account number.
00:12:14.109 --> 00:12:19.443
It's just a token that's been provisioned by your bank into the Apple wallet.
00:12:19.443 --> 00:12:24.009
It's the bank at the back end that more or less figures out the mapping between the two.
00:12:24.009 --> 00:12:27.802
A couple of examples there of Making data better.
00:12:28.775 --> 00:12:37.466
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.
00:12:37.466 --> 00:12:42.294
This is a very well designed so you don't have to worry about your card getting compromised from your iPhone.
00:12:42.836 --> 00:12:48.248
I wonder to that extent that that that reticence has been one of the reasons why it's it's taken.
00:12:48.248 --> 00:12:56.321
It took Apple a long time to start reaching the hockey stick uptick in the use of Apple pay.
00:12:56.799 --> 00:12:58.095
Yeah, well, the community factor of it.
00:12:58.095 --> 00:13:00.355
I mean I rarely pull my credit card out of my wallet anymore.
00:13:00.355 --> 00:13:10.264
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.
00:13:10.345 --> 00:13:17.346
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.
00:13:17.365 --> 00:13:18.067
I'm gonna see it happen.
00:13:18.375 --> 00:13:20.346
Well, steve, thanks very much, appreciate you.
00:13:20.346 --> 00:13:30.177
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.
00:13:30.177 --> 00:13:41.235
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.
00:13:41.615 --> 00:13:48.698
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.
00:13:48.698 --> 00:13:50.784
They didn't like the fact that we called it and an encryption.
00:13:50.784 --> 00:13:52.808
They wanted to call point-to-point.
00:13:52.849 --> 00:14:16.875
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.
00:14:16.875 --> 00:14:18.918
And then encryption.
00:14:19.340 --> 00:14:20.741
Yeah, and you know we.
00:14:20.741 --> 00:14:27.880
We had processors and trouble manufacturers coming to us and though we trademarked it and patented, we got a patent around it.
00:14:27.880 --> 00:14:34.716
We shared it because we thought it was important for the industry to not have another breach like Harlan had.
00:14:34.716 --> 00:14:42.383
So we tried to help them out through through a number of different avenues and for Harlan it was a two-part solution.
00:14:42.383 --> 00:14:47.482
One part was, you know this, physical security with the TRSM and the terminal.
00:14:47.482 --> 00:14:52.355
The other part was the psychological part that people needed to have confidence in in Harlan again.
00:14:52.355 --> 00:14:59.815
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.
00:14:59.815 --> 00:15:02.663
And that was a part of bringing the company back.
00:15:02.663 --> 00:15:09.649
And we brought the stock from three back in them like 40s or 50s, and it ultimately got sold to global payments for billions.
00:15:09.649 --> 00:15:10.798
So, but it took.
00:15:10.798 --> 00:15:15.552
It was on the break, the me other car brands were not happy, the it was teetering.
00:15:16.173 --> 00:15:16.554
Okay, safe.
00:15:16.554 --> 00:15:18.921
Well, one last question who done it?
00:15:19.623 --> 00:15:24.100
bad guys in Eastern Europe, the, the three letter agencies.
00:15:24.100 --> 00:15:30.552
Ultimately, when I got my Security clearance, you know kind of reveal a little bit more that they were very, very sophisticated.
00:15:30.552 --> 00:15:32.534
Very smart Is that they have better.
00:15:32.534 --> 00:15:33.336
They're just grammatics.
00:15:33.336 --> 00:15:37.604
From what I saw, the Harlan system then Harlan's engineers did well.
00:15:37.604 --> 00:15:41.297
They knew how long ran they'd had plenty time to 18 months.
00:15:41.297 --> 00:15:46.388
They said that the system just watched and listened and waited until the time to bust it out.
00:15:47.035 --> 00:15:53.816
Yeah, I think at the time the value of a credit card number Was in the 25 to $50 range.
00:15:53.899 --> 00:15:55.451
Yeah, same old by that time.
00:15:55.451 --> 00:15:57.432
Just three million cards, that's a real bank.
00:15:57.533 --> 00:15:58.037
That was worth.
00:15:58.037 --> 00:16:00.254
That was worth the month, a year and a half for weight.
00:16:01.578 --> 00:16:03.683
The patients pays on probably pretty good pity.
00:16:04.105 --> 00:16:07.735
That's a value book today because of these tools and other controls.
00:16:08.236 --> 00:16:27.075
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.
00:16:27.075 --> 00:16:44.248
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.
00:16:45.035 --> 00:16:46.981
All right, well, thanks very much, steve, really appreciate it.
00:16:47.022 --> 00:16:48.125
You're welcome, george, my pleasure.
00:16:50.635 --> 00:16:55.995
To be clear, getting card data encrypted before it entered the network required new hardware support.
00:16:55.995 --> 00:17:02.428
The old gear couldn't be upgraded because running encryption software in the terminals operating system was insecure.
00:17:02.428 --> 00:17:04.381
Hacking in OS is doable.
00:17:04.381 --> 00:17:12.028
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.
00:17:12.028 --> 00:17:16.575
Software Security oftentimes requires hardware support.
00:17:16.575 --> 00:17:25.150
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.
00:17:25.150 --> 00:17:27.240
Let's get right to it.
00:17:27.240 --> 00:17:39.847
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.
00:17:39.847 --> 00:17:49.042
But I also know that a TRSM is a microcontroller, so there's usually not a lot of space there.
00:17:49.042 --> 00:17:53.535
What was that process like for you as the, as the hardware integrator?
00:17:54.457 --> 00:18:26.127
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.
00:18:26.127 --> 00:18:28.278
They did do it.
00:18:28.278 --> 00:18:38.424
They got it in to our security chip processor with Literally bytes to spare there was.
00:18:38.424 --> 00:18:41.015
There was no left over space at all.
00:18:41.015 --> 00:18:47.075
I used to write code in my youth and I was more impressed with this than anything I've ever seen.
00:18:47.075 --> 00:18:55.779
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.
00:18:56.174 --> 00:19:02.208
Did they rewrite in assembler or they divide and conquer the functionality?
00:19:02.815 --> 00:19:04.559
They had to go low level on the code.
00:19:04.559 --> 00:19:18.946
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.
00:19:19.895 --> 00:19:22.714
So that's called right programming right down on the metal.
00:19:22.714 --> 00:19:25.384
So that's indeed indeed.
00:19:25.384 --> 00:19:26.721
And that's not a skill.
00:19:26.721 --> 00:19:30.682
Everybody has right and we've no, absolutely not.
00:19:31.355 --> 00:19:32.817
Especially this.
00:19:32.817 --> 00:19:38.288
10, 15 years ago people were already starting to just reuse code bundles.
00:19:38.288 --> 00:19:54.563
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.
00:19:54.563 --> 00:20:01.800
But that was a huge issue with these terminals because they were never designed to operate that kind of code.
00:20:01.800 --> 00:20:08.949
The microprocessor that we used in the first terminal was different from the subsequent chips.
00:20:09.555 --> 00:20:13.567
That terminal was not actually a UIC original.
00:20:13.567 --> 00:20:31.055
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.
00:20:31.055 --> 00:20:49.842
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.
00:20:49.842 --> 00:21:08.035
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.
00:21:08.194 --> 00:21:09.519
So I remembered Steve.
00:21:09.519 --> 00:21:19.580
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.
00:21:19.580 --> 00:21:27.035
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.
00:21:27.035 --> 00:21:39.494
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.
00:21:39.494 --> 00:21:41.039
That would either be dial up or IP.
00:21:42.914 --> 00:21:44.561
Classic stand beside terminal.
00:21:44.875 --> 00:21:46.795
Exactly that's where they wanted to start.
00:21:46.795 --> 00:21:59.326
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?
00:21:59.326 --> 00:22:23.194
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.
00:22:23.194 --> 00:22:24.654
They wanted to cut us out.
00:22:24.654 --> 00:22:33.570
I think at that time they saw UIC as not a big threat but somebody that was coming up and might be a competitor.
00:22:33.570 --> 00:22:35.035
More on that later.
00:22:35.557 --> 00:22:38.153
There was an interesting little side issue that occurred.
00:22:38.153 --> 00:22:55.055
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.
00:22:55.055 --> 00:23:10.770
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.
00:23:10.770 --> 00:23:13.513
The mechanical aspect of it had a lot of problems.
00:23:13.513 --> 00:23:16.599
The printer didn't work right.
00:23:16.599 --> 00:23:35.674
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?
00:23:36.078 --> 00:23:37.614
Yeah, caused us some problems.
00:23:39.578 --> 00:23:47.694
When someone carried a static charge and they would swipe that through the card reader, it was blowing up our security chip.
00:23:47.694 --> 00:23:51.665
So we had to spend a few weeks figuring that one out.
00:23:51.665 --> 00:23:55.694
So there's always issues and hiccups, but the pressure was on.
00:23:55.694 --> 00:23:57.694
Hartland wanted that terminal.
00:23:57.694 --> 00:24:03.267
Though we didn't promise an exact due date, we were shooting for one.
00:24:03.267 --> 00:24:11.426
I got to say our engineers and the voltage people and a fair amount of help from the Hartland engineering team.
00:24:11.426 --> 00:24:13.410
We did get a good product to market.
00:24:13.410 --> 00:24:16.763
It, I think, helped change and make data better.
00:24:17.714 --> 00:24:18.217
Thanks for that.
00:24:18.217 --> 00:24:19.561
It became the new benchmark.
00:24:19.561 --> 00:24:33.694
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.
00:24:35.317 --> 00:24:41.028
We did two other devices for them, also with the voltage security software embedded in there.
00:24:41.028 --> 00:24:55.009
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.
00:24:55.009 --> 00:25:03.528
And the one that I thought was really exciting was the standalone MagStripe reader, or a wedge as a lot of people called it.
00:25:03.528 --> 00:25:16.461
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.
00:25:16.461 --> 00:25:20.674
So we even sent a early prototype over to Infoguard to have them evaluate it.
00:25:20.674 --> 00:25:26.607
They pointed out there is no PCI standard for MagStripe readers because nobody had considered doing this.
00:25:27.518 --> 00:25:32.694
It's something that I suggested to Hartland that would be a good supplement to the product line.
00:25:32.694 --> 00:25:47.519
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.
00:25:47.519 --> 00:26:07.689
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.
00:26:07.689 --> 00:26:17.250
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.
00:26:17.250 --> 00:26:19.144
It was a pretty cool little product.
00:26:19.426 --> 00:26:19.847
That's great.
00:26:19.847 --> 00:26:23.327
And now, of course, it's morphed into the square dongle.
00:26:24.250 --> 00:26:24.431
Yeah.
00:26:24.920 --> 00:26:25.723
Does encryption.
00:26:25.723 --> 00:26:27.825
It's 15 bucks.
00:26:27.825 --> 00:26:28.827
That has staples.
00:26:28.827 --> 00:26:29.740
Of course.
00:26:29.740 --> 00:26:33.285
Now it's orphaned, since we don't have IOJACs anymore.
00:26:33.285 --> 00:26:37.545
Mostly it's 45 bucks or something like that for the Bluetooth one.
00:26:38.319 --> 00:26:57.010
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.
00:26:57.010 --> 00:26:58.665
They had a pretty slick product.
00:26:58.665 --> 00:27:11.522
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.
00:27:12.500 --> 00:27:17.207
Well, obviously you were the right guy for gluing software and hardware together into a product.
00:27:17.207 --> 00:27:21.565
I suspect it must have been really satisfying to see that go out the door and get used.
00:27:21.941 --> 00:27:37.181
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.
00:27:37.181 --> 00:27:39.189
The feeling was tremendous.
00:27:39.189 --> 00:27:46.364
I threw a party for our team at UIC to celebrate what they'd accomplished and they worked so hard.
00:27:46.364 --> 00:27:53.965
There were several people that, though I won't name, they know who they are and they did phenomenal work.
00:27:54.640 --> 00:27:55.704
Well, Tom, thanks so much.
00:27:55.704 --> 00:27:57.145
Great to catch up with you on this.
00:27:57.500 --> 00:27:57.961
You're welcome.
00:28:00.319 --> 00:28:08.288
As Steve and Tom said, getting sophisticated encryption software into the Tampa-resistant security module built into the MagStrike breeder wasn't easy.
00:28:08.288 --> 00:28:23.604
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.
00:28:23.604 --> 00:28:33.807
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?
00:28:34.380 --> 00:28:35.740
Yeah, absolutely so.
00:28:36.423 --> 00:28:51.469
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.
00:28:52.220 --> 00:28:58.190
So this was really really important in the Heartland scenario, which was a breach of payment environments.
00:28:59.099 --> 00:29:00.025
How did you do that?
00:29:00.025 --> 00:29:18.464
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.
00:29:18.464 --> 00:29:34.269
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.
00:29:34.269 --> 00:30:12.349
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.
00:30:13.160 --> 00:30:14.484
Given their vintage.
00:30:14.484 --> 00:30:18.928
Some of them, no doubt, are assembled with, as we used to say, spit and bailing wire.
00:30:18.928 --> 00:30:19.589
Absolutely.
00:30:19.609 --> 00:30:20.511
A little bit like that.
00:30:20.740 --> 00:30:24.268
Yeah, and they're definitely intolerant of perturbation.
00:30:24.268 --> 00:30:26.645
What did you do to the data?
00:30:26.645 --> 00:30:35.991
I mean there's a 16-digit card numbers typically Check that data and still not perturb the intermediary systems.
00:30:36.359 --> 00:30:51.343
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.
00:30:51.343 --> 00:31:08.842
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.
00:31:08.842 --> 00:31:14.266
The problem was that traditional encryption would break all of that.
00:31:14.266 --> 00:31:25.489
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.
00:31:26.339 --> 00:31:43.910
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.
00:31:44.660 --> 00:31:51.630
So a credit card could be encrypted to something that looked like a credit card, including the first digits, the checksums.
00:31:51.630 --> 00:32:18.393
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.
00:32:18.393 --> 00:32:27.015
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.
00:32:27.015 --> 00:32:38.012
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.
00:32:38.961 --> 00:32:49.128
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.
00:32:50.271 --> 00:32:56.491
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.
00:32:56.491 --> 00:33:01.634
It flowed in the clear over things like internet channels and modems and things like that.
00:33:01.634 --> 00:33:08.982
So fundamentally, you had to figure out a way to encrypt the data without breaking it and still retaining strength.
00:33:08.982 --> 00:33:25.682
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.
00:33:25.682 --> 00:33:29.250
It was in $1,500 per device to inject a key.
00:33:29.932 --> 00:33:51.109
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.
00:33:51.109 --> 00:33:58.724
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.
00:33:58.724 --> 00:34:13.286
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.
00:34:13.286 --> 00:34:23.563
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.
00:34:24.425 --> 00:34:37.931
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.
00:34:37.931 --> 00:34:46.978
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.
00:34:47.061 --> 00:34:56.199
Correct, because you also have the check somewhere you have to maintain to let the intervening characters, a term numeral rather.
00:34:56.963 --> 00:34:58.849
That was where the encryption took place.
00:34:59.510 --> 00:35:02.661
Yeah Well, the thing is too, all of that data is encoded in tracks.
00:35:02.661 --> 00:35:08.623
So what you see on a receipt of your last four digits, there's a different encoded version of that in the track.
00:35:08.623 --> 00:35:19.369
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.
00:35:19.369 --> 00:35:26.429
It's not asking, it's kind of a, I think it's like a 64 character set, so it's different again.
00:35:26.429 --> 00:35:29.259
So there was much more going on under the covers.
00:35:29.760 --> 00:35:50.954
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.
00:35:50.954 --> 00:36:00.085
And that was a game changer, because it became a technology problem with a technology solution but with a massive business advantage to them.
00:36:00.085 --> 00:36:03.652
So they went from being breached to being a leader, which is a.
00:36:03.652 --> 00:36:17.929
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.
00:36:18.693 --> 00:36:20.579
And a 10X increase in your stock price.
00:36:22.003 --> 00:36:23.405
Exactly, and the rest is history.
00:36:23.405 --> 00:36:27.322
Now They've been acquired by global payments who continue using this.
00:36:27.322 --> 00:36:44.666
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.
00:36:44.666 --> 00:36:52.762
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.
00:36:53.402 --> 00:37:06.307
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.
00:37:06.849 --> 00:37:09.940
Exactly and NIST did approve that standard.
00:37:10.101 --> 00:37:42.985
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.
00:37:42.985 --> 00:37:45.329
Did Voltage have any play in that?
00:37:45.329 --> 00:37:45.791
We?
00:37:45.831 --> 00:37:46.070
did.
00:37:46.070 --> 00:37:48.505
We did so, obviously, getting the data up.
00:37:48.505 --> 00:37:57.010
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.
00:37:57.010 --> 00:38:13.963
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.
00:38:14.023 --> 00:38:48.846
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.
00:38:48.846 --> 00:39:06.204
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.
00:39:06.204 --> 00:39:07.590
No cards were in the system.
00:39:07.590 --> 00:39:15.177
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.
00:39:15.177 --> 00:39:20.949
So this got the merchants off the hook of PCI compliance, which was a really big deal.
00:39:22.012 --> 00:39:22.492
I'm laughing.
00:39:22.492 --> 00:39:29.733
Here's an example of making data better by making data worse, at least as far as hackers concerned.
00:39:31.364 --> 00:39:41.273
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.
00:39:41.273 --> 00:39:56.644
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.
00:39:57.447 --> 00:39:58.268
Yes, absolutely.
00:39:58.268 --> 00:40:08.275
We will be coming back to you and the Anjuna security story, but we'll leave this history lesson at this point.
00:40:08.275 --> 00:40:09.925
So, mark, thanks very much.
00:40:09.925 --> 00:40:10.773
We really appreciate it.
00:40:10.773 --> 00:40:11.519
Thanks, george.
00:40:17.630 --> 00:40:19.094
What was the impact of all this work?
00:40:19.094 --> 00:40:21.197
To make, in this case, card data better?
00:40:21.197 --> 00:40:23.402
Well, for Heartland, it was huge.
00:40:23.402 --> 00:40:28.360
Within a couple of years, heartland's stock price recovered from $3 to over $30.
00:40:28.360 --> 00:40:35.699
In 2015, heartland was acquired by Global Payments for $4.3 billion at $100 per share.
00:40:37.244 --> 00:40:52.291
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.
00:40:52.291 --> 00:41:10.166
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.
00:41:10.166 --> 00:41:14.155
This made MagStripe card entry far safer.
00:41:14.155 --> 00:41:24.931
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.
00:41:24.931 --> 00:41:35.809
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.
00:41:35.809 --> 00:41:38.496
Steve Aliphond is a venture capitalist.
00:41:38.496 --> 00:41:50.860
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.
00:41:50.860 --> 00:41:55.132
Oh, albert Gonzalez.
00:41:55.132 --> 00:41:58.000
He scheduled for release September 9th from federal prison.
00:42:01.311 --> 00:42:02.615
Since the Heartland breach, much has changed.
00:42:02.615 --> 00:42:08.978
We've gone, as I said, to chip cards that have their own hardware approach to data generation and encryption.
00:42:08.978 --> 00:42:21.063
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.
00:42:21.063 --> 00:42:24.211
Well, that's it for this episode.
00:42:24.211 --> 00:42:29.795
If you have ideas about topics for the podcast, drop me a line at George at Making Data Better.
00:42:29.795 --> 00:42:33.150
Until next time, I hope all is well.
00:42:33.150 --> 00:42:37.429
Thanks for listening and for your work in Making Data Better.
00:42:37.429 --> 00:42:59.211
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.
00:42:59.211 --> 00:43:02.228
Really, we can't do better than this.
00:43:03.311 --> 00:43:03.753
Yeah.
00:43:04.706 --> 00:43:07.614
It just speaks to the low quality of ad tech.
00:43:08.547 --> 00:43:10.552
Well, I'm sure AI is going to fix all of that.
00:43:11.012 --> 00:43:12.034
Oh, absolutely yeah.
00:43:12.034 --> 00:43:17.976
We've only got a system now to produce bullshitted industrial scale at zero cost.
00:43:17.976 --> 00:43:22.461
What could go wrong?
00:00:22.995 --> 00:00:32.450
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.
00:00:32.450 --> 00:00:37.411
I'm George P Bidi, partner at Lockstep Consulting, and thanks for joining us.
00:00:37.411 --> 00:00:42.466
Today we're going to tell the first of a series of Making Data Better stories.
00:00:42.466 --> 00:00:53.389
This one, like so many others, arose out of need and will point to how difficult making data better can be.
00:00:53.389 --> 00:01:00.685
In October 2008, heartland payment systems discovered it had been breached.
00:01:00.685 --> 00:01:17.492
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.
00:01:17.492 --> 00:01:24.391
They were able to copy credit and debit card numbers and other data used in payment authorization.
00:01:24.391 --> 00:01:30.924
At the time, that data enabled those who bought it to create new MagStrape cards.
00:01:30.924 --> 00:01:37.436
It was disastrous.
00:01:38.658 --> 00:01:45.671
Some stats about the hack Heartland's stock price fell by 77% in the months following the attack.
00:01:45.671 --> 00:01:50.302
Some 130 million card numbers were exposed.
00:01:50.302 --> 00:02:02.890
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.
00:02:02.890 --> 00:02:14.390
And, of course, there was a big hit to the business of signing up merchants to accept cards using Heartland services To me.
00:02:14.390 --> 00:02:31.308
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.
00:02:31.308 --> 00:02:43.085
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.
00:02:43.085 --> 00:02:47.919
I was fortunate to play a very minor part in Heartland's response.
00:02:47.919 --> 00:02:54.622
As an analyst, I got to know some of the key players who will, in this episode, tell their part of the story.
00:02:54.622 --> 00:03:05.115
We'll start with then CTO Steve Elephant, who, as you'll hear, joined Heartland to help lead the recovery.
00:03:05.115 --> 00:03:08.167
Steve, welcome.
00:03:08.508 --> 00:03:08.709
Thanks.
00:03:08.748 --> 00:03:08.969
George.
00:03:08.969 --> 00:03:11.039
Steve, your CV is very long.
00:03:11.039 --> 00:03:16.812
I want to ask you just to give a couple of highlights here about your time in the payments industry.
00:03:17.681 --> 00:03:20.288
So I've been doing payments since before Fintech was a term.
00:03:20.288 --> 00:03:25.939
I started a company called IC Verify which is the first PC-based payments software in the 1980s.
00:03:25.939 --> 00:03:46.723
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.
00:03:46.742 --> 00:03:53.745
Right now, so you mentioned a firm called Heartland Payment Systems, and that's actually where this story begins and comes together.
00:03:53.745 --> 00:04:16.666
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.
00:04:16.666 --> 00:04:18.612
So what happened?
00:04:19.201 --> 00:04:20.225
I hardly had a little problem.
00:04:20.225 --> 00:04:21.730
Before I got there.
00:04:21.730 --> 00:04:24.759
We had a major breach at the time.
00:04:24.759 --> 00:04:26.987
It was the largest breach in US history.
00:04:26.987 --> 00:04:31.571
They exposed card numbers mostly through snippers.
00:04:31.571 --> 00:04:47.887
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.
00:04:47.887 --> 00:04:50.607
Then they start cycling out card numbers.
00:04:50.766 --> 00:04:54.588
Wow, so it was a SQL injection kind of a classic hacker tool.
00:04:54.588 --> 00:04:58.949
Yes exactly and what was the impact on Heartland when the breach happened?
00:05:00.041 --> 00:05:03.569
You know the company had a pretty difficult time.
00:05:03.569 --> 00:05:04.632
It was a public company.
00:05:04.632 --> 00:05:08.250
Heartland was one of the top 10 processors in the US.
00:05:08.250 --> 00:05:11.749
The stock went on the NASDAQ from 30 down to 3.
00:05:11.749 --> 00:05:14.668
The card brands were threatening to put them out of business.
00:05:14.668 --> 00:05:18.129
They had to figure out how they were going to come back from very large breach.
00:05:18.701 --> 00:05:21.074
This is an existential event for the company.
00:05:21.576 --> 00:05:22.120
Yes, very much so.
00:05:22.120 --> 00:05:24.610
It had been around for 20 plus years.
00:05:24.610 --> 00:05:29.447
Bob Carr did a great job starting it from scratch and now they had to figure out how to bring it back.
00:05:29.447 --> 00:05:33.250
I had known Bob for a long time through the industry and the industry events.
00:05:33.250 --> 00:05:37.490
He asked me to come in as a consultant and see what I could figure out.
00:05:37.490 --> 00:05:52.230
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.
00:05:52.230 --> 00:05:54.865
Because of the breach it was such big news.
00:05:54.865 --> 00:06:01.127
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.
00:06:01.127 --> 00:06:07.351
We had to sort through all those and figure out what was real, what we could use and what was practical.
00:06:07.351 --> 00:06:13.281
That took a little bit of time but we ultimately came up with a solution we called end-to-end encryption.
00:06:14.079 --> 00:06:20.791
Back then, card numbers were encoded on MagStripes in the clear no encryption whatsoever.
00:06:21.312 --> 00:06:25.449
Yeah, there were no chips on cards for validations, so it was just MagStripes.
00:06:26.060 --> 00:06:27.908
So data in the clear.
00:06:27.908 --> 00:06:31.422
When you swipe your card in the terminal, it was entered in the clear into the terminal.
00:06:31.422 --> 00:06:36.091
Then pass it on up the wire, if you will, to Harland.
00:06:36.673 --> 00:06:42.031
Yeah, who sort it and pass it on to the card grants like all the other processors did.
00:06:42.031 --> 00:06:43.934
What happened to Harland?
00:06:43.934 --> 00:06:51.930
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.
00:06:51.930 --> 00:06:55.949
We learned a lot and they were just as exposed as Harland was.
00:06:56.980 --> 00:07:00.987
We tried to help them grab solutions as well, so what was the solution that you put together?
00:07:01.721 --> 00:07:02.404
How did you make the?
00:07:02.425 --> 00:07:02.927
data better.
00:07:03.819 --> 00:07:04.845
We looked a lot at different things.
00:07:04.845 --> 00:07:10.620
We ultimately settled on working with a company called Voltage for the encryption part of the solution.
00:07:10.620 --> 00:07:16.312
They had a very elegant solution, brilliant Stanford engineers, and it had already been proven.
00:07:16.312 --> 00:07:22.432
It was used in major banks like Wells Fargo and they had a stellar list of clients and customers.
00:07:22.432 --> 00:07:26.209
We did a lot of reference, checking, a lot of validation on the solution.
00:07:27.100 --> 00:07:35.264
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.
00:07:35.264 --> 00:07:41.930
They had made MagStripe readers for me when I started IC Verify and I thought they made terminals or they could.
00:07:41.930 --> 00:07:43.586
It turned out they hadn't made a terminal yet.
00:07:43.586 --> 00:07:50.086
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.
00:07:50.086 --> 00:07:53.968
We ultimately put this into Verify and Hypercom terminals.
00:07:54.028 --> 00:07:58.867
But we created a tamper-resistant security module at TRSM.
00:07:58.867 --> 00:08:01.158
That was literally like a mission impossible.
00:08:01.158 --> 00:08:04.584
If you tried to open it or crack it it would self-destruct.
00:08:04.584 --> 00:08:09.129
That tamper-resistant security module was attached to the MagStripe head.
00:08:09.129 --> 00:08:15.567
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.
00:08:15.567 --> 00:08:23.509
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.
00:08:23.509 --> 00:08:29.584
It went into Heartland systems and all the way through the Heartland networks until we passed it off to the card brands.
00:08:29.584 --> 00:08:34.725
It stayed encrypted with a very elegant solution that at the time was unbreakable.
00:08:35.181 --> 00:08:46.941
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.
00:08:46.941 --> 00:08:54.933
You'd secured it from the moment the customer swipes the card to pass us up through Heartland.
00:08:55.234 --> 00:08:59.576
Yeah, part of the challenge was we were dealing with these fairly antiquated terminals that had been around for a long time.
00:08:59.576 --> 00:09:08.293
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.
00:09:08.293 --> 00:09:19.206
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.
00:09:20.296 --> 00:09:26.408
Did it change how Heartland, or did the experience change how Heartland stored card data thereafter?
00:09:27.518 --> 00:09:37.875
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.
00:09:37.875 --> 00:09:42.106
So we need to store static information and we need to store the information was a flight?
00:09:42.106 --> 00:09:48.294
How to just change how you store the static information and we went from everything being in the clear to everything.
00:09:49.380 --> 00:09:51.634
So it was all encrypted that thereafter as well.
00:09:51.634 --> 00:09:53.578
Yeah, so you really had.
00:09:53.578 --> 00:10:03.289
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.
00:10:03.309 --> 00:10:04.355
Yeah which is very difficult.
00:10:04.355 --> 00:10:14.835
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.
00:10:14.835 --> 00:10:17.087
So yeah, that would have been really, really hard.
00:10:17.107 --> 00:10:24.235
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.
00:10:24.235 --> 00:10:31.046
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.
00:10:31.995 --> 00:11:03.154
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.
00:11:03.154 --> 00:11:06.686
It was a very, it was not not elegant but it was functional.
00:11:06.956 --> 00:11:12.628
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.
00:11:20.636 --> 00:11:42.131
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.
00:11:42.131 --> 00:11:54.356
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.
00:11:54.356 --> 00:12:08.960
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?
00:12:08.960 --> 00:12:14.109
That number isn't in fact the number that's is your funding account number.
00:12:14.109 --> 00:12:19.443
It's just a token that's been provisioned by your bank into the Apple wallet.
00:12:19.443 --> 00:12:24.009
It's the bank at the back end that more or less figures out the mapping between the two.
00:12:24.009 --> 00:12:27.802
A couple of examples there of Making data better.
00:12:28.775 --> 00:12:37.466
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.
00:12:37.466 --> 00:12:42.294
This is a very well designed so you don't have to worry about your card getting compromised from your iPhone.
00:12:42.836 --> 00:12:48.248
I wonder to that extent that that that reticence has been one of the reasons why it's it's taken.
00:12:48.248 --> 00:12:56.321
It took Apple a long time to start reaching the hockey stick uptick in the use of Apple pay.
00:12:56.799 --> 00:12:58.095
Yeah, well, the community factor of it.
00:12:58.095 --> 00:13:00.355
I mean I rarely pull my credit card out of my wallet anymore.
00:13:00.355 --> 00:13:10.264
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.
00:13:10.345 --> 00:13:17.346
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.
00:13:17.365 --> 00:13:18.067
I'm gonna see it happen.
00:13:18.375 --> 00:13:20.346
Well, steve, thanks very much, appreciate you.
00:13:20.346 --> 00:13:30.177
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.
00:13:30.177 --> 00:13:41.235
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.
00:13:41.615 --> 00:13:48.698
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.
00:13:48.698 --> 00:13:50.784
They didn't like the fact that we called it and an encryption.
00:13:50.784 --> 00:13:52.808
They wanted to call point-to-point.
00:13:52.849 --> 00:14:16.875
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.
00:14:16.875 --> 00:14:18.918
And then encryption.
00:14:19.340 --> 00:14:20.741
Yeah, and you know we.
00:14:20.741 --> 00:14:27.880
We had processors and trouble manufacturers coming to us and though we trademarked it and patented, we got a patent around it.
00:14:27.880 --> 00:14:34.716
We shared it because we thought it was important for the industry to not have another breach like Harlan had.
00:14:34.716 --> 00:14:42.383
So we tried to help them out through through a number of different avenues and for Harlan it was a two-part solution.
00:14:42.383 --> 00:14:47.482
One part was, you know this, physical security with the TRSM and the terminal.
00:14:47.482 --> 00:14:52.355
The other part was the psychological part that people needed to have confidence in in Harlan again.
00:14:52.355 --> 00:14:59.815
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.
00:14:59.815 --> 00:15:02.663
And that was a part of bringing the company back.
00:15:02.663 --> 00:15:09.649
And we brought the stock from three back in them like 40s or 50s, and it ultimately got sold to global payments for billions.
00:15:09.649 --> 00:15:10.798
So, but it took.
00:15:10.798 --> 00:15:15.552
It was on the break, the me other car brands were not happy, the it was teetering.
00:15:16.173 --> 00:15:16.554
Okay, safe.
00:15:16.554 --> 00:15:18.921
Well, one last question who done it?
00:15:19.623 --> 00:15:24.100
bad guys in Eastern Europe, the, the three letter agencies.
00:15:24.100 --> 00:15:30.552
Ultimately, when I got my Security clearance, you know kind of reveal a little bit more that they were very, very sophisticated.
00:15:30.552 --> 00:15:32.534
Very smart Is that they have better.
00:15:32.534 --> 00:15:33.336
They're just grammatics.
00:15:33.336 --> 00:15:37.604
From what I saw, the Harlan system then Harlan's engineers did well.
00:15:37.604 --> 00:15:41.297
They knew how long ran they'd had plenty time to 18 months.
00:15:41.297 --> 00:15:46.388
They said that the system just watched and listened and waited until the time to bust it out.
00:15:47.035 --> 00:15:53.816
Yeah, I think at the time the value of a credit card number Was in the 25 to $50 range.
00:15:53.899 --> 00:15:55.451
Yeah, same old by that time.
00:15:55.451 --> 00:15:57.432
Just three million cards, that's a real bank.
00:15:57.533 --> 00:15:58.037
That was worth.
00:15:58.037 --> 00:16:00.254
That was worth the month, a year and a half for weight.
00:16:01.578 --> 00:16:03.683
The patients pays on probably pretty good pity.
00:16:04.105 --> 00:16:07.735
That's a value book today because of these tools and other controls.
00:16:08.236 --> 00:16:27.075
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.
00:16:27.075 --> 00:16:44.248
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.
00:16:45.035 --> 00:16:46.981
All right, well, thanks very much, steve, really appreciate it.
00:16:47.022 --> 00:16:48.125
You're welcome, george, my pleasure.
00:16:50.635 --> 00:16:55.995
To be clear, getting card data encrypted before it entered the network required new hardware support.
00:16:55.995 --> 00:17:02.428
The old gear couldn't be upgraded because running encryption software in the terminals operating system was insecure.
00:17:02.428 --> 00:17:04.381
Hacking in OS is doable.
00:17:04.381 --> 00:17:12.028
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.
00:17:12.028 --> 00:17:16.575
Software Security oftentimes requires hardware support.
00:17:16.575 --> 00:17:25.150
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.
00:17:25.150 --> 00:17:27.240
Let's get right to it.
00:17:27.240 --> 00:17:39.847
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.
00:17:39.847 --> 00:17:49.042
But I also know that a TRSM is a microcontroller, so there's usually not a lot of space there.
00:17:49.042 --> 00:17:53.535
What was that process like for you as the, as the hardware integrator?
00:17:54.457 --> 00:18:26.127
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.
00:18:26.127 --> 00:18:28.278
They did do it.
00:18:28.278 --> 00:18:38.424
They got it in to our security chip processor with Literally bytes to spare there was.
00:18:38.424 --> 00:18:41.015
There was no left over space at all.
00:18:41.015 --> 00:18:47.075
I used to write code in my youth and I was more impressed with this than anything I've ever seen.
00:18:47.075 --> 00:18:55.779
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.
00:18:56.174 --> 00:19:02.208
Did they rewrite in assembler or they divide and conquer the functionality?
00:19:02.815 --> 00:19:04.559
They had to go low level on the code.
00:19:04.559 --> 00:19:18.946
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.
00:19:19.895 --> 00:19:22.714
So that's called right programming right down on the metal.
00:19:22.714 --> 00:19:25.384
So that's indeed indeed.
00:19:25.384 --> 00:19:26.721
And that's not a skill.
00:19:26.721 --> 00:19:30.682
Everybody has right and we've no, absolutely not.
00:19:31.355 --> 00:19:32.817
Especially this.
00:19:32.817 --> 00:19:38.288
10, 15 years ago people were already starting to just reuse code bundles.
00:19:38.288 --> 00:19:54.563
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.
00:19:54.563 --> 00:20:01.800
But that was a huge issue with these terminals because they were never designed to operate that kind of code.
00:20:01.800 --> 00:20:08.949
The microprocessor that we used in the first terminal was different from the subsequent chips.
00:20:09.555 --> 00:20:13.567
That terminal was not actually a UIC original.
00:20:13.567 --> 00:20:31.055
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.
00:20:31.055 --> 00:20:49.842
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.
00:20:49.842 --> 00:21:08.035
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.
00:21:08.194 --> 00:21:09.519
So I remembered Steve.
00:21:09.519 --> 00:21:19.580
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.
00:21:19.580 --> 00:21:27.035
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.
00:21:27.035 --> 00:21:39.494
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.
00:21:39.494 --> 00:21:41.039
That would either be dial up or IP.
00:21:42.914 --> 00:21:44.561
Classic stand beside terminal.
00:21:44.875 --> 00:21:46.795
Exactly that's where they wanted to start.
00:21:46.795 --> 00:21:59.326
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?
00:21:59.326 --> 00:22:23.194
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.
00:22:23.194 --> 00:22:24.654
They wanted to cut us out.
00:22:24.654 --> 00:22:33.570
I think at that time they saw UIC as not a big threat but somebody that was coming up and might be a competitor.
00:22:33.570 --> 00:22:35.035
More on that later.
00:22:35.557 --> 00:22:38.153
There was an interesting little side issue that occurred.
00:22:38.153 --> 00:22:55.055
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.
00:22:55.055 --> 00:23:10.770
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.
00:23:10.770 --> 00:23:13.513
The mechanical aspect of it had a lot of problems.
00:23:13.513 --> 00:23:16.599
The printer didn't work right.
00:23:16.599 --> 00:23:35.674
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?
00:23:36.078 --> 00:23:37.614
Yeah, caused us some problems.
00:23:39.578 --> 00:23:47.694
When someone carried a static charge and they would swipe that through the card reader, it was blowing up our security chip.
00:23:47.694 --> 00:23:51.665
So we had to spend a few weeks figuring that one out.
00:23:51.665 --> 00:23:55.694
So there's always issues and hiccups, but the pressure was on.
00:23:55.694 --> 00:23:57.694
Hartland wanted that terminal.
00:23:57.694 --> 00:24:03.267
Though we didn't promise an exact due date, we were shooting for one.
00:24:03.267 --> 00:24:11.426
I got to say our engineers and the voltage people and a fair amount of help from the Hartland engineering team.
00:24:11.426 --> 00:24:13.410
We did get a good product to market.
00:24:13.410 --> 00:24:16.763
It, I think, helped change and make data better.
00:24:17.714 --> 00:24:18.217
Thanks for that.
00:24:18.217 --> 00:24:19.561
It became the new benchmark.
00:24:19.561 --> 00:24:33.694
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.
00:24:35.317 --> 00:24:41.028
We did two other devices for them, also with the voltage security software embedded in there.
00:24:41.028 --> 00:24:55.009
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.
00:24:55.009 --> 00:25:03.528
And the one that I thought was really exciting was the standalone MagStripe reader, or a wedge as a lot of people called it.
00:25:03.528 --> 00:25:16.461
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.
00:25:16.461 --> 00:25:20.674
So we even sent a early prototype over to Infoguard to have them evaluate it.
00:25:20.674 --> 00:25:26.607
They pointed out there is no PCI standard for MagStripe readers because nobody had considered doing this.
00:25:27.518 --> 00:25:32.694
It's something that I suggested to Hartland that would be a good supplement to the product line.
00:25:32.694 --> 00:25:47.519
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.
00:25:47.519 --> 00:26:07.689
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.
00:26:07.689 --> 00:26:17.250
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.
00:26:17.250 --> 00:26:19.144
It was a pretty cool little product.
00:26:19.426 --> 00:26:19.847
That's great.
00:26:19.847 --> 00:26:23.327
And now, of course, it's morphed into the square dongle.
00:26:24.250 --> 00:26:24.431
Yeah.
00:26:24.920 --> 00:26:25.723
Does encryption.
00:26:25.723 --> 00:26:27.825
It's 15 bucks.
00:26:27.825 --> 00:26:28.827
That has staples.
00:26:28.827 --> 00:26:29.740
Of course.
00:26:29.740 --> 00:26:33.285
Now it's orphaned, since we don't have IOJACs anymore.
00:26:33.285 --> 00:26:37.545
Mostly it's 45 bucks or something like that for the Bluetooth one.
00:26:38.319 --> 00:26:57.010
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.
00:26:57.010 --> 00:26:58.665
They had a pretty slick product.
00:26:58.665 --> 00:27:11.522
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.
00:27:12.500 --> 00:27:17.207
Well, obviously you were the right guy for gluing software and hardware together into a product.
00:27:17.207 --> 00:27:21.565
I suspect it must have been really satisfying to see that go out the door and get used.
00:27:21.941 --> 00:27:37.181
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.
00:27:37.181 --> 00:27:39.189
The feeling was tremendous.
00:27:39.189 --> 00:27:46.364
I threw a party for our team at UIC to celebrate what they'd accomplished and they worked so hard.
00:27:46.364 --> 00:27:53.965
There were several people that, though I won't name, they know who they are and they did phenomenal work.
00:27:54.640 --> 00:27:55.704
Well, Tom, thanks so much.
00:27:55.704 --> 00:27:57.145
Great to catch up with you on this.
00:27:57.500 --> 00:27:57.961
You're welcome.
00:28:00.319 --> 00:28:08.288
As Steve and Tom said, getting sophisticated encryption software into the Tampa-resistant security module built into the MagStrike breeder wasn't easy.
00:28:08.288 --> 00:28:23.604
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.
00:28:23.604 --> 00:28:33.807
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?
00:28:34.380 --> 00:28:35.740
Yeah, absolutely so.
00:28:36.423 --> 00:28:51.469
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.
00:28:52.220 --> 00:28:58.190
So this was really really important in the Heartland scenario, which was a breach of payment environments.
00:28:59.099 --> 00:29:00.025
How did you do that?
00:29:00.025 --> 00:29:18.464
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.
00:29:18.464 --> 00:29:34.269
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.
00:29:34.269 --> 00:30:12.349
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.
00:30:13.160 --> 00:30:14.484
Given their vintage.
00:30:14.484 --> 00:30:18.928
Some of them, no doubt, are assembled with, as we used to say, spit and bailing wire.
00:30:18.928 --> 00:30:19.589
Absolutely.
00:30:19.609 --> 00:30:20.511
A little bit like that.
00:30:20.740 --> 00:30:24.268
Yeah, and they're definitely intolerant of perturbation.
00:30:24.268 --> 00:30:26.645
What did you do to the data?
00:30:26.645 --> 00:30:35.991
I mean there's a 16-digit card numbers typically Check that data and still not perturb the intermediary systems.
00:30:36.359 --> 00:30:51.343
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.
00:30:51.343 --> 00:31:08.842
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.
00:31:08.842 --> 00:31:14.266
The problem was that traditional encryption would break all of that.
00:31:14.266 --> 00:31:25.489
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.
00:31:26.339 --> 00:31:43.910
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.
00:31:44.660 --> 00:31:51.630
So a credit card could be encrypted to something that looked like a credit card, including the first digits, the checksums.
00:31:51.630 --> 00:32:18.393
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.
00:32:18.393 --> 00:32:27.015
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.
00:32:27.015 --> 00:32:38.012
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.
00:32:38.961 --> 00:32:49.128
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.
00:32:50.271 --> 00:32:56.491
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.
00:32:56.491 --> 00:33:01.634
It flowed in the clear over things like internet channels and modems and things like that.
00:33:01.634 --> 00:33:08.982
So fundamentally, you had to figure out a way to encrypt the data without breaking it and still retaining strength.
00:33:08.982 --> 00:33:25.682
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.
00:33:25.682 --> 00:33:29.250
It was in $1,500 per device to inject a key.
00:33:29.932 --> 00:33:51.109
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.
00:33:51.109 --> 00:33:58.724
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.
00:33:58.724 --> 00:34:13.286
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.
00:34:13.286 --> 00:34:23.563
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.
00:34:24.425 --> 00:34:37.931
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.
00:34:37.931 --> 00:34:46.978
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.
00:34:47.061 --> 00:34:56.199
Correct, because you also have the check somewhere you have to maintain to let the intervening characters, a term numeral rather.
00:34:56.963 --> 00:34:58.849
That was where the encryption took place.
00:34:59.510 --> 00:35:02.661
Yeah Well, the thing is too, all of that data is encoded in tracks.
00:35:02.661 --> 00:35:08.623
So what you see on a receipt of your last four digits, there's a different encoded version of that in the track.
00:35:08.623 --> 00:35:19.369
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.
00:35:19.369 --> 00:35:26.429
It's not asking, it's kind of a, I think it's like a 64 character set, so it's different again.
00:35:26.429 --> 00:35:29.259
So there was much more going on under the covers.
00:35:29.760 --> 00:35:50.954
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.
00:35:50.954 --> 00:36:00.085
And that was a game changer, because it became a technology problem with a technology solution but with a massive business advantage to them.
00:36:00.085 --> 00:36:03.652
So they went from being breached to being a leader, which is a.
00:36:03.652 --> 00:36:17.929
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.
00:36:18.693 --> 00:36:20.579
And a 10X increase in your stock price.
00:36:22.003 --> 00:36:23.405
Exactly, and the rest is history.
00:36:23.405 --> 00:36:27.322
Now They've been acquired by global payments who continue using this.
00:36:27.322 --> 00:36:44.666
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.
00:36:44.666 --> 00:36:52.762
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.
00:36:53.402 --> 00:37:06.307
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.
00:37:06.849 --> 00:37:09.940
Exactly and NIST did approve that standard.
00:37:10.101 --> 00:37:42.985
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.
00:37:42.985 --> 00:37:45.329
Did Voltage have any play in that?
00:37:45.329 --> 00:37:45.791
We?
00:37:45.831 --> 00:37:46.070
did.
00:37:46.070 --> 00:37:48.505
We did so, obviously, getting the data up.
00:37:48.505 --> 00:37:57.010
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.
00:37:57.010 --> 00:38:13.963
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.
00:38:14.023 --> 00:38:48.846
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.
00:38:48.846 --> 00:39:06.204
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.
00:39:06.204 --> 00:39:07.590
No cards were in the system.
00:39:07.590 --> 00:39:15.177
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.
00:39:15.177 --> 00:39:20.949
So this got the merchants off the hook of PCI compliance, which was a really big deal.
00:39:22.012 --> 00:39:22.492
I'm laughing.
00:39:22.492 --> 00:39:29.733
Here's an example of making data better by making data worse, at least as far as hackers concerned.
00:39:31.364 --> 00:39:41.273
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.
00:39:41.273 --> 00:39:56.644
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.
00:39:57.447 --> 00:39:58.268
Yes, absolutely.
00:39:58.268 --> 00:40:08.275
We will be coming back to you and the Anjuna security story, but we'll leave this history lesson at this point.
00:40:08.275 --> 00:40:09.925
So, mark, thanks very much.
00:40:09.925 --> 00:40:10.773
We really appreciate it.
00:40:10.773 --> 00:40:11.519
Thanks, george.
00:40:17.630 --> 00:40:19.094
What was the impact of all this work?
00:40:19.094 --> 00:40:21.197
To make, in this case, card data better?
00:40:21.197 --> 00:40:23.402
Well, for Heartland, it was huge.
00:40:23.402 --> 00:40:28.360
Within a couple of years, heartland's stock price recovered from $3 to over $30.
00:40:28.360 --> 00:40:35.699
In 2015, heartland was acquired by Global Payments for $4.3 billion at $100 per share.
00:40:37.244 --> 00:40:52.291
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.
00:40:52.291 --> 00:41:10.166
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.
00:41:10.166 --> 00:41:14.155
This made MagStripe card entry far safer.
00:41:14.155 --> 00:41:24.931
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.
00:41:24.931 --> 00:41:35.809
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.
00:41:35.809 --> 00:41:38.496
Steve Aliphond is a venture capitalist.
00:41:38.496 --> 00:41:50.860
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.
00:41:50.860 --> 00:41:55.132
Oh, albert Gonzalez.
00:41:55.132 --> 00:41:58.000
He scheduled for release September 9th from federal prison.
00:42:01.311 --> 00:42:02.615
Since the Heartland breach, much has changed.
00:42:02.615 --> 00:42:08.978
We've gone, as I said, to chip cards that have their own hardware approach to data generation and encryption.
00:42:08.978 --> 00:42:21.063
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.
00:42:21.063 --> 00:42:24.211
Well, that's it for this episode.
00:42:24.211 --> 00:42:29.795
If you have ideas about topics for the podcast, drop me a line at George at Making Data Better.
00:42:29.795 --> 00:42:33.150
Until next time, I hope all is well.
00:42:33.150 --> 00:42:37.429
Thanks for listening and for your work in Making Data Better.
00:42:37.429 --> 00:42:59.211
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.
00:42:59.211 --> 00:43:02.228
Really, we can't do better than this.
00:43:03.311 --> 00:43:03.753
Yeah.
00:43:04.706 --> 00:43:07.614
It just speaks to the low quality of ad tech.
00:43:08.547 --> 00:43:10.552
Well, I'm sure AI is going to fix all of that.
00:43:11.012 --> 00:43:12.034
Oh, absolutely yeah.
00:43:12.034 --> 00:43:17.976
We've only got a system now to produce bullshitted industrial scale at zero cost.
00:43:17.976 --> 00:43:22.461
What could go wrong?
SEARCH PAST EPISODES
Search past episodes of Making Data Better.
Disclaimer: The podcast and artwork embedded on this page are from Lockstep Consulting Pty Ltd, which is the property of its owner and not affiliated with or endorsed by Listen Notes, Inc.
EDIT
Thank you for helping to keep the podcast database up to date.
