trust and certificate authorities

Ever heard of a certificate? No, I don't mean a teaching certificate. (Maybe I need to get one, but that's another story.) I mean the kind of certificate you sometimes see your web browser warning you is not up to date, or is assigned to some other url, or something even more incomprehensible.

Bill Gates, several years ago, finally half-grasped PKI and started selling his "web of trust" and his "trusted computing". Like most of what he sells, he borrowed a bunch of jargon from the industry, twisted a bunch of terms until the thing everyone else was having a hard time building became something his company could (claim to) build, sell, control, and, most importantly, sell control of. And the result is less than optimal, to say the least.

(Awfully close to random, Bill.)

PKI (Public Key Infrastructure) standards describe several structures of trust relationships. The easy to build structure is hierchical. The other structures are not just hard to build, but very hard to build and get right. Unfortunately, the hierarchical structure has a lot in common with the false royalism which the US was born in reaction against. Essentially, you trust the guy at the top of the heap because you think you have no options.

Except you don't really trust him, you just behave as if you do. Sort of. At the minimum level. Grudgingly. And every chance you get, you stick it to him. Because you don't really trust him. Or anyone in between him and you.

Hierarchies are good reporting structures, but are not good for much of anything else. Well, there is one hierarchy that is useful, but it's a really flat hierarchy: you and God.

(Now, if you have that hierarchy properly worked out, artificial trust structures become a bit superfluous.)

The actual relationship structures of trust are fairly simple to describe, but not easy to implement --

First, trust doesn't mean that you know the other guy will never let you down. It doesn't mean you know exactly what the person you trust will do. It only means you have a reasonably good idea. It also means that you accept, to a degree, the results and effects of that person's decisions.

You trust people you know. You don't trust them all equally, of course, but you know them, you know something about what they do, when, and how. So you can base your own choices on your expectations concerning them, to a certain extent.

How far can you trust the other guy? Only as far as you can throw him, according to the wag, and there is a certain meaning to that. It might be more hopeful to invert the action, however: Only as far as you don't have to reach to touch him.

People you know well, you tend to trust more, even if you know you can't trust them exactly the way you thought you wanted to.

A friend of a friend can't be given as much trust as the friend, without making the friend of a friend also a friend. Your friend may choose to act as a guarantor of his or her friend, but you aren't going to trust the guarantee more than the trust the guarantor.

You can extend trust, but until you have actual dealings and see the results, the trust is hypothetical.

Can you trust a friend of a friend of a friend? Is there some sort of formula that tells you how much to scale trust back as the relationship becomes farther away? Of course not. You'd be asking for a guarantor in hypotheses.

So, what does this have to do with computers?

PKI certificates are instruments conveying a substitute kind of trust. Kind of like there are sugar substitutes and food substitutes (My father used to call white bread "bread substitute".), you can substitute certification for trust. What they convey is actually (the witness of) a guarantee.

They are issued by "Certificate Authorities" of various sorts. The CAs don't guarantee much with these certificates. What they guarantee is only that someone identifying himself as so-and-so claimed such-and-such. For example, they might issue a software vendor a certificate that asserts that the software can use to claim they are the software vendor. Then, if you believe the CA, you have a pretty good reason to believe that any software that includes the certificate originated from the vendor.

The technology they work by is a separate subject, and worth exploring, but I'll leave that for another day. Encryption techniques make them at least partially useable in the present world. As long as the encryption isn't broken, as long as the person holding the secret key keeps the secret key secret, etc., they do function in conveying the witness of the guarantee.

If you're thinking this sounds a lot like what they call a CPA in the USA, well, you, that's pretty close to the idea.

I could maybe go to a CPA and show him my birth certificate and passport and get a certificate from he saying I should him those things and claimed certain things in front of him. (Or her. I think I know more women who are CPAs than men, but that is neither here nor there. I think. 8-/)

So, what do you do with these certificates?

Microsoft presently uses these certificates to attempt to prevent rogue software from installing itself in your MSWindows computer. (Not mine. At least at the time of this rant, I only have computers running Linux and Mac OS.)

In theory, the OS could be set to absolutely refuse to let a program that can't present a certificate from Microsoft to even run. In practice, getting those certificates into the right places imposes enough problems that it may not be possible to get the stuff you want certified.

That's always going to be a problem, but lets look at the certificates again. Do you know the CA?

Hmm. Well, you don't know the CPA in many cases, either. All you know is that a rogue CPA is likely to lose his or her license. And the certificate itself doesn't contain any means of ascertaining that issuing the certificate hasn't cost the CPA his or her license. You'd have to find the authority that certified the CPA to be sure.

PKI does contain a method for checking whether a certificate is valid and the issuer still certified to issue certificates, but the implementation is problematic. The flow of time, in fact, makes it impossible to perfectly check the certificates.

But the software you use behaves as if it (or you) can know whether these certificates are valid or not.

I'm not advocating ignoring the certificates. However, the infrastructure needs to be fixed, and that is part of the reason I don't bank on-line.

Okay, so how should these certificates work?

Right now, hardware can't be certified. Microsoft's Trusted Computing stuff notwithstanding, hardware can't be verified. Locked, but not verified.

It could be verifiable. Hardware could contain self-test functions, and it could contain the manufacturer's certificate, which it could be programmed to only present if the self-test passes. But, self-tests being tests self-administered, the only meaningful thing which could be known would be that the hardware either claims to pass the self-test, and claims to be manufactured by the owner of the certificate, or it doesn't.

So, all of the following is purely hypothetical. But here's what could theoretically be done.

