* 3 *

Passe bra sikkerhet

Ukens faktum

I 1977, ved å bygge på arbeidet til Diffie og Hellmann, fant tre MIT Professorer Ronald Rivest, Adi Shamir and Len Adleman, en metode for å kryptere informasjon, som nå er blitt en standard for privatkommunikasjon. Metoden heter RSA kryptering. Metoden er patentert i USA og et firma ble stiftet for å lisensiere teknologien.

Stallings kapittel 3 og 5

Rustning

I forrige uke snakket vi om hvilke krav vi må stille til sikkerhet i datasystemer på et generelt plan. La oss nå begynne kurset noe pragmatisk ved å se på hva vi kan gjøre for å hjelpe til med personlig sikkerhet (for en vanlig bruker). Vi sier `hjelpe til' fremfor å implementere fordi, som vi har understreket tidligere, uerfarne brukere kan være den svakeste lenken i kjedet, uansett hva slags verktøy man gir dem.

Backup

Omtrent alle som har brukt et datasystem har mistet data ved en eller annen ulykke en gang. Det fins mange grunner til at data kan gå tapt: det kan være det at brukere er uforsiktige, eller det kan ha f.eks. med naturkatastrofer å gjøre. Hensikten med en backup er å lage en kopi av data som sannsynligvis ikke kommer til å bli ødelagt av den samme årsaken derom originalen ødelegges.

I gamle dager, brukte man å ta backup av disker til tape. Tape ble brukt fordi det er et relativt billig medium som lett kan transporteres. Dersom vi vil beskytte backup mot den samme ulykken som evt. ødelegger originalen, må vi passe på å oppbevare den ved et annet sted enn originalen. I dag er de økonomiske forholdene noe anderledes: data kan speiles til en disk som ligger et annet sted, ved hjelp av et nettverk. Tape er et notorisk upålitelig medium. Diskspeiling er et sikrere og mindre arbeidsintensiv måte å ta backup på.

Ulike operativsystemer har hver sin spesielle programvare for å ta backup, men noen ting er felles for alle. Det sentrale prinsippet i backup er overflødighet (redundancy). Overflødighet betyr at vi lager flere kopier av data enn det vi trenger (i den perfekte verden), slik at vi alltid har en alternativ kilde. Vi snakker mest om backup av data, men vi kan også snakke om backup av tjenester, i tilfelle vi mister en viktig maskinressurs. Overflødighet er en strategi, en slags forsikring.

Naturligvis, tar det lang tid å lage backup av store datamengder. Det fins hovedsaklig to typer backup:

Incremental dumps foretas etter et bestemt mønster. Det er flere filosofier om hva som er det beste mønsteret. Her er en enkel sekvens: 
        Dag  Level
        ----------
        Mon   0
        Tir   1
        Ons   2
        Tor   3
        Fre   4
        Lør   1
Legg merke til hvordan dette virker. Vi begynner med en full dump på mandag kveld. På tirsdag dumper vi filene som ble modifisert siden mandag, på onsdag dumper vi alt som er forandret siden tirsdag, og så videre fram til fredag. På lørdag, oppsummerer vi hele uken ved å ta et level 1 dump, som kopierer alt som er forandret siden mandag. Dersom vi kopiere hvert dump til en ny tape, har vi flere kopier av de samme filene, dvs et høyt nivå av overflødighet. Det kan være viktig med et upålitelig medium som tape.

En annen kjent sekvens som tilbyr et høyt nivå av overflødighet heter Towers of Hanoi algoritmen. Mønsteret over flere uker ser slik ut: 

       0 -> 3 -> 2 -> 5 -> 4 -> 6
       1 -> 3 -> 2 -> 5 -> 4 -> 6
       1 -> 3 -> 2 -> 5 -> 4 -> 6
       1 -> 3 -> 2 -> 5 -> 4 -> 6

    (til slutten av måneden)
Du bør regne ut for deg selv, som en opgave, hvordan mange kopier av alle filene some blir lagret med dette mønsteret.

Digitale Hash funksjoner eller Message Digests

Trust (tillit) er et av de mest subtile problemene i sikkerhet. Hvordan kan vi stole på data eller filer som andre sender? Programmer vi laster ned kan innholde virus eller Trojanske hester. Og selv om vi stoler på den personen som skrev programmet, kan vi være sikre på at andre ikke har endret programmet?

Det er en del ting vi kan gjøre for å øke vår tillit til data som vi mottar fra fremmede kilder, men når det kommer til stykket så er det slik at det beste vi kan gjøre er å sjekke integriteten til dataene. Med andre ord, vi kan si med en rimelig sikkerhet hvem som sendte en beskjed og at beskjeden ikke ble endret p&arong; veien. Utover det må tilliten være implisitt.

Sjekksummer eller Message digests er digitale signaturer som ikke kan forfalskes. Tanken er det at vi lager en algoritme som fordøyer innholdet i en fil og dermed produserer en verdi eller hash som oppsummerer innholdet. Dersom vi forandrer en bit av innholdet i filen, forandrer sjekksummen seg på en unik måte. Populære algoritmer inkluderer: 

     MD4
     MD5   (Sterkere enn md4)
     SHA1
MD5 algoritmen kan brukes fritt i et hvilket som helst program, i følge lisensen til RSA som fant på den. The Secure Hash Algorithm (SHA) er en proprietær algoritme som eies av US Department of Commerce. Det er derfor litt uklart hvorvidt det kan brukes utenfor USA. MD5 programmet kan hentes og installeres på et hvilket som helst system som har en C kompilator. Funkjoner for å regne ut MD5 finnes i dag i de fleste språk. Algoritmen genererer en 128 bits hash verdi, som representeres som en ASCII sekvens. F. eks. 
     cube% md5 .cshrc
     MD5 (.cshrc) = 519ab7d30dba4a2d16b86328e025ec72
MD5 signaturer siteres ofte ved software baser som innholder sikkerhets relatert software, slik at det er mulig å verifisere hvorvidt softwaren er autentisk (gitt at sjekksummen er autentisk!).

En annen type signatur er den som brukes av PGP (se nedenfor). Denne kalles også Message Authentication Code (MAC). Dette er lik en message digest, men inkluderer også en kryptering ved hjelp av en hemmelig nøkkel, slik at mottageren kan bruke en offentlig nøkkel til å verifisere kilden til avsenderen.

Offentlige og private nøkler

På 70-tallet ble det funnet opp en krypteringsmetode som gjorde det mulig for et hvilket som helst par av personer å kommunisere med kun to nøkler per person. Med tradisjonell kryptering trengte hvert par en felles hemmelig nøkkel. Dersom N personer skulle kommunisere med hverandre privat ville de trenge N(N-1)/2 nøkler (et stort antall). Dette kunne bli mange nøkler etterhvert, og det ville være vanskelig å distribuere så mange nøkler. Den første realisering av den nye algoritmen var RSA algoritmen, som vi kommer til å beskrive mer senere i kurset. Ved å publisere en offentlig nøkkel, sier vi at hvem som helst kan sende X en kryptert beskjed, men kun X kan dekryptere den ved hjelp av sin private nøkkel. Vi skal ikke bry oss (ennå) om hvordan denne trolldommen virker i teorien; men vi skal se på hvordan det fungerer i praksis. Obs at, dersom vi skal sende en kyptert melding til 10 stykker, må meldingen krypteres for hver av dem: `offentlig nøkkel' betyr ikke at vi kan kyptere en melding til mange samtidig (hva ville så vært poenget med å kryptere beskjeden?). Det vil si at vi ikke kan bruke kun en nøkkel til å lage en privat melding til mange, men det vi kan gjøre er å sende en kort signatur---data som er kyptert med en privatnøkkel til avsenderen. Denne kan dekrypteres av hvem som helst som har den offentlige nøkkelen og forteller dem at kun X kunne ha sendt meldingen, ved hjelp av sin private nøkkel. Dette er en digital signatur, eller MAC.

