Begreber/OpenPGP for begyndere
Introduktion
En kryptografisk løsnings effektive sikkerhed afhænger mere af, at du ved hvad du gør og af hvad visse tekniske fakta betyder (og hvad de ikke betyder!) end af nøglelængden af og af selve softwaren. Denne artikel skal derfor give en introduktion til centrale begreber i OpenPGP.
Denne vejledning er for begyndere, så det mere komplicerede stof er udeladt. Desuden finde du ikke forklaringer på, hvordan man bruger forskellige programmer. Det har du programmanualerne til. Dette skal hjælpe dig til bedre at forstå de handlinger, som forklares her.
Der er en anden artikel, som gør dig klar til nøglegenerering og en, som forklarer avancerede begreber.
Asymmetriske nøgler
OpenPGP bruger nøglepar. Dette betyder, at der altid er en "hemmelig nøgle" og en "offentlig nøgle", som hører sammen. I modsætning til det meget intuitive begreb om symmetrisk kryptering (dvs. når samme nøgle bruges til at kryptere og dekryptere data) er dette svært at forstå. Tænk ikke for meget over det, acceptér det blot: matematikken bag er et mareridt, så det vil være et frustrerende spild af tid for de fleste at gå i detaljer med det.
Som navnet antyder kendes den hemmelige nøgle kun af sin ejer, mens den offentlige nøgle ideelt set skulle være kendt af alle. Med symmetrisk kryptering var problemet, hvordan du sikkert delte kodeordet med modtageren af en meddelelse. Med offentlige nøgler er problemet ændret: Nu er den vanskelige del at sikre dig, at du bruger en korrekt offentlig nøgle (og ikke en forfalsket nøgle, som en angriber prøver at narre dig til at bruge).
Kryptering
En af OpenPGP's to funktioner er kryptering. Du krypterer data med en eller flere offentlige nøgler (symmetrisk kryptering, dvs. brug af et kodeord er også en mulighed, men anvendes sjældent). Til dekryptering af data skal man bruge en af modtagernøglernes hemmelige nøgler.
Bortset fra de allerede nævnte problem med "Hvad er den rette nøgle at kryptere med?" så er kryptering - dekryptering en ret enkel operation, da der ikke er mulighed for misforståelser: Du krypterer noget, og ingen andre en modtagernøglernes ejere kan læse det. Og du enten dekryptere data eller du kan ikke. De dekrypterede data er måske svære at forstå, men selve dekrypteringshandlingen er ikke. Dog: Spørgsmålet "Hvad er den rette nøgle at kryptere med?" går ikke bar på "Hvem ejer denne nøgle?" men også "Er denne nøgle sikker nok til de data, der skal krypteres?". Dette handler ikke om nøglelængde og lignende men om nøglehåndtering. Før du sender kritiske data bør du således spørge nøgleejeren om nøglens sikkerhedsniveau!
Digitale signaturer
Kryptering af data kan vendes om på en måde: I stedet for at lave data, som kun en nøgle kan forstå kan du lave data som alle kan forstå, men som kun kan være lavet med én nøgle. Umuligheden af at kunne oprette de samme data uden adgang til den rette hemmelige nøgle gør disse data til en digital signatur. Igen: Spørg ikke hvordan dette kan lade sig gøre med mindre du virkelig holder af matematik.
One of the great things about digital cryptography is: In contrast to a handwritten signature it is very easy for everyone (OK: for everyone's computer) to check that this signature was made by a certain key. If you can relate a certain key to a person then you can also relate a digital signature to this person – unless, of course, the key has been compromised. You may have noticed: At this point the task becomes an organizational and legal one.
Technology does not solve all of your problems. And it is extremely important that you are always aware where the border between the technical and organizational problems is.
And relating a key to a person is not the hard part! That is: "What does the signature mean?" Is your interpretation of a signature legally binding for its creator? The meaning can be as low as a timestamp (which is a perfectly valid an serious application for crypto signatures!), proving nothing more than that a certain document existed at a certain time (and was not created later).
If somebody signs all his emails (to prevent address forgery) then the pure fact that he sent a certain document within such a signed email does not mean anything except for that he probably wanted to offer you a look at it. If the email (the signed part, not the unsigned subject) says something like "I accept the attached agreement" then the meaning is clear and the remaining risk of the recipient is mainly a technical one (compromised low security key).
Thus it makes sense to have different keys at different security levels: One for reasonably securing everyday tasks and another one for signing agreements (where the key policy documents explain the limits and privileges of the respective key).
In contrast to encryption the signature of data does not (technically) have an addressee. Everyone with access to the public key can check the signature. In many cases that is not a problem (or in contrast: It may even be a requirement). Instead of selecting an addressee you select the secret key which shall be used to create the signature (if you have more than one).
The big "Which is the right public key?" problem occurs with signatures, too. Not with creating signatures but when interpreting a successful signature validation. The real life question is: "What does a signature mean?" Obviously a signature by "any" key does not mean anything. Everyone can have created it. The signature itself does not state more than: "Somebody with access to the secret key decided to create this signature." This is a technical fact without relevance in real life.
Relating keys to people
This is another hard and complicated part. And because only few people do this correctly the whole system is much less secure than most people believe. You have to tell apart four components of this check. The first is the easiest: the key itself. You have to be sure that you are using the right key material (just the huge random number itself).
As keys are to big to be compared manually a secure hash is used instead. Once again: Evil math stuff you fortunately need not understand. A hash function does this: You throw any kind and amount of data at it (from a single digit to a DVD image file) and it outputs a "number" of fixed length. If it is (considered) impossible to create two different inputs which create the same output then the hash function is secure.
OpenPGP currently uses the hash function SHA-1 for identifying keys. SHA-1 has security issues but they do not affect the usage in OpenPGP. A SHA-1 value looks like this:
7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5
This is called the fingerprint of the key. There are two ways of being safe about the identity of a key (the raw key material) without third parties involved: You get either the key itself from a secure source (USB stick handed over by the key owner) or you get the fingerprint from a secure source (which is obviously much easier as you can print is on small pieces of paper, even on your business card, and spread them).
Your OpenPGP application shows you the fingerprint of the key you got from an insecure source and you compare "what is" with "what it should be". If that is the same then you can be sure about the key itself. Thus: Always have small slips of paper with your fingerprint with you.
A public OpenPGP key (a "certificate") consists of two parts: the key material and the user IDs. A user ID is just a text string. The typical usage of this string is:
Firstname Lastname (comment) <email address>
Many user IDs do not have a comment, some do not have an email address and there are keys without a (real) name, too (e.g. for anonymous usage). Even if you are sure about the fingerprint the name, email, and comment can be wrong.
Email is rather easy to check (send an encrypted message to the address and wait for a response which guarantees your message to be decrypted).
Checking the identity of unknown persons is not easy. At keysigning parties this is done by checking passports and the like. But would you recognize a well forged passport?
Fortunately for your own purposes the identity is usually not so important. "The one I met on that event who calls himself Peter" is usually enough. So this is more a problem for the web of trust (see below).
Comments can be critial, too: The comment "CEO of whatever inc." may make a real difference (if not to you then to somebody else). The question when to accept (and certify) a user ID is a really complicated one.
Most people don't understand this problem and thus reduce their own security and that of others. You can make this decision for others easier by having user IDs which consist of just your name or just your email address. This may be easier acceptable by someone checking your user IDs.
If you are sure about a user ID you should certify it. This means that you make a digital signature over the public key and this user ID. You can make this certification for yourself only (called a "local signature") or for the public (the "web of trust"). If a key has several user IDs then you can decide which ones you certify.
You can give a rough hint how well you have checked the user ID and key, too. It makes a big difference to OpenPGP applications (and so should it to you!) whether they recognize a key as "valid" or not.
The keys you have the secret key for are considered valid automatically. The others can become valid by signatures of your own keys. And by keys of others.
The web of trust (WoT)
In connection with OpenPGP you will often hear about the web of trust. This in an indirect method for relating people to keys, a mighty but complicated technology. Beginners should not use the web of trust but first become familiar with verifying and certifying keys directly. The WoT is explained in the article OpenPGP For Advanced Users.
Summary of key usage
| you need | in order to |
|---|---|
| the public key of another person | encrypt data for him |
| check those key's signatures (technical correctness, not key validity) | |
| your secret subkeys | decrypt data that has been encrypted for you |
| create signatures for data | |
| your secret main key | manage your key (add user IDs or subkeys, change settings like expiration date) |
| certify other keys (i.e. some or all of their user IDs) | |
| the fingerprint of the key of another person | ensure that you have imported the right key (before certifying the key either locally or for the public) |