|
Topics covered include:
[Top of Page]
JB: Welcome to the CREN Tech Talk Webcast, and to this session today with Jeff Schiller on Certificate Authority Services. You are here because it's time to discuss the leading core technologies in your future. This is Judith Boettcher, your CREN host for today, and I'm pleased to welcome Howard Strauss of Princeton as our technology anchor for the Tech Talk Series this fall. Howard is a well-known Web and all-around technology expert. Welcome, Howard.
HS: Thank you, Judith. And thanks again to CREN for choosing me as the technology anchor for Tech Talk. The job of the technology anchor is to engage our guest expert -- today, that's Jeff Schiller -- in a lively technical dialogue that will answer the questions you'd like answered, and to ask the very important follow-up questions that you also probably want to ask.
You can ask our guest expert your own questions by sending e-mail to expert@cren.net anytime during this Webcast. If we don't get to your question -- and we might not because we sometimes get a lot of questions -- but if we don't get to your question during the Webcast, we'll provide an answer in the Webcast archive.
Yesterday, the Internet was just a place where we sent each other simple e-mail and looked at each other's webpages. Today, we use it to check and modify sensitive personal data, pass credit cards around; we buy and sell stocks and bonds; we use it to reallocate our retirement nest eggs and all kinds of things. And yesterday, this was all protected by a publicly known user ID and an insecure password, usually passed around the Net in the clear.
Now we need a lot better than that. Today, Jeff Schiller is going to discuss digital certificates and certificate authorities. These are ways to make us more secure when we use the Internet. I should warn you that this is a complex topic involving encryption schemes, key escrow issues, export regulations and lots of other stuff. But understanding these issues will help you sleep at night after you've logged off the Internet.
Judith?
JB: Thank you very much, Howard. Let me give you our guest -- a little background on Jeff Schiller: Jeff is the Network Manager at MIT and has the distinction of having managed the MIT campus computer network since its inception way back in 1984. Jeff is recognized nationally for his expertise in security and authentication. Jeff's recent efforts have resulted in the first US legal version of the popular PTP encryption program being released by MIT, and you can find a direct link to Jeff's own homepage on the Tech Talk event page.
Welcome, Jeff, and thanks for joining us here on CREN Tech Talk.
JS: Thank you, Judith. I'm glad to be here.
HS: I think the way we ought to start, Jeff, is just to make sure that people have some background in this area in general. So could you, just for our listeners on our Webcast --
JB: I call them Webbers sometimes, but that's maybe a little silly.
Topics
HS: I'm not sure what they are here. We have to get used to this new thing. But Jeff, could you just give us some kind of overview of what digital certificates are, why we need them, what this whole technology is about, before we go off and get into some of the details here?
JS: Sure, Howard. I guess you can call our listeners out there lurkers because they're kind of listening in and we don't really know that they're there. Certainly I don't see them.
HS: Unless they send us e-mail, which we encourage them to do.
JS: Yes, which we certainly encourage them to do.
But let me draw an analogy. Today, we use the Internet and we tend to secure our transactions by sending passwords over the network. And yet, like our lurkers who are listening today, we really don't know who's listening or eavesdropping on the networks that we send the information over. Here at MIT, because we have almost 50,000 computers, we can't say at any point in time how many of those are compromised and have actually been turned into monitoring devices designed to capture those passwords in flight. Certainly we occasionally get break-ins, and after the break-ins, we discover logs with commonly hundreds of passwords that have been obtained. The cracking community swaps these passwords, and they literally swap them by the hundreds and the thousands.
So really, passwords are no longer the way to go. And that really only leaves us with one alternative, and that's to use an encryption-based approach, where instead of sending a password over the wire, we demonstrate the knowledge of a key by enciphering some information to prove that we are who we claim to be. And when you look at encryption systems, the ones that are practical -- in terms of they could scale to the millions of users on the Internet -- are the systems based on public key cryptography. And that's what digital certificates are critical to use.
Topics
HS: Jeff, can we just separate the two issues somehow, of encryption and authentication? They seem to be tied together here, the way you're describing this. But they're really two separate issues, aren't they? Or are they?
JS: Well, there's encryption for confidentiality, and there's encryption for authentication. The encryption is common to both -- it's just how you use it.
Obviously, in the case of confidentiality, you're going to encrypt data so somebody who's watching the wire can't see the data.
In the case of authentication, which is usually tied with integrity, you're using encryption-based systems. You're not actually encrypting the raw data as it goes back and forth, so somebody who might be watching could see the information. But the information that's crucial to authenticating you is encrypted in some way or other so that somebody who's watching it can't turn around and then claim to be you.
HS: Could you just give us sort of a realistic example of how these digital certificates are used? I want to interact with my bank. That might be a case where I'd be using a digital certificate, right?
JS: Okay.
HS: How would I do that? How would I make it so that my bank really knows I'm me and I really know it's the bank, because I'd really like both those things to be true if I'm going to start moving money around.
JS: Let me give you a very simplified example. Of course, the actual algorithms that are used are far more complex than what I'm going to describe.
HS: That's okay. We can skip those!
JS: But let's try to make it simple here. Suppose, in the case of public key systems, you have a public key and a private key. The bank will know your public key. In fact, any number of organizations or people might know your public key.
HS: How will the bank know my public key?
JS: At some point, when you registered for your account, you gave the bank your public key. So at some point in time, your public key was given to the bank. Now, I'll get to certificates in a minute and the role that they play in that, but let's just leave that aside for a minute. Basically, let's just make for argument's sake, the bank has your public key, you have your private key. No one but you knows your private key.
HS: I'm sorry to interrupt, but I just want to make this clear. How did I get my public key and my private key?
JS: Ah! You generated them together. You ran a piece of software than generated what we call a key pair, the pair being the public key and the private key.
HS: And I got that software from?
JS: Well, in the Web application, that software -- for example, if you're using Netscape, it's built into the browser. If you're using Internet Explorer, it's an ActiveX control that you have to download.
HS: Okay, so inside my browser I have something that will give me a private key and a public key so that now I can send my public key off to people.
JS: That's correct.
JB: And certainly, then, since the public key -- everybody can use it -- it's okay to send it out. And I don't have to worry about anyone getting it because, in fact, I want everyone to get it.
HS: So it's sent in the clear, then.
JS: Right, you can send that in the clear.
HS: Okay.
JS: Now, your private key you send to no one. You keep that just to yourself. Now, when you connect to the bank, the bank will challenge you. Typically, a challenge is a number. Again, we're going to keep it simple, so let's say the bank sends you the number 5. Using your private key, you perform a mathematical operation, and what pops out is 23. So you send 23 back to the bank.
HS: And this mathematical operation you perform, is that done by the browser as well?
JS: That's done by the browser.
HS: Okay, so I take this thing I get back. The browser does some stuff to it and I send it back.
JS: And you send it back to the bank, using the public key, and they take the 23, do a similarly complex operation with the 23, and they get back five. And they know that that must be you because only you could have computed the 23 from the five. Like I said, obviously with small numbers, somebody can say, "Let's try sending two, three, four, five. Eventually, we'll get in." So in real life, the numbers that are used are so large that you couldn't possibly try to search through the space by sending every possible answer.
HS: So now the bank knows you're you?
JS: That's right. Once I've done this transaction, the bank knows that they're dealing with me, assuming they know that they have my public key.
Now, where the certificates come into play is, how does the bank know it really has your public key? Obviously, one way is you could have brought it in on a floppy disk to the bank and said, "See? This is my public key." But that's not particularly -- it doesn't scale well. In this electronic age, the last thing we want to do is run to the bank with a floppy, particularly if the bank is on a different coast than we're on.
So what a certificate authority does is a certificate authority creates a document that's digitally signed. We'll go into that more in a bit. That binds your key to your name. So now what happens, when I talk to the bank the very first time, I can give the bank my digital certificate which says, "This guy is Jeff Schiller, and this is Jeff Schiller's public key." And that's issued by a certifying authority. Now obviously, for the bank to trust the certificate, the bank has to recognize and trust the certifying authority.
HS: I can understand how the key is bound to my name, so there is some key bound to Howard Strauss, but how do they know that Howard Strauss is really me and not you pretending to be me?
Topics
JS: Ah, well, this gets a little bit touchy. There's really two kinds of certifying authorities. There's private certifying authorities, like we might run here at the University, where we would establish the procedures that we would follow before we would give somebody a certificate.
For example, at MIT, we give each incoming student what we call an account coupon, and that coupon has their name, their MIT ID number on it, and a six-word phrase. And when they get their first certificate issued by MIT, they actually do this online. Part of the form they have to fill out is to enter those six words, and they have to get that correct. And so the ultimate authority is, we hope, that the people at the orientation center when the new students arrive only give John Doe's packet to the real John Doe.
HS: That seems to work pretty well for students. What do you do for staff and new employees? You do the same sort of thing for them?
JS: Yes, we have to do the same sort of thing for them. And because that process is a little bit more chaotic, ultimately what happens in some cases is the new employees will have to go in person to our Accounts Office at MIT and show an MIT ID.
HS: But basically, certificate authority somehow or other has to be pretty confident that you really are you. They have to come up with some scheme to do that, whether they actually look at you or take your fingerprints. Whatever they do, they've got to be pretty sure.
Topics
JS: That's right. And like some of the public certifying authorities -- like Verasign, for example, actually has different classes of certificates. And the difference between the different classes is the amount of rigor that they go through to prove that you are who you claim to be before they give you the certificate.
HS: Could you say a few more words about Verasign? Are they the only people who are doing this kind of thing? Are there other people out there issuing digital certificates? I mean, they're the people who issue digital certificates, right?
JS: Well, actually, anybody who's listening to this can go with their Web browser. I don't know the exact menus you follow. I can do it in here for Netscape. You find what's called the list of certifying authorities that the browser trusts. You'll see there's quite a few in there. You'll see AT&T; looks like they're going to be in this business. GTE looks like they're going to be in this business. There's a company called Thoughts Consulting which is in South Africa. Now, I don't know how many are actually issuing client certificates today, but certainly as this grows, we're going to see more companies getting into this business.
Topics
HS: Jeff, we just got a question in here. This is probably a little bit out of order, but I think we ought to try to handle it anyway. From John Wilkins. He's commenting on the fact that you said that passwords are dead. He said, "Well, if passwords are dead, what's the future for Kerberos?"
JS: That's a very good question. Kerberos, interestingly enough, is not a password system. Kerberos is actually designed to look like a password system to the end user, but when you use Kerberos, the password does not go in the clear over the wire. What actually goes over the wire is a very similar encryption-based challenge-response -- like I just told you when you talk to the bank, and what you do is you type your password into the client workstation to prove to the workstation that it's you. Actually, your password turns out to be an encryption key. And in fact, it's not a password system in that sense.
HS: John, if we haven't answered your question, just send us another and we'll try to handle that.
JB: And we might get back into this and clarify that just a little bit because I think that certainly people have heard so much about Kerberos, and you've been involved, Jeff, in its development. So just the relationship. Has the field just totally moved away from Kerberos, or will it?
HS: Especially with you being up at MIT, Jeff, where Kerberos came from. It's probably something very sensitive to your university. Are you going to be fired if you say bad things about Kerberos?
JS: No, I wouldn't be fired if I said bad things, but that's okay -- I'm not going to say bad things.
JB: Are you still using a Kerberos system at MIT right now?
JS: Absolutely. In fact, our scheme for issuing certificates is based at some level on Kerberos.
Topics
JB: So you're combining both digital certificate technology with the Kerberos?
JS: That's right. The issue here, it turns out -- I was going to say "the key here", but we could get ourselves confused that way. The issue here is Kerberos works very well in an institutional environment, where you have a single administration.
In our case, we have three centralized Kerberos servers. Every transaction -- when I log in each morning, I have to do a transaction with the Kerberos server and it issues me what are called Kerberos tickets which I can then use to prove my identity to the various services that I use. It works fairly well, but it's fairly interactive. If the Kerberos server is down, then I can't log in and I can't read my mail and there's a lot of things I can't do.
Now, when we have public key systems, public key systems don't require an online Kerberos server or "key distribution center," as we like to call it. So the theory of digital certificates and using public key is that you could have a million users. If we had a million students at MIT, Kerberos might be stretching its ability to handle that.
HS: Certainly, you'd have to have more than one server, or the server would fall over, with a million people.
JS: But even if you had multiple servers, it's not clear that it would really scale. It was never designed to scale to the one million to ten million users. But when you look to deploy technology on the Web, you are talking hopefully of about millions of people. So we have to use a somewhat different technology.
Topics
HS: Isn't there also a problem with Kerberos really having all the keys in one spot and being able to control all of them, rather than having them distributed across the user machines and servers and things?
JS: Actually, that's a criticism that's often leveled at Kerberos. Indeed, the Kerberos server has to be kept physically secure, because it literally has all the keys on it. And if you could just get a read-only copy of it -- like stealing a backup tape -- then you can compromise the entire system. (Our backup tapes are encrypted, but that's another story.)
A public key system is a little bit easier to protect because the central system doesn't have all the keys. It has just one key -- its key that's used for certifying people.
Now, there's actually something else worth saying here, that another feature of public key systems -- like I said earlier, you have your private key and your public key. In a public key system, only you have your private key. No central authority.
Topics
HS: What happens if you lose your private key?
JB: I'm glad you asked that, Howard.
HS: If there's anything that can be lost, if I don't lose it myself, my hard disk will disappear someday or the system will lose it or something will go wrong. But I wake up in the morning and I discover I have a disk error and the part I can't recover -- I assume your private key is stored on your disk somewhere. And I assume you don't want to keep 27 copies of it, or do you?
JS: Well, actually, the modern browsers, what they do is your private key is indeed stored encrypted on your hard disk. The key is stored encrypted in a password. When you use, say, Netscape or Internet Explorer, when you go to a website that demands authentication using a certificate, you'll be prompted for a password. I don't know what Internet Explorer calls it. Netscape calls it your Netscape password. That password is used to decrypt your private key, which is stored on your disk.
Now, one could say because your private key is stored on your disk, you better make sure you back it up. I know with Netscape, when you generate that key, it will actually say to you, "Why don't you insert a floppy? Let's back the key up, like, right now!"
HS: Is there any problem having lots of copies? I use several machines in my office. Can I keep several copies? Is it easy for me to have copies of that on several machines?
JS: There's some clunkiness to the tools. One of the effects of this public key stuff being a bit new is we're dealing with first generation implementations of the software. But you could actually export your key into a separate file and import it into the other systems.
HS: When you say I've got to export it, this is some function of the browser? I can't just figure out where it is and copy it? I've got to use some browser function.
JS: You use a browser function, and probably it's in the security page, and it's like "Export My Key."
HS: So I would export it to some file system and then hop over to my other computer and import it off that file system.
JS: That's right. And it'll actually ask you to set a password to protect it when you do that. And at that point, what happens -- where your security is coming from is hopefully the password you're using to encrypt it is a strong password. It's not like DOG, something that someone might guess.
Topics
HS: I'm getting just a little confused about -- I understand this public-private key kind of thing and I'm keeping my private key on my machine. If I have a digital certificate, am I also keeping that on my machine? Is that something I keep on my machine?
JS: It turns out your digital certificate is stored on your machine, but it's a public document. You can upload it to a directory. So because it's not a confidential document, you can have as many copies as you want.
HS: Okay, and it's not confidential because it's encrypted?
JS: Actually, it's not confidential because all it contains is your public key, which is a public value -- something that you can share.
HS: So it's not even encrypted. There's nothing on there that I couldn't put on the front page of the New York Times.
JS: That's correct. Your certificate itself could be published in the New York Times.
Topics
HS: But what else is on there? Isn't there something that says that that certificate really came from some certificate authority?
JS: Yeah, the certificate itself is digitally signed, meaning that the certificate authority using the certificate authority's private key created a digital signature of it and affixed it to it. So actually, if you look at it, there's three basic components to your certificate: your key, your name, some other overhead information as well like the (inaudible.)
HS: But again, it's my public key in the clear, my name in the clear and --
JS: And a signature from the identifying authority on that document.
HS: What's that signature look like?
JS: It looks like a pile of bits is what it looks like. It's a big number.
HS: But that's something that can be decrypted using the certificate authority's public key?
JS: That's correct. So if you have the certificate authority's public key, I can get your certificate and I can verify that your certificate -- the thing that claims to be your certificate has not been tampered with since it was issued.
HS: And the way I'm confident that it came from that certificate authority is that the public key decrypted it. And if it did not come from them, the public key wouldn't have decrypted it.
JS: That's correct.
Topics
HS: What does it say, though? I decrypt it. What am I expecting to see?
JS: Decrypting is not the right word. You're actually checking the signature, which is a mathematical operation, and it really returns a binary value: "yes, it worked," or "no, it didn't work."
And exactly how it's done depends on which algorithm. There are several public key algorithms out there. But the real check is binary: Is this certificate okay or has it been messed with.
And if it's been messed with, then you can't say anything about the certificate. It might have been a legitimate certificate that just got some bits damaged, it might be a complete fabrication -- you just don't know. But if the signature check algorithm says, "This is good," then we know the bits that you are looking at -- the name, the key, the validity dates that might be there, a serial number that's usually in there -- that those are as they were when the CA made them.
Topics
HS: If I'm going to be using all kinds of services on a whole bunch of different machines (which is what I do and I think a lot of people do), do I need more than one digital certificate? Do I need them from different certificate authorities? Or do I just have one of these things?
JS: Well, we don't know what the final model's going to be. Certainly, the browsers that are out there today can support multiple certificates and obviously multiple keys that go with them in a reasonably seamless way. So when you enter your Netscape password to Netscape, that unlocks all of your private keys, whatever number of certificates you have.
And what we may see in the future is we may see services like university services may want you to have a certificate issued by the University. Some services might want you to have a certificate issued by a public authority like GTE or Verasign or one of those. Yet other services might want you to have a certificate that they issued. We'll see as time goes by which model actually evolves, but certainly the browsers that are out there today are set up to support all of the above and do it in a way that you only need to know one password.
JB: Does this analogy, Jeff, work in terms of -- like today we have many, many different kinds of credit cards? So may we, in fact, end up with a whole set of digital certificates for different purposes, then? Authenticating that we belong to one group or another, or we have different levels of permissions for us to access information in some way?
JS: Actually, let me try to draw an analogy. Today, many websites require you to get an account from that website, and you have a separate user name and password for that website. I try to use the same name and password at all of those websites, but then again, they're not websites that are what I would call very sensitive (like reading the New York Times or the Wall Street Journal). So the password I use is not that sensitive, because my only other alternative with those websites is to have a different password for each one, and I'd never manage to remember all of them.
HS: No, you'd never remember any of those things. I use the same one all the time, too.
JB: Unless we wrote them down somewhere, right?
HS: I lose things I write down!
JS: And some of the trade magazines really annoy me because they don't let me use what I tend to use -- my e-mail address as my login name. They don't like that, so I have to come up with a different login name, which I never remember when I go back two weeks later to read some articles.
So the analogy I'll draw is today what happens is for each of these websites you have to have not a separate credit card -- a separate wallet.
JB: Oh, really?
JS: Imagine, if you will, that each one of these sites required that you had a credit card that could only be stored in a separate wallet, so now you have 23 wallets. And the way the browsers implement digital certificates -- imagine instead of having 23 wallets, you have one wallet with 23 credit cards. But even that's a little bit fat.
But the point is that you have one wallet, you have one keychain. It's a bit more convenient, and yet it's secure. You don't have to be concerned that because I give my certificate to one website that they can somehow use that certificate if they were broken into to subvert a different website. In other words, I could use my certificate to authenticate who I am, say, to the New York Times, and I could safely use the same certificate to authenticate myself to the bank. Nothing that could happen at the New York Times would put me at risk that someone would learn information that would allow them to go to my bank and claim to be me.
JB: Let me just insert at this point a reminder for our listeners or lurkers or Webbers -- whoever you are -- out there to go ahead and send in some additional questions for Jeff at expert@cren.net.
Topics
Maybe now is a good time to go back and double-check, Jeff, that we have maybe clearly stated just what a digital certificate is and why we need them, particularly in the context of our higher education campuses. Why would the higher education campus want to go ahead and really get started in this issuing of digital certificates?
JS: As we start looking at offering online services, whether it's distance learning -- here at MIT you can get to your grades, and actually we have students registering for classes online. You can envision libraries making certain restricted material available -- only allowed to be available to the student community, only available online. And obviously, the way to do that these days is over the Web.
And the certificate technology is built into the modern browser, so it's all there. You don't have to deploy your own application to use it. For example, here at MIT, all our students have digital certificates that we issued them and they can use that to go to the Registrar's website and register for classes and even check their grades. And they can also use them to go to our computer store and make purchases.
JB: And they can do this all from their dorm room and from their frat houses and wherever they are, or on vacation somewhere.
JS: That's right. They can do it from anywhere they can get an Internet connection.
Topics
HS: Jeff, I understand that CREN has become a certificate authority now, and is everybody at universities going to be going off to CREN to get digital certificates now? Are folks still going to be using Verasign? What's the implications of CREN being a certificate authority?
JS: Here's where CREN really fits in. Like I said, I issue certificates to all the students here at MIT, and obviously our Web servers that use those certificates recognize MIT-issued certificates. Now, obviously our registrar's office probably doesn't need to talk to students at other universities, but let's consider the library example. If my library requires authentication to access certain restricted materials, we might make a deal with another university, like for example, Harvard, and say, "We want MIT students and Harvard students to get to this." Now assuming that Harvard was to implement digital certificates and give them out to their own students, we would have to program our library server to recognize the Harvard-issued certificates as well as the MIT-issued certificates. If we then extended it to Princeton, I'd have to add a third. And after a while, the guy in my library who's managing this is going to have to keep track of the MIT certificates and the Harvard certificates and Princeton certificates, and it can start growing.
Now, what CREN can offer by being a certifying authority for higher education -- instead of programming that Web server to recognize all these different certificates, we say, "Recognize everything that's traceable back to the CREN issued certificate." And now, my library server, instead of having to have the CA -- the public key of the MIT CA and the public key of the Harvard CA -- to verify those certificates, it just has the CREN certificate and the CREN public key and it can always verify anything.
Now, we still may have to have some procedure in there that says, "Only these ten schools are allowed to get in," but at least in terms of setting up the authentication and getting the various cryptographic stuff done, that doesn't have to be done on a school-by-school basis.
HS: Does that mean, Jeff, that I would have a digital certificate from CREN, not from Princeton?
JS: No, it means you as a user would have a certificate issued by Princeton, but Princeton's certificate would be signed by CREN. And when you go to the library at MIT, you would actually be handing over two certificates. The servers do this automatically. You would be handing over your own personal certificate and you would also turn over the Princeton certificate. Then our library server would use the CREN key to verify the certificate that CREN gave to Princeton. It would know that certificate is correct. It would then take the public key out of that certificate, which is the Princeton public key, and use that to verify your certificate. Now it would know it would have your public key, and then, of course, it could use it to challenge you and verify you were really you.
HS: So CREN is saying that Princeton is really Princeton.
JS: That's right.
HS: And Princeton is saying I'm really me.
JS: That's correct.
HS: So both those links have to be pretty strong in that CREN can't be fooled into thinking that Princeton is somebody else, and we hope that Princeton has done a good job of making sure that I'm really me.
JS: That's right. Indeed, CREN has to make sure that whoever set this up is really speaking on behalf of Princeton and is really the right people at Princeton, and it's really the right Princeton. But by doing that, it eliminates the need of every school having to do that.
So if I go back to my earlier example, if I didn't have CREN and you wanted Princeton students to be able to access the library site at MIT, then I would have to make sure that I was really talking to the right people at Princeton. And if Harvard wanted to make a deal with Princeton, they would have to make sure they're talking to the right people at Princeton. This becomes an N2 problem pretty quickly.
HS: Oh, sure. Now, this is going to take some effort on CREN's part, and any time I see anybody doing anything that involves any effort, they start charging for things. How's this thing going to be paid for?
Topics
JB: Maybe now is a good time. Let me just mention that CREN is going to be offering this service as part of the membership so that institutions that are in fact CREN members will be provided with the certificate authority service, and we'll go ahead and create that relationship with each of the institutions -- once they, of course, verify that we know who they are. And they will then serve and sign those certificates.
HS: What about non-members, Judith?
JB: Non-members, in fact, we're still working on exactly how to deal with the non-members, but there may be an additional charge or a separate non-member fee structure set up for non-members. But we would certainly, in terms of higher education, both research and higher education institutions, encourage and hope they would become members of CREN.
HS: How many members are there at CREN?
JB: Right now, we have about 225 members of CREN, and in fact, all that information is on the CREN webpage.
HS: But that's a tiny percentage, right, of the total number of colleges and universities out there?
JB: Oh, yes. This is obviously a new service, and it is something that, as you were all saying, that as E-commerce and the need for certificates grows at, I suspect, very rapid rates, it's a service that we hope in fact we can provide for higher education to make it easier for the growth in this area to occur. So we welcome additional questions in that area and also for folks to take a look at the website. We'll be adding additional Q&A; and FAQ's on the website in this whole area, with Jeff's help as well.
Topics
HS: Jeff, one thing that I think is of concern to a lot of people who have to administer all of these certificates is the fact that I'm the only person on the planet, really, who can issue my certificate, right? Because I'm the only person who has control of my private key, and I can't get my private key unless I retrieve it from my machine. What happens if something happens to me? I quit, get run over by a truck or something like that, and I use my private key to encrypt all kinds of data?
JS: Here's where we get into an interesting issue. When you use a digital certificate for authentication or even non-repudiation, where you sign something such that you can't take it back, there's not a concern if the key is ever lost because the authentication is still valid. And obviously, if you're not here any more, somebody else shouldn't be able to authenticate as you.
HS: That's right.
JS: When you start getting into encryption, then you start getting into issues of what happens if we were to use your private key, if you will, to encrypt a whole bunch of data, and now we have to get to that data later. Actually, you use your public key and you use your private key to decrypt it. That's a real sticky issue right now.
Certainly today, using the browsers -- let me step back and say we are really pushing hard on this full authentication. There is encryption when you go to our websites, like to go to our Registrar, but that's communications encryption when you're talking to the Web server, SSL. People are probably very familiar with this. There's no need to ever get that data back because that's ephemeral.
But when you start using this technology for electronic mail, then you start running into problems. Today, for example, if I send you an encrypted piece of e-mail using S-mime (which is implemented in both Internet Explorer and in Netscape), if your private key is lost, you can't decrypt that mail. And in fact, if I send you that mail, you decrypt it, you looked at it, when you were done looking at it, it's kept encrypted in that key. And if a year from now, you have to get to it and your key is gone, that data is gone. It is just completely and utterly gone.
I tell people, if you're going to do that, make sure that you're really good at backing up that private key that you generated. You take it seriously when it says it's time to back up the key.
Topics
HS: Isn't this one of the reasons that people are pushing for key escrow systems so that a university -- if some employee has crucial data, the university would still like to be able to get at the stuff. It's not good enough to say we hoped this person backed everything up and we hoped there was a trail for the thing.
JS: It's a tough issue, and I actually think key recovery and key escrow is the wrong approach. Really, what should happen is when I send you encrypted mail, when you read that mail and store it, it probably should be stored decrypted. Or if you want to store it encrypted because it is very sensitive, then you should use some other key for that storage, and maybe that key might want to be recoverable or put in a safe deposit box known to so many other people -- whatever makes sense in the context.
Topics
HS: Why do you want the key that I use to retrieve archive documents to be different than the key that I use to read documents on the fly?
JS: Actually, you really want to have three keys. You want to have the archival key, you want to have the key that people use to send you encrypted information, and then you want to have a separate key for digital signatures, because you never want the digital signature key to be recoverable. You never want someone else -- it's like a power of attorney.
JB: Oh, okay.
JS: If your business needs to see some data that was encrypted to you and you're not available, that makes perfect sense. But on the other hand, to say that if you're not available, the business should be able to sign for you in a way that's indistinguishable from the real signature from you, that's not right. Now, in the real world, we actually do have people sign for other people, but they initial it. We know what's really happening. But they can't do it in an indistinguishable way.
Now, as for why the archive key should be different than the mail encryption key is the requirements on that key are different. You might want to change that key less frequently or more frequently. You might want that key to be backed up by your organization so they can get to that mail, whereas your communication key might want to change more frequently, less frequently. The requirements are just really different when you get into the details, and like many things, in this case, the devil really is in the details.
JB: That's really good information, Jeff. Howard, I do see that we have some questions coming in.
HS: We do? I don't see them coming in.
Topics
JB: You don't? Well, let me mention one here that I think is one that a lot of folks are interested in. This is coming from Kevin Maroney at Penn State. He says as follows: "So far we've heard talk about authentication. Are there any tools for enabling a continuum of authorization levels, such as can you speak to the granularity, i.e., individuals, groups and enterprises with which one could scaleably manage authorization?"
JS: Authorization. It's really funny, when we first did Kerberos, the name we came up with, Kerberos, was about the three-headed dog that guarded the gate to Hades.
JB: Right, I remember from my mythology days.
JS: Right. Against what is not clear, but we'll leave that aside.
And the idea when we named Kerberos was that Kerberos had three heads. One head was authentication, one head was authorization, and the third head was auditing. And we decided when we did Kerberos that authorization and auditing was actually a very different problem than authentication, so we lopped off those two heads, but we still called it Kerberos.
Topics
It turns out that authorization is actually a whole different problem. One of the things we're doing here at MIT is we're implementing this thing called the Roles Database, which would be a database that basically associates someone's authentication -- their name -- with what roles they're permitted to perform, like spend money on this account number, change other people's passwords, look at the telephone records for my phone. And we have other roles like department head, which implies a lot of capabilities. And the whole idea of the Roles Database is we give certificates and Kerberos keys to individuals and then it's the Roles Database that's used by services to figure out what roles those individuals have and then checks to see if those roles are compatible with what the thing is they're trying to do.
But that's a very different game and it's not as necessarily cryptographically intense as authentication is. And authentication in some sense is the key. You have to start with something. You have to know, who am I talking to? And then we'll figure out whether or not they're allowed to do what they want to do. I hope that answers it.
JB: Let's leave that one as a potential good answer, Jeff, and move on to a couple of the other ones that we've got coming in here.
Topics
This one is from Dave Capella at Cornell University, and he mentions that Netscape has a password function that requires the user to obtain a certificate from a CA. Assuming the user obtains a certificate and puts it into the browser, now he must input it into any other browser that he uses. The question is, it works fine for staff, but what about the network administrator using all sorts of browsers?
Any hints or clues for Dave on that question?
JS: Well, this is one of the open areas where I think we need some more work done by the browser vendors to deal with what we call the kiosk problem. It's one thing to say that my browser on my laptop has my certificate and my private key and that's all well and good. But that doesn't solve the problem when I walk up to a machine in a public room and I start using it, if my certificates aren't going to be there.
And I'll tell you, technically, it's a difficult problem because one could take, for example, envision implementing a network-based storage of the keys and the certificates. So if I walk up to a machine, I can download them. But now, all of a sudden, the password I chose to protect them winds up being my only protection. Because anybody could then download them and try to crack my password and get my keys.
JB: So right now, do network administrators just have a tough time with it?
JS: There's people like me, I carry a laptop. That's my answer. I jack in when I need to do stuff.
JB: So that way, you don't have to trust the network for anything, then.
JS: Yeah. The other thing I can do, and I've been known to do this, is on that workstation, our certificate-issuing server that we use allows you to say, "I want a certificate only good for a day." So using my authentication, which is based on Kerberos, I can get a certificate valid just for a day. It's a different certificate from my other certificates and I can use it for authentication. And then when I'm done with the workstation, I have to remember to delete it. Just in case I forget to delete it, at least tomorrow it won't be good anymore.
JB: Let me ask, Howard, are you getting any of these questions yet?
HS: Yeah, now I'm starting to get these in. They all came in at once. There seemed to be some kind of blockage here.
JB: Okay. Do you want to feed Jeff another one?
HS: Sure. Here's a question from Kevin Maroney and I'm not sure what university --
JB: Actually, that's Penn State and we already did that.
HS: That's the problem. I'm getting these just a little bit late here. There's another question, I just missed it over here, but this was from Bob Morgan at Stanford. Have we covered that one?
JB: Nope, not that one yet.
Topics
HS: That's good. Basically, Bob's question is, I think it's about how does public key encryption systems scale across heterogeneous environments? Can we really have hundreds of thousands of people using these things?
JS: They are standardized -- the format of the certificate in terms of where the bits go and how keys are formed. There's a lot of standardization there. Some say there's excessive standardization there, and that, in some sense, is an important step for building systems that are heterogeneous. To make sure that if everybody complies to the standard for what a certificate looks like and how you parse it and how you operate on it, then that's sort of an enabler to make these things.
Topics
HS: But do these public key things -- I mean, the algorithms are really quite complex. Do they gobble up a lot of system resources if a server was handling thousands of these things or hundreds of thousands of these?
JS: Now you're getting into the nitty-gritty details. There are different algorithms that you can use for public key that have different trade-offs of security versus performance.
There's a whole set of algorithms based on what's called elliptic curve cryptography which are very, very fast. In fact, they're targeted mostly for smart cards where you don't tend to have very high horsepower chips in a smart card.
I think in general, my experience has been people worry too much about the performance and how much computation you need to do these things. The reality is, it works. When we first built Kerberos, there was this huge concern that the key distribution would be doing all this encryption and it's really slow, it'll be really slow. And we discovered we could easily run our environment with our least performant machine (that's our KDC). Because the reality is you don't do it that often compared to other things that you do.
HS: Are the way these systems built today -- these public key systems -- are they really far ahead of the supercomputer curve in the sense that if I have a supercomputer (or a bunch of them) in my basement or if I have some scheme that people are playing with right now where they can harness free time on 10,000 computers, are we close to the edge of being able to break through these systems or break into them?
JS: No. We once actually did an energy argument. We were looking at a long RSA key, and what you --
HS: By long you mean how long? Like 12 bits?
JS: We were looking at the time at 1,500 bit keys.
HS: Okay.
JS: Which is completely doable today. In fact, I tend to use a (inaudible.)
HS: What is being used today?
JS: People today -- at least with PGP, you tend to use 1,000 bit keys or even 2,000 bit keys quite regularly.
HS: Okay.
JS: I know we're running out of time, so I'll be quick, and that is that we did an energy argument. We said, "If you could build a computer that was really very fast and it used very little energy and it was really very small, so you could build lots of them, so you could run them all in parallel, how much energy would it take to break this 1,500 bit key?" This was an envelope calculation, and it worked out to the entire output of the planet Earth's energy system for 500 years.
HS: So we just need more efficient computers, right?
JS: We actually assumed super efficiency. We were conservative on every imaginable front. So unless there's a breakthrough in mathematics -- that's what you have to worry about. Not in computing.
HS: Right. And if there were, probably you would just double the number of bits and you'd be back in business.
JS: Actually, it kind of depends. A significant breakthrough in mathematics might break the entire encryption system.
HS: Okay, independent of the number of bits.
JS: Independent, then you're sunk.
JB: Then we'd have to develop a whole new system, right?
JS: That's right. And there is a risk.
JB: Do we want to take one more question?
HS: I'm unreliable here in getting the e-mail. Judith?
Topics
JB: There is one more here that perhaps we can go ahead -- that came in actually quite early from Gary Dobbins. And the question is, when do you predict that services such as Novell and AFS and NT will accept PK certificates as proof of identity instead of the session user name and password configuration that they are using today?
JS: Actually Novell, starting with Netware 4.0, actually does use a public key based system.
JB: Oh, okay.
JS: We can argue whether they got it right or not, but we'll leave that aside. Novell's already using that, Lotus Notes from version 2 forward used Public Key-based systems, and I believe the latest version of Notes even uses the X509 certificate. That's out there. People don't know it because it's hidden. It's an infrastructure piece of the code, what do they know? They know they're running Lotus. So Lotus Notes already uses this.
I don't know when AFS will use it. I'd have to talk to the guys at Trans Arc about that, and the same thing goes for NT. But there are commercial systems today that make use of this technology, often without the users even knowing they're using it, and those systems work quite well.
JB: That gives a good update, I think. Howard, how are you doing on your questions?
HS: My e-mail things are not coming through the way they ought to, but someday we'll do an expert session on e-mail, I suppose.
JB: I think so. Actually, we have a lot of data on that one.
HS: (Inaudible) this technology.
JB: Okay. Well, there are a few other questions, but I think maybe, Jeff, you can answer them on the website and we'll do a little expanded Q&A; there.
Howard, any other questions before we wrap up, or Jeff?
HS: No, but thank you, Jeff, for engaging us in this kind of interesting conversation. I'm sure we haven't answered even half the questions that we could have asked here, and I urge our listeners -- or Webbers or whatever they are -- to tune in or come in to future sessions where we're going to discuss other interesting topics.
And don't forget, and Jeff may scream, but you can always send Jeff Schiller some e-mail, even after this broadcast is over.
JB: I don't know about that! We want Jeff to come back, Howard. I don't know whether he gets bombarded by e-mail. But perhaps the Q&A; on the website will help detract some of those going directly to Jeff.
Let me just remind everyone, too, to be sure to mark your calendars for the next Tech Talk event, which is actually only one week from today on October 15, same time. It's going to be a special Educom Tech Talk being beamed from the EDUCOM '98 conference down in Orlando, Florida. So do check the website and join us at that time. We have Brian Hawkins, the new president for EDUCOM joining us. Gary Crane of NizerNet, and Jim Wolfe, a member of the CREN board of trustees. It's going to be kind of an expert panel and, Howard, you're going to be able to share what you see that's exciting at EDUCOM '98 as well.
HS: Yeah, that should be a real interesting time. Really looking forward to it. I'm sorry that not everybody can be down in Florida with us.
JB: Down in Mickey-land.
HS: You're all invited!
JB: Okay, well, thanks everyone for today. The board of CREN, our guest expert Jeff Schiller, technology anchor Howard Strauss, Terry Calhoun for some of the writing and research and website, and Paul Bennett at Umich for the UM Web Services for the encoding. All of you for being here and participating with your questions. I'm sorry we didn't get to them all, but watch the website. You were here because it's time. Bye Jeff.
JS: Bye bye.
JB: Bye Howard.
HS: Bye Judith. Bye Jeff.
JB: Bye everyone.
Topics
|