PGP: pretty good privacy

PGP er et program med en lang og viktig historie. Det har vært hovedtemaet i en debatt om Amerikansk fortrolighetslover (privacy laws) i mange år, i tillegg til saken om eksport av sterk krypteringssoftware. (Det er ulovlig å eksportere software som implementerer sterk kryptering fra USA.) Krypteringssoftware klassifiseres som et våpen! På grunn av dette finnes det to versjoner av PGP:, en US version og en internasjonal versjon. Nå fins det også en GNU klone.

We shall use the GNU Privacy Guard program, for this course, since PGP has become poorly documented and difficult to understand. The principles are the same. PGP is called "pretty good privacy" because it explores the use of public, private key methods to enable encryption and signing. This allows users to send private messages to one another using strong cryptographic methods. Why not perfect security then? The reason is that, while the cryptographic methods might work well, users can still be tricked into trusting false data, so the security of even cryptographic methods is not perfect.

To begin using GPG, you have to create a pair of keys: a private key and a public key. To do this you use: 

gpg --gen-key
and follow the prompts (and defaults). You will need to think of a pass-phrase which is long but easy to remember: e.g. 
  I could tell you my pass-phrase but then I would have to kill you
This will be used to encrypt your private key, so that only you can read it. Of course you should not reveal the pass-phrase to anyone. When the key pair is created, it is hidden in private files. If you want to make your public key available for others, so that they can send you encrypted files, you must extract it as text and mail it to them. The keys are complicated and can be used in binary form, or ASCII form. My public key is extracted with 
gpg --export -a mark > filename
and looks something like this: 
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v0.9.10 (SunOS)
Comment: For info see http://www.gnupg.org
 
