 Welcome to the annual DEF CON convention. This meeting was held in exciting Las Vegas, Nevada from July 9th through the 11th, 1999. This is video tape number 25, SET technology. The world that used to work for the evil gatesy and the warriors. Now, he's gone through the 12 step program. He's back with us. So with that, dead addict. Thank you. I'm dead addict. Thank you all for coming, etc. I'm going to talk about currency systems, the history of currency systems, the fraud issues associated with currency up to e-commerce where we are now, and touch on some other payment systems. Talk about the SET protocol, where it's at, where it's going, and talk a little bit about the pieces involved with SET and how the message flow works, etc. Because I don't have slides ready. You won't see, there's pretty much no way to properly illustrate a message flow or understand it without seeing diagrams. It's quite complex, but once you're familiar with it, it makes sense. It's somewhat straightforward. Although that is the typical complaint initially was when SET came out, people were like, oh my goodness, this is complicated. Well, it's a protocol. Protocols tend to be somewhat complicated. Once you have implemented, then you just use them, right? No one on the internet is concerned about the complexity of TCPIP when their dad's using a web browser. That's how SET should be if properly implemented. So the specification overall is very good. It's a good spec. I haven't heard any serious critiques on the spec, and that's good. Without a good specification, you're doomed. There's no way to win. It's games over. And with a good specification, there's a chance of getting constantly improving products that have a chance at security and could be secure. I think most of the SET implementations are pretty reasonable, but I'm sure once they get deployed in a mainstream fashion, everyone's using it, people such as yourselves will really attack it. And we'll find issues in it then. But because the specification is quite reasonable and it's a good spec, the implementation can be improved. So that's a good thing. Security is obviously important to the banking industry. They care a lot about money for some reason. So the current solutions that were out there weren't solutions, and they saw very large risks for themselves. I'm going to talk a little bit about the crypto. The crypto issues are security implementation, your key creation, your random seeds, et cetera. Bush now can talk about the importance of a good crypto implementation better than I can, and I suggest you visit his website and read what he has to say about the importance and pitfalls of crypto implementations. But the crypto that SET uses is pretty straightforward. Public key stuff, it deals, it wrappers crypto a lot in different layers. And SET's designed so if there's any major flaws in any of the cryptographic algorithms used in SET, they will be replaced. So the cryptographic methods aren't fixed in the protocol. They're what they're using now. Granted, there would probably be some real interoperability issues and a tough transition period and moving away from one crypto algorithm to another. But the specification does hold for that and does allow that. One problem that SET vendors do not have is export issues for the most part. They still have to go through the red tape and they still have to communicate with the government agencies and do all that sort of thing. But for the most part, the U.S. federal government has said that banking is very important and that banks of all people should be getting this drone crypto. I guess the government trusts banks. Yeah, I used to work for the man. I thought operating system software was working for the man. Now I'm working for a very small, lovely company, not a 20,000 person company. But we're working for multinational banking industry, which makes the previous man Bill wishes he could be that for the most part. Thanks to the risk management, that's what they do. That's how they decide how to move their money around. So currently the current e-commerce implementations are not to their liking from a risk management perspective. But they're concerned with more than outside attacks. Ideally in a proper implementation of SET, any given rule should be able to be compromised. Your system administrator, that's an administrative machine where the software is running, should be completely compromised and there's no danger to the financial information. As your DBA, as your network administrator, you should be able to sniff any link, you should be able to be in the middle, and attempt man-middle connections, which isn't really a rule violation per se. But you should be able to be anyone in the system with more or less any amount of access and not have a compromised SET solution. Because most security issues are related to people within the corporations. Initially, when SET is implemented, it will be familiar with SET software, people implementing it, and the people running it, and the absence of people that the audience will have an opportunity to really specify the four pieces of a SET transaction. And the only SET is only for credit cards. It was designed by card associations. It's not a generalized e-commerce solution. It's a credit card solution only. That's what the credit card associations care about it. They are the ones that develop the spec. Privacy. No one in the industry cares about privacy. Individuals within corporations care about privacy, but as corporate entities, virtually no software companies at all care about it. I think the few exceptions to that rule would be in perception management. Microsoft recently announced, and I'm very happy they did, that they wouldn't allow advertisement that violated their privacy statements. On the other hand, they sell sophisticated data mining software and they do sophisticated analysis on their logs so they don't really care about privacy, and no one does. And the banking industry is more so that way. Furthermore, financial information is valuable. It builds demographics. It's extremely valuable. This is not an anonymous e-commerce solution. There are e-commerce solutions out there for cash and money transfers that are anonymous. They haven't done very well, unfortunately. And I'll talk about that some more in a minute here. So I kind of like to talk a little bit about fraud as it applies to through the ages slightly. So we started out with the gold more or less, or some substance that was real. And for the most part, the only way you could commit fraud was to shave it off, hollow it out, attempt to dilute it with another metal. And for each of these things, there's been ways to counter the fraud. You can do volume tests on the metal, et cetera. When we went to paper currency, the problem of fraud increased dramatically. And counterfeiting is actually a very large problem in the world, specifically with U.S. currencies outside of the United States. Hence our new $100 bills. I was going to explain how our currency system works and how money exists. With gold, it's pretty straightforward. You go find some gold, you have gold, you trade it for goods. But with banks involved, you have a situation where they're giving out more money than they have, so they're creating money. And there's a reasonably good explanation of how a financial system works in regards to money distribution on eggold.com. I found every time I attempt to fully understand, let alone re-communicate how our currency systems work, it makes you sound like a complete nut. And if you've listened to any length to economists, you'll know what I'm talking about. So the credit system, many people, the card associations care about their brands, much like other businesses do. So people think, I'm a Visa card in my wallet. No, you have a card that was issued by a bank. That's not a Visa card. Visa is associated with that bank and an association. The bank has rules they have to play with to stay in that association, as does the merchant that accepts that credit card. For instance, there's charges associated with all of this, and your merchant, one of the rules in the States, is a rule they're not allowed to charge you less for non-credit card transactions, because that makes it really clear to the consumer that this is costing them money. Well, so what ends up happening is everyone with cash subsidizes those credit charges that the merchant has to use. There's a couple of different types of credit card transactions, and these are very important for risk analysis. Face-to-face is considered the most secure, and you hand someone a credit card, and they may go off for a while, but the fraud rate is relatively low in a face-to-face transaction. So the card associations, their banks, they have formulas they say, we've gotten this many charge backs, this many credit card denials, so this is what we're going to charge you for this type of transaction. Merchants get charged less for face-to-face transactions than they do for what we call motel, or mail-order telephone transactions. They get charged a lot more for that. Some of you in the room are actually responsible for that. It's very easy to commit fraud over the telephone, and the card associations are obviously very interested in minimizing that fraud, but it will always be much easier if you're a disembodied voice on the other end. With face-to-face transactions, the card associations, if they cared, could get more strict in the protocol they require. For instance, if you hand someone a credit card and the card association requires that the idea is checked and you're committing fraud, the merchant most likely is going to eat that charge, and that's why those rules are in place. There are some instances where the bank will eat the cost. This all costs money. If I buy something and I say, well, I didn't buy that and dispute the claim, that costs money, that costs the merchant money, even attempting to run an authorization, you have a credit card that expires, your limit is expired. When the credit card fails, that just costs the merchant some money. Even people attempting to commit fraud with say generated credit cards with correct check sums or whatever they're doing, attempting to use fraud, even if it's caught, ends up costing the merchant money. In the case of the internet, those numbers are rising very dramatically. The most often heard question I hear concerning SET is, so that's dead, right? That hasn't gone anywhere, right? Two and a half years ago or so, everyone was extremely interested. There was a lot of buzz and hype. The card associations moved remarkably fast to create the specification or to empower the correct bodies to create the specification. For bank time, they moved very fast. It hasn't gone anywhere, so why is that so? One problem is there's four pieces in a SET system, a card holder, a wallet, a pause, point of sales, a gateway, which connects to the legacy financial networks for credit card authorization and a certificate of authority that validates everyone. Well, if you as a client, or a consumer has a SET wallet, you need a SET-enabled merchant. And that SET-enabled merchant, that SET-enabled merchant then needs a gateway to connect to the legacy networks. And that chicken and egg problem has prevented deployment to some degree. There's also the issue of Y2K. Banks are wanting to make sure that they're good with that and don't want to introduce new software that they'll have to implement 2K compliancy tests. They really know where they're at as far as Y2K now and they want to devote their energies and their budgets to that. So I think after the years over, we'll see more SET implementations. In the United States, there's no reason for anyone to use SET from a consumer standpoint. This isn't the case elsewhere. In fact, SET isn't completely dead in Europe or Asia. The consumer has no risk associated. They, for the most part, don't care about their credit card security at all. They know if their card's lost or stolen, they can make a phone call. They don't have to worry about anything. The worst that will happen to them is a $50 charge. That's very nice. That $50 limit means no one has anything to worry about here. In Europe, that's not the case. And I don't think that's the case in Asia either. If you lose your credit card, you're liable, you're potentially liable for the entire credit limit that you have with the institution. So if you have a $5,000 credit card and lose that, you might be in trouble. This is perhaps the reason why e-commerce hasn't taken off so wildly in Europe as it has in the U.S. is people in Europe are aware of the risk associated with credit card usage. And for the most part, the internet's not secure. And they could lose their data. They could lose their money rather. Last year was the first year, for the most part, the Christmas season last year was the first year e-commerce had significant dollars behind it. There was enough traffic flowing in cash for people to realize this was suddenly real and was not a fluke of one or two successful merchants on the internet. So as the e-commerce use goes up, the fraud rates are also increasing and the card associations are looking at those. But until last year, everyone's, as far as major corporations were more or less getting an owner at presence and developing a commerce presence just to have it so they wouldn't be beaten by the other guys. Now that there's real money going through there, there's a lot more incentive to have secure systems. So that's why SET hasn't taken off. Why it might take off? Massive fraud, obviously. That's costing the merchants. It's costing the banks. And if there's large visibility issues, the card associations might realize people aren't comfortable with spending money, which means they make less money. So that's no good. Our current e-commerce solutions is for the most part SSL. You got any say about security and they're talking about SSL. And SSL is fine. I like SSL. Nothing wrong with it. It is a secure connection. It is a secure link for the most part. So that's great. The problem is, though, from a bad guy's perspective, they could watch my link, try to find out when I'm purchasing somewhere. If I purchase once or twice a month, they'll have to wait one month or two weeks to find a single transaction. And then they'd have to break the SSL if they wanted my credit card number. But for the most part, I don't have a lot of hesitation in sending my credit card on SSL through the Internet. The only reason why that bothers me at all is because the people that have the systems without SSL, and I've seen merchants without SSL on their credit card entering information, are the same people who are going to have really bad back ends. And as a hacker, the thing to do, if you want to get lots of cash, or as a criminal on a thief with computer abilities, if you want to get 30,000 credit cards, you don't get them one at a time. You go to the merchant, you hack into the merchant system, you go to his database, you hack his database, and you have 20 or 30,000 credit cards. I wouldn't suggest anyone in the audience do this. Hackers have a tendency to sell those credit cards to the FBI, so I don't recommend that either. There's no alternative to set right now. SSL is there and it's a good piece, but it's not an end-to-end solution. Very often those credit cards are sitting on the merchant side in plain text and some database somewhere. They're very vulnerable. And there have been instances where companies have been hacked and their databases have been pulled. This is happening. It doesn't instill confidence in the consumer. This is for certain. One important thing about set as interoperability, all of this stuff has to work together perfectly. There's four components and they all have to talk to each other well and they have to work all the time. If IBM is making one piece of software and Compaq is distributing another piece of software and Microsoft is distributing a wallet and they don't all talk together, the consumer really doesn't care who's fault it is. He might blame the wallet because that's what he sees as an interface, but his impression of set will be bad and set won't work if there's not full enough ability. So the very software vendors communicate with themselves very closely and do things like interoperability fairs where they test against permutations of each other's software to ensure interoperability. This is kind of interesting because while bugs are discovered everyone's competing with each other. So as a rule you don't want to announce your bugs to your competitors but there's no other way to ensure interoperability other than testing against each other. Anyone familiar with SAIC? So there's an SAIC division or team that branched out into a separate company called SIRTCO. SIRTCO is kind of important in the set world. It has a few different roles. They developed a specification which is in ESN 1.1 I do believe. Here's a formal definition here. It's not light reading, not light reading at all. And so they developed a specification working with the card associations and the various players to see what's necessary to replicate the functionality of existing credit card systems. So it does that pretty well. The credit card models, the authorizations, the captures, the batch captures, all of this stuff which if any of you are familiar with credit card processing existing in credit card world directly applies to the set world which probably makes the gateway implementation a little bit easier. So SIRTCO also has the root certificate of all the CAs so they issue other CAs certificates and they're at the top of the chain. I'm not sure if that's quite the case. There's been a little bit of fragmentation on that end. That was the ideal to begin with. It might happen that there will end up being multiple certificates. They also give out set marks and that's just a certification saying you passed our battery of tests that achieve a baseline or the reasonable amount of set functionality and it all works good or perfectly. Set mark is useful because it's sunbar. It's not a perfect battery of tests but it's certainly better than nothing. So there's the players. There's the certificate authority, the wallet, the pause in the gateway. The certificate authority distributes certificates to all the parties. How the wallet user gets this certificate will probably be distributed by the bank and the bank will allow them to get their certificate. The pause, or I'm sorry, the issuing bank. There's a couple of different terms in relation to the banking parties involved here. The issuing bank is who gives you your credit card. The acquiring bank is the merchants bank that takes money from your credit card. So your issuing bank will issue you certificates. The acquiring bank will issue the pause certificates and the acquiring bank will also probably be running the gateway into their legacy networks. And as a rule, if the pause is not using hardware cryptography, the gateway to the legacy networks definitely is. That's probably the most vulnerable piece of the set equation is the gateway because all the credit cards from various merchants are going through this one point and they do have to leave the set protocol so they're not encrypted anymore and make it onto the gateway network. Fortunately for people that are implementing this, the gateway is normally in a banking secure environment and people who implement banking systems at ops centers as a rule do reasonably good jobs and are very thorough in their security audits and their physical security and all of this sort of thing. So when you make a transaction and set, what it looks like is you're shopping a merchant. You say, yes, I want to pay. The merchant then sends a MIME type that's a set MIME type packet with what's called a wake-up message. And the wallet receives the wake-up message and the browser receives the wake-up message, kicks off the wallet. So that's associated with the wallet application. And the wallet could be a locally based wallet or a server-based wallet that's located at bank. The advantage of a server-based wallet is that your keys are stored remotely in an environment that's more secure than my mom or your mother's computer is. And so you can roam around on various computers. So if you have a wallet that's locally a PC, you can't purchase from someone else's PC. So a server wallet's kind of nice in that respect. So the wake-up message is received from the wallet application is launched. You type in your password. And the message is sent back to the merchant saying, yes, I agree. This is fine. The merchant sends a message to the gateway that includes your message. And that says, well, is this credit card valid? So the gateway then determines whether your credit card is valid or not, sends a message back to the merchant. The merchant then sends a message back to you saying, yeah, the gateway said it was fine. So I think it's fine. So the purchase is complete. And that's over. One nice thing is that I'm not going to go into high-level detail of the crypto layering and the message laying right now. The books do a reasonably good job of explaining it. And these books, by the way, are located on CertCo's site. So certco.org has, in PDF form, free all of the specifications, somewhat of a dry read. To see it doesn't revoke user certs. Generally the certificates authorities, they issue certs and revoke certs. They don't revoke user certs at all. This is kind of a minor point, but that's because of certificate revocation lists for 20 or 40 million card holders would get unreasonable and network traffic would be obscene. So what happens is the certificates that the CA issues are only revocable for the gateway and the pause. So as a card holder, you will know that that pause doesn't work and it won't work if the certificate's been revoked. One of the things that excites me is a possibility about SET. I like SET because it's more or less secure. It's better than SSL, which kind of offends me. And it's so much that vendors pretend that this is their security and this is real security. If they want to talk about security, they should show me their network topology and where everything's sitting and be happy enough to know that even if I know all this, I still can't get them because their employees will most likely mess with them, not outside intruders. So about security as a sell doesn't make me happy. What I would like to see is pavement gateways. I've seen some, there's Milakash, there's equal, there's some, commerce solutions are designed to allow anonymity and it's entirely possible that you could go to a site and buy with, say, SET, $50 worth of credit in another payment type and then use that payment type elsewhere. I think this would be very interesting. And also very interesting is it's possible and feasible to implement your own currency systems if you can get enough people to go along with it. E-gold is sort of an interesting example of that although it's a gold-based currency system and not one they completely made up. Let me see. Do you have any questions? Yeah. I'm not sure, I'm not sure. That's a good question. Did you cash review in Megapro? And one of the things that they had was online cash. And the question was, you know, do you know the license it had to qualify? I don't know the answer to that. I was looking at DigiCash and it's once again one of those chicken meg problems where you need all the merchants or a significant base of merchants to increase the usage and there just weren't enough merchants. Yeah. I don't think the banks are very excited about micropayments. I don't see them moving to implement them soon. I think it's entirely possible that one could implement micropayment systems. Obviously they have been implemented. I like them a lot myself. The charges that credit card companies charge right now are exorbitant and outrageous in my mind. They're banking, so to speak. We talked a lot about the domestic national set and everything but a lot of the commerce has started to go overseas in different countries with different regulations. What kind of crypto that you can use? I mean obviously we treat our SSL or encryption as munitions in the United States. So certain is not allowed to... And for most encryption but certainly true banking encryption is more or less the exception of that if anyone realizes if there's one weak link in the chain and it's this country, that just won't work. It's my understanding that the set is only not allowed from our perspective and it does have strong crypto. The set is not allowed into Iraq and two or three other countries. But for the most part it's allowed to be exported and for the more Europe and Asia are actually implementing set a lot more than we are. There's been some pilots in the US but the pilots in Europe and the usage in Europe is vastly higher than that. There's a site called set-site. I think it's .com or .org that lists all the merchants that are available and 80% of those are European. I'd say 15% of those are Asian and I think there's one US merchant at the moment that's using the set. Yeah. I'm trying to get a representation. I'm ready to say I'm going well with my heart and both hands. And of course it's back to my perspective. How many of you issued those? So you lost your certificate as your scenario, right? My top gets stolen. So if your laptop gets stolen or you lose control of your key material the proper thing to do then is act as if it was a physical device that you just lost. It was your card that you just lost. And then once your credit card is revoked it doesn't matter if the certificate is still valid because the transaction will be denied. Yeah. I wonder what the difference is from a hacker's perspective getting into the back-end database of going through and using SSL connection versus when you go to a point of sale using credit card they take the same imprint and put it into their computer system again. And the all-time back-end system is the same back-end system. So there's this big juicy database back there whether you go through the internet or you go through a cache or call. Yeah, you're probably right and I haven't seen a lot of large commercial institutions topologies in exact implementation details. I would imagine though that on the internet and their e-commerce there's more or less a gateway to their back-end system there and it would probably be a lot more non-trivial to gain access to that back-end system that you're referring to. But I would imagine quite simple to get that link in between the two and grab everything that's on the internet. I'm not certain how secure these people are these merchants are. It's obvious though with the bugs in site server for instance that just came out. The merchant software bugs that have been exposed and shown in my mind these problems should have been discovered by security audits by these companies that are implementing them. There are mom and pop shops on the internet but there's also multi-billion dollar corporations running some of the software and without a security audit trusting Microsoft to be sure is never a good idea. They'll learn any other software vendor. Yeah. The certificate authority chain is different from the SSL sort chain. So the certificates involved are X509 certificates but there are set extensions to them. So I'm not sure if they're strictly speaking X509 but that's what they're based off but there are set extensions to that. One interesting point one of the beauties about the set protocol thing that excited me most about it is my merchant never sees my credit card info ever. They never had my number as that was developed. So there's no chance of fraud on the merchant side. They just get the clearance from the gateway and then they get their cash from the gateway but they never see my credit card number. That's also important from the standpoint of the tax point view in the fraud issue that is important. Yes. Yes, they are. Yep, non-repudiation is very important to them. Anyone else? Good. There's set off any protection against fraud involved in buying things that are purely software passwords. That's an interesting question. So the question was to set off for any specific protection against fraud and electronic items or non-tangible items. That's the non-repudiation factor that you signed your key and you signed the transaction. That is a face-to-face transaction. Suddenly the internet's much higher than mail or telephone fraud but they consider a face-to-face transaction and right now a lot of fraud is concerning things like pornography. I've known people working at credit card call centers and the husband that denied ever visiting the porn site was very common call to him. Could you explain a little bit about what exactly happens but I guess there's more than just typing in your credit card and saying okay. The only time you type in your credit card number is when you initially are getting your certificate. So after that your credit card information is wrapped in crypto layers. So you're typing in a password at some time to set up? Yes. As you enter your information in your credit card number you have a password that's associated with that certificate. That could be grabbed off your system. The certificate on your local machine is what we were talking about. I guess if somebody was running out of a piece of program I would directly go around the memory of somebody. And there's very little to do about that and that's outside the set of classification but certainly one attack against that would be to have a Trojan that hits client machines and hits the communication between them and their wallet and watches that. So yeah that's pretty reasonable attack against it. I'm sorry, I just want to make sure I understand that every bank now that is a credit card has to be in the surgery business as well. Not necessarily. They can firm that out. They can give that to they can abdicate that responsibility or give that to a third party certificate authority if they want. That has been the general model how it's been deployed in pilots. I think when we're dealing with 20 and 30 million certificates they might firm it out to someone else. I think they like being in control of it though as a bank because the process of issuing a certificate has some business rules at the back end so your bank can send you a letter and this is called out of band stuff of the protocol but they would send you a letter saying here's your activation code to activate your wallet log into this site so you're in this site enter your information enter the activation code then enter your credit card number and password and then it's checked against the certificate authority because you're requesting a certificate and if they're running the certificate authority they can be talking to their back end databases to make sure that the information you just entered corresponds to their information so if other parties are going to implement it they'll probably have to have pipes into the bank's back end systems to execute that business logic. You probably want to initialize your certificate and pass it out of bounds and compare them when you do it on the internet like you're going to your bank physically and set it up on the legacy system then you know that the initial transmission does not open. And that would be the issuer bank's decision and yes that would help mitigate fraud and I've heard some of the business decisions go to various levels of physical authentication to get that set up information and at that point they see your credit card they see in person you should assert you're the only one that has a password the non-repudiation thing is pretty much clenched at that point. Yeah. What do you think about the future of the AXDA 509? No opinions. Ask me. Yeah, ask for this. Ask for this. Yeah. Do you have any plans to improve or encourage any of these capabilities to set up? Yeah, there are some plans. Japan has some very, very bizarre payment options so there's extensions to set called Japanese payment options that credit your account and they give you little kickback gifts and it's all very odd and confusing. It's very confusing how Japanese does it. There's smart card extensions there's a set too well and I don't think it's very far through the committees and whatnot. I think they're going to wait for set 1.0 to take off but yeah yeah, there's definitely more work on the protocol being done. Yeah. Do you have some of the resources you talked about that you would like to review? Let me see setco.org is one and they have a list of the various set vendors on that site. There's a set protocol and more information about set. There's a book about set at Amazon and I don't recall the name of that but I believe the author's last name is Grady so Grady G-R-A-D-Y I believe. Set sites I'm not sure if there's a dash in between the two it might be set-sites at least. Has a list of all merchants that they found on the internet using set which is probably a couple hundred at this point and the issuing banks and whatnot. The other people involved with set. That's how I can think of it offhand. Searching for articles on set from American Banker on the American Banker site is pretty interesting too. You can get the banking industries assessment analysis of set. Also the entire set specification is available over the net I forget exactly where I got it about a year and a half ago. It's on SIRTCO. All of these are on pdfform at SIRTCO.org so yeah. Very fun reading and I think I'm about out of time I guess I'm going to take maybe one or two more questions. Yeah. You mentioned the anonymous credit card I don't know about anonymous credit cards issued by banks. Try egold.com I'm not sure how well they're doing but that's something very interesting. egold.com also has a description of currency systems that's very, very good reading. Last question. There's a lot of legacy financial networks and I do work in a financial infrastructure company but I'm not familiar with any of those. Thank you very much. Appreciate your time. Thanks very much.