An Introduction to some Basic Concepts in IT Security and ...

one much faster than by exhaustive search. So keys must in general be muchlarger for public-key authentication than for the secret-key case.Note here a very important difference between public and secret-key authentication:in the secret-key case, if B receives a message from A andaccepts it, he is himself convinced that it came from A, but he will not beable to convince anyone else: both A and B have the secret key, and so anythingB claims to have received from A could as well have been generatedby B. This does not happen in the public-key case: the value S sk (m) canonly be computed by someone who knows sk, and so it could only have beenproduced by A. This is why public-key authentication systems are also calleddigitial signature schemes, and the value S sk (m) is called A’s signature onmessage m. The property is sometimes called non-repudiationNote that, as for public-key encryption, it is important that the receiveruses the right public key when checking a signature, otherwise he can bemade to belive that a message comes from A when this is not the case.6.2 Examples of Digital Signature systemsIt is usually the case that given some public-key crypto-system, the underlyingtechniques can also be used to build public-key signature schemes. Thuswe have an RSA signature scheme, and also El-Gamal and Elliptic curve signatureschemes. For instance, it is straightforward to use RSA with publickey n, e and private key n, d to generate signatures. For this, we will assumethat the message is a number m in [0..n − 1]. The idea is that the signer whois the only one who knows the private key, will do something to the messagethat no one else could have done, namely apply the private-key operation tothe message. That is, the signature on m is s = m d mod n. It turns outthat the special way e and d are chosen will ensure that raising s to power emodulo n wil produce the original message, i.e., we haves e mod n = (m d mod n) e mod n = mSo when you receive a pair m, s you can check the signature by verifyingwhether s d mod n = m. In general, the signature schemes in their basic formmentioned here are the same speed as the corresponding crypto-systems.Thus they are much slower than the MAC algorithms, and too slow to beapplied to really large amounts of data. One point to note, however, is thatfor RSA, if we apply the optimization where we use a small number as e,4

then checking a signature will be much faster than generating one. This isimportant in applications where a signature is generated once, but verifiedmany times.6.3 Problems with digital signatures schemesApart from the performance problem, many digital signature schemes do nothave all the security properties we would like, if we use them too naively. Forinstance, for basic RSA as we just decribed it, an adversary could choose somes, compute m = s e mod n and claim that m is a signed message. Indeed,this will look OK, since m and s precisely relate as they should in order fora signature to be valid. This is not complete disaster, since the adverarycannot control the value of m –most likely m is not meaningful at all– butnevertheless this is an undesirable property.6.4 Hash FunctionsThe solution to both the speed and security problems is known as cryptographichash functions. Such a function h should have the following properties:• It should be able to take a message of any length as input.• It should produce an output of fixed length• It should be fast to compute, speed similar to the best secret-key systems• It should be a hard computational problem to produce a collision: twoinputs x, y such that x ≠ y but h(x) = h(y). Note that the first twoconditions clearly imply that many such x, y exist. But this is fine, wejust need that it hard to find such pairs.W.r.t. the last condition, one can of course always just try to compute h onrandom x’s in the hope that this will happen to produce a collision. If theoutput of h has length k bits, this can be expected to succeed after about2 k/2 evaluations of h.We argue informally why this is the case: the reason is the so called“birthday paradox” (which is not actually a paradox, but just a somewhatsurprising fact from probability theory). If we choose a random (long enough)5

including the intended recipient’s address, are signed? there is in fact a verybig difference. The latter method ensures that the sender always commitsto the identity of the recipient, the former only does this if the recipientis explicitly mentioned in the text of the mail. As a silly –but illustrative–example, suppose Bob is in love with Alice and sends her a signed mail saying“I love you, will you marry me?”. Then with the former method, anyone canclaim to have a signed offer of marriage from Bob!A more subtle problem of this type is the case when a sender encryptsa message and then signs the ciphertext. This signature does not committhe sender to the plaintext message! The simple reason is that anyone caneavesdrop a ciphertext from the net and sign it, without knowing anythingabout the plaintext.7 More About AuthenticationThe secret-key and public-key approach to authenticating messages are actuallynot satisfactory by themselves in all cases. The reason for this is thatif I receive for instance a message m with a digital signature from A, thisonly proves that at some point, A produced this message. It leaves open thepossibility for an adversary to take a copy of the signed message and sendit to me as many times as he wants. This is known as a replay attack. IfA is a bank customer, the reciever is a bank, and the message is a requestto transfer money from A’s account to someone else, the security problemswith replay should be evident.So what we really want in practice is often not just to protect the integrityof messages, but to have a real authentic channel, that is, we want B toreceive the exact same sequence of messages that A sends, and if this notpossible, we want to come as close to this as we can. If we do not have physicalcontrol over the communication line, we cannot prevent an adversary fromphysically blocking some messages or from reordering them before they arereceived, but we should at least be able to make sure that replayed messagesare filtered out.One trivial way to ensure this is have the sender make sure that he neversends exactly the same message twice, for instance by appending a sequencenumber, and also add a MAC (computed over both message and sequencenumber. Then we can have the receiver store every message he ever receives(or at least the sequence numbers). This will allow the receiver to filter out8

8 Getting both Confidentiality and AuthenticityMany applications require both confidentiality and authenticity at the sametime. One may of course use a combination of the two types of techniqueswe have seen. But it is worth while to warn against some pitfalls:In the secret-key case, we will want to compute MAC’s and also encryptmessages. But one must use different and independent keys for the two purposes:there is NO guarantee for security if the same key is used. However,there exists specially engineered encryption modes that provide both confidentialityand authenticity at the same time, using one key. One such modeis known as OEM.Another point is that if you compute a MAC or a signature on the plaintextand then encrypt, it is safer to encrypt the MAC/signature as well, sinceit may in general contain information on the plaintext.9 Summing upHere follows a taxonomy of examples we have seen, both in the confidentialityand authenticity sections(leaving out the unconditionally secure methods):ConfidentialityAuthenticitySecret-Key AES, DES, RC4, IDEA CBC-MAC, HMACPublic-Key RSA, El-Gamal, Ell. curves RSA, El-Gamal, Ell. CurvesHash FunctionsRIPEMD-160, SHA-1, MD510