mQGiBDtdcNkRBACN4xRpVDv0Zx7tbv5JhD+W1uDJKfiBO7DtZ8IXz2Nv1iuhyCFb
QIXAd3zBd6sBrYkMk15bKeNj9hcEnZXtK1gVXPYIi2s03aVhq6fEFdigNlD3qWBE
vP5rMg1sa5uxcHd813FQC8LJPjRsHwUQ7lk7wkXcY/djXhn9JmLf9RDARwCgybj0
b+D4IChXz7afqhbiynuPOJMD/01ZWl3REmLg/nt29VPot50ufMyEts4K2h9z3h0b
3eS4ZjqdcwCr6d69PlXhuhp3a6bfPDfCdZ3IMs4U8mtMpkdOA7LAbm2SXwCW+pT5
KT6pW3Hv8jjAJdsVc/EoPB8JlvyViW5HJW+oz+NdQydgohSXtm4vtTvPwV5Bvufr
b93NA/9zwFz8QbuI+VWfjQx1aLKg+xTiOS0zJaG2IdacjvLVmFwzFec/Yv87mojb
31kg7zb5z/nn/JskZx9vvekbgSJknsTik+nJs3UDdLMIM+Ol0A632XeasYIKjwyZ
U/IOwHXtZ1Aeo1AR7MIoTMOLLn6hEffnv059J9bIXGOudfpPmrRBTWFyayBCdXJn
ZXNzIChBc3NvY2lhdGUgUHJvZmVzc29yLCBPc2xvIENvbGxlZ2UpIDxtYXJrQGl1
Lmhpby5ubz6IWwQTEQIAGwUCO11w2QUJCWYBgAMLCgMDFQMCAxYCAQIXgAAKCRA+
kjZW5jiA7NIwAJ9Td7rTBEVAV0dTZoZX6qsNaBXN5gCgjbTw2dK1yecZQeCdBtfz
ZYZN+/a5AQ0EO11xCxAEAK69w0z0Ec/Ba0VFeYPSOj+VPTuvCBqMdQsAPmpquV3P
QB2UX/4mFCFrEzvERJeWuZy0cwJRoANtFGXLee/nD0hP+XstpFYmq4GwNODbcFHf
+9t5oiOnS6Hv8VlaVTjaZ/xwD3jj2LiVd1uQ5qqb12zLFVYjw1ZxBzlxdnmDzEUH
AAMFA/9cM8zAt5342zgk4bxZ7SkOMhtb+cZyI8Q2QOp2SZ98FPY1/qbCbaL+pe4y
9dd1VmasIpiXcnMPKessD3CL9LBLWR2EaS44hqkZlrpCDJpPgDE0pvvzI9xoiWfU
5V5OWLZsQIbmOISMGT1E29ks2x1a0CZVhPBMtUpQSFJYHZWctIhLBBgRAgAMBQI7
XXELBQkJZgGAAAoJED6SNlbmOIDsY14AmO0lDn0Lvhs9cf4exxDUH6u/WwIAoMRL
3vBRzQ9ZGYCtvu35++wYl7o+
=ZzKN
-----END PGP PUBLIC KEY BLOCK-----
When you receive a key from someone else, you can add it to your key-ring by saving the key to a file (exactly as above). GPG looks for the lines 
-----BEGIN PGP PUBLIC KEY BLOCK----- 
-----END PGP PUBLIC KEY BLOCK-----
and takes what lies between them, so you don't have to strip away the rest of the message. You should be careful not to get any extra spaces or characters into the file, or the key will be read incorrectly (i.e. don't cut and paste from the screen, save to a file). To add the key from a file, then: 
gpg --import filename
In order to indicate to others that you are sure you know whose key it is, you can sign keys and say how much you trust them, so that others can share in your private knowledge. You should only sign keys that you know to be authentic. Use of signatures is a way of telling others that you think they should trust the information you send them. You can also sign your own public key so that others can verify that it has not been tampered with between you and them.

To sign a key in your keyring, 