The system bootstrap boots the various hardware the first time and collects the certificates. It then self-tests, and adds it's certificate to the bundle, in a certificate that claims to have booted and collected the certificates. It can do this because it "knows" the hardware. Each certificate contains a cryptographic token that (should) uniquely identify the actual piece of hardware in place. (Product number and serial number, encrypted against some reasonably complete operational image of the hardware.)

The bootstrap passes the certificate thus generated to the OS, which boots, self-tests, checks the hardware and bootstrap certificatesand builds its own certificate. It discards the hardware certificates when it bundles the boot-up certificate. Again, it adds cryptographic tokens.

If something fails in the process, the failed hardware should disable or limit itself, or be disabled, and the rest of the system should continue to boot as far as possible. Hopefully, enough of the system can boot far enough to tell the integrator (or, later, the user) what failed to boot and why.

The integrator, who should be a salesman you, the buyer, know, checks the certificate presented by the OS, and bundles the OS cert sans the bootup cert with his own, storing the certificate on the computer. Then he loads the optional software, all of which self-test and present their certificates to the OS and integrator for making more certificates. The OS certifies it all and stores another certificate keeping the result of the initial set of installations, bundled with the integrator's certificate. Later installations will again be certified, and all certificates kept.

Before the integrator turns it over to you, he certifies you as the new admin/integrator.

You, as the owner, can view every certificate. But when the computer goes on-line, the network only sees the overall certificate. Software connected to the computer can query the overall certificate and the certificate of the software it is communicating with. But the queries can be refused, particularly when operating on networks or functions where the identity of the computer or user is not required. (For example, browsing the internet, or window-shopping at some on-line shop, or watching movies at an on-line theatre, or practically any normal on-line activity.)

When you get the computer home (or to the office), if you add or remove either hardware or software, you repeat the certification process, since you are now the admin/integrator.

You can also add users, and you can make certificates for the users.

When you need to update stuff, you probably want to go to the guy who sold it to you, because he knows the guys upstream, and you don't really. (Unless you are running Fedora or Ubuntu, in which case, you are effectively your own integrator, and, hopefully, you at least monitor the announcement lists so that you can keep track of the guys upstream in a meaningful way.)

Ultimately, all this does is give the computer an identity and an associated administrator identity, together with a current user identity. Together, these identities can be used, for example, at a store, to help maintain an account, or at an on-line bank, to augment the banks identification processes. But they can only identify an on-line presence, and this is the way it should be. (Forgery is always possible, and it is building faults into any system to attempt to make it prove identity beyond possibility of forgery. I'll have to rant about the forgery issues at some point, later.)

Since your internet browsing computer terminal can't prove your idendity to the bank, how do you prove your identity to the bank?

You need a hardware token to do that. Think USB key, but think ethernet or Firewire, instead. This is because the token has to be able to be a bus master in order to establish a tunnel, and you need a tunnel because you simply cannot depend on a terminal that you don't have general physical control over. (Yeah, that means you need to keep your token in a safe place, just like you keep your wallet in a safe place.)

The hardware token is a very simple device, because the more complex a device is, the more bad certificates could be lurking in it. Preferably, it only has a cpu, ram, flash or some other kind of persistent store, a time keeping device, a small display and a small keyboard, and (in terms of present tech) an ethernet port. It would be tempting to put a calculator or cellphone on it, but that way lies dragons and dwarves and goblins and worse. Well, no, a simple calculator is likely to be useful enough to have on-board, but you have to think carefully about that.

And maybe phone? No. Turn that around. Wireless modem on the token, the primary phone functions on a handset that connects to the wireless network through the token. Well, maybe you have a separate token physically incorporated your phone, but it must have its own CPU, RAM, and flash. Preferably its own keyboard and screen, so that if your phone gets eaten by malware and installs a keyboard eavesdropper, what you type on the token keyboard won't be seen by the eavesdropper. No, just, keep the token off the phone.

If you do put a wireless modem on the token (in parallel with the ethernet port), you would want direct physical switches and indicators, so you could be sure that you know when it is on or off. You'll think you want to believe your token is safe from attack, but in the end (and I will have to rant about this sometime) it's just a piece of electronic paper with an automatic pen, and the more ways for people to connect with it without you seeing, the more time bad people have to attempt to get that automatic pen without you noticing.

Best way to do this is have the wireless phone provide a place to physically plug the token in, that gives the token a direct physical connection to the modem. Always best to keep the terminal separate from the token.

So, what does the token do?

You take it with you to the bank. The bank has a (secure) machine which jointly generates a one-time pad in the token. Jointly, because every one-time pad has to be completely different, or some mathematically inclined bad guy will reverse engineer the generator from the pad he or she is given.

Since you want the token for several different services, it has to have enough persistent (flash or whatever) store to save quite a few. (Credit cards, savings banks, stock brokers, video store, etc.) You browse on a terminal, you load the shopping cart on the terminal, then you go to checkout. The checkout counter software displays a connection url and a transaction code. You plug your token into a spare ethernet port near your terminal, and key the connection url into the token's keyboard. The token connects with the store over a cryptographic tunnel. The token displays the store's connection prompt and you key the transaction code in, and then the token tells you to key in the token's authorization ("pin") code, and the token and store exchange the credit information.

It seems like a long way around, when you presently just do the one-click stuff on Amazon, but the only reason Amazon is not riddled with fradulent transactions is that most of the bad guys are presently intelligent enough to not draw attention to what they can get away with. (As opposed to the guys who generate spam.)

Why?

It's simple. Your bank sort of knows you. The on-line store does not. Your computer at home sort of knows you, but it knows the web better, especially if it's hooked up to a constant-on broadband connection.

Trust is not transitive.