TechTalks Transcript
Using Digital Certificates to Authorize Campus and Resource Services
April 18, 2002
Audio
• Streaming
MP3
• Download
MP3 (Download
Tips)
 Judith Boettcher [JB] |
 Howard Strauss [HS] |
 Bill Weems [BW] |
JB: Welcome to the CREN Tech Talk series for spring of 2002 and to this session on Using Digital Certificates to Authorize Campus and Resource Services. You are here because it�s time to discuss the core technologies for your future campus. This is Judith Boettcher, your co-host for today, and our session is coming to you today with the support of the SAINT Corporation and the CREN member institutions. SAINT Corporation is a global leader in vulnerability assessment, striving to make network security easy and affordable. Visit SAINT Corporation at the URL that�s on our website! Howard! I�d like to welcome you back as our well-known web technology expert and portal expert and before you go off to Tasmania.
HS: Thank you, Judith. I�m Howard Strauss. I guess I am not really inviting all the listeners to go with me, but if they�d like to, that�s okay.
JB: Well, you can give us a report when you get back.
HS: Right, we�ll just do a Tech Talk on this thing when I get back here. As Judith said, I�m Howard Strauss, the technology anchor for the Tech Talk series of technology webcasts. In this webcast, I invite you to join Judith and me in a lively technical dialogue with our guest expert, Bill Weems, that will answer the questions you�d like answered about Using Digital Certificates to Authorize Campus and Resource Services and ask those very important follow-up questions. You can join in this dialogue by sending your questions via e-mail to expert@cren.net anytime during this webcast. If we don�t get to your questions during the webcast, we�ll provide an answer in the webcast archive. Once upon a time, a young girl named Little Red Riding Hood who lived on the edge of the forest with her mother set out to take her grandmother, who was very sick, a basket of cookies. On the way, while picking flowers, she met the Big Bad Wolf who, using social engineering, was able to discover the location of Grandmother�s house and was able to delay Little Red Riding Hood�s arrival there. Did Little Red Riding Hood check the Wolf�s identity? No! He seemed to be just any wolf, not the notorious, grandmother-eating Big Bad Wolf. Of course, that�s a problem we have every day when we use resources on the web. Maybe our online banking system, for example, tries to make sure that we are really who we say we are, as the Wolf who made a positive ID of Little Red Riding Hood did. But are we sure that what looks like our bank website isn�t the one built by the notorious Big Bad Hacker who would just gobble up your ID�s, PIN�s and passwords? The Wolf, having delayed Little Red Riding Hood, arrived at Grandmother�s house first and tapped on the door. �Who�s there?� asked the very sick Grandmother. In his best Little Red Riding Hood voice, the wolf answered, �It is I, Little Red Riding Hood,� and Grandmother told him to just lift the latch and come in, which he did and promptly ate her up. Every day, Big Bad Wolves follow our network paths and arrive unannounced at our computers and servers, pretending to be someone they�re not. Much of our computing infrastructure has no more protection than Grandmother�s latch. Not surprisingly, many of the baddies that come to our doors get in easily and gobble up our data and other valuable resources. We need better latches. We need to not tell folks how to open them and need to positively identify folks, especially those that are unexpected, that sneak up to our doors, or we�ll end up in the belly of a Big Bad Wolf. When Little Red Riding Hood arrived at her grandmother�s house, she tapped on the door. The Wolf, having now taken over Grandmother�s house and her identity, told Little Red Riding Hood how to lift the latch and come in. When a rogue person or program gets into one of our computers, it is often given the level of trust that the computer would get if it were not compromised. It is very common today to be attacked by computers you trust because they have let their security down and they have been compromised. When someone taps on the door of your computer, you cannot trust them, even if they seem to be your own grandmother. Little Red Riding Hood came into the house and looked at her grandmother and said, �Oh, Grandmother, you look terrible!� Security and safety are full time jobs. Everyone needs to play an active role and to know how to protect themselves and to recognize the earliest signs of trouble. When Grandmother looks sick, it may be time to feed her chicken soup, but when her face is covered with brown fur, it�s time to run! Little Red Riding Hood came closer to her grandmother and said, �Grandmother! What big eyes you have!� Hey, this website doesn�t look the way I expected it to. Ah, but I�ll enter my Social Security number anyway. �The better to see you,� said the Wolf. �And Grandmother, what big ears you have!� Wow, things look really strange here. But my mother�s maiden name is McCormick and my date of birth is 7/25/65. �And Grandmother, what big teeth you have!� And the Wolf gobbled up Little Red Riding Hood. Hey, where�s that $5,000 I had in this account? The story, you may recall, had a happy ending for everyone except the Big Bad Wolf who was discovered in a catatonic sleep from overeating Little Red Riding Hood and her grandmother by some woodsman who killed the Wolf and saved our stories heroes whom the Wolf had eaten whole. But the wolves we encounter on our network rarely allow intact recovery and often the wolf is never caught. Digital certificates and public key infrastructure, PKI, would have gone a long way to keeping Little Red Riding Hood and her grandmother out of the Wolf�s stomach. If Little Red Riding Hood has insisted on a digital certificate from the Big Bad Wolf, he might never have made it to Grandmother�s house and she certainly would not have taken his advice to go somewhere else to pick some more flowers. But digital certificates and PKI, while an important part of the security problem, are not the whole solution. For example, Grandmother needs better security than that latch you just lift up. Little Red Riding Hood needs to keep her cookies encrypted when she transports them through the woods. And just in case everything else fails, there needs to be a strategically located woodsman and woodswoman with axes at the ready, investigating suspicious snoring sounds coming from cabins in the woods. We�ll leave Little Red Riding Hood and her family to their blissful and more secure future in the woods now that they better understand PKI and digital certificates. For us in higher education, Judith and I will have Bill Weems explain the very latest gadgets and procedures for using Digital Certificates so that, like Little Red Riding Hood, we can all live Happily Ever After on today�s webcast of Tech Talk. Judith?
JB: Thank you, Howard. Are you really Howard and how big teeth do you have?
HS: You can�t be sure! I never gave you a digital certificate.
JB: That�s right! We�ll have to hear from our expert today, Bill Weems, who is from the University of Texas Health Science Center at Houston. Bill is the Assistant Vice President of Academic Computing and also the Associate Dean of Information Technology for the UT Houston Medical School. And Bill also has another title, which is the Associate Professor in the Department of Integrative Biology and Pharmacology. Welcome, Bill, and before we get started, you want to share how you got into information technology from Integrative Biology? Was it a big step or a little step?
BW: Well, I think the Wolf may have had something to do with it!
JB: Aha! Okay.
BW: Actually, I just sort of evolved into it. My research area actually is gastrointestinal physiology and I��
HS: We�ll skip that in this webcast!
BW: As my children sort of day, �My dad�s a shit quality control engineer!��
JB: That explains it all, right?
BW: That explains it all. You�ll probably hear some of that as we go along.
JB: Okay.
BW: I had some grants for some time from the National Institutes of Health to develop software for that particular research area and that ultimately led into us getting heavily involved with the Internet and that ultimately led to the University asking me to head the Office of Academic Computing back almost 11 years ago, I guess it is now. So that�s sort of how I got here.
JB: So we won�t be talking about trusting biology today.
BW: No.
HS: Because we don�t trust at all!
JB: All right, well, we�ve got a lot of questions today and I think people are really anxious to hear how you�re using digital certificates on the campus so Howard, do you want to start?
HS: Yeah, but before we do that, maybe you could just review for the folks who�ve forgotten just what a digital certificate is and basically how they work.
BW: Sure, I�ll be glad to. Digital certificates are also sometimes called digital ID�s and the basic goal here is to give people digital credentials that they can use for transacting business and identity on the global Internet. The way this is basically done is someone generates a key pair which has a public and a private key and the public key is made available to everybody in the universe, so to speak, such that when someone does something with their private key, the public key can be used to identify that it really was, say, Howard. To do that, however, somebody has got to testify that that public key really does belong to Howard. Sort of like maybe the US government does with a passport when someone�s traveling. So what a certificate in essence is, is it is a certification from a reputable certificate authority that says the public key really belongs to, say, Jane Doe. And that�s what certs are all about.
HS: Who generates these key pairs? You said you need somebody to generate a key pair. Who?
BW: Generally, they are generated under the control of an individual, either as is often the case most usually now, using a browser like IE or Netscape Communicator. Can also be generated sometimes on a smart card or some other device like a USB token, which we may talk about a little bit later. Once that key pair is generated, then the browser sends the public key to the certificate authority which then goes through a well-defined process to identify who the person is that sent them the public key that goes along with that individual�s private key.
HS: Can you tell me what people do with these public/private keys? I mean, somehow they do encryption with these things. Give me sort of a transaction that uses these things.
BW: Okay, a couple of them right quick. One is, let�s say that I want to send you an e-mail message and when you get that e-mail message, you want to be 100% sure that it came from me, Bill Weems. And the way that can be done is when the e-mail client�say, something like Outlook or Outlook Express�sends that message, it forms a digital signature which in essence is a representation of the message. It then signs that with my private key. When you get the message��
HS: When you say it �signs� it, do you mean it uses your private key to encrypt it?
BW: It uses my private key to encrypt it such that when you get it, the only way that you can decrypt that representation of the message is with my public key and only my public key would be able to decrypt that. So that keeps Judith, for example, if she was crazy enough to pretend to be me�that would keep her from sending you a message and saying that it was Bill Weems. She couldn�t sign it because she doesn�t have my private key.
HS: Okay, because when I try to decrypt it with your public key, I would get gibberish.
BW: You would get�well, it basically would fail because if she had encrypted it with her private key, my public key would not do it.
HS: Yeah. Okay, now I�m pretty sure it�s you, although somebody could have recorded a message from you and then sent it along to me, right? I could have been listening on the line and saw you send this encrypted message and then I could have sent it along to somebody, pretending to be you.
BW: You could have sent it to me, but since it was encrypted with my private key, then when they got it�even though you had captured it and sent it�they wouldn�t be able to decrypt it or its content actually would have been that that was put in by myself, not by you.
HS: Um-hum.
JB: Bill, maybe it would be good to talk about just where the private key is and where it resides for the most part. You know, if I�m doing my e-mail, just where is my private key that I�m going to use to sign my mail with?
BW: Well, the key to this�that�s sort of a��
JB: You didn�t really mean that!
BW: The secret! That�s a bad term also. What really makes this work is that the individual must solely maintain possession of their private key and that is usually contained in one of two types of containers�either a software container that is on your computer, such that when you need to use the private��
HS: Like it�s written to the disk somewhere.
BW: It�s written to the disk somewhere.
JB: Okay.
BW: And when you need to use that private key for some reason, it then is protected by a password that only makes it available on the computer. That password never goes out on the net, which is one of the strengths of the whole thing.
JB: So that�s what makes it better than the current PIN and password implementations.
BW: Right.
JB: Is that correct?
BW: Because no one should ever know the password for your key store other than you because you�re the one who created it.
JB: Okay.
HS: Now if I��
BW: [inaudible] Go ahead.
HS: If I have several computers, do I try to copy that key from computer to computer? Do I have different keys? In fact, in general, do I need more than one public/private key pair?
BW: Probably, particularly in the US, the answer is going to be yes. The way things are currently set up here is that there can be multiple certification agencies and so a banking group, for example, may require one particular certificate authority to sign a set of keys. Another one might do it for educational reasons, etc. There are some countries�for example, Canada, some of the Scandinavian countries�which actually have a national PKI hierarchy such that you are issued a single, say, sign-in key to identify Judith as Judith and as a result, that could very easily be used for virtually all types of transactions.
HS: What about people using these keys just to encrypt data or e-mail or things like that they store on their computers? Are people doing that?
BW: People do do that. The thing you have to be a little careful with�and it goes back�let�s build on the question you asked earlier. Can you have your key set or your digital certificate on multiple computers? The answer often is yes, if you, say, generate it on your computer with your browser and then you copy that key store to a disk which you could put in some sort of safe deposit box to keep it secure. You could also put it, say, on your laptop, your computer at work and the computer at home so then you would be able to use it all places. The downside of that a bit is if somebody gets your computer, they could physically conceivably somehow get to your private key. An alternative is to actually put your key set along with this certificate on some device other than the computer. Such a device might be a smart card or what we refer to as USB token which is a little electronic device that plugs into the USB port that is virtually on all computers now, and as a result, then you can take that with you and take it from computer to computer, which is a much more secure solution.
HS: I understand that�s the kind of thing that you�re using at Texas. How did you decide to use one of those USB tokens as opposed to just storing the things on the disk? What did you see as the advantages of doing that?
BW: One is mobility, in the sense that is makes it really easy to go from computer to computer. We also use it for getting access to restricted resources that contained very secure, confidential and sensitive information, say, patient identifiable information, for example. We wanted to have really a true, strong two factor authentication mechanism where it had to be something that you have�say, the USB token�and something you know, which would be the password which would allow you to use the private key that is on your token.
HS: Tell us more about the program that you have at UT with these tokens and what the future of that program is.
BW: Well, actually here at the Health Science Center at Houston, it is our strategic initiative to really get digital ID�s to everyone. For example, Dr. Bulya who is dean of the Medical School already now requires that all faculty members and staff�and actually, we�re in the process of rolling them out to the first and second year medical students�that everyone has digital ID�s. Now, the goal ultimately, particularly with the students that need to go from place to place, various computer labs, etc., the idea to go with the tokens was that it made it very easy for them to go from computer to computer and be able to use their digital credentials as opposed to having to somehow load that key set on every computer that they used.
HS: Could you tell us what this thing looks like and how big it is and what it costs?
BW: The ones that we are using, they�re�gee, how big are they? They�gee, I�m trying to��
HS: The size of a thumb?
BW: Oh, about maybe not quite as big as a thumb. Depends how big a thumb you�ve got, Howard!
JB: What about, is it as big as a house key?
BW: It�s bigger than a house key, in thickness, but it easily fits on your key ring. I keep mine on a key ring.
JB: Okay.
HS: And is that what people do, people just put the things on their key ring?
BW: Well, the males do, often. The ladies oftentimes do or don�t, depends on whether you carry a purse or not. The nice thing about putting it on something like a key ring is that if you start to go home in the evening, you don�t get very far without realizing that you may have left it connected to your computer because you can�t start your car.
HS: But if you do, now somebody has access to your car and your house and your lockers and everything!
BW: That�s true.
HS: You don�t just give up your public/private key, you give up all your possessions!
BW: Well, you probably give up more of the things that your traditional keys would do than with your token, obviously.
JB: Let�s remind everyone that Bill will be taking questions shortly and to be sending in your questions to expert@cren.net. Okay, Bill, how many of the faculty and staff currently have the tokens for their digital ID? Do most of them do, or are there lots of other folks that have the digital certificates on their computers?
BW: We have several thousand that actually have digital ID�s. At this particular point, we are somewhere between about 400 and 600 people that have tokens. I suspect, if plans go as we�re thinking about starting this fall, there will be considerably more with that.
HS: How do digital ID�s get into these tokens?
BW: A couple of ways. If you really want to do very strong authentication processes, all you do is when you plug the token into your computer and you use your browser to generate the key set or to trigger that. It is actually generated, the key set is actually generated on the token by the little computer on the token. In that case, it never gets put in the computer storage at all.
HS: So you don�t even know it?
BW: Huh?
HS: You don�t even know it. It�s on there, you don�t even know what it is and you don�t care.
BW: Right, and you actually can�t get it off. It�s not something that you can download from that in the sense of getting the private key off. [inaudible]�
HS: But somehow you can read the public key because you�ve got to publish that.
BW: The public key, not only do you need to pull it out and be able to send it literally to everybody in the world and very importantly, to the certificate authority such that they can incorporate the public key into the certificate such that if I send you or you get somewhere off of a directory service somewhere my public key, you then have the certificate�s certification that it is really Bill Weems� public key.
HS: You never said what these things cost.
BW: Ah, the tokens?
JB: Yes.
BW: We�re paying about $40 apiece now in quantities of, say, a thousand.
JB: Did you say 40?
BW: Forty, yes.
HS: Individuals are buying these or are universities buying them for the students?
BW: At this particular point, the university is buying them.
JB: What are people actually using these for? I mean, we�ve talked a little bit about how big they are and how they work and all the rest of that. What applications are really driving this?
BW: Well, there are really, I guess, two or three things that make smart cards or USB tokens very appealing. One is very good security, obviously, which we talked about. Secondly, if you sit down at your computer and you plug the token in, then if you need to, say, sign messages, decrypt encrypted messages you get [from] someone else or use your private key to be authenticated against some sort of restricted database somewhere on the net, the nice thing about that is it really gives you in general a very good single sign on procedure in the sense that you don�t have to sit there and type your password in every time you want to go and you don�t have to use multiple usernames and passwords to get there.
HS: Do the applications have to change to take advantage of that?
BW: It�s really how the host and then how the application, in essence, work with the host as to whether or not you can make it client certificate authenticated. If I may, let me expand on that just a little bit.
HS: Sure.
JB: Okay.
BW: You know, if you order a book, say, from amazon.com and it comes up for you to put your credit card number in, the server at that point sends its certificate out that says you are really talking to the server that is at Amazon.com. That is server authentication. If, on the other hand, the server in order to allow you to do something�say that it is a web interface to a database that has patient identifiable information on it�then the server may very well require from the client�that is the browser in this case�that the user be able to present a cert to certify his or her identity. And so whether or not the mechanisms are in place with usually what�s now called the web application server or with the application itself is whether or not that has been enabled for client certificate authentication.
HS: You�ve been talking about people using electronic signatures. I understand there was some legislation back in 1999 that said that electronic signatures are now legal. Could you tell us a little about that?
BW: Sure. Actually, before �99 a number of states�Texas was one�that actually had an Electronic Signature bill within the state and that�s one of the things that pushed us as a state university system to begin to look at using these for legally signing documents for legal transactions. Then the bill that you mentioned in �99, the E-Sign Bill, actually extended that out to federal jurisdiction. So for all practical purposes, with a few exceptions like wills�I know wills are one exception�virtually a digital signature is equal to a wet signature and actually is more akin in most cases to what would be a notarized signature because you have the certificate authority in effect acting as the notary. So in reality, that legislation says an electronic signature is equal to a wet signature.
HS: On most campuses, people are not doing that. I mean, there are all kinds of forms that one fills out on campus and at least my experience has been that people say, �No, you�ve got to sign it. You can�t�we can�t do this electronically.� Is this because word has not gotten to campus administrations that a digital signature is legal? Why do you think this has not really taken hold?
BW: Well, I think it�s two reasons, and it�s a very good question. One is that truly some people don�t really realize that they are equal under the law. I think more importantly is that to get digital signatures and the public key infrastructure that is used to manage the issuance and revocation and use of the digital certificates is a fair amount of infrastructure that is going to take some time to get into place. And our experience has been with watching things evolve here and watching sister campuses around the country have various levels of acceptance is it�s a lot like e-mail was, say, 15 years ago when those of us that were really advocates of it�people would say, �We will never use that! Why would we use it? Who would we send it to?� Now being on the production side of things, it would be really nice if people said that with e-mail when e-mail goes away. We�re saying sort of the same thing here now in Houston at the Health Science Center. People begin to see the real utility of using digital ID�s. They use it all the time. It�s something they don�t think much about, and as a result, things start coming up like, �Why do we have to use another username and password to do this when we could, in fact, have used our digital ID?� So we�re finding that users really do like and quickly begin to appreciate the advantages of the technology. Once you have a critical mass of applications and people using it, then it becomes sort of common knowledge that this a cool thing to do.
HS: So you sort of have single sign on then with this technology.
BW: Yes.
HS: What about your alums? Are they taking advantage of this?
BW: We haven�t approached that here. Clearly, being a Health Science Center university, though we�re interested in our alums, of course, it�s not quite the focus that it is in, say, a more traditional four-year academic institution. And so as a result, we really haven�t looked at that at this particular point. It�s a very good question.
HS: But a campus could issue a digital certificate to alums, right?
BW: Sure.
HS: Judith, I�m sorry?
JB: Oh, I�m sorry, what was the first application that you put in place using digital certificates, Bill?
BW: Probably the first ones were really sort of the low-hanging fruit of just being able to digitally sign messages. There are a lot of reasons for wanting to do that, particularly if you want to do business. It turns out there are a lot more reasons to really sometimes encrypt messages than you might think of. One is that when you�re still dealing in many cases with usernames and passwords and somebody loses, say, one of those passwords, a thing that the help desk has really learned to love with this is that you can send them a signed message and they really know that the message came from you, Judith, needing information about a new password. We�ve taken that one step further, which is even cooler, in that we have a very large LDAP directory service here�which I think you�ve discussed on one of your previous Tech Talks in terms of the utility of LDAP�s. We use LDAP-enabled authentication for a lot of systems where all you have to know is the LDAP user ID and password. If you forget your password on that or if you haven�t yet activated one, you can use your digital ID to actually set your password on the LDAP system. That takes the help desk totally out of the system and also makes it a lot more secure because there�s never the problem of having to initially issue a temporary certificate or a password and get it changed, etc.
JB: Um-hum. We�ve got a couple questions coming in. Howard, were you going to take one of those?
HS: Yeah, in fact, I just reviewed these. The first one, since you mentioned LDAP anyway here, we have a question about LDAP from Gary Chapman at NYU. And Gary asks, �What about the viability of storing digital certificates and private keys in an LDAP directory? How big a security hit do you take doing this?��
BW: You really don�t want to store the private key in a public directory or in an LDAP directory because it�s not really that secure a key store and multiple people can get to it. What is really nice about storing the public key there is two big things. Let�s say that I want to send you, Howard, an encrypted e-mail message. To do so, I have to have your public key to encrypt the message so that when you get it, you can use your private key to decrypt it. Well, if I don�t have your public key, how do I get it? One of the nice things with the new LDAP structure that is being put together is I should be able to go out with, say, an SRV record to the LDAP of your institution, get your public key from your LDAP and hence be able to send you an encrypted message. That works very nicely.
HS: Yeah, and the other way, too. If you want to decrypt a message I send you encrypted with my private key.
BW: Right.
HS: And you�ll need my public key then as well.
BW: Right. So usually when a message�oftentimes, when people send you an encrypted message, they will also include as part of that your public key, which causes you not to have to use it quite as much. One thing that we do with the LDAP that is very strong for using it for authentication to restricted resources is let�s say that, Howard, we�re trying to let you authenticate for a resource here in Houston and if, in fact, we have your private key in our LDAP, it checks to see if we have your�I�m sorry, I think I may have said private key.
HS: You said private. You meant public key.
JB: You meant public key, right.
HS: We get automatic translation here.
BW: Thank you! I can use help, obviously. If we have your public key in the LDAP and you authenticate, we check to see if in fact we really have your public key. If we don�t, even though the key is authenticated, we might say, �Well, for some reason, we�ve decided not to trust you, Howard.� We�ve pulled your thing. That makes it nice in the sense that the other mode of doing it has used what�s called certificate revocation lists or CRL�s and though that works, oftentimes the time delay associated with doing or obtaining CRL�s to see if you still have a valid cert oftentimes isn�t rapid enough to really maintain authorization control to a restricted resource. So if, say, the university comes to its senses and they decide that I need to leave, then instantly, somebody can pull my public key from our directory service and even though I still have my private key, I can�t use it to get to the resources.
HS: Right, and that would turn you off automatically from all resources.
BW: Turns me off for all resources.
HS: Because I think a common problem universities have is we turn you off of these two resources but we forgot that you have access to these three others.
BW: Absolutely, and that�s one of the nice�you used the term awhile ago, �single sign on.� And a lot of people equate single sign on along with the same thing as a single authentication mechanism, and actually that�s really different in some aspects. If you have a single authentication mechanism, clearly it�s a single sign on. But some of the single sign on methods actually do things like capture a whole bunch of your usernames and passwords, say, on a smart card and so what you do is when you put the smart card in, you use the single password to unlock the multiple or the appropriate username password on the card to go and do something. That still leaves you with the problem of how do you sort of across the board turn off access to multiple resources? So people should keep in mind, I think, that single sign on processes are oftentimes not a single authentication mechanism.
HS: Okay, we have another question from Andrew Ludington at Northwestern University and Andrew says, �How physically rugged are these USB tokens? Do they have pins that might get bent with use and other problems?��
BW: So far, we haven�t had problems with them. They seem to be pretty robust. If you look at my key ring and the number of times it takes large falls and gets stepped on and you know, I am not aware of any token that has ever failed of 400-plus that we�re using. There may have been some that have failed, but I�m not aware��
JB: And you�ve been using them for what, a couple of years now?
BW: Year and a half.
JB: Year and a half, okay.
HS: Okay, and Stephen Tihor at NYU says, �I�ve had trouble finding vendors for the PKI USB tokens. Can you suggest a few?��
BW: The company we�re using is Rainbow Technologies. We use their I-Key product. If you look at www.rainbow.com, you will find their product. They have both an 8K and a 32K token. We�re using primarily the 8K one at this point. We have had some of the other University of Texas components worked with the 32K and we have been very pleased with them at this point.
JB: Yes, and in fact, that link is linked off the CREN event site here too for folks to make it easy if they want to go there.
HS: What about digital certificates and PDA�s or cell phones or even my [inaudible] system? Any chance those things are going to work with those things?
BW: That is a question that I am asked often and you would think, as often as I�ve been asked, that we would have really researched it, but we haven�t. I hear comments from various people at some points that they have products that do this, but in all honesty, the staff here really has no real solid information about that.
HS: I mean, especially you would think that, for example, if I get e-mail on a PDA�which some people do��
BW: Yes. HS �does that mean if somebody sends me signed e-mail on a PDA, I can�t do anything with it?
BW: No. In fact, that�s the same problem that happens oftentimes if you�re using a webmail system. Some of the webmail systems now will say, yes, that is a valid signature and some of them have even gone so far as to keep a list of standard certificate authorities. But oftentimes what you find with the mail client is it will just simply say, �We can�t verify that this signature is really who is purporting to have sent the message nor can we verify that the message has not been somehow unaltered.� But you can still read the message. So it�s equal to what you would get in a normal non-digital e-mail exchange.
JB: And then if you also received it to your laptop, you could, in fact, validate it there potentially.
BW: Right. Well, I have a PDA that I get�I have a Palm Pilot which I sometimes, when I�m traveling, get mail sent directly to the Palm account. And since all of the staff here in Academic Computing always digitally sign everything they send out, what happens is it just simply leaves a little note that this message was digitally signed but it can�t handle the signature.
HS: Okay, we�ve got questions pouring in here which is really great here. We have one from Ken McCreary at Virginia Tech and Ken says, �How is Texas handling the issue of data encryption? What is your policy for cases where an employee encrypts important data on a computer, then leaves the university or loses their private key? Is Texas escrowing private keys for data encryption?��
BW: A very good question and one that is discussed a lot. You can actually play the game of using keys in the sense of having two key sets, one for encryption and one for signing. The general philosophy is that for the key set that is for signing, the private key is never escrowed because you want to make sure that you do not invalidate or weaken the non-repudiation. In other words, if you get something that purportedly was signed by me, the odds should be very, very high that only I have access to the private key. On the other hand�and those of us in the medical environment are dealing with this now with the upcoming federal regulations that many of you know about referred to as HIPA�those regulations probably when they go into effect are going to require that all electronic e-mail documents that contain patient identifiable information in fact have to be encrypted. So the encryption key, on the other hand, the private key can be put into a key management system where it is escrowed and usually there is some situation or process similar to launching a nuclear missile from a submarine where you have to have two or three people��
HS: At arm�s length!
BW: �have the keys at arm�s length to, in essence, you know, get the private key so it can be decrypted. But clearly, if you�re an enterprise, particularly one dealing with health information, then you very well may want to have the encryption key, private key escrowed so that you can in fact get to that information.
HS: Is University of Texas doing that?
BW: We are right now, particularly us and the University of Texas Medical Branch in Galveston and probably maybe the other four medical components are looking very heavily at doing dual keys. The University of Texas Medical Branch actually has been conducting a little over a year pilot where they have been using dual key sets, one for encryption and one for signing.
HS: And just escrowing one of them, the one that they use for encryption?
BW: Only the one that they use for encryption is escrowed.
HS: Okay, and when they actually save their mail, they�re encrypting their mail using the encryption one, not the other one?
BW: Correct. Now, we have policies on our book here, as most people do, that say that once you get the mail and particularly if you are now starting to archive electrically�electrically! Digitally signed documents, that you maintain those in the archive in an unencrypted state.
JB: Oh, okay.
HS: Okay, we have a question from Sun Microsystems here from Steve Hanna and Steve says, �What is your PKI trust model? That is, who are your trust anchors, root CA�s, and who have they certified? Do you have a campus root? Has it cross-certified with any other campuses or bridge CA�s?��
BW: Very good question! We currently are certified within the public hierarchy of a commercial CA so we have what are called co-branded certificates. There are 16 University of Texas components and each one of those components is a sub-CA under the commercial CA�s root and so that�s basically how that�s handled.
HS: Why are you using a commercial form rather than using CREN?
BW: Well, when we first started with this back in �98, �99�basically that time period�CREN�correct me if I�m wrong, Judith�wasn�t really in the game at that point. And one of the things that the state of Texas required then and still requires is that the Department of Information Resources certify the certificate authority before you can actually issue and use keys for signatures to transact business in the state of Texas. And at the time that we did this in �99, there was only one CA, a commercial CA, that was actually certified or approved by the Department of Information Resources, what we call the DIR. The advantage for that is we had actually played around with trying to start our own campus root and what we found was much more of a problem than technical issues was trying to get through all of the various what I like to call the trust documents, the certification practice statement, the relying party agreements, etc., that really permit us to have the legal infrastructure that�s necessary to really utilize these keys as legal instruments, as legal signatures. That, we found, was one of the nice things about going with a commercial CA is that they were large enough and had already done the documents and gotten the approvals to make this work. Trying to get that done as an institution is a more difficult problem which actually CREN has been addressing. And Judith, you may actually want to say something about the PKI Lite stuff.
JB: Right. Let me just mention that, that folks who are interested in this can go and take a look at the PKI Lite. That�s a set of trust documents created by the HEPKI groups and those were just all really finalized, I think�well, they�re not really finalized. They are all under review right now since late last fall, 2001. But the CREN service in this area did start and get launched in late �99 but we really did need the trust documents. Now we�re making things move forward much more speedily and provides that environment.
HS: But what�s �lite� about PKI Lite? I mean, I know what�s �lite� about margarine or beer or�they�re all reduced calories. I can�t imagine reduced calorie PKI!
JB: Actually
HS: Why�s it called PKI Lite?
JB: Actually, we do define it this way and that is that it is full-featured PKI in that you�ve got a trust anchor and you�ve got someone therefore who issues certs, who validates that a person in fact should be issued a certificate, is eligible for that, and then monitor that and have a validity date and all those kinds of things. So it�s full-featured PKI but rather than instituting a new registration authority like an external validation authority, we use the existing campus registrar processes and the regular campus Human Resource processes. That really makes the whole validation of a person as being eligible for a certificate much easier. Reduces the costs and that.
HS: Okay, we have another question here from Gary Chapman at NYU. It seems like everybody at NYU is listening to this! You must have real security problems up there at NYU! But Gary says, �Can Bill name a specific webmail product or more than one that does digital certificates?� Bill?
BW: Well, I think it depends on what you mean by doing digital certificates. None of them are totally digital certificate-enabled that I�m aware of, that would allow the sender of the message to actually digitally sign the message and that obviously comes up to the point as to how do you handle the private key in a secure fashion with doing something like webmail? My comments earlier about the fact that sometimes or oftentimes things like, I know, Netscape Messenger for example�their webmail client� if you get a signed message from somebody that sent it to you using a client and you�re viewing it on the webmail, that it shows that the message is in fact signed and sometimes that the signature is valid in the sense that if the web server process actually has the CA roots on the system such that it can look at the trust chain and verify that the public key is really issued by the CA, then it will tell you that actually the signature is valid. But that�s only sort of half of the process.
JB: Okay, let me take the opportunity to remind folks that we have time for a few more questions so be sure to send them in here to expert@cren.net. And then I think we�ve got another question coming in having to do with healthcare applications, Bill, which obviously I think would be a particularly good topic for you. And the question is from Alan Ellis from the UNC Center for Maternal and Infant Health. He�s got about three questions and they�re all quite long, so what I�m going to do is just abbreviate the second one. And he says he works in healthcare and particularly interested in using digital certificates to secure confidential patient information and possible applications include, number one is hosting a clinical database on a campus server to be accessed over the web by clinical staff at the university�s Healthcare System. And I�m going to stop there so that you can keep that question in mind and give Alan some hints there. Does that work?
BW: It works very well, actually. What we�re doing now with a lot of our databases that truly contain PHI or patient health identifiable information, we�re requiring at all access to that be done with digital ID�s and in most cases, using our two factor authentication that you�ve got to have the token also. We actually, the Department of Information Resources just did a, oh, what�s the word I�m looking for? Where they were trying to break into our network. That�s not the word I�m looking for. It�s not hacking, either. Help me here, Howard! Drawing a blank. But anyway�penetration study! That�s the word I�m looking for. And they very strongly were recommending that for confidential and sensitive resources that you use two factor authentication because password, username things are becoming so very weak and susceptible to invasion.
HS: Okay
JB: Do we want to ask one of those other questions from Alan, Howard? There was the�well, let me go on.
HS: Oh, I think you�re doing a fine job of condensing them. Better job than I could have done! You want to try to condense another part of one, Judith?
JB: All right, sure, I will. Another one is what about allowing external providers, some of whom are not university affiliated, to access selected database records about patients that they share with us?
BW: That�s a very good question. Let me just sort of preface by saying that one of the critical things in dealing with the upcoming HIPA regulations are the fact that we have to deal with all of our partners, and like the Health Center here has somewhere on the order of 300 partners that you have to deal with. And this is where the whole realm of what I like to call inter-realm trust or global trust needs to be worked out in part of the whole middleware-PKI stuff, why this is so important. The issue is what do you�and we didn�t really answer part of this question earlier. What happens�the person from Sun asked the question�what happens if you�ve got multiple certificate authorities? And the way this is being looked at here somewhat, the feds have what they call their Federal Bridge CA or the FBCA which in essence is a process that allows trust relationships to be worked out amongst different certificate authorities. The Higher Ed Bridge CA or the HEBCA is a similar type process. One of the things that makes it difficult in this country is since we can have multiple CA�s is how do you handle the situation that you have multiple enterprises that are needing to get to the same data using separate CA�s? The basic idea of certs and PKI is really, really good. Where it gets somewhat complicated is when you have multiple certificate authorities.
JB: Okay. Good.
HS: Okay, Bill, there was an article that I saw�I�m trying to get the reference to the thing here. It was by this gentleman, L. Taylor of Technology.com, and it was way back in October of 2000. And the article said �PKI and Biometrics Ready for Takeoff!� Has that happened? And if it hasn�t, how come?
BW: Well, part of the reason, I think, as to PKI taking off is the question or the answer that I gave earlier, that there�s a lot of infrastructure that has to go into place. And I think as this infrastructure gets into place and people become more aware of it, like e-mail, it�ll be more embraced. The biometrics aspect comes in the fact that you need a reader that�s capable of, say, reading a thumbprint and part of that is cost, you know. We were talking about the USB tokens being about $40. If you�re dealing with smart cards, you can buy them in quantity somewhere around, I think, $15, $18. But then you�re dealing with buying the readers that make them work and if you want to have something that�s biometric-enabled as a reader, then you�ve just added another $20 or $30.
HS: Oh, yeah, the one�s I�ve seen are over $100.
BW: Yes. So I think part of it is both the infrastructure issue and the fact that it�s just a costly technology to implement at the moment because of both scale and people are still trying to work through it.
HS: But if you use biometrics, would you still need PKI?
BW: Yes, you would. And this is something��
HS: Could you tell me why?
BW: Yeah. You know, sort of the three roots of security is something you are, something you have and something you know. And obviously, the biometrics are something you are. But knowing who you are or who you purport to be, you still need that certificate to, in essence, say, �Somebody says that that particular thumbprint belongs to me, Bill Weems.� And you also need to have the cert associated with that so that you can do things like the digital signature. So a lot of people seem to think, �Well, if you just had a thumbprint and you put it in and the thumbprint in some form would go across the net and then be identified at some remote site,� what you start to worry about with that particular issue is, do you want people around the world in essence to say, �This is my thumbprint and I�m going to identify with it�? The way it works with something like a smart card is you actually put the thumbprint on the smart card along with the certificate so that when you use your thumbprint, it activates the private key on the smart card in place of you using a pin. And at that particular point, you�ve got a really nice marriage.
HS: So the thumbprint never travels to anyplace, just the card?
BW: Never goes anywhere. It�s always on the card.
HS: That sounds like a real advantage. Do you think the costs are going to come down?
BW: I would think there�s a good chance, as we have to embrace security more and more in terms of everything that we do in the cyber world.
HS: Talking about costs, what does it cost a university to do all that? If we decide we want digital certificates, we want PKI, where are we going to have to spend our money?
BW: Well, you would think I would know maybe that answer in a little bit more detail than I do. The one I know best is that one of the real costs is doing the certificate authority management, the PKI management and that�s going to depend very much upon the number of individuals that you�re going to get. If you�re a large university system and you�re buying 200,000 seats, obviously that per-seat cost is going to be a lot less than if you�re a small organization that�s going to buy a hundred.
HS: You�re buying these from a commercial��
BW: From a commercial CA, okay. Now, if you go the CREN route, for example, your costs are going to be getting the legal documents approved, through whatever that process is concerned. You probably are going to have to go ahead and run your own certificate server to issue the certs, where you might get that from the commercial CA. In theory, those costs probably are going to be less, but then you have a fairly large structure or an operational maintenance structure that�s going to have to be in there, personnel, etc., to make those pieces work. Even when you go with a commercial CA, you still have to have training, desktop support. You have to have, if you�re doing LDAP client-enabled applications, those things have to be put into place. So there�s multiple factors that have to be considered in all of this. And in all honesty, we have not sat down and down a real exhaustive study as to what all of those components are and what are the real costs that are associated with it.
HS: Bill, I carry a�I don�t carry with me, but I have a passport and I also have a Blockbuster video card and both of those things identify me. In one case, Blockbuster says I�m Howard and in the other case, the federal government says I�m Howard. And obviously, there are people who will accept one of those bits of identification and not the other. Do we run into the same sort of problem with CA�s? Are there some CA�s that are going to be more trusted than others?
BW: Yes, and a lot of that�s going�part of what falls into what�s called the Certification Practice Statement is the level of user identification that�s associated with whether or not they really know it was you, Howard, that they�re getting the public key for to validate. Sort of two extremes. You can get sort of a low level cert where maybe you apply for it from a commercial vendor and they go out and they look through some credit card databases or credit databases and the information that you provide them appears to be sort of right and so they say, �Yep, that�s Howard and here�s your cert.� What we do at the University of Texas system is you literally have to show up physically before a local registration authority and that individual looks you in the eye and says, �Let me see two picture ID�s,� one being a university badge and the other, say, a driver�s license.
HS: And bring a child that looks like you with you!
BW: Yeah! And so you can carry that on up. And the Federal Bridge CA process at this point has four levels of trust that�s associated with that identification process. So where Blockbuster for you didn�t particularly do a whole lot of identify verification��
HS: Well, it doesn�t get me into France!
BW: Right. The federal government one does.
JB: Okay, we�re getting close to the end and there�s a couple other questions I think it�s really important to get in. We did get a reply back from Stephen Tihor from New York University and he�s inquiring a bit about the [inaudible] solution and the fact that it really does seem to have support for Microsoft Windows, but limited support for Macs, UNIX and other platforms. And then he also wanted to respond to Howard�s comment that, no, they don�t have security problems because they�re very proactive! I think we needed to get his voice back here to get that there.
HS: Okay.
JB: So anyhow, what about no support for Macs and other UNIX systems, etc., Bill?
BW: It�s weak. We haven�t looked at that too much at this point in the sense of doing it directly with UNIX. And he�s right. On the other hand, if you�re running a UNIX server and you have your patient database on some relational database system on it, you can easily use the whole client authentication process that works very, very well. I think what he�s alluding to is if you�ve got a workstation on your desktop and you want to use the key with that, directly in Linux or directly in UNIX. That�s a bit weak at the present time.
JB: Okay. And then one other question. This is another part of PKI that we haven�t talked about much yet, and there�s a question from Daniel Salinas from Southwest Texas State University. And he says that earlier, you mentioned that checking CRL�s can be slow. How does verifying the current validity of a certificate work on your campus? Does it rely on the Internet for communication back to the certificate authority?
BW: This is an area we could spend a lot of time talking about. The way it all started was the idea would be that the certificate authority would, say, release every 24 hour period a certification revocation list. You would put that somewhere in the server and it would check against that. At best, that gives you a 24 hour delay. If you�re a bank and you�re wanting to determine whether or not somebody really has a valid cert, you want to operate much more rapidly than that and there�s some protocols out there now�and I�m blocking on the letters. COSP or something like that.
JB: OCSP.
BW: That�s it! Thank you very much. OCSP, Online Certificate Status Protocol, which in essence is a real time query back to the CA to see if as far as the CA�s concerned, that�s still a valid cert. So it depends, I think, a lot on your application and what you�re wanting to do. What I was talking about earlier, what we do for our really critical online resources is we require that we have the individual�s public key in our directory service. If we want to revoke that access, then when we pull the public key out, they can�t get in. But that obviously is not globally something that can be looked at. So this is an area that needs some work.
JB: So this is another area of the infrastructure that�s kind of stay here, watch this space and you�ll see what happens.
BW: Correct. This is one of the weaker aspects of the system at this point.
JB: Okay. We are unfortunately out of time, but as you know, we could go on for a long time with this. Howard or Bill, let me ask, any final comment or question before we go into our closing notes?
HS: I don�t have any comments. I have lots of questions, but I�m never going to be able to fit them in. I mean, we�re actually over the hour!
JB: I know we are!
HS: Right now. So Bill, perhaps you have some final comments?
BW: No, other than the fact that we really have found this to be a really useful technology that for the buck gives you a lot of security return. The real issue is getting that critical mass of applications and users in such that people really buy into the technology.
JB: Okay, and with that, thank you so much for being with us here today and be sure to join us again in two weeks, on May second, for a session with Dr. Shankar from Indiana University for a talk on Managing Distributed Storage. As Howard will be off globetrotting in Tasmania, Mark Bruhn from Indiana University has graciously accepted an invitation to be our guest technology anchor. Thanks very much to the SAINT Corporation for their proactive approach to network security using their renowned SAINT Tool Suite for Security Assessment for their support of today�s programming and also for CREN member institutions today, and to our Tech Talk expert, Bill Weems; to technology anchor, Howard Strauss; to Terry Calhoun, Tech Talk web guru; to Jason Russell, Bonnie Boyles and the support team at Merit; to Susie Berneis, audio file transcriber; and finally, a thanks again to all of you for being here. You were here because it�s time.
END OF WEBCAST