nexus$ gpg --edit-key sigmund
gpg (GnuPG) 0.9.10; Copyright (C) 1999 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.
  
pub  1024D/BB3B5564  created: 2001-07-24 expires: never      trust: -/q
sub  1024g/EEF5CD48  created: 2001-07-24 expires: never
(1)  Sigmund Straumsnes <sigmund@example.org>
 
Command> sign
 
pub  1024D/BB3B5564  created: 2001-07-24 expires: never      trust: -/q
             Fingerprint: 2962 8834 FAF4 7684 0E08  1B7B 87E8 916C BB3B 5564
 
     Sigmund Straumsnes <sigmund@example.org>
 
Are you really sure that you want to sign this key
with your key: "Mark Burgess (Associate Professor, Oslo College) <mark@iu.hio.no>"
 
Really sign? y
 
You need a passphrase to unlock the secret key for
user: "Mark Burgess (Associate Professor, Oslo College) <mark@iu.hio.no>"
1024-bit DSA key, ID E63880EC, created 2001-07-24

Encrypting a message (asymmetric)

Suppose I want to send a message to a recipient. I have to have their public key in my keyring. Then I do this: 
gpg -r recipient --encrypt filename --output newfile

e.g.

gpg -r sigmund --encrypt sig.msg
This results in a file called filename.gpg which I can then mail or give to that person. Note that with asymmetric encryption, I encrypt specially for one recipient.

Decrypting a message (asymmetric)

When I receive a message for me from someone else, I decrypt it by typing: 
gpg --decrypt filename --output newfile
Since I need my private key to decipher the message, I have to type in my pass-phrase. The result is a newfile.

Trust and signatures

Signing a message is like adding a cryptographic message digest which verifies the state of the message when you sent it. This is only part of a signature however. The other part is like RSA encryption in reverse. By using my private key, I can encrypt a signature which anyone can decode using my public key. This tells them exactly whom the message comes from (since only the owner of the secret key could produce a message decoded by the public key). This is a way of establishing consistency.

PGP occasionally warns us that a public key might not be trustworthy. How do we really know that it is the right key for the right person? For instance, suppose I receive an encrypted file from Sigmund. I decrypt it like this: 

gpg --decrypt filename
How do I know it came from Sigmund? The answer is I don't really know, unless I watched Sigmund send me the message, and I am sure that the message was not altered in passage. Anyone could claim to be Sigmund.

We decide which keys are to be trusted or not. Our trust is conferred by signing a key with our own. If we find a key which has been signed by several trustworthy individuals, we might be more inclined to trust the authenticity of the key, assuming that we trust them. (This leads to a so-called Web of Trust) For instance, I have just received Sigmund's public key. Since I watched him send it to me, I believe that it is his. I can sign the key with my signature like this: 

nexus% gpg --clearsign filename    (or just -s for a binary file)
When ever you sign something (and use you private key) you have to give your passphrase, in order to unlock it. (This is because, on most systems, others can access your files -- e.g. anyone on Windows 95, or the superuser on Unix). This results in a new file filename.asc. (Ascii, signed message)

This is a service to me and to anyone else who trusts my signature. Now when I try to decode a message from him: 

nexus$ gpg sig.msg.asc
gpg: Signature made Tue Jul 24 15:39:27 2001 MET DST using DSA key ID E63880EC
gpg: Good signature from "Mark Burgess (Associate Professor, Oslo College) "

Trusted third party

Some software houses sign code, so that user can verify its authenticity. This, of course, implies that one trusts the database of public keys, corresponding to private keys. The solution to this problem is to create a "trusted database", run by a third party (an impartial observer). This third party makes pains to assure the authenticity of they keys in their database. When a signature is encountered then, you are only trusting the "trusted third party".

Attacks against signing and encryption

With the recent attention given to encryption and signing, there has emerged a naive belief that signing and public key encryption give strong security, especially in combination. This is partially true, assuming that the keys are authentic. It is however possible to construct attacks against the naive use of these encryption methods.

Let's define some notation for representing encrytion and signing.

Public keys: capital letters
Private keys: small letters
Encryption with public key A: { "message" }A
Signing with private key b: ( "message" )b
We can now describe two attacks: The solution to both of these attacks is to SIGN, ENCRYPT and SIGN again messages. Note that symmetrical ciphers are not susceptible to these attacks.

We see that encryption mechanisms, while useful, are not an assurance of security.

Ukens tanke

Dersom du vil at andre skal holde på din hemmelighet, må du først holde på den selv.
-- Seneca in Hippolytus, c. 60AD

Back