This article can also be found in the Premium Editorial Download "Information Security magazine: IDSes takes aim: Emerging "target-based" systems improve intrusion defense."
Download it now to read this article plus other related content.
After nearly three decades of tackling some of the world's hardest cryptography problems, Ron Rivest is turning his attention to another tough nut: "micropayment" schemes for e-commerce transactions. Along with MIT colleague Silvio Micali, Rivest is serving as the technical brains behind Peppercoin, a Waltham, Mass., startup that hopes to make big bucks helping e-tailers increase the security, efficiency and profitability of low-cost Web-based transactions, such as digital songs, games and copyrighted articles. We caught up with Rivest at his MIT office in Cambridge, Mass., to find out more about Peppercoin, and to get his insight on other pressing Internet security issues.
ISM: Tell me about Peppercoin.
RIVEST: It's the right way to do microbusiness, because the technology hits the key difficulty on the head: the problem of efficiency.
ISM: Why is efficiency important?
RIVEST: Because it keeps the bank out of the payment processing loop for every transaction. Every payment doesn't go back to some central place, which is a huge source of inefficiency in standard online payment schemes. Payments are made from, say, the consumer to the merchant, and only some of those payments end up back at the payment processing/service provider. Our technology uses a cryptographic sampling procedure to specify which payments are going to end up back at the payment service provider. So if, for instance, the provider is picking one out of 100 transactions, he will be paid hundredfold for each of those he turns in. The other 99 transactions, he gets paid nothing for.
"I think people who are trying to figure out whether they should shop on the Web should not worry so much about security issues. There are many other things to be concerned about."
I think people who are trying to figure out whether they should shop on the Web should not worry so much about security issues. There are many other things to be concerned about.
ISM: So, the merchant essentially gets paid once every 100 times, and he gets the value of that one transaction multiplied by 100. If I'm selling digital music online and I sell 100 songs at $1 each, I won't submit all 100 transactions to the payment provider. I only submit one of them, but still get paid $100.
RIVEST: That's correct.
ISM: What if the price of that song isn't the same for each of those 100 times?
RIVEST: The merchant gets paid the correct amount on the average. The first key to making this work right for variable-sized payments is to adjust the sampling frequency in proportion to the value of the payment -- so that, in this case, a $2 payment is chosen one out of 50 times. The second key here is quantity. If you're in a business based on micropayments, you're going to be doing lots of them. In those cases, the law of large numbers comes in, and this kind of statistical information procedure is going to work very well. When you get into the thousands of payments or more, even though the payment is an average, the amount the merchant gets paid is essentially right on the nose.
ISM: Our discussion about payment schemes brings up larger questions about e-tail security in general. Would you say that the implementation of most of today's e-commerce systems is reasonably secure?
RIVEST: Yes, I think so. We've got good technology out there that's reasonably well deployed. I think people who are trying to figure out whether they should shop on the Web shouldn't worry so much about security issues. There are many other things to be concerned about: malicious merchants, merchants who may have poor security practices and so on. But, by and large, I think e-commerce security is working.
ISM: As a consumer, what should I be concerned about?
RIVEST: The security of your home computer is a good place to start. The vulnerability of the current setup of home consumer platforms is a real concern. Trojan horses on your home computer are perhaps more of a concern than the security of the connection to the merchant or the merchant's security. Making sure your system is updated and has the latest patches and so on is probably the best place to start.
ISM: How well do you think your work in cryptography, particularly on public-key systems, will stand the test of time?
RIVEST: I think the work on the RSA algorithm has certainly withstood that test already. When we developed the technology in the late '70s, it wasn't clear whether it would withstand the test of time. But it really has withstood all attacks.
ISM: What is the particular genius of RSA? Is it in factoring large prime numbers?
RIVEST: Well, it was really the first proposal -- in the public literature, anyway -- for a public-key crypto system that worked. There had been the seminal paper by Whitfield Diffie and Martin Hellman for the idea of a public-key crypto system, which is what motivated us. Our contribution was providing the first practical realization of that.
ISM: Silly question, but is the sequence R-S-A indicative of your respective roles in its development? Why wasn't it SRA or RAS or ASR?
RIVEST: Adi [Shamir] and I talked to Len [Adelman] about having "ARS" or something. But Len joined the project a little after Adi and I, so he asked to be put last.
ISM: Do you think that most enterprise security professionals are focusing on the "right" things?
RIVEST: I would like to see several issues addressed better. Ease of use is one of those. I think security and technology is often very good from an academic perspective, but when you field the technology you have to be very careful that it's usable by your average system administrator.
ISM: Would that be a strike against the current PKI systems?
RIVEST: PKI certainly has problems. The whole idea of PKI was to bind domains to public keys, but when you start to think through that issue carefully, you get into some conflicting requirements. If a name needs to be globally unique, it tends not to be memorable by people. Also: Who's the authority for actually binding a name to a key?
ISM: A lot's been written about quantum cryptography. What's your take on it?
RIVEST: I think it's interesting from a scientific and technical point of view. But in terms of widespread applicability, it's quite limited. Quantum computation is another very interesting area of research. Should people succeed at building quantum computers at large scale, it threatens RSA and other crypto systems. It seems, however, at the moment, that engineering difficulties are extreme for building large-scale quantum computers.
ISM: On an academic level or a basic research level, where is the greatest need for security research? Is it in new crypto systems? Or protocol development? Or standardization of processes? Or what?
RIVEST: Security spans a wide range of activities-that's one of the things that makes it so interesting. In the real world, you have to worry about things like, where do the secret keys get stored, and how do they get kept secret? If we're going to have homes with 40 or 50 computers -- which is likely to happen down the road a bit -- security and key management become huge challenges for the average person.
ISM: What other applications could benefit from applied crypto that aren't using them today?
RIVEST: I think voting is an area where security is obviously the number one requirement. Ease of use is, of course, a high priority, too. The challenges in designing good voting systems are extreme because you have to maintain the anonymity of the voter. And so you don't have audit trails like you do for e-commerce systems.
ISM: Are you concerned about the erosion of privacy in general?
RIVEST: Absolutely. I think we're in an area where the defaults are changing from privacy being innovationally private by default to an area where information is almost public by default. We have to work hard just to stay in the same place.
Andrew Briney, CISSP, is editorial director of Information Security.
This was first published in January 2004