Feature - Telenor

Feature:Security

1 Guest Editorial; Øyvind Eilertsen

2 An Introduction to Cryptography; Øyvind Eilertsen

10 Advanced Encryption Standard (AES). Encryption for our Grandchildren;Lars R. Knudsen

13 Development of Cryptographic Standards for Telecommunications; Leif Nilsen

21 Show Me Your Public Key and I will Tell Who You Are;Lise Arneberg

26 Security in a Future Mobile Internet;Henning Wright Hansen and Dole Tandberg

34 Mobile Agents and (In-)security; Tønnes Brekne

47 An Overview of Firewall Technologies;Habtamu Abie

53 CORBA Firewall Security: Increasing the Security of CORBA Applications;Habtamu Abie

65 Telenor’s Risk Management Model;Erik Wisløff

69 Risk Analysis in Telenor;Erik Wisløff

Contents

Telektronikk

Volume 96 No. 3 – 2000

ISSN 0085-7130

Editor:

Ola Espvik

Tel: (+47) 63 84 88 83

e-mail: [email protected]

Status section editor:

Per Hjalmar Lehne

Tel: (+47) 63 84 88 26


Editorial assistant:

Gunhild Luke

Tel: (+47) 63 84 86 52


Editorial office:

Telenor AS, Telenor R&D

PO Box 83

N-2027 Kjeller

Norway

Tel: (+47) 63 84 84 00

Fax: (+47) 63 81 00 76


Editorial board:

Ole P. Håkonsen,

Senior Executive Vice President.

Oddvar Hesjedal,

Vice President, R&D.

Bjørn Løken,

Director.

Graphic design:

Design Consult AS, Oslo

Layout and illustrations:

Gunhild Luke, Britt Kjus, Åse Aardal

(Telenor R&D)

Prepress:

ReclameService as, Oslo

Printing:

Optimal as, Oslo

Circulation:

4,000

1

To a certain extent, security has been regardedas a matter that should be left to military andnational security interests. With the advent ofworldwide electronic networks, such miscon-ceptions can be dangerous. Luckily, it is nowstandard procedure to carry out a risk analysisof all new products and systems before they areput into service. A problem is that security con-siderations are often ignored until the productis almost finished, when someone remembers:“Oh, and we need some security”. Security fea-tures are among the first to be removed fromprojects suffering from exceeded budgets. It isan important issue to make sure that security isbuilt into applications from the very beginning.Last-minute introduction of security featureswill generally lead to both higher expenses andpoorer security.

Apart from the actual physical damage resultingfrom a security breach, the loss of goodwill aftera blearing front page in the tabloid press or aprime-time news story must not be overlooked.The latter may actually represent a much moreserious and long-lasting loss potential.

This feature section addresses communicationsecurity comprising both the security of theusers (security services and security as a valueadded service) and the security of e.g. a tele-phone operator (security against malicious in-truders, competitors, etc.). Physical security(e.g. barbed wire, locks and fences, but alsopersonnel questions) will generally be left out.

Although most users are still not concerned withthe security of services, the awareness is cer-tainly growing rapidly, and the ability to offersecurity-enhanced services will become an evermore important issue for service providers.

Even if the “paper-less office” is still far frombecoming a reality, more and more informationthat previously only existed on paper is nowstored on electronic media. While this develop-ment makes it easier to share information amongthose who need it in their daily work, it alsoincreases the potential for outsiders (maliciousor not) to intrude. Industrial espionage is a threatthat all competitive companies must consider.

In the real world, the so-called “Bribe the secre-tary attack” is probably the attack with the low-est complexity of them all, whereas crypto-graphic protection often is the strongest link inthe chain. Cryptographic security can be quanti-fied (relatively) easily compared to other aspectsthat are much less tangible. Thus, we are in thesomewhat paradoxical situation that purely aca-demic weaknesses in otherwise secure crypto-graphic algorithms get a disproportionate inter-est compared to other security risks. Neverthe-less, with the number of available strong algo-rithms, there is simply no excuse for using weakcryptography.

Guest Editorial

Telektronikk 3.2000

Telektronikk 3.2000

1 Some Basic NotionsThe word Cryptology is derived from the Greekwords kryptós “hidden” and lógos “word”. Cryp-tology comprises cryptography (from kryptósand graphein, “write”), and cryptanalysis (cryp-tós and analyein (“loosen” or “untangle”). Cryp-tography is the science of principles and tech-niques to hide information such that only thoseauthorized can reveal the content. Cryptanalysisdescribes methods of (unauthorized) solving orbreaking of cryptographic systems.

A cryptographic algorithm or cipher is a system(mapping) where a plaintext is transformed intoa ciphertext. This transformation is known asencryption (or encipherment) and is defined bya key that is known only by the sender and thereceiver. The inverse mapping is called decryp-tion (or decipherment).

Breaking a cipher means disclosing the plaintextwithout prior knowledge of the key. A perfectcipher is impossible to break with any (finite)amount of resources.

In its simplest form, the setting consists of thetwo persons A(lice) and B(ob)1) who want tocommunicate securely over an insecure channel.Alice encrypts the plaintext P into the ciphertextC by means of the encryption function E and thekey k. Likewise, Bob uses the decryption func-tion D with k to decrypt C in order to find P.Before the communication can take place, Aliceand Bob must have exchanged the key k by

means of some secure key channel. We writethe encryption and decryption as follows:

C = Ek(P) and P = Dk(C) (1)

The adversary E(ve), who is eavesdropping onthe insecure channel between Alice and Bob,does not have access to k and cannot gain anyinformation from the ciphertext. See Figure 1.

1.1 Ciphers and CodesThe principal classes of cryptographic systemsare codes and ciphers. A code is a system wheresentences, words, syllables, letters, or symbolsare replaced with certain groups of letters ornumbers (code groups). The code groups (nor-mally 2–5 letters or figures) are listed in a code-book together with the corresponding plaintexts.The idea behind the code can be to hide the mes-sage from unauthorized persons, to shorten themessage in order to save transmission costs (e.g.telegram expenses; bandwidth), or to translatethe message into a form that is suitable for trans-mission (e.g. Morse code). During World WarII, the resistance movements in e.g. France andNorway received coded broadcast messagesfrom London where a short sentence had a pre-arranged meaning. “Jean a un moustache trèslongues” was the code signal sent to the Frenchresistance movement to mobilize their forcesonce the Allies had landed on the Normandybeaches on D-day.

In this article we will concentrate on ciphers anddiscuss codes no further.

An Introduction to CryptographyØ Y V I N D E I L E R T S E N

Cryptography constitutes one of the main building blocks of secure communications. Whilecryptography historically has been largely a military and diplomatic discipline, the develop-ment of electronic communication (e.g. the ubiquitous Internet) and the increased used ofcomputers in almost all layers of society have emphasized the need for secure communica-tion solutions also in the civilian sector. A particularly relevant issue is the so-called “neweconomy”, including electronic commerce, where the parts involved need cryptographicmethods to prove their identity and to protect transactions against unauthorized disclosureand tampering.

The purpose of this article is to present an introduction to some of the basic elements ofcryptography. We will first look briefly at the history of cryptography and then have a closerlook at some cryptosystems that are in use today. We conclude with some remarks aboutan application of quantum theory with possible far-reaching impact on the future of cryp-tography.

1) Alice and Bob were first introduced in [7].

Øyvind Eilertsen (34) is Re-search Scientist at Telenor R&D,Kjeller, where he has worked inthe Security group since 1992.Special interests include cryp-tography and mobile security.

[email protected]

2

3Telektronikk 3.2000

1.2 CryptanalysisWhile cryptography denotes the search for meth-ods and algorithms to protect communicationagainst adversaries, cryptanalysis finds weak-nesses in these algorithms (breaks them) to facil-itate eavesdropping or counterfeiting. Cryptanal-ysis is not necessarily “evil”; your friendlycryptanalyst can disclose weaknesses in yoursystems and propose countermeasures. Muchcryptologic research is concerned with findingweak points in existing cryptosystems, and thenmodify them to withstand these attacks. A fre-quently used method for testing the securityof computer systems is employing a team ofexperts with knowledge of security “holes”(tiger team), and let them try to break into thesystem.

In earlier times, cryptosystems usually dependedon the language in which the plaintext was writ-ten. Cryptanalysts employed knowledge of themessage language, including the structure, fre-quencies of letters and words, and the relation-ships between vowels and consonants. The useof computers for cryptanalysis has generallymade such systems obsolete.

Analysis and breaking of modern cryptosystemsrequire advanced mathematical/statistical meth-ods and major computer resources. TypicallyTerabytes of storage space and operationscounted in thousands of MIPS-years are neces-sary; see e.g. the account of the breaking of RSAkeys in Chapter 3.5.

If cryptography is used in a communication sys-tem with a significant number of users, one mustassume that the details of a cipher cannot be keptsecret. If the security is based on the secrecy ofthe cipher, the system is said to rely on “securitythrough obscurity”, a rather derogatory termwithin the crypto “community”. This does notimply that all secret ciphers are insecure, al-though this is a common misunderstanding.Obviously, it is much more difficult to cryptana-lyze an unknown cipher than a known one, andcryptosystems that protect matters of nationalsecurity are generally kept secret.

While considering the security of a cipher, secretor public, it is therefore assumed that an attackerknows all details of the cipher, except the actualkey in use. This principle was first stated by theDutch/French philologist Auguste Kerckhoffsin his seminal book La cryptographie militaire(1883), and is known as Kerckhoffs’s principle.In addition, a common assumption is that anattacker can generate an arbitrary number ofcorresponding pairs of plaintext and ciphertextfor a given key. This is called a known plaintextattack, or a chosen plaintext attack if the attackercan choose which plaintexts to encrypt.

The one-time-pad system, where the key and themessage have the same length, was described bythe American engineer Gilbert S. Vernam in1917. If the key is truly random (e.g. resultingfrom fair coinflips), such a cipher is perfect, aswas shown mathematically by Claude Shannon[9] in 1949. The main drawback with this cipheris that the key must be at least as long as themessage, and it must be used only once (hencethe name). Because of the key exchange prob-lem, one-time-pad systems are used only in en-vironments where security is paramount and themessages are rather short. As an example, a one-time-pad system developed by the Norwegiantelephone manufacturer STK was used to protectthe “hot line” between Washington D.C. andMoscow in the 1960s.

2 Some HistoryThe history of cryptography is probably is old asthe history of writing itself. Of course, duringmost of the history of writing, the knowledge ofwriting was enough – there was no need to en-crypt messages (or encrypt messages further),because hardly anyone could read them in thefirst place. There are a few examples of Egyptianscribes playing around with the hieroglyphicsymbols, possibly to attract the curiosity of thereaders, much like rebuses. (Considering theproblems modern linguists encountered trying toread hieroglyphs, one is tempted to say that theywere thoroughly encrypted in the first place.)

2.1 The Caesar CipherOne of the most well-known ciphers in historyis the Caesar cipher, probably employed by theRoman emperor Gaius Julius Caesar. Each letterin the alphabet is “moved” three places to theright, so that A is replaced by E, B with F, etc.This is an example of a simple substitutioncipher, as each letter in the plaintext is replacedwith another letter (monoalphabetic substitu-tion.)

The Caesar cipher is a simplified case of thelinear congruence cipher. If we identify theEnglish letters with the numbers 0–25, encryp-tion and decryption is defined as follows: (Weassume the reader is familiar with the modulonotation.)

Figure 1 The fundamentalcryptographic objective

Alice

Eve

Bob

Key channel

4 Telektronikk 3.2000

The key is the number pair (a, b), where we havethe additional restriction that a must be invert-ible modulo 26. This is the case if and only ifa and 26 have no common factors except 1. Wewrite this as gcd(a, 26) = 1, where gcd stands for“greatest common divisor”. The Caesar cipheruses a = 1 and b = 3, so unique decryption isguaranteed.

The main problem with a simple substitutioncipher is that the statistical variations in theplaintext language are still present in the cipher-text. The cipher is therefore easily broken withfrequency analysis of single letters, pairs(bigrams) and triples (trigrams) of letters. Forinstance, in ordinary written English, the letter‘e’ accounts for about 13 % of the letters, theletter ‘q’ is always succeeded by ‘u’, and so on.Obviously, the longer a message is, the moresubstantial the statistical skews. A plain mono-alphabetic substitution that contains more than40 letters can (almost) always be trivially bro-ken, because only one plaintext is possible. Latercryptographers introduced countermeasures tostatistical analysis, e.g. by letting several cipher-text letters represent the most common plaintextletters.

2.2 Polyalphabetic SubstitutionA significantly more advanced method is thepolyalphabetic cipher, which uses severalciphertext alphabets. Around 1470 (accordingto Kahn [4]), Leon Battista Alberti describeda “cipher disk” with two concentric circularmetal disks mounted on a common axis. Alongthe circumference of each of the disks an alpha-bet is outlined; one for the plaintext and one forthe ciphertext. By turning the disks, the cipher-text alphabet is changed. Alberti’s device can beused to construct polyalphabetic ciphers. Poly-alphabetic ciphers were described by Blaise deVigenère in 1586 and are often called Vigenèreciphers.

The polyalphabetic ciphers were consideredunbreakable for almost 400 years, even thoughseveral cryptologists in their writings were closeto discover a general method for breaking theciphers. The method was at last described by thePrussian officer Friedrich W. Kasiski in 1863.This did not, however, stop a device principallyidentical to Alberti’s disk from being patentedin Norway in 1883 under the name “Strømdahlskryptograf”. This device was used in the Norwe-gian defence up to the Second World War. Simi-lar systems were used by the US Signal Corps in1914.

E(P) = a ⋅ P + b (mod 26)

D(C) = a ⋅ C − b( ) (mod 26), (2)

with aa = 1 (mod 26)

2.3 The NomenclatorThe most widely used (indeed almost the only)method of protecting secret information from the15th to the 18th century was the nomenclator. Anomenclator is a kind of mix of a codebook anda cipher. It contains hundreds (or even thou-sands) of letter groups that represent commonlyused words and phrases, typically together withan extended monoalphabetic cipher.

2.4 The Rotor and Mathematical Cryptanalysis

Around 1920 several people independentlythought of using electrical versions of the cipherdisks, so-called rotors. By stacking severalrotors serially, one can construct polyalphabeticciphers with arbitrary complexity. Ciphermachines include the Swedish Hagelin and theEnigma, which was patented by the Germanengineer Arthur Scherbius in 1918.

In the 1920s and 1930s rotor machines were pro-duced commercially in several countries, includ-ing USA, Sweden and Germany. The machineswere used by both military and civilians

In the 1930s, growing unrest in Poland over theGerman military build-up led to extensive Polishefforts to encounter the German cryptosystems(The Enigma). With help from the French intelli-gence service (and the German spy Hans-ThiloSchmidt [5]) the Poles got the details of theEnigma, and led by the brilliant mathematicianMarjan Rejewski, they managed to outline theprinciples for breaking the encryption.

During World War II, all parties used rotor-based cryptographic machinery; the GermanEnigma (several different models), UK TYPEXand USA SIGABA. The British headquarters ofcryptanalysis was located at Bletchley Parknorth of London. Here, up to 12,000 peopleworked in the utmost secrecy with the decryp-tion of Enigma cryptograms. Based on the workby Rejewski prior to the war, and further devel-oped by (among many others) Alan Turing, theAllied Forces were able to more or less routinelybreak and read German secret communication.It has been argued that this work probably short-ened the war by at least one year. The differentparts of the German army used different variantsof the original Enigma design. The Wehrmacht,Kriegsmarine, Luftwaffe, and the military intelli-gence (Abwehr) all had their own version of theEnigma, which were constructed from the samestarting point, but all had their own idiosyn-crasies that had to be dealt with by the Alliedcryptanalysts.

The Enigma was (principally) used for encryp-tion of Morse traffic. In addition, the Germansused the cipher machines SZ 40 and 42 (Schlüs-


selzusatz) for teletype traffic, as well as theSiemens T 52 Geheimschreiber. At BletchleyPark, the foundation of modern electronic com-puting was laid down. The first electronic com-puter (“Colossus”) was constructed to break theGerman Lorenz cipher.

In USA, the Japanese ciphers (dubbed RED,BLUE and PURPLE by the Americans) wereroutinely broken from the mid-1930s. TheAmerican ability to read Japanese secret com-munication probably had significant influenceon the outcome of the war in the Pacific, e.g.the battle of Midway.

After World War II, the British government dis-pensed Enigma-type cipher machines to severalformer colonies (India, Pakistan, etc.), but therecipients did not know that the cryptographycould be broken. This was not generally knownuntil the end of the 1960s. (Actually, the factthat German Enigma messages were being bro-ken and read by the Allies was not publisheduntil 1974 [12].)

3 Computers and ModernCryptography: Crypto goes Public

The electronic computer has had an enormousimpact on cryptography. As we have seen, thefirst electronic computer was developed speci-fically for cryptographic purposes.

On the one hand, the computer and the interna-tional communication networks (e.g. the Inter-net) make it possible to move data around theglobe in seconds. On the other hand, this inter-connectivity opens new possibilities for fraud.

In a time when all banking orders were sent astangible pieces of paper, a fraudster needed toget hold of the specific piece of paper. When theorder is sent electronically, however, the fraud-ster may sit in a different part of the world butnevertheless have access to the data.

An interesting scenario is a thief stealing verysmall amounts of money from a very large num-ber of victims, a so-called “salami attack”. If theamounts are sufficiently small, the victims willnot notice, but the grand total will be significant,because the number of victims is so large. It ise.g. conceivable that a thief may collect fractionsof cents from interest calculations. This scenariohas often been cited, but it is not known to haveoccurred. A less subtle variation is actuallytransferring small amounts from accounts in thehope that the victims will not notice until theirnext account statement, at which time the thiefis long gone.

3.1 The Data Encryption StandardTo keep up with the need to protect banking,health, and other sensitive communication, whileallowing intercommunication, the US govern-ment moved to make public a cryptosystem. TheNational Bureau of Standards (now the NationalInstitute of Science and Technology or NIST)invited interested parties to offer candidates.A handful of algorithms were presented, andafter a period of scrutiny and adaptions, the DataEncryption Standard was published in 1976.

The winning algorithm was based on an algo-rithm called Lucifer from Horst Feistel of IBM.The 128 bit key of the original design wasreduced to 56 bits, and additional so-called S-boxes were introduced. The adaptions were sug-gested by the National Security Agency (NSA),and this immediately caused great controversy.Non-governmental cryptographers maintainedthat the NSA either had deliberately weakenedthe algorithm by reducing the key size to abreakable level, or that they had incorporateda “trap door” that enabled the NSA to easilybreak ciphertexts.

No substantial evidence was presented, however,and DES was published as a Federal Standardfor “un-classified government communication”in January 1977. DES was also adopted by theAmerican National Standards Institute (ANSI)for use in the private sector in USA, and by ISOas an International Standard for protection ofbanking communication (ISO 8730 and 8732).

3.1.1 The DES KeyDES is by far the most widespread and also themost publicly analyzed algorithm. No traces oftrap doors or deliberate weakening have beenfound, but with the rapid development of com-puting power the 56 bit key is now under seriousattack.

In 1998 The Electronic Frontier Foundation(EFF) presented their DES breaking machinecalled “Deep Crack”. With this hardware device,it was possible to check all the 256 ≈ 7.2 ⋅ 1016

keys in less than 72 hours. To counter this typeof attack, the newest version of the DES stan-dard [3] recommends only use of triple-DES.In this scheme, three instances of the originalDES algorithm is used as follows:

C = EK3(DK2(EK1(P))) (3)

The sequence encryption-decryption-encryptionwas chosen to facilitate interoperability witholder DES implementations; if K1 = K2 = K3equation (3) reduces to simple DES encryption.A common variation is letting K1 = K3, givinga key size of 2 ⋅ 56 = 112 bits.


In 1997, NIST initiated the process of finding asuccessor to DES, known as the Advance En-cryption Standard (AES). The selection processfor AES is the theme of an article by Lars Knud-sen in this issue of Telektronikk.

3.2 Stream Ciphers and Block Ciphers

Symmetric algorithms are usually divided intoblock and stream ciphers.

A block cipher breaks the plaintext message intostrings (blocks) of a fixed length (the blocklength and encrypts one block at a time. With agiven key, a pure block cipher will always pro-duce the same ciphertext from a given plaintext.In many applications this is not a favourable fea-ture, and some kind of feedback must be intro-duced.

A stream cipher produces a key stream k1k2k3 ...The key stream is combined with plaintextstream p1p2p3 ... using a simple transformation Eand producing the ciphertext C = c1c2c3 ..., withci = E(pi, ki). Usually, E is the XOR operation, i.e.

c1 = p1 ⊕ k1, c2 = p2 ⊕ k2, c3 = p3 ⊕ k3 ...

In a synchronous stream cipher, the sender andthe receiver must be synchronized to allow forcorrect decryption. This means that they mustuse the same key stream and operate at the sameposition in that key stream. If the synchroniza-tion is lost, decryption will fail, and re-synchro-nization, e.g. re-initialization of the streamcipher is necessary.

In contrast, in a self-synchronizing stream cipherthe key stream is generated as a function of theencryption key and a fixed number of previouskey stream bits. If ciphertext bits are deleted orinserted, only a fixed number of plaintext bitswill come out garbled before the synchronizationis re-established.

Most stream ciphers are based on linear feed-back shift registers, a structure very well suitedfor fast hardware implementations. The ciphersthat protect the confidentiality of the radio com-munication in GSM and UMTS are both streamciphers.

The difference between stream ciphers and blockciphers is a bit “academic”. Observe that astream cipher may be considered a block cipherwith block length 1. On the other hand, there arestandardized modes of operation that turn ablock cipher into a stream cipher.

3.3 Building a (Symmetric) Block Cipher

Obviously, an encryption function E must becomplex, preventing unauthorized reversal of thetransformation. Modern block ciphers achievethis goal by combining simple functions inclever ways.

3.3.1 Confusion and DiffusionCiphers are based on two basic techniques (oper-ations); transpositions and substitutions. Atransposition changes the order of the symbols(permutation), without changing the symbolsthemselves. In a substitution, each symbol isreplaced by another symbol (from the sameor some other alphabet).

3.3.2 Product CiphersAlmost all modern block ciphers are productciphers. The idea is to build a complex encryp-tion function by composing several simple func-tions, each offering some, but not adequate, pro-tection. The simple functions are then combinedin such a way that the combination is moresecure than the individual components. Basicoperations include transpositions, linear transfor-mations, arithmetic operations, modular multi-plications and simple substitutions.

3.3.3 Iterated CiphersAn iterated block cipher involves a sequentialrepetition of an internal function called a roundfunction. Let F be the round function, r the num-ber of rounds, and let Ti be the temporary outputof the round function. Then we get these equa-tions:

T1 = F(T0, K1)T2 = F(T1, K2)

.

.

.Tr = F(Tr-1, Kr)

The plaintext is the input to the first round (T0),and the ciphertext is the output from the last (rth)round (Tr). The Ki are the round-keys that arederived from the encryption key K accordingto the key scheduling. In order to make uniquedecryption possible, the round function mustbe a bijection for all round-keys Ki.

3.3.4 Feistel CiphersA Feistel cipher is an r-round iterated blockcipher with block length 2t. The plaintext is theordered pair (L0, R0), where the t-bit values L0and R0 represent the left and right half-block,respectively. In each round i, 1 ≤ i ≤ r, (Li-1, Ri-1)is mapped to (Li, Ri) as follows:


Li = Ri-1, Ri = Li-1 ⊕ F(Ri-1, Ki) (4)

where Ki is the round-key of round i. DES is anexample of a Feistel cipher.

3.3.5 Round Keys (Key Scheduling)In the round function, the output of the lastround is mixed with the current round-key.Typically, these entities are approximatelyequal in length, i.e. equal to the block length.

The encryption key must be expanded (typicallyr-fold). Ideally, all round-key bits should bedependent on all encryption key bits to maintainmaximal entropy. The expansion of the encryp-tion key to round keys is known as key schedul-ing.

3.3.6 S-boxesAn m × n substitution box or S-box is a mappingthat takes an m-bit input and returns an n-bit out-put. A one-to-one n × n S-box is a permutation.

S is non-linear if for two numbers a and b, wherea ≠ b, S(a) ⊕ S(b) is not equal to S(a ⊕ b). S-boxes are typically used to provide non-linearity(often they are only non-linear operations in anencryption algorithm), and are thus very impor-tant.

A number of criteria for selection (generation)and testing of S-boxes have been proposed, i.e.the strict avalanche criterion (SAC), which statesthat flipping one input bit should cause a changein (on average) 50 % of the output bits.

S-boxes are generally visualized and imple-mented as look-up tables, but some may addi-tionally be computed arithmetically. Smart-cardimplementations of look-up tables are vulnerableto power attacks (attacks that measure powerconsumption on the chip when performing en-cryption). Countermeasures to power attacksinclude duplicating the look-up tables in RAM;thus large S-boxes are more difficult to protectthan small ones. If an S-box can be implementedarithmetically, protection against power attacksbecomes much easier.

3.4 Public KeysIn 1976, Diffie, Merkle, and Hellman describedthe principles for asymmetric or public key cryp-tography. The principle is to use different keysfor encryption and decryption, thereby avoidingsome key management problems. In addition,asymmetric cryptography presents the abilityto make digital signatures, with approximatelythe same features as ordinary hand-written sig-natures. It has turned out that researchers at theBritish Communications-Electronics SecurityGroup (CESG) discovered these principle as

early as 1970; see [2]. This work was, however,not made available to the non-governmentalcrypto-community until 1997.

In a traditional (symmetric) cipher, the senderand the receiver must have access to a common,secret key. This key must be distributed in asecure way before the communication takesplace. In an asymmetric cipher, each user has aprivate and a public key. Asymmetric ciphersare therefore often called public key ciphers. Inprinciple there is a distinction here, as it is con-ceivable to have an asymmetric cipher withoutpublic keys. The distinction is, however, some-what academic, and no secret-key asymmetriccipher has been published, so we will treat theseas synonyms. The private key is only known tothe user (it is called “private” rather than“secret” in order to avoid confusion with sym-metric ciphers), while the public key is broadcastto all parties the user wants to communicatesecurely with.

A message that is encrypted with a public keycan only be decrypted with the correspondingprivate key, and vice versa. Knowledge of a pri-vate key shall not make it possible to reconstructthe corresponding private key.

3.4.1 UsageAssume that Alice wants to send a confidentialmessage to Bob. Alice encrypts the messagewith Bob’s public key. Now only somebody whohas access to Bob’s private key (presumablyonly Bob) can decrypt and read the message.

Assume on the other hand that Alice does notcare about secrecy, but she wants every reader ofthe message to be sure that Alice is the source.She then encrypts the message with her own pri-vate key. Now everybody with knowledge ofAlice’s public key can read the message. In addi-tion, since the message can be decrypted withAlice’s public key, only Alice can have en-crypted it. This is a kind of electronic signature.Alice can combine these features by first en-crypting the message with her own private key,and then encrypt the result with Bob’s publickey. Now only Bob can decrypt and read themessage, and he can be convinced that Aliceis the source.

Asymmetric ciphers are typically much slowerthan symmetric. Hybrid systems are common,where messages are encrypted with a symmetriccipher, while the (symmetric) key(s) are pro-tected with an asymmetric cipher. An efficientvariation of the digital signature above, is togenerate a hash value (or checksum) of the mes-sage, encrypt it with one’s private key and sendit together with the message. A recipient can


decrypt the signed hash value, recompute thehash value of the received message, and com-pare the two values.

3.5 RSAWhile there is a large theory on the constructionof symmetric ciphers (see Chapter 3.3), no gen-eral method is known for construction of asym-metric ciphers. Existing asymmetric ciphers arebased on suitable mathematical problems, ofwhich discrete logarithms and integer factoriza-tion have shown the most promising results. Themost widespread public key cryptographic algo-rithm is RSA, which was published in 1978 byRivest, Shamir and Adleman [7]. (The algorithmis obviously named after its inventors.) Thesecurity of RSA is based on the intractability ofinteger factorization.

3.5.1 The AlgorithmTo construct an RSA public/private key pair,Alice finds two large prime numbers p and q andchooses a number e. The public key consists ofthe pair (m, e), where m = p ⋅ q. Typical valuesfor e are 3, 17, and 65537. Alice then solves theequation

e ⋅ d ≡ 1 (mod (p – 1) (q – 1)) (5)

with respect to d. The private key is d, togetherwith p and q. Encryption and decryption is doneby computing powers modulo m:

C ≡ Pe (mod m) and P ≡ Cd ≡ Ped (mod m) (6)

The decryption works because ed = k(p – 1)(q – 1) + 1 for some integer k, and by Euler’stheorem

P(p-1)(q-1) ≡ 1 (mod pq) (7)

If an adversary (Eve) can factor the modulus mto find the prime numbers p and q, she can easilysolve equation (5) and find the private key d.Presently, no efficient method of integer factor-ization is known, but it has not been proved thatno such algorithm exists. It is not proved thatinteger factorization is necessary for breakingRSA, but no other efficient attacks are known,except in very theoretical cases. Boneh andVenkatesan [13] present strong evidence thatbreaking low-exponent RSA cannot be equiva-lent to factoring.

As of today, the largest RSA modulus whosefactorization has been published had 155 digits(512 bits). The main part of the work was doneusing a network of 285 workstations and PCs,running for 3.5 months, while the final calcula-

tions were done on a Cray supercomputer. Thetotal amount of CPU time was estimated to 8000MIPS-years.

Most applications now use 1024 bit RSA keys.Compared to a 512-bit key, factorization of a1024 bit key will demand an increase in CPUtime by a factor 5 ⋅ 106 and in RAM capacityby a factor of at least 6 ⋅ 103.

4 A Quantum Future?David Kahn notes in [4] that “The war of cryp-tographer against the cryptanalyst has been wonby the cryptographer.”

He argues that present-day ciphers are so diffi-cult to break, even with enormous amounts ofcomputing power, because of the exponentialnature of the work factor (rule of thumb: Whenthe cryptographer does twice as many calcula-tions, the work factor of the cryptanalyst issquared.) A so-called quantum computer mayactually reduce the work of the cryptanalystfrom exponential to linear again. As an example,an efficient factorization algorithm is describedin [10]. Whether a quantum computer will everbe built is quite another matter. Today, this“beast” is well outside the range of practicalimplementations, even if reports pop up fromtime to time.

On the other hand, quantum key distributionutilises the uncertainty principle to provide keydistribution between two parties with no priorcommon (secret) key [1]. If the parties haveaccess to a separate channel with only a passiveadversary (i.e. the adversary cannot activelyinfluence on the signals), the key distribution asprovably secure, even against adversaries withunlimited computing power.

5 Suggested Further ReadingDavid Kahn’s The Codebreakers [4] is the majorwork on the history of cryptography up to the1960s. However, it was first published beforethe details of the Enigma solutions were pub-lished. These events are the theme of a largenumber of accounts, including Kahn’s Seizingthe Enigma [5] and Gordon Welchman’s TheHut Six Story [11].

Much of the theoretical background of modernciphers was laid down by Claude Shannon in thepapers A Mathematical Theory of Communica-tion [8] and Communication Theory of SecrecySystems [9]. The most comprehensive work onpresent-day cryptography is the Handbook ofApplied Cryptography [6] by Menezes et al.


References1 Bennett, C et al. Quantum cryptography, or

unforgeable subway tokens. In: Advances inCryptology – Proceedings of CRYPTO’82,1983, 267–275.

2 Ellis, J H. The Possibility of Secure Non-secret Digital Encryption. January 1970.(CESG report.)

3 NIST. Data Encryption Standard (DES).Federal information processing standardspublication. 1999. (FIPS PUB 46-3.)

4 Kahn, D. The Codebreakers. [Rev. ed.] NewYork, Scribner, 1996.

5 Kahn, D. Seizing the Enigma. London,Arrow Books, 1996.

6 Menezes, A J, van Oorschot, P C, Vanstone,S A. Handbook of applied cryptography.London, CRC Press, 1997.

7 Rivest, R L, Shamir, A, Adleman, L. Amethod for obtaining digital signatures andpublic key cryptosystems. CACM, 21 (2),120–126, 1978.

8 Shannon, C E. A mathematical theory ofcommunication. The Bell System TechnicalJournal, 27, 379–423, 1948.

9 Shannon, C E. Communication theory ofsecrecy systems. The Bell System TechnicalJournal, 28, 656–715, 1949.

10 Shor, P W. Algorithms for quantum compu-tation : Discrete log and factoring. In: Pro-ceedings of the 35th FOCS, Los Alamitos,116. IEEE Computer Society Press, 1949.

11 Welchman, G. The Hut Six Story. M&MBaldwin, 1997. ISBN 0947712348.

12 Winterbotham, F W. The Ultra Secret.London, Weidenfeld and Nicholson, 1974.

13 Boneh, D, Venkatesan, R. Breaking RSAmay not be equivalent to factoring. In:Advances in Cryptology – EUROCRYPT’98,57–71, 1998.

Telektronikk 3.2000

IntroductionEncryption used to be something which only thesecret services and military had a real interest inand which private citizens only knew fromcrosswords and puzzles in Sunday newspapers.Today encryption is an important part of theinformation society. Outside of the secret ser-vices the interest in encryption started to blos-som at the end of the 1970s.

First, IBM (International Business Machines)developed the cryptosystem Lucifer, which laterwas adapted as a US Federal Information Pro-cessing Standard, although slightly modified.This standard was published in January 1977as the DES (Data Encryption Standard) and istoday probably the most used encryption systemin the world (at least outside of the secret ser-vices). The system is a so-called secret-key cryp-tosystem, where the same information, or key,is used to encipher (or encrypt) and decipher (ordecrypt) the messages.

Second, the researchers Whitfield Diffie andMartin Hellman discovered (or re-discovered1))so-called public-key cryptography, where thesecret key is split into two parts, a public partand a secret part. The public part of the key ismade available to everyone; the secret part stayssecret with one party. The public key can beused by everyone to encrypt a message, whilethe secret key can be used to decrypt the cipher-text and restore the message.

The differences between today’s secret-key andpublic-key cryptosystems are many, but there isa need for both of them. Even though the DEShas withstood almost 25 years of cryptanalyticattempts to find shortcuts in the algorithm bycryptanalysts from all over the world, time isrunning out for the algorithm. The main problemis that the DES was designed to accept keys ofonly 56 bits, which means that there are 256 ≈1017 different keys. Even though this numbermay seem huge, (as an example, 256 seconds areabout 2 billion years), it is small enough toenable the design of special-purpose built hard-ware, which can run through all possible valuesof the key in a very short time. In 1998 it wasestimated that an attacker who is willing toinvest one million US dollars, could try all val-ues of the key, one by one, in just half an hour!

With a few encrypted messages on hand, onecan simply decrypt these under all possible val-ues of the key. The value of the key which yieldssome meaningful messages is with a high proba-bility the correct one, and the system is broken.

Technical DetailIn a cryptosystem the message is always firstconverted to a number. This number is thenencrypted by applying some mathematical ornon-mathematical operations to it, and theresulting number is then transformed back tocipher-text. The numbers are represented in thebinary number system, that is, a number is eithera zero or a one. As an example, the number 17in the decimal number system (the one we usenormally) is 10001 in the binary number system.The symbols in the binary number system arecalled bits.

AES – Advanced EncryptionStandardIn 1997 the American National Institute forStandards and Technology (NIST) decided thatit was time to find a substitute for the DES. Sur-prisingly (at least to this author) NIST invitedparties from all over the world to participate inthis process and announced a call-for-candidatesfor the Advanced Encryption Standard (AES).The conditions for the competition were manyand included a whole range of documentationrequirements and test results.

The most important requirements for the systemare that there must not be any trapdoors (short-cuts), and that the best attack against the systemis the trivial one of trying all keys one by one. Amore specific requirement is that the secret keysmust be of length of at least 128 bits. This meansthat there will be at least 2128 different keys,which is about 1039. The above mentioned spe-cial-purpose built machines to try all keys oneby one will not have a chance of being applica-ble in practice before 2030 – 2040, or probablyeven later.

NIST also invited the world’s cryptanalysts toparticipate in the process. The goal of NIST isthat the whole process be as open as it can be,and that all aspects of the design and analysisare made public.

Advanced Encryption Standard (AES).Encryption for our GrandchildrenL A R S R . K N U D S E N

Lars R. Knudsen (38) is Profes-sor at the Institute of Informaticsat the University of Bergen. Hereceived his M.Sc. and Ph.D.degrees in computer scienceand mathematics from AarhusUniversity, Denmark, in 1992,respectively 1994. He has writ-ten numerous scientific papersin the area of cryptology and isregarded a world expert in blockcipher encryption algorithms.

[email protected]

1) The English intelligence service claims that they invented the public-key techniques around thesame time.

10


The deadline for submitting candidates to the AESwas June 15, 1998. Out of a total of 21 submis-sions, six were discarded because of incompletedocumentation. Of the remaining 15, five are fromthe USA, two from Canada, there is one candidateeach from Australia, Belgium, Costa Rica, France,Japan, Korea, and Germany, and then a multi-national candidate from Denmark, United King-dom and Israel. This author represents the Scandi-navian colours in this competition.

After one year of gathering information aboutthe 15 candidates NIST decided in August 1999to pick five candidates for a final and last round.This author was involved in the breaking of twoof the 15 candidates and in the finding of seriousweaknesses in a third candidate. The five candi-dates for the final round are in alphabeticalorder.• MARS by IBM, USA;• RC6 by RSA Inc., USA;• Rijndael by researchers from Belgium;• Serpent by researchers from Denmark, UK,

Israel;• Twofish by Counterpane, USA.

In April 2000 the last conference on the AEStook place in New York, USA, and May 15,2000 was the deadline for sending in commentsand analysis of the five candidates. NIST ex-pects to announce the winner(s) some time inthe year 2000.

SerpentSerpent is a snake; the idea is that Serpent willslither away from all cryptanalytic attacks. Myco-authors on Serpent are Ross Anderson fromCambridge University in England and Eli Bihamfrom Technion University in Haifa, Israel. Thefirst version of Serpent (later called Serpent-0)was developed in 1997 and presented at a con-ference on encryption in Paris, March 1998. Theversion we submitted to NIST, called Serpent, isa slightly modified version of Serpent-0. Today(July 2000) no one has managed to find anyweaknesses of any kind in Serpent.

Secret-key cryptosystems are traditionally con-structed by running the message through severalso-called substitutions and permutations depen-dent on the value of the secret key. Substitutionsare also sometimes called S-boxes and are oftenimplemented in terms of a look-up table, whichfor every input specifies the function value. Theadvantage of this approach is that it is relativelyeasy to choose and use functions with complexmathematical formulae. Permutations are oftensimple functions which permute (or re-order) thebits of the messages typically, one uses a set ofsmall substitutions each modifying a small pieceof the message, but such that the whole text ismodified. Subsequently, the pieces are moved

around and mixed. This recipe is then repeated asufficient number of times, until the resultingciphertext looks like total gibberish (and oftenmore than that).

Serpent is constructed as above and has 32 itera-tions or layers. In each layer the 128-bit text issplit into 32 smaller parts of four bits each. Thefour bits are input to a small S-box, which againreturns four (other bits). Then the 32 blocks offour bits are concatenated (put together) and the128 bits are mixed using a permutation. The nicefeature of Serpent is that the 32 S-box evalua-tions can be done in parallel. Most computerstoday operate on 32-bit words, which enables usto look up 32 S-box values in parallel; that is, oncomputers with just one processor. This meansthat the 32 look-ups are much faster than doing32 conventional look-ups. On 8-bit processorsit is possible to do eight evaluations in parallel.The substitutions and permutations are well cho-sen, such that all known attacks on block cipherhave to give up after 7 to 9 layers. Thereforethere is a big safety margin in Serpent, bigenough to handle even considerable improve-ments in the known techniques.

On the average PC Serpent is not the fastestalgorithm of the final five candidates left in thecompetition. On the other hand, on other plat-forms, e.g. in smart card applications, Serpent isone of the fastest; also in hardware Serpent is thefastest of the five. The great advantage of Ser-pent is that the safety margin protecting againstfuture cryptanalytic improvements is the largestof all five candidates.

Licenses?One of the great properties of the AES, apartfrom high security (if Serpent is chosen!) is thatthe system must be royalty free and free to usefor everybody all over the world. It was a con-dition to participate in the competition that allpatents and rights were waived, in case the algo-rithm should be selected for the AES.

Hidden TrapdoorsOne of the favourite subjects in the boulevardpress when it comes to encryption system is hid-den trapdoors. As an example, when the DESwas first published there was a lot of debate onthe possibility that the American governmenthad put in a trapdoor enabling them to readencrypted traffic without knowing the secretkey. However, I am convinced that no such trap-door exists for the DES, and I guarantee that nosuch trapdoors have been put into Serpent. It isvery hard to break the encryption systems whichare constructed according to the state-of-the-art,but it is even more difficult in my opinion to puta trapdoor into a public cryptosystem withoutbeing detected.


On the Need of EncryptionIn a modern society when we send a (conven-tional) letter, we expect that only the intendedrecipient can open the letter and read it. Like-wise, we probably expect that documents on ourdesk are inaccessible to the public. It ought to beexactly the same for electronic information, nomatter if it is sent over a public channel or if it isstored on a hard disk. I say “ought to”, becauseI do not think that this is the case today, unfortu-nately. By far the most electronic mail (e-mail)is sent in clear text today, which at least in prin-ciple makes it accessible to everyone. And howmany people encrypt the data on their hard disk?Encryption does not require a change in attitude,I think, since I believe everyone would use it forboth the above purposes, if all it took was topress a button on a screen. I am perfectly awarethat the existence of a good encryption system isnot sufficient to enable secure e-mail communi-cation. One needs to solve the problem of howdo the sender and receiver share a secret keybetween them such that no one else knows it?This is not a trivial problem, but there are knownsolutions.

And the Winner is ...Who knows? NIST will decide sometime thisyear (2000). There are rumours that NIST is

going to choose several candidates for the stan-dard. The advantage of this is that the users getmore flexibility, since one scheme could be bet-ter suited for a certain platform or applicationand another scheme for some other platform orapplication. Furthermore, with several algo-rithms, one would be able to switch from onealgorithm to another in case the first one shouldbecome vulnerable to some cryptanalytic attack.This would save us having to go through a longtedious process like the one for the AES will be.The disadvantage of having more than one algo-rithm is that not everyone would use the sameand that the AES therefore should not becomeas popular as the DES. There are applications,e.g. smart cards, where it is not feasible toimplement more than one encryption system.

NIST claims that they will consider all submit-ted attacks and comments, and that the wholeprocess will be open to the public. This is proba-bly true but with one small modification. I thinkit is very likely that NIST will receive inputfrom the NSA (the National Security Agency).This input will probably not be accessible to thepublic. There is of course also politics involvedin the AES. Is it likely that NIST will choose anon-American algorithm for a federal Americanstandard? I do not know, but I think that if NISTchooses more than one algorithm, a non-Ameri-can algorithm will be one of them.

NIST does not have the means to pay money toany of the designers and analysts. Also, the win-ner(s) will not receive any direct monetary bene-fit from NIST. All the work of the submittersand people who have spent hours analysing thecandidates is unpaid and voluntary.

Why do we do it then? I guess we do it for thefame and recognition one would get in caseone’s algorithm is selected or even being amongthe final five. Also, the AES is a chance to givea good encryption algorithm royalty-free to peo-ple from all over the world, and to our childrenand grandchildren.

More InformationMore information can be found at the officialAES-site http://www.nist.gov/aes; or my sitehttp://www.ii.uib.no/~larsr/aes.html, or my Ser-pent-page http://www.ii.uib.no/~larsr/serpent.

Feature Editor’s Note:On October 2, 2000, NIST announced that theBelgian algorithm Rijndael is the winner of theAES contest. NIST said that Rijndael was cho-sen because of its combination of security, per-formance, efficiency, ease of implementationand flexibility. NIST tentatively expects the AESstandard to become official in April – June 2001.

01/97 Announcement of AES

04/97 First workshop in Washington, USA

06/98 Deadline for submission of candi-dates

08/98 First AES conference in Ventura,USA, with presentation of candidates

03/99 Second AES conference in Rome,Italy

08/99 NIST announces the five candidatesfor the final

04/00 Third and last AES conference inNew York, USA

??/00 Announcement of the AES winner(s)

Table 1 Timetable for AES

Table 2 The 15 AEScandidates. The underlinedalgorithms are the final fivecandidates

Name Country

Cast256 (Canada)

Crypton (Korea)

Deal (Canada)

DFC (France)

E2 (Japan)

Frog (Costa Rica)

HPC (USA)

Loki97 (Australia)

Magenta (Germany)

Mars (USA)

RC6 (USA)

Rijndael (Belgium)

Safer+ (USA)

Serpent (Denmark/England/Israel)

Twofish (USA)

13

1 IntroductionMoving towards an information society wherewe see a rapid integration of information systemsand communication systems, more and more ofpublic, industrial and private business take placein an open, distributed and digital marketplace.This trend implies an increasing need for secu-rity services for protection of both user data andnetwork management data. The ISO SecurityArchitecture [1] defines the following set ofsecurity services and also specifies at whichlayer of the communication protocol the serviceshould or could be implemented:

• Peer Entity Authentication• Access Control• Connectionless Confidentiality• Connection Integrity with Recovery• Non-Repudiation• Data Origin Authentication• Connection Confidentiality• Traffic Flow Confidentiality• Connectionless Integrity.

The use of encryption algorithms is a basic tech-nique for the implementation of several of theservices mentioned above, even if the traditionaluse of cryptography has been to provide infor-mation confidentiality. For an excellent histori-cal overview of the use and importance of crypto

systems, see D. Kahn [2]. In this paper we willdiscuss several issues related to the developmentand use of cryptographic standards with empha-sis on their use in telecommunication systems.

2 Basic Model of aCryptographic System

In order to give some tutorial background to howcryptography is used in a communication sys-tem, we will briefly discuss the basic model ofa cryptographic system as shown in Figure 1.

The sender A wants to send the message M to thereceiver B. The communication will take placeover an insecure channel, where an eavesdropperZ may listen and get unauthorised access to theinformation passing over the channel.

By applying the encryption device Enc, theentity A transforms the message M, often calledthe plaintext, into an unintelligible message C,called ciphertext, under the control of the en-cryption key KE. The receiver B has the corre-sponding decryption key KD and is able torecover the plaintext M from the ciphertextC using the decryption device Dec.

In a symmetric cryptosystem KE = KD and theexchange of keys has to take place over a confi-dential key channel. In an asymmetric crypto

Development of Cryptographic Standardsfor TelecommunicationsL E I F N I L S E N

Figure 1 Basic model of acryptographic system

Leif Nilsen (48) is Senior Cryp-tologist with Thomson-CSF Nor-com AS and Associate Profes-sor at the University of OsloGraduate Studies at Kjeller(UNIK). He is working with infor-mation security, cryptographicalgorithms and key managementsystems. He is Norwegian ex-pert to ISO/IEC JTC1/ SC27and member of ETSI/SAGE.

[email protected]

EncA

Z

Dec B

KE KDKey channel

M C M

The development of secure information systems encompasses the use of system technicalsecurity solutions based on cryptographic techniques. The article provides a basic tutorial oncryptographic algorithms and describes the development of cryptographic standards for usein telecommunications. We review the set of algorithms that has been developed for dedi-cated use within ETSI standards. This development has been targeted to balance divergenttechnical and political requirements and has produced a variety of system specific solutions.The article also includes a survey of the most influent standardisation initiatives for general-purpose cryptographic algorithms.

Telektronikk 3.2000


system (also called public key system), it isimpossible to find KD from knowledge of KE

and the encryption key can be a public parameterbelonging to the entity B. In this case there is aneed for an authenticated key channel from B toA. Current systems often solve this distributionproblem using certificates and a Public KeyInfrastructure (PKI).

For symmetric systems, the algorithm definingthe encryption/decryption transformation caneither be a block cipher or a stream cipher de-pending on the use of internal memory in theencrypting device.

A stream cipher breaks the plaintext messageinto successive characters or bits m1, m2, ... mn

and encrypts each mi with the i’th element of akey stream k1, k2, ... kn derived from the basickey K and optionally an additional message key.Most stream ciphers operate bitwise by addingthe message bit and the key stream bit modulo 2,i.e. ci = mi ⊕ ki. The receiver can now recoverthe plaintext bit mi from the ciphertext bit ci byadding with the corresponding key stream bit ki.Note that this requires full bit synchronisationbetween the encrypting and decrypting devices.The general principles for a stream cipher areshown in Figure 2.

A block cipher breaks the plaintext message intosuccessive blocks M1, M2, ..., Mn and encryptseach block using the same key K. A typicalblock length is 64 or 128 bits. For a fixed keyK, the cryptographic transformation can then beseen as a permutation on the set of all possibleblocks. The US Data Encryption Standard DES[3] is a well-known example of a block cipherusing a 56 bits key and operating on 64 bits datablocks. Note that a block cipher can operate in

different modes as defined by the internationalstandard ISO/IEC IS 10116 [4]. By operating ablock cipher in Cipher Feedback Mode (CBC) orOutput Feedback Mode (OFB), a block cipherbehaves like a stream cipher. There are also stan-dardised methods for using a block cipher tocompute Message Authentication Codes (MAC)[5] and for hashing operations [6]. This meansthat a strong and efficient block cipher is ahandy tool for implementation of several secu-rity services. The general principle for a blockcipher is shown in Figure 3.

The strength of a cryptographic system reliesheavily on the two components, the encryptionalgorithm and the key management system; nei-ther is simple to design. For the encryption algo-rithm several security requirements can be sum-marised in the following: Without knowledgeof the secret key, it shall be impossible for anattacker to find the plaintext, given the cipher-text; or from known plaintext/ciphertext pairs tofind the secret key. This means that the securityof the system does not depend on the secrecy ofthe algorithm itself. When an algorithm is anal-ysed, it is important to assume that the opponenthas detailed information about the specifications.

3 The Strength ofCryptographic Algorithms

Cryptographic algorithms are fundamentallydifferent from other algorithms with respectto their intended goal. Normally an algorithm isdesigned to solve a specific problem like errorcorrection or finding a path through a complexnetwork. We are then normally able to provethat the algorithm solves the problem com-pletely, even if other and more efficient algo-rithms may be found. As long as we can meetoperational requirements, the algorithm willcontinue to do its job and it will never be“worn out” or “broken”.

The goal of an encryption algorithm is to protectinformation against all possible attacks of knownand unknown enemies. Even if we are able toprove that an algorithm is resistant to a specificattack, we can never be sure that it can withstanda novel attack tomorrow. Perhaps we can designan algorithm that is secure against the computa-tional power of a single enterprise. With the cur-rent growth in processing power, the same algo-rithm could be vulnerable to governmental agen-cies and dedicated hardware in a few years’time. We see today that some of the most mod-ern and secure crypto systems will be easy tasksfor new computational models like DNA com-puting [7] and quantum computing [8].

A theoretical foundation for cryptographic sys-tems may be based on information theory orcomputational complexity theory, but neither of

Figure 2 Principles forsynchronous stream cipher

Figure 3 Principles forblock cipher

ki

Streamcipher

algorithm

K

mi mici

ki

Streamcipher

algorithm

K

Blockcipher

encryption

K

C Blockcipher

decryption

K

M M


these approaches can be used to design practicalsystems that provide provable security in a strongsense. Most algorithms are designed using a sys-tem-theoretic approach combining well-estab-lished principles with partial security proofs.

All cryptographic algorithms can be attacked bya brute force attack on the key space. Assumingan enemy has knowledge of the algorithm in-volved, he can try to decrypt the ciphertext withall possible keys. Meaningful plaintext will appearwhen the proper key is found. If the length of thesecret key is n bits, there are 2n different keys totry. This means that the key length is a simpleparameter used to indicate the strength providedby a cryptographic algorithm. However, it isimportant to recognise that a sufficient keylength is a necessary but not a sufficient require-ment for a strong algorithm. An algorithm couldhave a long key, but still be vulnerable to otherattacks more efficient than exhaustive keysearch. A report from 1996 [9] gives guidelinesfor selection of key lengths as shown in Table 1.

It is important to stress that this table is only rel-evant for symmetric algorithms. The situationfor asymmetric ciphers is much more complexand adequate key lengths for such systems arecompletely different from those in Table 1. Anexcellent guide is [10].

4 Encryption PolicyThe implementation of encryption solutions isnot only a technical matter, but also sensitivepolitical issues are involved. For a long timeserious use of cryptography was restricted todiplomatic and military use and encryption tech-nology was considered to be of strategic impor-tance to national security. National and interna-tional regulations were developed to monitor theuse and dissemination of the technology. Mostcountries still enforce some kind of export con-trol, but the rules have gradually become moreliberal.

The introduction of confidentiality as a standardservice in telecommunication systems will notonly protect the involved link against fraud andmalicious eavesdropping, but it will also prohibitpolice and security agencies involved in legalinterception as part of their combat against ter-rorism and organised crime. In many countriessuch interception has been an important toolagainst serious criminal activity, but normallya special court order must be available beforethe interception can take place.

In mobile systems like GSM and DECT, theradio link is considered to be an exposed andvulnerable channel and the standards specifyencryption of this link. The solutions involved

have been a carefully chosen design balancingthe specific threats involved and the need forgeneral exportability. For such systems there areno export controls on the terminals, but a licenseis normally needed for network equipment.

5 Open or Secret AlgorithmsAs stated above, the strength of a cryptographicsystem should not rely on the secrecy of thesystem description. In order to provide optimalanalysis and confidence in a cryptographic algo-rithm, it will be important to have public avail-able specifications that have been studied byindependent experts. By standing such publicscrutiny over a long period of time, an algorithmcan achieve the necessary trust and assurance.This is a strong argument in favour of open algo-rithms and it seems clear that this is the onlymodel for wide acceptance of general-purposecryptographic algorithms.

Open algorithms may be subject to a variety ofresearch analysis and many results are publishedas “breaks”, even if the announced attack cannotbe conducted within the operational environmentof the system. Normally any attack with com-plexity lower than exhaustive search is reportedas “cracking the algorithm”, often resulting inmuch publicity and worried users. In many casessuch results are mostly of academic interest andhave minimal impact on the security of theactual system.

However, in the same way as openness is noguarantee for strong algorithms, a secret algo-rithm does not implicitly mean that the algo-rithm is weak. Cryptographic algorithms usedin military systems for protection of classifiedinformation are seldom or never revealed. Theseorganisations have a strong internal competencein design and analysis of algorithms and do nothave the same need for an open process. Fromhistory they know the difference between attack-ing a known versus an unknown crypto system.In order not to provide an enemy cryptanalystwith any advantage, they prefer the use of secretalgorithms.

Type of attacker Key length needed

Pedestrian hacker 45-50

Small business 55

Corporate department 60

Big company 70

Intelligence agency 75

Table 1 Guidelines forselection of key lengths


6 Use of Encryption inTelecommunications Area

Traditionally the use of encryption technology inthe telecommunications area has been seen alongthe following lines:

1. Protection of network management infor-mation. Operator initiated encryption of dedi-cated connections in order to secure importantconnections vital to the operation and mainte-nance of the network itself. This approach maywork well within one domain controlled by oneoperator, but may face problems in multipledomain solutions implementing the Open Net-works Provision policy.

2. End-to-end encryption by dedicated userswith high security requirements. Users thatexchange confidential information over publicnetworks using secure phones or crypto-faxes.Such solutions normally depend on expensiveand proprietary equipment. Due to the complex-ity of key management, the solutions do notalways scale well and there are no standards forsuch connections.

3. Encryption of vulnerable links. Modernmobile networks like GSM, DECT, UMTS andsatellite-based networks involve a radio linkespecially vulnerable to eavesdropping (as wellas other security threats). In order to protect userdata and signalling information in such systems,encryption techniques have been introduced onthe radio link between the mobile terminal andaccess points to the fixed network.1)

4. Entity authentication. Mobile communica-tions lacks the conventional access point to thenetwork and there is a strong need for authenti-cation of users involved in a call. It may alsobe necessary for the user to authenticate the net-work. In most systems such authentication isbased on a “challenge and response protocol” inwhich an entity authenticates itself by provingknowledge or possession of a unique secret key.The challenge and key are then input to somecryptographic algorithm which outputs the cor-rect response.2)

7 The Data EncryptionStandard (DES)

For many years the US Data Encryption Stan-dard (DES) [3] has been the de-facto standardfor commercial encryption. DES was proposedin 1975 and approved in 1977 as a Federal Stan-dard for protection of sensitive, but unclassifiedinformation. DES was designed and proposed byIBM, endorsed by the National Bureau of Stan-dards (NBS, now NIST) and later approved byANSI as US standard. Around 1985 there waswork within ISO to establish DES as an interna-tional crypto standard, but this project washalted due to political problems. DES is widelyused by banks for protection of electronic fundstransfer.

DES is a symmetric block cipher, which en-crypts a 64-bits data block under the control ofa 56-bits key. From the very first moment therewas strong criticism against the key length ofDES and it was argued that the key space couldbe searched by strong opponents using dedicatedhardware devices. In July 1998, using customdesigned chips and a personal computer, theElectronic Foundation built “DES Cracker” [11].Costing less than USD 250,000 and taking lessthan a year to build, DES Cracker broke a DES-encoded message in fifty-six hours. There wasnothing terribly novel about the decryptionmachine except that it was built. From Table 1 inSection 3 we see that this result fits nicely withthe predictions from 1996.

The immediate response to the shortcomingsof the DES key length has been to implementTriple-DES systems, in which the DES algo-rithm is used in three consecutive steps usingtwo or three different keys. The long-term solu-tion will be to develop a replacement algo-rithm(s), see section on AES below.

Even if DES is approaching the end of its lifecycle, it has been an example of a carefully de-signed algorithm, which have resisted open anal-ysis over many years. Today we know that itwas designed to withstand attacks that were notpublicly known back in the seventies [12]. Evennew attacks have appeared over the years, butthey had little impact on the practical strengthprovided by DES.

1) Due to interoperability requirements, this encryption has to be based on standardised algorithmsknown both to the mobile station and the network.

2) This authentication is often a protocol between the subscriber’s SIM module and the operator andmay be based on an operator-controlled algorithm. In this case it is not necessary to have one stan-dardised algorithm.


8 ETSI StandardisationETSI is the European Telecommunications Stan-dards Institute. It has approximately 450 mem-bers and its main objective is to produce techni-cal standards in the area of telecommunications.

The specification of security standards for a spe-cific telecommunications area or system withinETSI is in principle carried out by the responsi-ble Technical Committee (TC) or ETSI Project(EP). For general security issues there is a dedi-cated Technical Committee called TC Security.For the design and specification of cryptographicalgorithms a Special Committee was installed:the Security Algorithm Group of Experts(SAGE). Unlike other TCs or EPs, SAGE isa closed group with an appointed membership.

The outline procedure for the design of crypto-graphic algorithms for ETSI standards is that theETSI TC or EP first decides if there is a need fora standard algorithm. Then the TC/EP drafts adocument specifying the requirements for thisalgorithm. These requirements normally de-scribe issues like use of the algorithm, imple-mentation complexity, performance, resilience,exportability and management of the algorithmand its specifications. The document also speci-fies if the algorithm should be published or con-fidential. If needed the TC Security assists theresponsible committee to draft the requirementsspecifications.

In the next phase ETSI SAGE designs and speci-fies the algorithm according to the requirements.The algorithm is then delivered to the algorithmcustodian (in most cases this is ETSI) whichtakes care of the distribution of the algorithms tothe intended users. SAGE also produces a reportfor the ordering committee describing the workdone, the rules achieved and the rules for man-agement of the algorithm.

9 Algorithms Used in ETSI Standards

In this section we will review several standardsdeveloped by ETSI and describe the use of cryp-tographic algorithms in those standards.

GSM – The Global System for MobileCommunicationsGSM was the first public standard digital tele-communication system which included substan-tial use of cryptographic algorithms. The origi-nal system employed a standard encryption algo-rithm called A5 for encryption of user data andsignalling information. Only the vulnerable radiolink was protected by this encryption and thetraffic was in clear within base stations, switchesand networks. When GSM began to expandbeyond Europe there were difficulties involvedin exporting the system to certain countries and

the need for an export algorithm was identified.The original A5 now became A5-1 and a newexport version A5-2 was designed by SAGE.Both algorithms should be implemented in thehandset and it is up to the network to decidewhich algorithm to use. Both A5-1 and A5-2 isbased on stream cipher technology.

The GSM system also uses an algorithm forauthentication of the user and generation of theencryption key. This algorithm is called A3/A8and is not a standard algorithm in the system.The operator is free to design their own algo-rithm or they can use an example algorithm fromthe GSM Association called COMP128. Somesecurity problems have been found in COMP128and a replacement example algorithm is nowavailable.

For the new data services in GSM, the GeneralPacket radio service (GPRS), a special encryp-tion algorithm called GEA was developed bySAGE. SAGE also developed a special authenti-cation/integrity/key generation algorithm forGSM Cordless telephone System (CTS) in 1999.

DECT – Digital Enhanced CordlessTelecommunicationsDECT has security features that are similar tothose in GSM. As in GSM it uses an encryptionalgorithm, the DECT Standard Cipher (DSC),and an authentication and key generation algo-rithm called the DECT Standard Authenticationalgorithm (DSAA). Like A5-1 both DECT algo-rithms were designed before SAGE was set up,but the algorithms have recently been reviewed.

ISDN based audio-visual systemCCITT (ITU) has drafted recommendationsH221, H261 and H233 in the area of the use ofaudio-visual systems and specifies security forthese. The CCITT recommendations wereadapted by ETSI. Recommendation H233(“Confidentiality for audio-visual services”)specifies the use of encryption and allows differ-ent algorithms to be used. SAGE designed anencryption algorithm especially for this purpose.It is called BARAS (baseline Algorithm recom-mended for Audio-visual Services).

Multi-application telecommunicationscardsA sub-committee of the ETSI TC terminalEquipment (TE) drafted a series of standards forMulti-application telecommunications IC(Smart) card. The specifications included a num-ber of security functions.

To support these functions SAGE was asked todesign a cryptographic algorithm called TESA-7. The specification included four modes of usefor the algorithm. These are authentication


mode, integrity mode, key diversification mode(i.e. generating an individual key from an iden-tity and a master key) and a secure key loadingmode.

So far there has been little use of the Multi-application standards and it has recently beenagreed to broaden the use of TSEA-7 to theGSM SIM (Subscriber Identity Module – thesmart card of GSM).

UPT – User Personal telecommuni-cationsUPT is a telecommunication service standard-ised by ETSI that enables users to register ona foreign telephone and then be reached thereunder their own telephone number. This servicerequires authentication before it can be invoked.

ETSI SAGE designed a standard authenticationalgorithm, called USA-4, for this service. How-ever, until now there has been limited use of theUPT standard and hence the USA-4 algorithm.

Hiperlan – High Speed radio LANHiperlan is a standard for high-speed radio LANover which data is transmitted at high speedsover the air interface. For this standard SAGEdeveloped a dedicated encryption algorithmcalled HSEA (Hiperlan standard EncryptionAlgorithm). The export restrictions on the algo-rithm should be minimal and the algorithm pro-vides a basic level of security. The ETSI projectBRAN is currently standardising a successorfor Hiperlan. This standard (BRAN) will supporthigher data rates and it seems that it will employa standard encryption algorithm.

BEANO – Binary Encryption Algorithmfor Network OperatorsA few years ago the ETSI TC Security identifiedthe need for an algorithm that could be used toprotect the confidentiality of network manage-ment data. ETSI SAGE designed a special en-cryption algorithm called BEANO (Binary En-cryption Algorithm for network Operators).BEANO is a strong block cipher algorithm em-ploying an 80 bits key. To overcome the con-flicting requirements for broad exportability anda high level of security, the license and confi-dentiality agreement explicitly limits the use ofthe algorithm to the protection of network man-agement data. The use of the algorithm for otherpurposes such as the protection of user data isexplicitly excluded.

TETRA – Terrestrial Trunked RadioTETRA is the new standard for digital privatemobile radio communications system. The sys-

tem has been chosen by major Public Safetyorganisations in Europe as their future mobilecommunication system, but can also be used inpublic networks. Security is a big concern inTETRA and the system includes a large numberof security features. These are supported by alarge number of standard cryptographic algo-rithms. For the moment there are four standardencryption algorithms defined for TETRA.TEA1 and TEA4 are for general use in TETRAand provide a baseline level of security. The useof TEA2 is restricted to European Public Safetyorganisations (mainly from the “Schengen”countries). TEA3 is a similar solution for useby other Public Safety organisations. All the en-cryption algorithms are dedicated stream ciphersdesigned by ETSI SAGE and their intended useis for the protection of user data and signallinginformation over the radio link.

Furthermore SAGE has specified one set ofTETRA Authentication and key managementAlgorithms (TAA1). The TAA1 is designed foruse in all TETRA systems.

UMTS – Universal Mobile Telecommuni-cations SystemThe next generation of mobile systems will beUMTS specified by the 3rd Generation Partner-ship Project (3GPP). The first set of technicalspecifications was finalised January 2000 andincludes the definition of confidentiality andintegrity algorithms. Both algorithms are basedon a standard block cipher called KASUMI.KASUMI is a modified version of the Japaneseblock cipher MISTY ([13]) which has beenavailable and publicly analysed for several years.

Due to the high-speed requirements in 3GPPsystems, it was important to design an algorithmwhich was suitable for efficient implementationand could offer a high degree of security. KA-SUMI makes full use of a 128 bits key operatingon 64 bits blocks.

The design and specifications of the standardalgorithms for UMTS were conducted by SAGEenlarged with experts from manufacturers inEurope, Asia and US. In addition to the internalevaluation and analysis of the 3GPP algorithms,three different groups of independent expertswere involved in an additional external evalua-tion. The intention is to have these specificationspublished in the same way as other technicalstandards, but all issues related to such publica-tion have not been resolved at the time ofwriting.

3) Information on AES can be found at http://www.nist.gov/aes


10 Regional Initiatives – AES and NESSIE

AES – Advanced Encryption Standard3)

In 1997 the US National Institute of Standardsand Technology (NIST) initiated a process toselect a new symmetric-key encryption algo-rithm to be used as a replacement for DES. Thecall for candidates stipulated that AES wouldspecify an unclassified, publicly disclosed algo-rithm available royalty-free, world-wide. Thealgorithm must be a block cipher supporting ablock size of 128-bits and key sizes of 128-,192- and 256-bits. In 1998 NIST announced theacceptance of fifteen candidate algorithms andrequested the assistance of the cryptographicresearch community in analysing the candidates.This analysis included an initial examination ofthe security and efficiency characteristics andthe outcome was five finalist algorithms. Thefive finalist algorithms are currently subject forfurther study before selecting one or more ofthese algorithms for inclusion in the AdvancedEncryption Standard. If all steps of the AESdevelopment process proceed as planned, it isanticipated that the standard will be completedby the summer of 2001. It seems obvious thatthe final AES algorithm(s) will be the preferredalgorithm in the years to come.

NESSIE – New European Schemes forSignatures, Integrity and Encryption4)

NESSIE is a new European 3-year project thatstarted in January 2000. It falls within the Infor-mation Societies Technology (IST) Programmeof the European Commission and includes par-ticipants from industry and the academic world.NESSIE will contribute to the final phase ofAES, but has a much wider scope. The mainobjective of the project is to put forward a port-folio of strong cryptographic primitives thathave been obtained after an open call and evalu-ated using a transparent and open process. Theseprimitives should be the building blocks for thefuture standard protocols of the informationsociety.

11 Work in ISOWithin the International Standards Organisations(ISO) there are several groups defining securitystandards. There is one sub-committee (ISO/IECJTC1/SC27) dedicated to this work, but formany years the development of internationalstandards for confidential algorithms was explic-itly excluded from their work program. This rulehas recently been changed and a new project fordevelopment of such standards is now approved.We can expect that results from the regional ini-tiatives described above will be forwarded toISO for global standardisation.

12 ConclusionsCryptographic algorithms are a fundamentalbuilding block for a variety of security services.The design of such algorithms is a long andtedious process involving a mixture of skills, andthe final solution is often a trade-off between di-vergent requirements. We have presented someof the basic principles of such algorithms andhave described the variety of standard algo-rithms that exist for different telecommunicationsystems. We argue that the development of stan-dard algorithms will benefit from the use of openand well-analysed algorithms. AES and NESSIEare examples of new initiatives intending todevelop and evaluate new and secure primitives.Future standardisation projects will then focusmore on how to embed these primitives securelyinto a system in order to achieve defined securitygoals.

References1 ISO. Information processing systems – Open

Systems Interconnection – Basic referencemodel – Part 2 : Security architecture (firsted.). International Organization for Stan-dardization, Geneva, 1989. (ISO 7498-2.)

2 Kahn, D. The Codebreakers. The Story ofSecret Writing. New York, Macmillan, 1967.

3 FIPS 46. Data Encryption Standard. FederalInformation Processing Standards Publica-tion 46, U.S. Department of Commerce/National Bureau of Standards, NationalTechnical Information Service, Springfield,Virginia 1977.

4 ISO. Information processing – Modes ofoperation for an n-bit block cipher algorithm(first ed.). International Organization forStandardization, Geneva, 1991. (ISO/IEC10116.)

5 ISO. Information processing – Security tech-niques – Data integrity mechanism using acheck function employing a block cipheralgorithm (second ed.). International Organi-zation for Standardization, Geneva, 1994.(ISO/IEC 9797.)

6 ISO. Information processing – Security tech-niques – Hash functions – Part 2 : Hashfunctions using an n-bit block cipher algo-rithm. International Organization for Stan-dardization, Geneva, 1994. (ISO/IEC 10118-3.)

4) Information about NESSIE can be found at https://www.cosic.esat.kuleuven.ac.be/nessie/


7 Beaver, D. Computing with DNA. Journalof Computational Biology, 2 (1), 1995.

8 Steane, A M, Rieffel, E G. Beyond Bits :The Future of Quantum Information Pro-cessing. IEEE Computer, 33 (1), 38–45,2000.

9 Blaze et al. Minimal Key Lengths for Sym-metric Ciphers to Provide Adequate Com-mercial Security. Counterpane (2000, June20) [online] – URL: http://www.counter-pane.com/keylength.pdf

10 Lenstra, A, Verheul, E. Selecting Crypto-graphic Key Sizes. Cryptosavvy (2000, June20) [online] – URL: http://www.crypto-savvy.com/cryptosizes.pdf

11 Electronic Frontier Foundation. CrackingDES : Secrets of Encryption Research, Wire-tap Politics, and Chip Design. Sebastopol,Calif., O’Reilly and Associates, 1998.

12 Coppersmith, D. The Data Encryption Stan-dard (DES) and its strength against attacks.IBM J. Res. Dev., 38 (3), 243–250, 1994.

13 Matsui, M. New block encryption algorithmMISTY. In: Fast Software Encryption ‘97,LNCS 1267. Biham, E (ed.). Berlin,Springer-Verlag, 1997.

21

Internet and Security – Two Contradictory Terms?It has been repeated again and again – the lackof security mechanisms on the Internet slowsdown the development of the new economy. Isit true? Hard to say, really. It is a fact that thereare no global trust mechanisms on the Internetinfrastructure, you cannot be really sure ofwhom you are talking to. The only global identi-fication mechanism is the network address, andnetwork addresses may be forged rather easily.

On the other hand, you can build as much secu-rity as you like into one specific application.You may issue usernames and passwords andeven equip your users with password calculatorsor one-time passwords to ensure strong authenti-cation between the user and your application.And you may encrypt user sessions by SSL andbuild crypto based cookie mechanisms to obtainconfidentiality and preserve session integrity.

What is the problem then? A number of issuesof course. Key lengths is one, secure storage isanother. But in my opinion, the lack of commonauthentication mechanisms is one key issue. Theconsequences differ slightly depending on whichmarket segment is addressed, the Business toBusiness (B2B) or the Business to Consumer(B2C) segment.

In the B2B segment, the relation to the customeris often established through other channels thanthe Internet. For a long time relation, you canafford a (partly) off-line registration procedureand you might take the trouble of managingusernames and passwords for all your users. So,the authentication problem can be coped with.As I see it, the problem is on the customer side.How many different passwords, userids andtokens can you possibly handle? If your dailywork involves using five or six web-based ser-vices, delivered by as many companies, youmight have to remember five or six passwords orhandle five or six password tokens. And all ofthem issued to you in the same role in the samecompany. A general authentication mechanismwould leave the user with one token, valid asauthentication mechanism on any service.

Show Me Your Public Key and I Will Tell Who You AreL I S E A R N E B E R G

A short introduction to digital certificates and some thoughts on their significance to thedigital economy.

Lise Arneberg (40) is SeniorConsultant at Telenor BusinessSystems, in the department ofe-commerce. She holds aCand.Scient. degree in Mathe-matics/Algebraic Geometry fromthe University of Oslo, 1985.She has long experience fromsecurity and cryptography re-lated issues at Alcatel (researchdepartment, telecom and de-fence communications), and atScandinavia Online (electroniccommerce).

[email protected]

The problem in the B2C segment is slightly dif-ferent because you often do business with some-one you do not know in advance. From the busi-ness perspective you may have no option but totrust that the name, address and credit card num-ber supplied are actually genuine. It is a facthowever, that Internet shops make quite an effortto check for false orders, false credit cards andfalse shipment addresses, but may still experi-ence losses or fraud.

As a consumer, you may have experienced thatit is a lot of work to remember username andpassword for a number of different Internetshops or services. It would be nice if I did nothave to. And it would also be nice if I had a wayof checking the authenticity of the service at theother end. Is this really my bank that I am talk-ing to?

Whether the need for more global authenticationmechanisms comes from practicality reasons,productivity reasons or genuine lack of trust,the answer to the authentication problem maybe digital certificates. As web-based servicesinvolves more and more valuable transactions,the issue of non-repudiation and legally validsignatures on documents arises. These servicesmay be built on top of an infrastructure basedon digital certificates.

The rest of this paper is an introduction to digitalcertificates, the infrastructure to make themfunction and some examples of use.

The General Idea of Digital CertificatesA digital certificate is really an ID card for thedigital world. As an analogy, consider an old-fashioned, paper-based ID card. What it does isreally to establish a binding between a name anda picture. If you resemble the picture I acceptthat the name belongs to you. In the same way, adigital certificate establishes a binding between aname and a cryptographic key. If you can provethat you possess that key I accept that the namebelongs to you.

Telektronikk 3.2000


In both cases, my trust depends on the issuer ofthe ID card or the digital certificate. If I recog-nise the issuer as trustworthy, the ID card has avalue. Passports and ID cards issued by banks orthe postal service are normally recognised astrustworthy anywhere. While the ones issuedby a school or an employer are not generallyaccepted outside that school or company. Thesame mechanism applies for digital IDs. If youpresent a digital certificate and I do not trust orrecognise the issuer, it would be of little valueto me.

Issuers of digital certificates are normally re-ferred to as Trusted Third Parties (TTPs). InNorway, we have currently three actors on thisscene: Bankenes Betalingssentral (BBS), PostenSDS and Telenor. All these three are companiesor institutions we are used to trusting. They areall currently running digital certificate services.

Their certificates may be designed for differentpurposes or services. For remote LAN access,for Internet banking, for security services withinan organisation, for tax reporting or for otherspecial applications. And the contents may dif-fer. But generally the content is at least:

• Name of the owner;• The public key;• Name of the issuer;• Validity period and expiry date;• The issuer’s signature.

The issuer’s signature ensures the authenticityof the certificate. If any part of the content isaltered, a signature check will reveal the fraud.And it is not possible for anybody else to issuefalse certificates, because you cannot forge sucha signature. If we use the passport analogy, theissuer’s signature is the seal of Norwegianauthorities, as well as the special paper qualitythat makes a passport so difficult to forge.

Registration and Distribution– the Key Issues for Building TrustIf you have applied for a passport lately perhapsyou remember that it is quite a tedious process.You are required to meet personally, show anID and fill in a couple of forms. To receive thepassport, you must once again meet at the policestation and show your face and an ID card toverify that you are the correct owner of the pass-port. Getting a new credit card is much easier.You simply phone and tell that the previous cardis broken. After a few days you receive a newone by mail.

These two examples represent different registra-tion procedures and different distribution proce-dures. The result is that a passport has a higher

level of trust than a credit card (at least in thesense of ID cards). Once again, the analogy canbe made to the world of digital certificates. If anauthentication process is based on cryptographickeys, how sure can you be that those keys are inthe hands of the right person? That dependspretty much on the checks performed duringregistration, as well as distribution proceduresfor the certificate and the cryptographic keys.If you have to show an ID card to apply for andreceive the certificate, this is a high level ofsecurity. If you fill in a form on the Internet andreceive the certificate by mail, the level of trustwould be low. Requirements for registration anddistribution processes is often called a certificatepolicy (CP). In a sense, the certificate policydefines the likeliness that the certificate is in theright hands.

Two different TTPs may agree to accept eachother’s digital certificates. They would do soonly if the process of registration and distribu-tion are similar and ensures the same level ofsecurity or trust. This is called cross certificationand is a formal process between to TTPs. If yourTTP accepts the certificates of my TTP and viceversa, then we can actually trust each other’scertificates. And we may check each other’s sig-natures.

And a Little Bit on theCryptographic Protocolsto Make it all WorkDigital certificates are based on public keytechniques, mostly RSA. For the slightly rustyreader, I will just repeat that an RSA key pairconsists of a modulus, a private key and a publickey. If you sign a message with your privatekey, the signature may be checked using yourpublic key. If someone encrypts a message withyour public key, only the private key can decryptthe message.

The modulus and the public key are publicknowledge. The private key must be kept secret.Key lengths these days are normally 1024 bitsbut sometimes the double. Encryption processesinvolves exponentiation modulo 1024 bits num-bers and may be time consuming.

The beauty of public key encryption is that youcan easily prove that you possess a key (the pri-vate) without exposing it.

Some definitions before we look into the authen-tication process:

• The Registration Authority (RA) receives cer-tificate applications and verifies the appli-cant’s identity according to what is specifiedin the Certificate Policy.


• The Certificate Authority (CA) issues certifi-cates and distributes them to the user.

• The CA also publishes all issued certificatesin a catalogue or directory, which is availablevia the Internet.

• When a certificate is revoked for some reason,the CA updates the Certificate Revocation List(CRL).

These are all services operated by the TTP. Theyare critical applications and are run in a physi-cally secured environment by specially autho-rised personnel.

In the world of digital certificates, when I wantto prove my identity to you, the authenticationprocess would go like this:

1. I claim my identity by sending my digital cer-tificate. Or you look up the certificate in a cer-tificate directory.

2. You check the issuer’s name. If you recognisethe name as someone you trust, you do thesignature check to verify authenticity of thecertificate. If not, you look up the directoryof your Trusted Third Party to check if thisissuer is someone he trusts (i.e. is certified byhim). If that is so, you receive the informationyou need to check the signature of my certifi-cate. If not, you reject my certificate becauseyou have no reason to trust its origin.

3. You check the revocation lists (CRLs) to seeif this certificate is still valid.

4. If all is well so far, you send me a challenge.

5. And my response is the challenge signed bymy private key.

6. You verify the signature, using the public keyof my certificate.

7. If the signature is OK, you will trust that I amthe genuine owner of the certificate and nowyou know who I am.

The reader may have noticed that the stepsabove require a bit of infrastructure. First of all,digital certificates must be issued by the CA andtransported securely to their owners. Secondly,the user must know whom to trust, i.e. (s)hemust have access to the public key (or rather thecertificate) of the trusted TTP. Thirdly, certifi-cates must be available in a directory. If the cer-tificates are general purpose IDs, this directorymust be available to the public. As some certifi-cates inevitably will get lost, stolen or corrupted,

a blacklist or revocation list must be publiclyavailable for everyone to check. And there mustbe someone who controls and updates the revo-cation lists.

There is a number of standards describing thedetails of these steps. Most important is theCCITT X.509 standard for digital certificates.Currently, version 3 of the standard is in use.The PKCS-7 standard describes how to createand verify signatures. The directory is an X.500service, and the LDAP protocol specifies theinterface to the directory. A number of PKCSprotocols describe cross certification and othercertificate exchange protocols.

On the Practical SideSuppose your Internet provider or someone elsehas equipped you with a digital certificate. Howdo you receive it, keep it and how do you get touse it without knowing the details of the proto-cols above?

Keys can be kept in SW or in a smart card. Keysin SW must be protected by encryption and youwill need a password to decrypt the keys and getaccess to cryptographic operations. In a smartcard, the keys are protected by the operating sys-tem of the card and the private key will neverleave the card. A PIN is required to open thecard for use.

The certificate issuing process may take differ-ent forms. It may be done online with the CAand with keys generated locally. In this way, theprivate key never leaves “home”. To secure thecertificate generation process, the user is firstequipped with two codes used for authentication.

The certificates may also be personalised offlinewith centralised key generation (mainly smartcards) and then shipped to the user according topolicy.

If keys are in SW, there must be a “bridge”between the application (for instance a loginscript) and the cryptographic keys. Let us callthis bridge a security module. It offers a speci-fied interface (API) of security operations to anyapplication on the PC. The application may beable to order a signature, perform the steps of anauthentication and perhaps to check the certifi-cate of the entity at the other end. The API mayalso specify a number of other services such asencryption mechanisms and exchange of encryp-tion keys. With keys in a smart card, all crypto-graphic operations may be performed at the card,and the application (or the security module) maycommunicate with the card through the smartcard reader.


A number of standard PC applications, such asmail clients and web browsers, is available todaywith plug-ins that are adapted to a specific secu-rity module. For the security module from onemajor supplier, Entrust, there is a wide range ofapplications, denoted “Entrust ready”, thatexploits the security services in their securitymodule. This is all done seamlessly to the user.The user may sign or encrypt mail, or communi-cate securely with a web service, simply byclicking icons in her regular applications.

For more specific or proprietary applications,security services must be built in by utilisingthe API of the security module.

Digital certificates can be managed or unman-aged. With a managed certificate, the securitymodule automatically communicates with theCA to handle necessary certificate updates, keybackup for encryption keys and other services.

SET – Digital Certificatesas Credit CardsThe Secure Electronic Transaction (SET) stan-dard was perhaps the first example of a commer-cial use of digital certificates. It was developedas a cooperation between VISA and Eurocard.Their goal was to establish secure credit cardtransactions on the Internet. It is an open stan-dard, based on digital certificates. It was pub-lished in 1997 and the first SET transactions inNorway were performed late 1997.

The certificate issuers or CAs of SET certificatesare the credit card companies. Both card holdersand shops will have certificates. Each credit cardcompany will define their own procedures forregistration and distribution of certificates. Thereis no cross certification between CAs, i.e. youcannot pay with a VISA credit card unless theshop (or merchant in SET terminology) has aVISA certificate too.

The payment process is based on a set of pre-defined messages between the card holder, themerchant and the acquirer payment gateway(also called payment gateway) – the interfaceto the credit card company. All messages in theprotocol are encrypted and signed. The protocolensures maximum anonymity. The merchant willonly know that the card holder is authentic andthat the amount is accepted by the credit cardcompany; she will not know the credit card num-ber of the card holder. The payment gatewaywill only know the amount and not what waspurchased. The card holder can be sure that thisis an authentic shop with a real VISA (or other)certificate and not just someone who set up afraud service.

The protocol, it seems, took into account anyexperience with practical use of credit cards,as well as exploited the new possibilities thatcame with the new technology. The best of twoworlds? Unfortunately, SET has not been a suc-cess so far, despite all its beautiful cryptography.Partly because it was early. But also because inits first implementation it had two practicalweaknesses.

The certificates were in software and had to beinstalled on your PC. (Smart card readers wereexpensive in 1997, about 7 times the pricestoday, and were out of the question.) Do youknow how to take care of a credit card residingon your PC? If it is not in your wallet, how doyou keep control of who is using it? Should it beon your home PC or on your work PC? Whathappens if your children or your cleaning ladyare not to be trusted? Now, after a few years, wehave got used to the idea of SW certificates, butpersonally I am still not sure that credit cardsshould be in SW.

The second practical weakness occurred on themerchant side. A specialised SW called a SETMerchant is required to run the SET protocol.And in 1997, the SET Merchant applicationswere so expensive that they were out of thequestion for most Internet shops. Not to mentionthe requirements for infrastructure. A SET mer-chant with its certificates is not an applicationyou would want to put on the server directlyaccessible on the Internet.

So, in spite of SET, most Internet transactionsare still paid by old fashioned credit cards.Shops add a bit of security by use of SSL toavoid sending credit card numbers as cleartexton the Internet. But they have to put a lot ofeffort in manually handling all their credit cardtransactions. To help this situation, some creditcard companies now develop further anotheroption of the SET – without card holder certifi-cates. It is called MOSET (modified SET?) andpermits on-line handling of credit card transac-tions without card holder authentication.

What About the m-Business?The “mobile Internet” is evolving just thesedays. There are two approaches to services on aGSM phone. One is the WAP – Internet brows-ing and Internet services adapted to the format ofthe cell phone screen and the bandwidth of theGSM network. The second approach is buildingexplicit services into the SIM card of a regularGSM phone. Any way, a phone is much morepersonal than a PC. It is also more quickly en-abled and services will seem more easily acces-sible than on a PC. So it should be expected that


services accessible by mobile phones will evolvequickly and offer a wide range of services.

With banking services, shopping and subscrip-tion services, the issue of authentication arisesalso in the m-world. Even though the GSM algo-rithms themselves provide some authentication,this is not automatically available to applicationsoutside the GSM systems.

However, SIM cards are smart cards and as suchideal for storage of cryptographic keys and digi-tal certificates. Telenor Mobil are planning toequip all their new GSM subscribers with alarger SIM card, containing a digital certificate,a security module and a set of applicationclients, thereby providing a new electronicworld with a “global” authentication mechanism.

Paperless Business? Digital Certificates and Legally Valid SignaturesAlthough so much business communication isdone over electronic channels, there is still nomechanism or infrastructure in place to substi-tute a legally valid, hand written signature on apaper document. What would it take to establishlegally valid signatures on a document? In sucha manner that none of the signing parties candeny that they have signed, what they havesigned and when?

The answer to the “when” is a timestamp service– a trusted party that adds the time to the signeddocument and then uses its own certificate tosign it.

The answer to the “what” part may be a publicnotary – a trusted party that stores valuable doc-uments and may verify signatures upon dispute,even after many years.

And the parties must have their digital certificates,containing keys that may be used for signing.

The issue of legally valid signatures still has notreached enough maturity to bring out the imple-mentations. This is due to legislation, but also toinfrastructure and trusted actors.

Conclusive RemarkWould it be nice to have only one digital id, onesmart card valid in all situations? With creditcards, health information, access to entrancedoors at work and whatever. I am not so sure.On the other hand, I may never have that option.So far, the structure or content of a digital cer-tificate must reflect some information about itsusage. Your certificate as an employee with acertain role in a certain organisation will be dif-ferent from your SET certificate or from the cer-

tificate on your GSM phone, which only reflectsyou as a private person. So we will probablyhave to cope with a number of digital certificates– just as we cope with a number of magneticcards. Let us just get used to the idea! And letus pray that someone invents the all-secure-PIN-storage-device – real soon now! (Based on fin-gerprint identification?)

AbbreviationsB2B Business to Business

B2C Business to Consumer

CA Certificate Authority

CCITT Comité Consultatif International Télé-phonique et Télégraphique (Now: ITU-T)

CP Certificate Policy

CRL Certificate Revocation List

GSM Global System for Mobile Communi-cations

LAN Local Area Network

LDAP Lightweight Directory Access Protocol

PKCS Public-Key Cryptography Standards

RA Registration Authority

RSA Rivest-Shamir-Adleman (algorithm)

SET Secure Electronic Transactionhttp://www.europay.com/common/Index.html

SSL Secure Sockets Layer

TTP Trusted Third Party

WAP Wireless Application Protocol

Telektronikk 3.2000

IntroductionEveryone knows it – computers are getting moreand more common. Computers are also gettingmore and more portable. At the same time theInternet has become a common place. The pro-fessional computer users demand the possibilityto work as usual independent of time and place.And why not? The technology that will makethis happen is more or less here.

However, the companies that own and controlthe computers used by these demanding usershave second thoughts. What about security? TheInternet is itself a “dangerous” place to be, andeven highly skilled personnel make mistakeswhen implementing security solutions to protectthe internal network from script kiddies or may-be even worse, from unscrupulous competitivecompanies or foreign governments. Who reallyknows what might be out there?

And now the users want to open up the internalnetwork to be accessed from the Internet. Howcould this be done in a satisfyingly secure man-ner? How should the mobility management beimplemented to allow for transparent access –both to and from the machines on the road?

This article will try to cover these issues andpropose solutions that may become the futurefoundation for secure Internet mobility in theyears to come, with a particular focus on theusers and their terminals. Only selected securitytechnologies will be covered, focusing on themobile users and their terminals.

A Mobile Wireless Networkof the FutureThe Internet has traditionally offered very poorsupport for mobility. It is of course possible tomove computers connected to the Internet fromone local area network to another, but there hasbeen no support for mobility. That is; whenmoving a computer from one LAN to another,you have to supply it with a brand new IP add-ress. From the network point of view, this isseen as a totally different computer since the IPaddress is used to identify it. Even today, somelegacy operating systems claimed to be “up todate” need to be rebooted in order to use a dif-ferent IP address.

Mobile IP is about to change this, however,allowing the computer to be moved to keep itsold IP address used for identification, and at the

same time obtain and use a new topologicallycorrect IP address. This may be achieved byusing e.g. tunneling mechanisms.

Internet mobility may be achieved without alter-ing the routers or other hosts on the Internet, theonly thing really needed is a Home Agent placedon the home network. The Home Agent isresponsible for registering the current locations(IP addresses) of mobile nodes, and forwardingpackets destined for the mobile node out to itscurrent location. Authentication is built-in inorder to make it difficult to redirect traffic tounauthorised hosts, this will help prevent some-one stealing traffic destined to the mobile nodes.

When a mobile node connects back to the homenetwork, an extension is made from the LAN tothe Mobile Node. Traffic traditionally beinginternal and restricted to the LAN only, nowends up being routed over the Internet for every-one to see. Utilising VPN technology is there-fore very important if privacy, authenticity andintegrity of the data exchanged is of any con-cern. Traditionally VPN systems have been usedfor protecting traffic between different kinds ofnetworks, but the same technology may be inte-grated directly on the mobile nodes in a net-work-to-host scenario. (Or host-to-host for thatmatter.) The technology used to achieve this istypically IPsec.

At the home network, the extension of the homenetwork towards the mobile nodes is typicallycombined with the use of firewalls. The firewallis supposed to enforce a security policy separat-ing those “inside” from those “outside” the fire-wall.

Wireless technology such as the IEEE 802.11may be used as one attractive method of access-ing the Internet or LAN IP networks. The secu-rity mechanisms in these standards are howeverlimited in flexibility, and VPN technology istherefore needed on top. WLAN technology issometimes envisioned to replace traditionalwired LAN networks, particularly in dynamicand new environments. Time and money may besaved as the need for cabling is reduced consid-erably. In future office environments, WLANtechnology may be used as a shared access tech-nology, e.g. within a large office building. Itwould be much more efficient to offer WLANaccess to all employees in different firms withinthe building, instead of having each firm imple-

Security in a Future Mobile InternetH E N N I N G W R I G H T H A N S E N A N D D O L E T A N D B E R G

Henning Wright Hansen (28) isResearch Scientist at TelenorR&D, Kjeller, where he has beenworking on aspects related toInternet security since 1996. Hisresearch interests include wideaspects of security related tocomputing, focusing on thesecurity consequences of intro-ducing Internet mobility as wellas solutions making the Interneta safer place to be for the mobileusers of the future. He is alsoinvolved in the TigerTeam acti-vities (practical security testing)at Telenor R&D.

[email protected]

Dole Tandberg (38) is ResearchScientist in the Security Group atTelenor R&D, Kjeller, where hehas been working since 1997.His research interests includesecurity in Internet and mobiledistributed systems. He is alsoinvolved in the TigerTeam acti-vities and practical securityexploits.

Background: 1982–1988 Univer-sity of Zagreb, Croatia; 1988–1996 ABB Corporate Research;4 patents holder (2 WW and 2UK); 1994 Sheffield University(UK), Largest civilian FEM-testresearch program; 1995 LondonConference “New Era Technol-ogy” paper holder.

[email protected]

26


menting its own WLAN system. Visitors mayalso be given network access through theWLAN within or nearby the office building.

However, using WLAN technology in thismanner, the concept of firewalls separatingthe “internal” from the “external” network isno longer useful. The once physically protectedinternal network is now more or less publiclyavailable. To maintain the concept of a “securedlocal area network” completely new firewalls,VPN, as well as other security mechanisms areneeded.

This article describes selected techniques neededto fulfil the security needs in such a future wire-less mobile network.

Secure Networking in the Future

Technical Solutions

Local Adaptive Firewall ServicesA commonly used technique used to protect a“private” or “internal” network from an externalnetwork such as the Internet is to implement afirewall service. Firewalls started out as simplepacket filters, capable of filtering out packetsbased on IP addresses and information containedwithin other higher level protocols, such as theTCP and UDP headers.

The simplified firewall illustrated in Figure 1accepts only inbound connections from TCPport 80, which is dedicated to HTTP traffic, andrejects other types of traffic.

While traditional “static” terminals typically areprotected from the Internet by the use of fire-walls, mobile terminals of the future are envi-sioned to roam freely, using the Internet wher-ever it is available. The firewalls on the home

network will not be able to protect those users.This is the reason why firewalls must be imple-mented locally on the mobile terminals, and notonly on the borders of the home network.

It is however not enough to install “traditional”firewalls on these mobile terminals, some re-quirements that firewalls on mobile terminalsshould meet include the following:

• They need to be configured dynamically,depending on the current location;

• They should be able to adapt themselves to thecurrent network traffic (e.g. blocking attacksdynamically);

• They need to be easily and securely remotelycontrolled by their administrator or automati-cally by a server on the corporate network;

• They need to adapt to dynamic IP addresses;

• They need to automatically adapt to the net-work interfaces currently in use (ethernet,modems/ISDN, IrDA, Bluetooth, etc.);

• They need to be integrated seamlessly andtransparently (for the user) with other applica-tions running on the mobile nodes, rejectingall network connections unless the firewallhas been properly activated;

• They need to be integrity protected as well asverifiable, ensuring that the configuration istrustworthy.

To administer these firewalls will be a challengein the future world of mobile communication.

Some of the same principles presented here arealso found in a recently published paper fromSteven M. Bellovin, Distributed Firewalls [1].

Figure 1 A simple packetfiltering firewall allowingweb surfing only

“Telnet” to an internal machine

Surfing the web´, Internet Explorer

“Ftp” to an internal machine

Request to an Intranet server


Securing Locally Stored InformationLocally stored information needs to be protectedfrom unauthorised access.

The way to properly protect locally stored infor-mation while it is not being used is to use strongcryptography, e.g. through properly encryptedfile systems. If a terminal is lost or stolen, thismay prevent unauthorised access to the informa-tion stored. It may still be a security problemthat a terminal may be lost or stolen while thelocally stored information is in use (currentlyunencrypted).

Using tamperproof hardware tokens for storingcryptographic keys that are used for accessingthe locally stored protected information will helpprotect against unauthorised access if the termi-nal is lost or stolen.

While the locally stored information is beingused, making certain parts of this informationread-only may help prevent unauthorised modi-fication. This may help prevent the installationof viruses, Trojan horses, etc. Of course, someparts of the system need to be writeable, andhence there is still a need to have mechanismsto detect and possibly remove viruses, Trojanhorses, etc.

In addition, there is a need to have file integritymechanisms installed, in order to detect all unau-thorised modifications made to the file system.

Distributed Secured StorageModern state-of-the-art solutions for communi-cation security offer excellent security for thecommunication channels using e.g. IPsec. How-ever, although the use of such technology is wellsuited to protect private or sensitive data in tran-sit, the same data is often stored without protec-tion at both ends of a secure communicationchannel.

This leaves the data vulnerable to attacks. In par-ticular, servers connected to the Internet haveproved extremely difficult to secure, and evenservers that have been properly configured andwell protected are frequently broken into.

In order to offer sufficient protection of datastored in such servers, one has to protect the dataitself, not only the communication channel. Oneway to achieve this is to use “object security”.One example of how this could be done is staticweb pages on a web-server. Instead of establish-ing a secure communication channel using e.g.SSL (Secure Socket Layer), these web-pagescould be encrypted and/or signed digitally onceand for all before being made available on the

server side. This would also reduce the load onthe server, as establishing SSL connections ismuch more processing intensive than establish-ing traditional HTTP connections.

The pages could then be downloaded using tra-ditional HTTP connections that are not consid-ered secure. However, since the object (the web-page) is itself encrypted, only the authorisedrecipients would be able to decrypt the contents.

Using PGP (Pretty Good Privacy) to encryptemail, this is what actually happens. The objectitself, and not the communication channel, issecured. The encrypted object might be de-crypted at its endpoint for use at once, but theobject originally received (encrypted) might(should) be stored securely for later use ifneeded.

There are several benefits using this approach:

• Less processing-intensive: Objects are crypto-graphically secured only once, not once perconnection (as with SSL or IPsec).

• More secure: Even if the server where theobject is stored is broken into and the objectson this server are modified or replaced, thiswill be detected since the signature is nolonger valid (content signing).

• More secure: An intruder that has managed tobreak into a server will not be able to decryptthe protected objects unless he/she is autho-rised to do so (has the necessary keys).

• More secure: It will be possible to use the net-work as a secure place for storing user infor-mation without worrying whether the server iswell enough protected or not. The networkcould be used for e.g. backing up importantdata remotely in a secure manner, if theobjects are sufficiently cryptographically pro-tected before they leave the mobile terminal.

• Cheaper: Since objects are protected in a lessCPU-intensive way, cheaper machines mightbe used.

• Cheaper: The servers need not be protected asmuch as servers that hold unencrypted sensi-tive data.

• Legal benefits: If Telenor offers a “securestorage” for e.g. backing up GSM/UMTS-tele-phone data (e.g. address books or calendars),it would only need to provide a storage space,not security services to protect the object withregard e.g. to privacy.


• Less prone to attack: Since the sensitive datais encrypted, the potential gain from attackingthese servers is reduced.

• Cheaper: The servers themselves need not bemonitored as closely as servers containingunprotected information.

• Cheaper: It is no longer that critical to up-grade the systems once new vulnerabilitieshave been discovered.

Of course, in order to prevent Denial of Serviceattacks when storing protected objects on aserver, there is still a need to secure theseservers. The point being made is that it is nolonger as crucial as for servers where unpro-tected sensitive information is being stored.

VPN Access to the Corporate NetworkThe mobile professional computer user needsto be able to connect to the corporate (home)network while being “on the road”. Whateveraccess technology used, there is a need to securethe communication channel back to the corpo-rate network. This may be achieved using theVPN technology currently being standardisedand implemented. The technology used to buildVPN networks is typically IPsec. IPsec offersencryption, authentication and integrity protec-tion services on IP packets, and may be inte-grated with future PKI and hardware token basedsecurity solutions. The user may e.g. be requiredto use their smartcard in order to gain access tothe corporate resources using the network.

The same technologies as described here may beused to secure access to home network expectedto be implemented in future homes.

The VPN technology needs to be able to adapt todifferent network interfaces as well as workingtransparently with e.g. Mobile IP.

Multiple Shared “Virtual” VPNsImplementing wireless access technologies suchas 801.11 (Wireless LAN), the security thoughtto be available in a physically protected cablebased network is no longer there. In a largeoffice building with many different companies,WLAN access may be offered as a generic net-work access service to all. On top of this“generic” network access, each company maybuild a “Virtual” shared VPN network to protectcommunication within their own defined secu-rity domain. Since unauthorised users may bereceiving this radio based communication, spe-cial care is needed to protect all communicationwithin this virtual network.

This would be a much more efficient andcheaper solution, compared to the case where

each company had to build their own corporatenetwork, WLAN or cable based. In addition, theemployees would benefit from having access tothe internal corporate network from withinWLAN reach of the office building. However,using this Virtual VPN technology combinedwith mobility, the employees could have trans-parent secure access to the corporate resourcesfrom every access point imaginable.

Currently, firewall solutions are however notwell suited to protect such a virtual network.The firewall services need to be integrated onthe terminal itself, as stated earlier in this article.

IPsec, smartcards and PKI systems are the idealsecurity technologies to be used to implementthe scenario “Multiple shared Virtual VPNs”described above.

Intrusion Detection SystemsEven though you have implemented a local fire-wall policy, have integrity checking mechanismsin place as well as updated anti-virus softwareand partially read-only system installed, thereis still a possibility that you may be exposed tosuccessful “hacking attempts”. Even though youmay not have been compromised, it is importantto detect such activities. (You should know your“enemy”.) Intrusion Detection Systems (IDS)have been designed for exactly this purpose.

There is a need for both network based and hostbased IDS. In our case, focusing on users usingmobile terminals, the network based IDS wouldbe responsible for monitoring all network inter-faces against unauthorised activities. The net-work based IDS may pass this information onthe other parts of the security system on the ter-minal, e.g. allowing dynamical modification of

Figure 2 A simple WLAN Vir-tual VPN technology combinedwith mobility

NTserver

Novellserver

Homeagent

DMZ

Securitygateway

Firewall Mobilenode

WLAN

IP ordinaryIPSEC Enc. (IP Ordinary)

MIP Enc. {IPSEC Enc. (IP Ordinary)}


the security policy as well as warning the userand maybe the home network as well. The hostbased IDS will monitor access to local resourcesin an attempt to detect unauthorised activity. Itmay, as the network based IDS warn the user aswell as his home network, and trigger a differentand stricter security policy if needed.

The mentioned countermeasures have beenenforcing a stricter security policy on the localterminal. Other countermeasures may be possi-ble, e.g. trying to track the source of the unau-thorised activity. However, one should be verycareful implementing and using such counter-measures, as there is a substantial risk of spoof-ing (e.g. falsifying the IP source address of pack-ets reaching the mobile terminal). This mayagain lead to sophisticated and hard to preventDenial of Service attacks.

PKI as the “Security Glue” of the FutureA Public Key Infrastructure (PKI) is a systemsupporting the use of public key cryptography,often combined with the authorised issuers ofpublic key certificates (also called digital certifi-cates). In a PKI system each user, being a personor a service/machine, would have at least onesuch certificate.

A public key certificate typically contains in-formation about its legal user such as the name,address, e-mail address as well as the public key.The certificate is signed by its issuer, a certifi-cate authority, in such a manner that all attemptsat modifying the information contained in thecertificate is easily discovered.

To each public key certificate there is a uniquecorresponding private key. The public key cer-tificates are part of the public domain and arepublished through large searchable databasesaccessible to everyone. The corresponding pri-vate keys are strictly personal and are at all timesexpected to be accessible by its legal user only.An ideal protected place to store such privatekeys would be tamper-proof hardware tokens,such as smartcards.

A PKI would offer a scalable security platformfor services such as e-commerce, dynamic VPNnetworking, secure messaging, non-repudiationand digital signatures. There need not be a pre-defined trust relationship between the communi-cating parts using a PKI system. As there areseveral different issuers of public key certifi-cates, there must be a trust relationship betweenthese issuers, hiding the fact that these certifi-cates are issued by different issuers from theusers (cross-certification). There may also bemany different types of specialised digital cer-tificates, according to the policy and serviceprovided.

AAA ServicesAuthentication, Authorisation and Accounting(AAA) are services needed in a mobile Internetwhere different operators want to enable e.g.chargeable roaming between the differentdomains (ISPs).

Figure 3 A simple PublicKey Infrastructure

Figure 4 A “simple” user-to-user public key crypto-graphy

CA

AuthenticatedEncrypted tunnel

Alice

IKESession

Bob

LocalNetwork

LocalNetwork

IKESessionDigital Cert.

CA

6 8

o%””x#

A - public

B - public

C - public..............................

Public DB

B - public

1

2

A - publicB - public

#4%#

B - public + A - private

Signature

Mr. A

B - publicB - private

B

A - publicA - private

A

5

B - private + A - public

Signature

Mr. B

B - publicB - private

B

A - publicA - private

A

9

EFGH

A - private

? Mr. B

BA - publicA - private

A

3

47

ABCD

A - private

? Mr. A

A

VerifiedSignatureDecrypt

Mr. A

o%””x#

#4%#

Mr. BVerifiedSignatureDecrypt


The AAA systems supporting scalable Internetmobility are currently under development by theIETF. Radius and Tacacs, the commonly usedAAA systems today, have major shortcomingswith respect to support for roaming and mobil-ity. The IETF is currently investigatingthe requirements and working on the solutionsneeded to support the future mobility servicesexpected to be offered on a future mobile Inter-net.

A PKI would be an ideal platform to build theseAAA systems upon. Having a PKI availablewould enable easier mechanisms for trust acrossdifferent security domains, allowing simplerroaming between different operators.

Use of Hardware TokensThe SIM card (smartcard) in the GSM systemhas turned out to be a successful way of achiev-ing secure user mobility.

Using a relatively tamperproof secure storageand processing device as a smartcard, accesscontrol on the terminal may be enforced in asecure manner. In particular, storing and usingprivate keys used in a Public Key Infrastructureon smartcards currently offers the best combina-tion of user mobility and security available.

Integrating the Security TechnologiesEach of the selected security technologiesdescribed in the previous section is important inorder to protect the mobile users of the future.However, the security technologies describedneed all to be co-ordinated according to adefined security policy. This policy should bedefined and managed by the security organisa-tion on the corporate network for professionalusers, and maybe as a service for its customersfrom the ISP perspective.

Take the professional corporate and mobile useron the Internet as a scenario. Let us say she hasarrived in the UK on a business trip, having leftTelenor R&D at Kjeller earlier the same day.Having arrived at the hotel in London, shedecides to connect to the Internet using theoffered WLAN connection at the hotel. Onceconnected, she establishes a VPN connectionback to Telenor R&D to read the latest mailusing a combination of Mobile IP and IPsectogether with her smartcard for authenticationpurposes. However, the security policy requiresseveral security services to be established beforethe home network accepts the VPN connection.A local firewall has to be configured properly, avirus scan has to be performed, the integrity ofimportant files and system aspects need to beverified, important security logs need to beaudited, etc.

The results of all these checks and configura-tions need to be securely reported to the homenetwork before access is granted to internalresources at the corporate network. This is actu-ally required if the home network is supposed totrust that the mobile terminal has not been com-promised. Using the currently deployed state-of-the-art security technology, users establish asecure VPN channel back to the corporate net-work based on proper authentication only, leav-ing the mobile terminal to be hacked by anyonewithout the home network ever finding out.

The challenge is however to enforce the requiredpolicy, e.g. automatically configuring and check-ing the mobile terminal as presented above.

A proper security policy may e.g. include:

• What security services are needed;

• The right order to enable the different securityservices;

• How to configure the different security ser-vices;

• How to verify that all services and checkshave been performed successfully;

• What to do if some services and/or securitychecks fail;

• What to do if attempts to compromise the cur-rent policy is discovered once the policy hasbeen successfully established;

• How to inform the right entity on the corpo-rate network about the attempt to compromisethe current policy.

Different users may have different security poli-cies defined, according to e.g. the type of ser-vices the user is authorised to access. For eachuser, there may also be different security policiesdefined reflecting the current network access.Three examples of different scenarios includeone for using dial-up connections to the corpo-rate network, a second one to be enforced whenconnecting directly to the Internet and a thirdone to be enforced if being on a physicallysecured corporate network.

The different security policies and its “enforce-ment software” need to be secured as well, mak-ing sure any attempts on modification is detectedand properly handled according to the definedsecurity policy.


The Policy Control CenterAn implementation of a policy enforcementmechanism described in the previous sectionis currently being developed at Telenor R&D,called a “Policy Control Center”. The PolicyControl Center is controlled by a secured “Pol-icy Control Center Server” located at the home/corporate network.

For communication between mobile terminalsand this server (between the Policy Control Cen-ter and the Policy Control Center Server) LDAPover SSL is currently being used with both clientand server side certificates.

The Policy Control Center Server contains dif-ferent policies for different users, as well as dif-ferent policies for different network configura-tions. When a mobile terminal is outside the cor-porate network, we enforce a stricter securitypolicy compared to the case where the mobileterminal is connected via a physically “secured”cable inside the corporate network (and behindthe corporate firewalls).

However, when introducing the concept of Mul-tiple shared virtual VPNs as described earlierwhere a physically secured cable is simply notavailable, you need to introduce a security policysimilar to the one used when connected directlyto the Internet.

The initial implementation of the Policy ControlCenter was running on Linux, where we haveinvestigated among other things the followingsecurity technologies to be integrated and usedto secure the mobile terminal:

• Local firewall service through the use of“Ipchains”. This is a rather basic packet filter-ing firewall available on Linux systems.

• A simplified network Intrusion Detection Sys-tem by a combination of “Ipchains” and “Port-Sentry” [2], allowing dynamical blocking ofunauthorised network attacks using TCP-wrappers.

• Host based Intrusion Detection Systemthrough the use of “LIDS” [3], the LinuxIntrusion Detection System.

• Integrity protection on the PCC itself as wellas on all system critical parts of the file sys-tem through the use of “LIDS” [3]. LIDSenables the strict enforcement of read-onlypolicies, making selected parts of the file sys-tem read-only or append only even for thesuperuser (root).

• VPN access through the use of “FreeS/WAN”[4], a Linux IPsec implementation.

• Disk encryption mechanisms.

All policies need to be verifiable. To verify thatthe policies defined are actually implementedcorrectly on the mobile terminal, we need tobuild our implementation upon strong crypto-graphic protection mechanisms as much as pos-sible. All software components to be used as partof the Policy Control Center need to be integrityprotected so that as many attempts as possible onmodifying and bypassing the protection mecha-nisms are discovered. Successfully bypassingof the Policy Control Center could mean that acompromised mobile terminal is able to accessthe internal corporate network.

We are currently investigating the possibility ofintegrating local information protection throughfurther use of disk encryption, incorporating theuse of smartcards and PKI systems as well as allother security mechanisms required covered ear-lier in this article, in order to achieve the bestpossible security for the future users of Internetmobility.

Our current work covers the development of apure JAVA version of the Policy Control Center,making sure that all kinds of different terminalsrunning JAVA may be secured using our PCC.Although the PCC implementation is platformindependent, the policies themselves are how-ever highly platform dependent.

Challenges currently under investigation includefor example:

• How to most efficiently and securely writeand handle the policies for different platforms;

• How to protect the Policy Control Centeritself from unauthorised modification andbypassing attempts;

• Making sure the right policy is selected auto-matically, how do you know where you are?

ConclusionsKeeping a computer system connected to theInternet secure is a challenging task even forexperienced security personnel. New software isfrequently being introduced, often with little orno concern for potential security implications,and new vulnerabilities are constantly beingfound both in old and new software. In particu-lar, without an open development model, mis-takes made before are bound to be repeated overand over again without the customers ever hav-


ing the possibility to verify the functionality ofthe software or detect potential security flaws inthe implementation themselves.

Other security mechanisms are needed to securecomputers, in particular mobile terminals roam-ing the Internet; the security focus must beshifted towards the terminals themselves. ThePolicy Control Center takes the security levelsteps ahead compared to the currently imple-mented state of the art security mechanismsavailable for mobile (as well as other) terminals.In particular, there are two aspects of the PolicyControl Center worth repeating; it is able to

• Automatically configure the mobile terminalwith respect to a predefined security policy;

• Verify the state of the mobile terminal withrespect to security before access is granted tothe internal corporate network.

When designing the actual security policies,“Defence in Depth” should be the guideline; addredundant security mechanisms – do not rely ona single protection mechanism that will be a“single point of failure” with respect to security!

The security level that may be achieved by intro-ducing a Policy Control Center however is onlyas good as the actual security policies them-selves; even with a flawless Policy ControlCenter in place, it will not be able to defendyour terminal if there is an “opening” or a flawin the actual security policies.

Coming technologies and products that intro-duce some similar concepts as our PCC includeCOPS within the IETF [5], MEXE within the3GPP [6], and PGP Desktop Security 7.0 fromPGP Security [7].

References1 Bellovin, S. Distributed Firewalls. ;login:

special issue on security, November 1999.

2 Psionic PortSentry 1.0. 2000, September 28[online]. – URL: http://www.psionic.com/abacus/portsentry/

3 Linux Intrusion Detection System. 2000,September 28 [online]. – URL: http://www.lids.org/

4 Linux FreeS/WAN. 2000, September 28[online]. – URL: http://www.freeswan.org/

5 The Internet Engineering Task Force. 2000,October 9 [online]. – URL: http://www.ietf.org/

6 3GPP. 2000, October 9 [online]. – URL:http://www.3gpp.org/

7 PGP Security. 2000, October 9 [online]. –URL: http://www.pgp.com/

Telektronikk 3.2000

1 IntroductionA mobile autonomous agent is a process that iscapable of migrating between different executionenvironments during its computation. In doingso, it may cross boundaries between differentdomains, and do parts of its computation ondifferent hosts.

EXAMPLE 1. An autonomous mobile agent could bea program which visits database hosts to searchfor data, and place orders for query results atthose sites where relevant data are found.

There also exist mobile agents that are notautonomous, which follow data, and mighteven be embedded in data.

EXAMPLE 2. Word and Excel macros embeddedin the corresponding document types are exam-ples of mobile agents that are embedded in doc-ument data, and that are supposed to lack auton-omy, although they sometimes are autonomous.

There is no inherent harm in using mobile soft-ware. As with other software, security issuesshould be satisfactorily resolved before usingmobile software. Unresolved security issues usu-ally introduce risks which are not under control.

Knowledge about how to secure systems freeof mobile agents is fairly widespread – at leastamong security professionals. What is not sowidespread is knowledge about how one securesa system properly against any ill effects causedby mobile agent systems, especially those wherethe agents supported can be autonomous. This isprimarily because such knowledge is currentlyfar from complete.

Code mobility violates several assumptionswhich are usually considered reasonable for sys-tems without code mobility. Chess lists in [2] anumber of previously reasonable assumptionsthat are violated by mobile code. Each of theseviolations gives an attacker more possibilities.

Many of the services envisioned as importantapplications of mobile agents, require the agentsto act as representatives of one identifiable legalperson. This has important implications for therequired level of security, because such actionsomehow has to be made legally valid. Such ser-vices will probably require the agent to be capa-ble of generating a valid digital signature onbehalf of its owner: the legal person sending the

agent which is also represented by the agent. Inany case some sort of signature traceable backto the agent’s owner will probably be required.

Agents acting as representatives of legal personsmay also have other requirements they must ful-fill.

EXAMPLE 3. Consider an agent that carries out atransaction on behalf of its owner. What hap-pens if a fault disrupts the transaction? Twopossibilities are:

• The agent crashes on the host platform rightafter it commits to the transaction. Becauseit crashes, it does not return to its owner toinform the owner of the transaction’s comple-tion. If the agent system has “at least once”semantics, then the owner’s system might senda new agent with the same instructions oncemore, potentially duplicating all the transac-tions that the first agent was supposed tocarry out. If the agent system has “at mostonce” semantics, then the owner’s systemmight not do anything, and get a surprisewhen the service provider sends its bill.

• The agent crashes during the transaction.Depending on the exact type of fault, and theconstruction of the agent platform itself, thehost may not be able to recover the computa-tion. In this case, the host might be able to rollback the transaction. Otherwise this is similarto the case above, with the exception that thetransaction was not completed.

The point of the above exercise is to demonstratethat fault-tolerance issues border on some secu-rity issues, and that the fault handling one selectshas an influence on what happens when thingsgo wrong. Faults may be induced by attacks(denial of service attacks, for example), so theway one handles faults is relevant not only fordependability, but also in part for the securityof mobile agent systems.

There are other issues as well. When an agententers a domain under the control of anotheroperator than the one it was sent from, thereis the question of policy compatibility:

• The agent may have defined which parts of itthe host platform may pass on to the host, andwhich are only for use within the agent plat-form. This access control pattern may or may

Mobile Agents and (In-)securityT Ø N N E S B R E K N E

Tønnes Brekne (31) is on leavefrom his position as ResearchScientist at Telenor R&D. He iscurrently a doctoral student atthe Department of Telematics atthe Norwegian University of Sci-ence and Technology in Trond-heim.

[email protected]@telenor.com

34


not be compatible with the security policywithin which the host platform operates.

• Regardless of whether data are passed on tothe host or not, the second issue after policycompatibility is the enforcement of legitimatedata usage. This has a lot in common withcopyright issues.

Policy data that an agent carries with it, maytherefore end up having a lifetime significantlylonger than the agent’s entire computation. Thisin turn implies that agent visits may entail irre-versible changes to remote security policies oraccess control structures.

Enforcing security policies is a problem that isgenerally difficult, particularly when the policiesalso say something about how data may be used,distributed, etc. There are mainly two sides ofthis problem in the mobile agent context:

• securing the host against policy violations byan agent running on the host’s agent platform;and

• securing an agent against policy violations bythe host platform on which it is running.

A lot of work has already been done on the firsthalf of this problem. Schneider recently pro-posed in [8] a mechanism that handles a class ofpolicies more sophisticated than those that canbe modeled by the classic access control matrix.The real challenge is providing the same protec-tion to the agent and its data. This appears to bea very hard problem, as the agent computation isrunning on a platform completely under the con-trol of a potential attacker. Therefore one mustassume that the attacker effectively has read andwrite access to all parts of the agent.

2 TerminologyFor the sake of brevity, the term agent will here-after refer to mobile, autonomous processes(sometimes also called mobile agents), or codefor processes embedded within data (sometimesalso called embedded agents), unless otherwiseis stated. The main practical difference betweenthe two types of processes covered by the termmobile agent is that code embedded in data mostoften is not autonomous. A platform is the envi-ronment within which an agent executes.

Denote by Ψ the set of all possible executions(terminating and non-terminating) by any singleprocess. Each element in Ψ is a string whereeach symbol represents an event, a state, or acombination of these; the type of representationis not relevant for the purposes of this article.

A process p has an associated set of possibleexecutions Ψp.

Let φ be the set of all algorithmically definableoperations. A very general model of access con-trol is an extension of the access control matrix.The normal access control matrix model consistsof a matrix of elements A[s, o], which containsthe rights subject s has to object o. An object ismerely a named data structure. A subject is anobject that happens to represent executable codeor a hardware processor of some kind. A right isa reference to an operation in φ that may beapplied to an object. Note also that s may applysome right r ∈ A[s, o] to o at any time. Thismodel may be generalized by:

• letting A[s, o] be a set of triples (r, q, c),where- r is a reference to an algorithmically

expressible operation selected from φ;

- q is a state of some sort;

- c is an algorithm that takes q as a parameterand checks if s may apply r to o; and

• requiring c to return the decision result as wellas a q' that replaces the q stored in A[s, o]prior to the access attempt.

By dropping the informal requirement of algo-rithmic expressibility, as well as allowing sub-jects to be both legal persons and automatedcomponents, the above model can accommodateboth the automated and manual parts of a system(read: both computers and people).

A subject s has a right (r, q, c) to an object oif and only if it has the legitimate authority toapply r to o under the constraints defined byc and q. A security policy can be viewed as asystem for assigning and managing rights.

An interesting model proposed by Schneider in[8] is one based on execution monitoring. In theexecution monitoring model, a security policyis defined by a predicate P operating on a setP Ψ. Since it is not practical to evaluate predi-cates on sets, another predicate P̂ is defined,which operates on the elements of each set: theexecution of a process. P̂ is necessarily at least asrestrictive as P (see [8] for details), and one saysthat a process p adheres to its security policy iffor any given execution σ, P̂ (σ) holds.

⊆


Sets definable by such predicates are also calledproperties. Sets that cannot be defined by firstorder logic are called quasi-properties for theduration of this article.

A system, or a part of it, is called secure if:

1. the operator’s risk associated with operating thesystem is bounded and under control; and/or

2. all executions adhere to the security policydefined using the risk assessment.

There exist a lot of models for access control,but until recently there was only one widespreadmechanism employed in implementations: thereference monitor. Execution monitoring can beconsidered a generalization of the referencemonitor model, where a monitor can be builtinto a process p prior to execution. This monitorobserves events, states, or a combination ofthese as they occur during p’s execution. Theseactions form a string σ which is the prefix ofsome execution ψ ∈ Ψp. If σ is such that there isno execution in Ψp ∩ P having σ as prefix, theprocess p is terminated. By definition p has vio-lated the security policy by attempting an execu-tion not in P.

3 Securing AgentsThis section lists many of the properties (andquasi-properties) one could wish from mobileagents in a security context. It outlines the chal-lenges that arise when one tries to constructagents that satisfy these properties. The chal-lenges are subdivided according to the source-based partitioning of threats given in Section 1.

Mobile agents are dependent on a host platform,which:

1. supports their computations;

2. interacts with them; and

3. supports their interaction with other “nearby”agents.

In the case of the autonomous agent in Example1, one possible platform type would be TACO-MA. In the case of the macro agent in Example2, the platform could be a Word or Excel pro-gram combined with underlying network ser-vices used to transport Word and/or Excel docu-ments between hosts.

From this starting point, threats can be parti-tioned according to their source(s):

• agents; and• agent environments.

Many of the relevant problems have been stud-ied in some depth before, either in the context ofviruses (in the sense of Cohen in [3]) or hostileapplets. The results for viruses are perhaps espe-cially interesting for agents embedded in docu-ment data, as is the case with Excel and Wordmacros, and languages like PostScript. This arti-cle, however, will not focus on the challengesthat still remain with respect to malicious soft-ware.

In the following, subsections titled “AgentAttacks” deal with attacks carried out by agentson other agents in the host platform environmentor on the host platform itself.

4 AvailabilityAvailability is of fundamental importance. Ifresources are not available to legitimate users,other security properties or quasi-properties areusually of little or no interest. For an agent plat-form at some host, availability may be associ-ated with an ability to:

• receive incoming agents, and initiate theircomputation within a reasonable amount oftime;

• supply visiting agents with the resources nec-essary for them to complete their tasks at thathost within a reasonable amount of time; and

• do limited recovery from faults, for as manytypes of faults as is cost-effectively possible.

For an agent at some platform, availability maybe associated with an ability to:

• have limited fault-tolerance in the face ofhost-induced faults;

• have some graceful mode of failure as a(hopefully) last resort, which informs thesender of the failure, and how far the compu-tation had proceeded prior to the failure.

Availability is primarily a dependability issue,but it is also security relevant. Several attacksbase themselves on causing resource outages inthe attacked system (or a component therein).Attacks of this type are usually called denial-of-service attacks. The point of causing resourceoutages may be to:

1. cause parts or all of the system to stop func-tioning and cause economic or other damage;or

2. generate a vulnerability, which can subse-quently be used to mount the “real” attack.


This subsection will concentrate primarily ondenial-of-service attacks, hereafter abbreviatedDOS.

4.1 Agent AttacksThe most obvious attacks are those originatingwith the agent itself. Agents may mount DOSattacks by:

• attempting to consume certain types of systemresources such that system performance de-grades drastically; or

• disabling system resources by changing cru-cial data in configurations or executables.

Similar attacks by viruses and Java applets orsimilar software have been studied in somedetail.

The remedies for these types of attacks areusually:

• Only allowing agents that run in interpretedlanguages, and that may only access virtualresources, thereby allowing the host system avery effective reference monitor-based controlof the agent’s actions.

• Absolute caps on system resources that maybe allocated to any single process or ownerof processes.

• Pre-emptive scheduling constructed to ensurefairness for processes with similar priorities.

• Termination of entities that do not adhere tosecurity and/or usage policies.

Apart from these methods, the host platform’s“judgement” in a very primitive sense must beemployed to filter agents assumed untrustworthyfrom agents assumed trustworthy. To do this, thedigital signing of agents has been proposed (andimplemented in some commercial browsers). Inorder for this to have the intended effect, how-ever, the signature should ideally represent a sealof approval derived from (trusted) third partycode inspection of some type. Additionally, it isnecessary to employ digital signatures that canbe traced to a real-world legal person via atrusted key repository. To the author’s knowl-edge, none of the commercial implementationssatisfy both the conditions needed for such ascheme to be effective.

4.2 Platform AttacksPlatforms may mount DOS attacks on an agentby doing one or more of the following things:

1. terminating the agent execution;

2. depriving the agent of resources necessary tocontinue execution; or

3. inducing faults in the agent execution causingit to crash or enter a deadlock.

There may be other types of DOS attacks thatplatforms can carry out against agents executingon them, but the attacks described above are rea-sonably well modeled with the failstop failuremodel. The agent can to a certain degree bemade resistant against such attacks with aslightly modified and specialized version ofthe Norwegian Army Protocol (NAP). Example3 provides some additional motivation for theintroduction of fault-tolerant behavior intoagents and their platforms. It is desirable tohave a fault-tolerant computation that executesat least once, but not more than once, neither inpart nor in whole, provided no more than f faultsoccur.

4.2.1 The Norwegian Army Protocol(NAP)

NAP represents a solution that gives limitedfault-tolerance to a mobile agent, and is pro-posed by Johansen et al. in [6]. This schemeallows an agent to detect failures and initiaterecovery actions, and can to a limited extentcope with the DOS attacks mentioned above.

NAP assumes that each host has a platformcapable of running the agent, and that platformcrashes can be detected by a well-defined setof platforms. A fail-stop failure model is thusassumed, and in addition, a bounded crash rateis assumed:

There exists a positive integer f such that forany 0 i f no more than i crashes of hosts orplatforms occur during the maximum periodof time taken by an agent to traverse i distincthosts.

In NAP a mobile agent is an ordered collectionof mobile processes.

The ith action, ai, of an agent is transformed to afault-tolerant action, which is a pair (ai, a'i) suchthat ai is a regular action, and a'i is a recoveryaction. The execution of a fault-tolerant actionsatisfies:

1. ai executes at most once, irrespective ofwhether it fails or not.

2. If ai fails, then a'i executes at least once, andexecutes without failing exactly once.

3. a'i executes only if ai fails.

≤ ≤


A failure is caused by some type of fault duringthe execution of an action. When a failure occursno earlier than action ai and prior to action ai+1,the recovery action a'i starts execution.

A simplified and slightly modified version ofNAP (hereafter called NAP') is presented here.Whereas the NAP protocol tolerates f fail-stopsduring a computation, the modified versionshould tolerate f fail-stops per action-broadcastpair.

Since a mobile agent is represented by manysimilar agents in the NAP' protocol, write ai,j forthe jth action taken by agent number i for thef + 1 agents in a single NAP' protocol execution.Similarly the recovery action for the jth actiontaken by agent number i is written a'i,j. In the fol-lowing, the head will refer to the primary pro-cess, which is doing the actual agent computa-tion. The tail consists of the remaining backupprocesses.

It is assumed that the agent execution consistsof a series of actions satisfying the followingassumptions.

1. At least one action is executed on any givenplatform.

2. An action may consist of a move to a newplatform, possibly entailing movement toa different host.

3. After each completed action, state informationis propagated to the backup processes using areliable broadcast. This state informationshould be enough for recovery if the subse-quent action fails.

4. The actions need not be specifically listed, butare given algorithmic expression.

5. Upon completing an action, reliable broadcastis immediately initiated.

The preconditions of a NAP' execution is thefollowing:

1. The degree of fault-tolerance f ≥ 1 is fixed.

2. The sender has a platform within his domaincapable of supporting (part of) a NAP' com-putation.

3. The 1 + f head and tail processes are initiatedat the sender’s platform, with the initial stateof the head distributed to all tail processes.

By convention, the head is written p0, and thetail processes are written p1, ..., pf . The platform

supporting a process pj is written Pj. Note in par-ticular that it is not necessarily the case that i j⇒ Pi Pj. Note also that Pj changes during theagent execution if the agent ever changes plat-form. A broadcast message associated with thecompletion of action i is written bi.

The NAP' execution itself is carried out by let-ting the head execute action a1,i, immediatelyfollowed by a reliable broadcast of bi to the tailprocesses containing the new state informationof the head. The head is elected to ensure thatthe broadcast is delivered to all the tail pro-cesses. The broadcast itself proceeds as theone given in [6], but with some differences.The possible outcomes of the broadcast areessentially unchanged:

1. No platform delivers bi. This happens if eitherP0 failed or if p0’s execution of action a0,isomehow failed. One of the tail processes pj

must therefore begin recovery action a'j,i.Immediately after recovery (including thenew broadcast) is completed, pj takes on p0’srole and spawns a new process pj to take itsprevious role.

2. The platform P1 delivers bi. This happens onlyif all non-faulty platforms supporting theagent have delivered bi. The head process p0may thus begin executing action a0,i+1.

3. A platform Pj delivers bi+1, but P0 does not.Thus either P0 failed or p0’s execution failedsomehow before the broadcast terminated.The Pj with the lowest j 0 such that Pj P0acts as rearguard, and executes the recoveryaction a'j,i+1. Immediately after recovery(including the new broadcast) is completed,pj takes on p0’s role and spawns a new processpj to take its previous role.

The postconditions of a NAP' execution is thefollowing:

1. The head has completed the last action a0,n.2. The last broadcast has terminated.3. The head and tail processes have terminated.

This description concentrates on the invocationof the fault-tolerance parts. The broadcast proto-col details and other details necessary for a com-plete implementation should not deviate muchfrom that described in [6].

5 ConfidentialityConfidentiality is about controlling the ability ofany given subject to extract information from anobject. Information here is taken in the widestknown sense, the information-theoretic sense.There are three basic methods controlling suchinformation extraction:

�=

�=

�= �=


1. Rendering data uninterpretable for all practicalpurposes (which is what encryption does),such that the usual transformation of data toinformation through interpretation becomespractically impossible.

2. Partitioning data into discrete units, and treat-ing the units as distinct objects in a secretsharing scheme, or more generally: an accesscontrol scheme.

3. Blocking the release of non-sensitive data Athat could reveal information about other, sen-sitive data B due to known or deducible func-tional dependencies between A and B. In prac-tice these are inference controls as those usedin statistical databases.

For platforms the techniques for implementingthese are well-known. The challenge is replicat-ing those mechanisms in mobile agents. It mightalso be of interest to replicate them for em-bedded agents.

EXAMPLE 4. An embedded agent might be con-tained in a partially encrypted document, withinstructions to only reveal the encrypted parts topre-specified platforms. This is something withtypical application to Word documents or simi-lar document formats.

5.1 Agent AttacksThe agent attacks are fairly well studied. Someways of leaking confidential information are

1. attempting unauthorized accesses of otheragents’ code/data areas;

2. installing a payload on the host computer,executable outside the platform as a “normal”process (such as word macro viruses withDOS virus payloads);

3. attempting to manipulate the platform in orderto gain access to confidential information(attacking crypto-APIs, for example); or

4. using pure information theoretic attacks todesign queries used by agents to collect datafor subsequent tracker-type attacks (see [5])on collected data, a technique which couldtypically be employed in business (or other)intelligence activities.

The first attack above is fairly effectively haltedby a virtual machine-based platform (as for Javaapplets), provided the transformation from anagent’s implementation language to the codeactually run on the platform is correct, and intro-duces no new functionality. For agents somehowrunning as native machine code, one needs hard-

ware support for controlling memory accessfrom the operating system and/or platform suchthat agents cannot exploit host-specific architec-tural information to mount attacks.

The second attack above is not necessarilyhalted by a virtual machine-based platform,although such a platform still forms a fairlyeffective defense. The reason is that if the agentis allowed to write to a file and can choose partof or all of its name, it can still attempt theinstallation of a Trojan horse.

The third attack represents the typical attackimplemented by a hostile Java applet, wherebugs in the implementation are exploited inorder to execute unauthorized actions. Defend-ing against this type of attack depends for themost part on a correct implementation that actu-ally logically isolates the agent from manipulat-ing the platform in an unauthorized manner.

The fourth attack is hard to avert. Any invest-ment spent to defend against these attacksdepends on how information is made availableto the agent.

5.2 Platform AttacksThe complementary case, where the platform isregarded as a potentially malicious entity resem-bles to a great degree the problem outlined in apaper by Anderson and Needham [1]. The hosthas effectively complete control of all plaintextdata, including the agent platform, and anyagents executing on it, along with any of theircode and data stored at the host in question.

The host can under such circumstances achieveeffortless compromise of all information, savethat which somehow is encrypted in such a formas to still be of use to the agent. This problem isa difficult one to solve. It appears to be crucialto enable mobile agents to:

1. use secrets in their data without revealingthem to the platform;

2. securely generate digital signatures; and

3. securely encrypt information extracted fromthe host platform or decrypt encrypted infor-mation meant for that platform.

Properties such as these are only possible if onecan encrypt the agent’s code without changingits properties when viewed from the outside asa process. In other words, the encrypted agentmust ideally be able to:

1. encrypt/decrypt selected inputs and/or outputs;


1. For all fi and f 'i:

f ’i (a’i , ..., a’gi) =

EK( fi(DK(a’1), ..., DK(a’gi))),

where a’1, ..., a’gi∈ S’, and K is a symmetric

encryption key.

2. For all pi and p'i:

p’i(a’1, ..., a’gi) if and only if

pi(DK(a’1), ..., DK(a’hi)).

3. For all si and s'i DK(s'i) = si.

Although this is elegant, it has an inherent weak-ness, summarized in theorem 3.1 in [5]. Inessence, it is impossible to have a secure encryp-tion function E for an algebraic system like Uwhen that system has a predicate pi inducinga total order on the constants s1, ..., sm, and itsomehow is possible to determine the encryptedversion of each constant. The following exampleis from the proof of the theorem in [5].

EXAMPLE 5. Take a plaintext system wheresi = i ∈ NN for all 1 i m. Let one function beaddition (written +), and one predicate be therelation less-than-or-equal-to (written ). Thecorresponding function applied to encrypteddata is written +', and the corresponding predi-cate is written '. If the cryptanalyst knows 1 and1', it is possible to decrypt any c' to c by doing abinary search using +', 1', and '.

5.2.2 Computing with Encrypted Functions

The privacy homomorphism is revisited in workby Sander and Tschudin [7]. They mention twopotential candidates for encrypted computation:

1. polynomials encrypted with a particular typeof privacy homomorphism; and

2. rational function composition, where onerational function is used to encrypt another.

Only the first scheme, called non-interactiveevaluation of encrypted functions, is detailed intheir work. Sander and Tschudin present a sim-ple protocol demonstrating how it could work.The protocol is as follows:

1. Alice encrypts f.

2. Alice creates a program P(E(f)) which imple-ments E(f).

3. Alice sends P(E(f)) to Bob.

Figure 1 This figure illustratesthe general principle of pri-vacy homomorphisms. Theplaintext is x, the encryptionfunction E, decryption functionD, and f is a function appliedto plaintext data. The functionf' is the counterpart of f, whenapplied to encrypted data

f`f

E

D

E(x)

f(x)

x

f`(E(x))=E(f(x))

2. interact with its environment using eitherencrypted or plaintext messages, or a com-bination of both;

3. sign certain data in complete confidentialitywhile executing on a potentially malicioushost; and

4. support encrypted Turing-universal compu-tation.

If one looks at these requirements, it shouldbecome clear that what is actually needed is theability to apply operations to encrypted data. Thisproblem was originally studied in the form of pri-vacy homomorphisms for databases. The conceptof privacy homomorphisms is a good idea, andaddresses many of the requirements above aslong as strong encryption is not a requirement.In spite of this, the concept could be central tosolving the above problem. The few subsequentapproaches in the field have to some degreebased themselves on the privacy homomorphismconcept, even if the resulting system is strictlyspeaking not a privacy homomorphism.

5.2.1 Privacy HomomorphismsLet S and S' be non-empty sets with the samecardinality. A bijection E : S → S' is the encryp-tion function, with its inverse D being the corre-sponding decryption function. Denote an alge-braic system for cleartext operations by

U = (S; f1, ..., fk; p1, ..., pl, s1, ..., sm),

where the fi:Sg

i → S are functions with arity gi,the pi are predicates with arity hi, and the si aredistinct constants in S. Denote U’s counterpartfor operation with encrypted data by:

C = (S'; f '1, ..., f 'k; p'1, ..., p'l; s'1, ..., s'm),

where each f 'i corresponds to fi, and each p'i cor-responds to pi, and each s'i corresponds to si.Thus f 'i has arity gi and p'i has arity hi.

A mapping E is called a privacy homomorphismif it satisfies the following conditions:

≤ ≤

≤

≤

≤


4. Bob executes P(E(f)) using x as argument.

5. Bob sends P(E(f))(x) to Alice.

6. Alice decrypts P(E(f))(x) to obtain f(x).

The encryption itself uses an additively homo-morphic encryption scheme on a ring ZZn.

EXAMPLE 6. An additively homomorphic schemeis presented in [7]. The encryption functionE : ZZp-1 → ZZp for a prime p is gx for plaintext x.g is a generator of ZZ /pZZ . Addition of plaintextis thus arithmetic addition, while addition ofciphertext is done using multiplication.

The plaintext function is a polynomial with coef-ficients from ZZp-1. Encryption of f is achieved byencrypting each of f’s coefficients individually.The resulting f ' is applied to plaintext data byusing so-called mixed multiplication. Mixed mul-tiplication is an operation where the productE(xy) is computed from E(x) and y directly. Notethat E(xy) = (gx)y, so E(x) must be raised to theyth power in order to compute E(xy). This can bedone using a double-and-add algorithm, whichtranslates into a square-and-multiply algorithmfor encrypted data.

The scheme in Example 6 appears to avoid theinherent weakness of privacy homomorphismsby selecting an encryption function such thatthere is no known easily computable total order-ing of the encrypted elements. Along the way,the ability to do repeated applications of thefunction on the encrypted data appears to be lost,as the result is encrypted, and Bob can onlycompute mixed-multiplication. Note in particu-lar that if Bob were able to compute multiplica-tion in the encrypted domain, he would probablybe able to decrypt the ciphertext fairly easily.The ability to do multiplication with only en-crypted elements requires knowledge of either:

1. the generator g; or

2. a method of efficiently solving the discretelogarithm problem.

Thus the second scheme trades functionality forincreased security compared with easily applica-ble privacy homomorphisms.

6 IntegrityIntegrity deals with the detection of unautho-rized operations on data in a system. Therestoration of damage after unauthorized opera-tions have occurred is usually considered a partof dependability, while the prevention of theunauthorized operations is typically taken careof by authentication and access controls.

Integrity can typically be boiled down to theunauthorized detection of modification of sys-tem objects by editing, creating, deleting, orreordering data in objects. Integrity is usuallyachieved by the inclusion of redundant informa-tion strongly dependent on the data (or systemstructure) to be protected such that attempts atunauthorized

1. modifications (or creations or deletions) ofobjects are detectable; and

2. modifications (or creations or deletions) ofthe redundant information, are detectable.

In addition to the common integrity conceptthere is also a concept of sequence integrity,where a mandatory order is imposed on other-wise individual data/messages/processes in thesystem. Such integrity is relevant for ordereddata, such as video and audio streams. It is alsorelevant for protocols being executed by anagent, its platform, or the host upon which theplatform resides.

6.1 Agent AttacksAs with confidentiality, the agent attacks arefairly well studied, and they are also very simi-lar. Most of them can be realized if the accesscontrols are not precise or not secure (as de-fined in Denning [4]). Some ways of violatingintegrity are

1. attempting unauthorized accesses of otheragents’ code/data areas;

2. unauthorized creation, modification, or dele-tion of data associated with host software(such as changing mailing lists in MS Out-look);

3. feeding the platform with misleading informa-tion or falsifications; or

4. intentionally trying to trigger race conditionsor confuse host protocol state machines bymanipulating protocol messages used in com-munication with the platform.

In addition, mobile agents may also becomemalicious if their state is corrupted during theirexecution, irrespective of whether that corrup-tion was intentional or not.

The first attack above is also halted by any effec-tive virtual machine-based platform (as for Javaapplets), under similar conditions as those men-tioned in Section 5.1. Similarly, if the agent isrunning as a native machine code process on theplatform, there must be hardware support forcontrolling memory access from the host’s oper-


ating system(s) and/or platform to enforce accessrestrictions placed on the agents.

The second attack is not necessarily halted by avirtual machine-based platform, although such aplatform can thwart a selection of direct attacks.The problem is that the agent may try to doactions allowable within its platform environ-ment, that still affect host data external to theplatform in accordance with the platform’s pol-icy, but in violation of the agent’s policy.

EXAMPLE 7. Consider a spreadsheet whichincludes an embedded agent in the form ofmacros for a computation. A virtual machineexecuting those macros might allow write opera-tions to one particular file on the host. Anattacker could exploit this by letting the originalembedded agent itself be harmless, while theoutput to the file is a spreadsheet with macrosthat make up a malicious agent. Such an agentmight subsequently be executed with the permis-sions of a local user on the host. This type ofattack is also related with the problems concern-ing legitimate usage of resources.

The third type of attack can in part be thwartedusing systematic trust management. Discerningintentionally falsified information from wronginformation given in good faith is at best verydifficult, and undecideable, as it encompassesat least one problem with inherent ambiguity(computers are generally not particularly goodat deducing intent). Farmer et al. give examplesof this type of attacks in [5].

The fourth attack is usually stopped by protocolsconstructed to take such conditions into account,or by restricting the communication of the agent(as is already done with Java applets).

6.2 Platform AttacksPlatforms can attempt to compromise theintegrity of an agent by

1. modifying data carried by the agent or in theagent’s workspace;

2. manipulating the agent’s execution; or

3. not properly protecting the agent’s workspace.

The novel attack here is the manipulation of exe-cution. Not only must the agent’s data be pro-tected, but the agent’s execution must also beprotected. Even if an agent could be executed inan encrypted form, this would still be a problem– the only difference would be that the platformwould not know what it was doing. In effect,

some sequence σ = σ1σ2 ... σn of actions mustnot be interfered with, or any interference mustbe detectable.

6.2.1 Execution TracesVigna proposes in [9] a protocol, which in com-bination with a trusted third party, enables thesender to check the execution of an agent uponcompletion. The protocol bases itself upon a sys-tem where each platform records the executiontrace of an agent from the agent’s execution onthat platform. An execution trace is a series ofpairs (n,s), where n uniquely identifies a particu-lar action in the agent, and s records changes ininternal variables as a result of the execution ofn. In a sense this is nothing more than specifyingthe format of an “action”, as mentioned earlier,so these traces can also be considered executionsin the sense mentioned in Section 2.

The protocol itself consists of messages prior to,and after, the agent’s execution which transmitdata about the agent and its execution. After anexecution, the agent’s sender should be able tocheck an execution trace Tp by using the data inTp to simulate the complete execution of theagent locally, and compare the outcome to thatprovided by the remote platform. Obviously, thischeck is only done when there is a suspicion thatthe remote platform somehow has tried to com-promise the agent’s computation.

Denote by EK(data) the symmetric encryption of“data” by encryption function E using key K.Denote by Xs(data) the “data” signed with X’sprivate key. Denote by H(data) the hash valueof “data”. Write the identity of the trusted thirdparty as T. The notation A →m B:data denotes thetransmission of message m from A to B, wheremessage m consists of “data”.

Let A be the sender of the agent in question.Denote by B1, ..., Bn the list of platforms theagent is to visit. For the initial platform, thefollowing steps initiate the protocol:

1.

2.

The field As(A, iA, tA, H(p), T ) will also be writ-ten agentA, and be referred to as the agenttoken. The contents of the messages is givenin Table 1.

Am1

→ B1 :

As(A, B1, EKA(p, SA), As(A, iA, tA, H(p), T ))

B1

m2

→ A :

B1s(B1, A, iA, H(m1), M)


Before continuing, A must examine M to see if itconstitutes an acceptance or refusal on B1’s part.If it is a refusal, the protocol is finished. If it isan acceptance, the protocol continues for the ini-tial platform as follows:

3.

4.

The contents of the messages is given in Table 2.

When all necessary verifications have beendone, B1 can begin executing the agent. Thisexecution continues until the agent requestsmigration to a new platform B2. The migrationfrom any given Bi to Bj requires a separate proto-col. Denote by T p

Bithe trace produced by the part

of the execution carried out on Bi. The migrationto the next platform Bj is initiated by the follow-ing three messages:

1.

2.

3.

The last field in the third message (M) containseither Bj’s acceptance to run the agent, or itsrefusal to run the agent. The contents of themessages are given in Table 3.

7 AuthenticityThere are two types of authenticity:

1. authenticity of origin; and2. authenticity of identity.

Authenticity of origin deals with proving or dis-proving the claimed identity of the creator ofsome data, be it art, code or something else.Authenticity of origin is a very hard problem,which might not have any good solution. Withrespect to agents, the most relevant cases proba-bly include authenticity of the origin of:

1. data carried by an agent from its sender;2. data acquired by an agent at some platform;3. an agent’s code.

It is important to note that authenticity of originis not the same as authenticity of the sender: datamay be sent without their creator having to dothe sending in person.

Authenticity of identity deals in general withproving or disproving the identity claimed bya subject. Traditionally, authenticity has beenproven using one or more independent tech-niques, and efforts have been concentrated onthe case where humans prove their identity to an(automated) subject of some sort, or where auto-mated subjects need to prove their identities toeach other as the initial step in some protocol.Within automated environments, only passivedata have been authenticated. What one effec-tively needs for agents is authentication of pro-cess instances.

Table 2 The rest of the initial-ization of the protocol for exe-cution traces, if B1 agrees toparticipate in the protocol

Message Sender Recipient Message part Explanation

m3 A B1 As( Signature generated by A

A, A’s identity

B1, B1’s identity

iA, The agent’s identifier

B1p( Encryption with B1’s public key

KA)) A’s symmetric encryption key

m4 B1 A B1s( Signature generated by B1

A A’s identity


H(m3)) Hash of message m3

Table 1 Initialization of proto-col for execution traces


m1 A B1 As( Signature generated by A

A, A’s identity

B1, B1’s identity

EKA( Encryption with A’s key KA

p, The agent’s code

SA), The agent’s initial state

As( Signature generated by A

A, A’s identity


tA, Time stamp for agent dispatch

H(p), Hash of agent’s code

T)) Identity of TTP

m2 B1 A B1s( Signature generated by B1

B1, B1’s identity

A, A’s identity


H(m1), Hash of previous message

M) B1’s reply

Am3

→ B1 :

As(A, B1, iA, B1p(KA))

B1

m4

→ A :

B1s(B1, A, iA, H(m3))

Bim→ Bj :

Bis(Bi, Bj ,agentA, H(T pBi

), H(SBi, tBi

))

Bim′

→ Bj :

Bis(KBi(p, SBi

), H(m))

Bjm′′

→ Bi :

Bjs(Bj , Bi, iA, H(m, m′), M)


7.1 Agent AttacksWithout some mechanism for ensuring authen-ticity of origin, agents may present false claimsof origin for some or all of

1. its own data;2. the data it acquires during its execution; or3. data it feeds the platform.

One method of ensuring authentication of originis to use steganography to mark the object inquestion. This can be difficult, however, forreasons mentioned in subsubsection 7.2.1.

Almost all ways of exploiting insufficientauthentication of identity are forms of masquer-ade attacks. In particular, an agent may attemptto masquerade as another agent by exploitinginsufficiently authenticated protocol messages.Ensuring this type of authentication in agentsproperly seems to require either:

• an ability to execute cryptographical primi-tives in plain view; or

• platform-supported communication with theagent’s sender.

The former “solution” runs into the problemsmentioned in Section 5.

7.2 Platform AttacksWithout proper authentication of origin, plat-forms may present false claims of origin forsome or all of

1. its own data;2. data acquired from visiting agents; or3. data fed to visiting agents.

As with the corresponding agent attacks, thiscould be based on digital watermarking tech-niques, if there are any that work with the typeof data in question.

Without proper authentication of the platform’sidentity, an agent may be exposed to any attackinvolving:

• unauthorized access of the agent’s data; or

• simulation of a transaction that was supposedto execute somewhere else, thereby “duping”the agent.

7.2.1 Watermarking and SteganographyOne suggested mechanism for authenticatingorigin, is the digital watermark. Watermarkingworks by placing information in the data onewants to mark. This information may or may notbe visible, although most efforts are directed atinvisible watermarks, as one does not want themarking to affect the data in any perceivableway. The information will typically contain theidentity of the originator/creator, along withother document-specific information of rele-vance.

Systems for invisible digital watermarks areoften based on steganographical techniques.When a digital watermark is invisible, it may be

1. only perceptually invisible; or

2. both perceptually invisible and hidden as acommunication of data.

The digital watermark can be considered a com-munication where the message is an identity ofa creator, possibly along with other information.Steganography is the art of concealing the exis-tence of a communication, so steganographicaltechniques are necessary for the second variantof invisible watermarks.

Ideally any steganographical marking used forauthentication of origin should:

1. not affect the original data such that legitimateusers perceive it as degraded;

2. withstand changes to the original data withoutbeing compromised, and becoming uninter-pretable for at least the owner; and

3. encode the identity of the originator and otherinformation in a robust manner.

Table 3 Messages for han-dling migration from one plat-form to another


m Bi Bj Bis( Signature generated by Bi

Bi, Bi’s identity

Bj, Bj’s identity

agentA, The agent token

H(T pBi

) , Hash of agent trace at Bi

H(SB1), Hash of agent state at migration

tB1) Time stamp at migration

m' Bi Bj Bis( Signature generated by Bi

KBi( Bi’s symmetric encryption key

p, The agent’s code

SBi) The agent’s state at migration

H(m)) The hash of Bi’s previous message

m'' Bi Bj Bis( Signature generated by Bi

Bj, Bj’s identity

Bi, Bi’s identity


H(m,m'), Hash of messages m and m '

M) Bj’s reply to Bi


So far so good, but this is still insufficient. Thisis only of use against the casual attacker. Inorder for such a marking to actually be of usein this context, it must also

4. withstand tailored attacks designed to destroythat particular type of marking;

5. contain enough information to beyond anyreasonable doubt separate the markings ofdifferent originators.

This is an impressive list, and any marking thatactually satisfies this list will be fairly good.There remains but one property that must besatisfied if the marking is to be of any real use:

6. The first marking must withstand all subse-quent markings satisfying properties 1 – 5subsequently applied to the data, and it mustbe possible to single out the first marking assuch – the marking applied first to the data.

This last property is not likely to be satisfied, asit depends on the first marking being affected byall subsequent markings without losing any of itsdata. To the author’s knowledge, no such systemexists. Any document with two or more stegano-graphically “strong” markings may therefore beof little or no use as evidence in any court case.Copyright cases would seem to be a relevantexample.

Even if one ignores the last property, achievingthe first five properties for most data types is initself a formidable task. The reason for this isthat steganographical techniques are notoriouslytype-dependent when it comes to their influenceon perceived data degradation.

EXAMPLE 8. Steganographic techniques that pro-vide little or no image degradation, and maywork very poorly when applied to text. Thismeans that image manipulations that pass un-noticed to the naked eye, may stand out as glar-ing errors when applied to text, and vice versa.

In addition to all this, the five first propertieswill almost always compete with the actual mes-sage for bandwidth. In particular, relativelysmall objects may be extremely difficult to pro-tect steganographically, which could rule outuse of such techniques to some degree.

Currently, steganography has not advanced farenough to sort out all the above problems. Espe-cially property 2 above demands a lot of band-width out of that which is available. Stegano-graphical techniques do, however, have a certainpromise in this area.

8 Legitimate UsageLegitimate usage concerns itself with ensuringthat an object (which may be a subject) is usedsubject to constraints imposed by that object’screator. In a sense it contains confidentialityand integrity as specialized forms of legitimateusage. In essence, legitimate usage can be con-sidered the enforcement of a security policydefined for a particular instantiation of an object,regardless of whether it is beyond the reach ofthe formal owner or not.

EXAMPLE 9. Enforcement of copyright on DVDmovies, as well as their zoning, is a matter ofenforcing legitimate usage. Whether zoningactually is a legal policy or not is anothermatter.

Example 9 illustrates the point of control fairlywell: enforcement of copyright would be possi-ble with known techniques provided the objectis kept within the boundaries of the system inwhich it was created.

This problem has many similarities with that ofconfidentiality in an agent context. It should beimmediately obvious that legitimate usage is ingeneral impossible to enforce unless some robustform of authenticity of origin exists. Unlessauthenticity of origin can be ensured, the policyrestrictions placed on an object may be circum-vented by simply changing the creator’s identity.This is the core of all problems regarding copy-right enforcement.

Since there as of today exist no known schemesfor authenticating origin based on difficult prob-lems, or problems conjectured to be difficult,such as the discrete logarithm problem, the exis-tence of such a scheme will be assumed for theremainder of this section.

Enforcing legitimate usage where objects moveout of their owner’s control, has always been aproblem. Agents only highlight the difficultieswith respect to enforcing confidentiality andintegrity. In effect, this is the problem of globalsecurity policy enforcement for objects, eventhough access control mechanisms only controlthe objects as long as they exist within their sys-tem. This problem in itself consists of the fol-lowing subproblems:

1. authentication of origin, which is assumedsolved in this section to highlight the otherproblems;

2. policy interaction;

3. mechanisms for enforcing very general typesof policy (see the generalized access matrixmodel in Section 2).


Assume some agent a carries with it a set ofobjects D, which is to be distributed to othersystems via agent platforms. Each of the objectsD has a usage policy A[⋅,D] that is to be en-forced irrespective of which domain they existin. A[⋅,D] is interpreted as: the rights for an arbi-trary subject to objects in D.

The platform can control the agent’s action byinserting execution monitoring into the agent.This enables the platform a fairly general anddetailed control of the agent’s actions.

The interesting thing is that embedded agentsmay come into their own here. Many data typesare constructed such that they effectively dependon embedded agents to be displayed and/or usedcorrectly. This means that the platform must usethe data by executing the agent. The agent effec-tively provides a service to the platform. Thus itis possible to implement a certain control ofusage by constructing an agent with executionmonitoring. This time however, the agent moni-tors the platform’s requests, and terminates if theplatform attempts a series of requests that violatethe data’s security policy.

There are two problems with this approach:

1. it requires some method of enforcing agentexecution integrity;

2. it probably requires the data to be encrypted,and thus the agent to be capable of encryptingand/or decrypting data using encrypted code.

9 ConclusionThis article has outlined some of the major chal-lenges in making agents viable as a computingparadigm in contexts where a high level of secu-rity is necessary.

Among the main challenges facing constructorsof secure mobile agent systems are:

1. enabling the secure generation of strong cryp-tographic functions by mobile agents;

2. ensuring sufficient fault-tolerance;

3. enforcing agent policies; and

4. handling policy interactions.

Work on these issues has started in earnest onlyrecently. It may be a while before one can con-clusively state whether or not mobile agents willbe sufficiently securable for applications in, forexample, electronic commerce.

References1 Anderson, R, Needham, R. Programming

Satan’s computer. In: Computer ScienceToday : Trends & Developments. vanLeeuwen, J (ed.). Lecture Notes in ComputerScience, vol. 1000. Berlin, Springer, 1995.

2 Chess, D M. Security issues in mobile codesystems. In: Mobile Agents and Security.Vigna, G (ed.). Lecture Notes in ComputerScience, vol. 1419. Berlin, Springer, 1998.

3 Cohen, F. Computer Viruses. PhD thesis.University of Southern California (USC),1985.

4 Denning, D. Cryptography and Data Secu-rity. Reading, Mass., Addison-Wesley, 1982.

5 Farmer, W M, Guttman, J D, Swarup, V.Security for mobile agents : Authenticationand state appraisal. In: Proceedings of theEuropean Symposium on Research in Com-puter SEcurity (ESORICS), number 1146 inLNCS, 118–130. Berlin, Springer, 1996.

6 Johansen, D et al. Nap : Practical fault-toler-ance for itinerant computations. In: Proceed-ings of the 19th IEEE International Confer-ence on Distributed Computing Systems(ICDCS ’99). Gouda, M G (ed.). 180–189,1999.

7 Sander, T, Tschudin, C F. Protecting mobileagents against malicious hosts. In: MobileAgents and Security, LNCS State-of-the-ArtSurvey. Vigna, G (ed.). Berlin, Springer,1998.

8 Schneider, F B. Enforceable security poli-cies. Cornell University, Ithaca, New York14853, Dept. of Computer Science, 1998.(Technical report.) (Revision of July 24,1999.)

9 Vigna, G. Cryptographic traces for mobileagents. In: Mobile Agents and Security.Vigna, G (ed.). Lecture Notes in ComputerScience, vol. 1419. Springer, 1998.

47

1 IntroductionToday’s networks change and develop on a reg-ular basis to adapt to new business situations,such as reorganisations, acquisitions, outsourc-ing, mergers, joint ventures, and strategic part-nerships, and the increasing degree to whichinternal networks are connected to the Internet.The increased complexity and openness of thenetwork thus caused makes the question of secu-rity more complicated than hitherto, and necessi-tates the development of sophisticated securitytechnologies at the interface between networksof different security domains, such as betweenIntranet and Internet or Extranet. The best wayof ensuring interface security is the use of a fire-wall.

A Firewall is a computer, router or other com-munication device that filters access to the pro-tected network [16]. Cheswick and Bellovin [6]define a firewall as a collection of componentsor a system that is placed between two networksand possesses the following properties:

• All traffic from inside to outside, and viceversa, must pass through it.

• Only authorised traffic, as defined by the localsecurity policy, is allowed to pass through it.

• The firewall itself is immune to penetration.

Such traditional network firewalls prevent un-authorised access and attacks by protecting thepoints of entry into the network. As Figure 1shows, a firewall may consist of a variety ofcomponents including host (called bastion host),router filters (or screens), and services. A gate-way is a machine or set of machines that pro-vides relay services complementing the filters.Another term illustrated in the figure is “demili-tarized zone or DMZ” [6]. This is an area or sub-network between the inside and outside net-works that is partially protected. One or moregateway machines may be located in the DMZ.Exemplifying a traditional security concept,defence-in-depth, the outside filter protects the

An Overview of Firewall Technologies*)

H A B T A M U A B I E

Figure 1 Firewall schematics

Inside FilterFilter

OutsideDemilitarized Zone (DMZ)

Internal & ExternalGateway Systems

Habtamu Abie (42) is ResearchScientist at the Norwegian Com-puting Centre. He has previouslyworked as Senior Engineer andResearch Scientist at TelenorR&D (1997– 1999) and as Sci-entific Associate and ScientificFellow at CERN in Geneva,Switzerland (1989–1993). From1994 to 1997 he also held aresearch position at ABB Corpo-rate Research and worked as aSoftware Development Engineerat Nera AS and Alcatel TelecomNorway AS. He received hisEngineering Diploma in Electri-cal Data Processing from GjøvikEngineering College (1983), andhis B.Sc. (1985) and M.Sc.degrees (1988) in Computer Sci-ence from the University of Oslo.He is also working towards hisPh.D. in Computer Science atthe Department of Informatics,University of Oslo and UNIK. Hispast and present research inter-ests encompass security for dis-tributed systems, distributedobject computing, architectureand methodology, formal meth-ods and tools, data acquisitionand control systems, hard real-time systems, and mobile andpersonal computing.

[email protected]

The increasing complexity of networks, and the need to make them more open due to thegrowing emphasis on and attractiveness of the Internet as a medium for business transac-tions, mean that networks are becoming more and more exposed to attacks, both from with-out and from within. The search is on for mechanisms and techniques for the protection ofinternal networks from such attacks. One of the protective mechanisms under serious con-sideration is the firewall. A firewall protects a network by guarding the points of entry to it.Firewalls are becoming more sophisticated by the day, and new features are constantlybeing added, so that, in spite of the criticisms made of them and developmental trendsthreatening them, they are still a powerful protective mechanism. This article provides anoverview of firewall technologies.

*) The work was carried out while the author was a Research Scientist at Telenor R&D.

Telektronikk 3.2000


gateway from attack, while the inside gatewayguards against the consequences of a compro-mised gateway [6, 9]. Depending on the situa-tion of the network concerned, there may bemultiple firewalls, multiple internal networks,VPNs, Extranets and perimeter networks. Theremay also be a variety of connection types, suchas TCP and UDP, audio or video streaming, anddownloading of applets. Different types of fire-wall configuration with extensive practicalguides can be found in [6, 4]. There are alsomany firewall products on the market from dif-ferent vendors. See [8] for an updated list ofproducts and vendors.

This article surveys the basic concept of firewalltechnology by introducing the various kinds ofapproach, their applications, limitations andthreats against them.

2 Firewalls: Basic Approachesand Limitations

Firewall technology can be used to protect net-works, by installing it strategically at a singlesecurity screen station where the private networkor the Intranet connects to the public Internet,making it easier to ensure security, audit andmonitor traffic, and trace break-in attempts.It can also be used to isolate sub-networks, inorder to provide additional layers of security(defence-in-depth) within the organisation.There are three basic approaches or services thata firewall uses to protect a network: packet fil-tering, circuit proxy, and application proxy [6,10]. Some authors [12, 9] broadly classify theseinto two kinds of approach: transport level andapplication level (by including circuit proxy inthis category).

2.1 Packet FilteringFirewalls having this function perform only verybasic operations, such as examining the packetheader, verifying the IP address, the port or both,and granting and denying access without makingany changes. Due to this simplicity of operation,they have the advantage of both speed and effi-ciency. The filtered packets may be incoming,outgoing or both, depending on the type ofrouter. An additional advantage is that they dotheir job quite independently of the user’sknowledge or assistance, i.e. they have goodtransparency. Packets can be filtered on the basisof some or all of the following criteria: sourceIP address, destination IP address, TCP/UDPsource port, and TCP/UDP destination port.A firewall of this type can block connectionsto and from specific hosts, networks and ports.They are cheap since they use software alreadyresident in the router, and provide a good levelof security since they are placed strategically atthe choke point.

2.2 Circuit proxyThe second approach is the use of what is calleda circuit proxy. The main difference between thecircuit proxy and the packet filtering firewall isthat the former is the addressee to which allcommunicators must address their packets.Assuming access has been granted, the circuitproxy replaces the original address (its own)with the address of the intended destination. Ithas the disadvantage of laying claim to the pro-cessing resources required to make changes tothe header, and the advantage of concealing theIP address of the target system.

2.3 Application ProxyThe third approach involves the use of what isknown as an application proxy. An applicationproxy is more complicated in operation than apacket filtering firewall or a circuit proxy. Theapplication proxy understands the applicationprotocol and data, and intercepts any informa-tion intended for that application. On the basisof the amount of information available to makedecisions, the application proxy can authenticateusers and judge whether any of the data couldpose a threat. The price to be paid for this morecomprehensive function is that the clients oftenhave to be reconfigured, sometimes a compli-cated process, with a consequent loss of trans-parency. Application proxies are referred to asproxy services, and the host machines runningthem as application gateways.

2.4 Packet Inspection ApproachThis approach, in contrast to the technologies sofar described, involves inspecting the contents ofpackets as wells as their headers. An inspectionfirewall carries out its inspection by using aninspection module, which understands, and cantherefore inspect, data destined for all layers(from network layer to application layer). It car-ries out its inspection by integrating all informa-tion gathered from all layers into a single inspec-tion point, and then examining it. A state-fullinspection firewall is one which also registersthe state of any connection it is handling, andacts on this information. An example of a state-full inspection firewall is the state-full packet-filtering mode in Checkpoint’s “Firewall-1” [5]or Network Associates’ Gauntlet.

Inspection firewalls can provide address transla-tion and hiding, virus scanning, Web site filter-ing, screening for key words (typically in e-mail),and context-sensitive security for complex appli-cations.

2.5 Firewall LimitationsAs pointed out in [9], “Information security pro-fessionals often find themselves working againstmisconception and popular opinions formed


from incomplete data. Some of these opinionsspring more from hope than fact, such as theidea that internal network security can be solvedsimply by deploying a firewall”. While it is truethat firewalls play an important and central rolein the maintenance of network security and anyorganisation that ignores them, does so at itsperil, they are neither the panacea of every secu-rity aspect of a network, nor the sole sufficientbulwark against intrusion. Knowing what fire-walls cannot do is as important as knowing whatthey can. The following are limitations oneshould be aware of.

• A firewall is by its nature perimeter defence,and not geared to combating the enemywithin, and consequently no useful countermeasure against a user who abuses authorisedaccess to the domain.

• A firewall is no real defence against maliciouscode problems like viruses and Trojan horses,although some are capable of scanning thecode for telltale signs.

• Configuring packet-filtering rules tends to bea complicated process in the course of whicherrors can easily occur, leading to holes in thedefence. In addition, testing the configuredrules tends to be a lengthy and difficult pro-cess due to the shortcomings of current testingtools. Normal packet-filtering routers cannotenforce some security policies simply becausethe necessary information is not available tothem.

3 Additional ImportantFeatures

Firewalls are becoming more complex andsophisticated by the day, and thus more efficientat identifying attempted intrusions and loggingthem, and automatically notifying the right peo-ple. They provide multiple layers of protectionand some cache data to improve performance,and support Virtual Private Network (VPNs),Web-based administration, authentication, etc.There is also a tendency to add non-security-related functions to the firewall such as built-inWeb servers, FTP servers, and e-mail systems,and even proxy servers for streaming audio andvideo.

We agree with those who feel that some addi-tions to firewalls make sense and are usefulwhen they enhance security, while others do notmake sense and may even be dangerous, espe-cially over time, when they represent a decreasein security and an increase in vulnerability. Forexample, to add services that increase the admin-istration load adds another potential avenue ofattack.

Content CachingWhile caching is not traditionally a function offirewalls, it is becoming an increasingly frequentand important feature. An increase in perfor-mance is achieved by caching the contents of anaccessed location with the result that subsequentrequests for access will lead to already cachedcontents being used, without it being necessaryto access the location again (except when it isnecessary to refresh).

Logging and AlertsIt is important for a firewall to log events, deter-mine their legitimacy or otherwise, and notifythe network administrator. It should be notedthat it is essential to protect the integrity of thelog, since unauthorised access to, and editingof, the log will, of course, neutralise its raisond’être. Whether the function of protecting thelog is fulfilled by the firewall itself or not, isa matter of implementation.

ManagementManagement ranges from command line tosophisticated GUI-based and secured remoteaccess. Security management and administra-tion, particularly as it applies to different fire-walls using different technologies and providedby different vendors, is a critical problem. Asmore and more security services are introducedand applied to different firewall components,properly configuring and maintaining the ser-vices consistently becomes increasingly diffi-cult. An error by an administrator in maintaininga consistent configuration of security servicescan easily lead to security vulnerability. A fire-wall should thus provide a security managementinterface that enables it to be locally or remotelymanaged in a coherent and comprehensible fash-ion.

Virtual Private Networks (VPNs)A VPN is an encrypted tunnel over the Internetor another untrusted network providing confi-dentiality and integrity of transmissions, andlogically all hosts in a VPN are in one Intranet[16]. Some firewalls include VPN capabilities(reasonable extension) to secure networks, sothat they can safely communicate in private overthe public network. They achieve this by strongauthentication and encryption of all trafficbetween them.

Adaptive FirewallsThe new trend is towards adaptive firewalls thattie filters, circuit gateways and proxies togetherin series [2]. This gives the firewall administra-tor greater control over the level of security usedfor different services or at different points in theuse of those services. He may, for example, con-figure the firewall to give priority to speed of


transfer at the expense of security when this isappropriate. The firewall will then on such occa-sions reduce security to a lower level, thus al-lowing for greater speed of transfer, and return itto its original level on completion of the transfer.

Phoenix [15] states that Adaptive Firewall Tech-nology provides fluid, self-adapting control ofnetwork access, a key to establishing an effec-tive network security policy by examining everypacket (and adapting rules “on-the-fly” based oninformation in the packet) passing through thenetwork interface.

Quality of Service (QoS)Some firewalls include QoS features that allowadministrators to control what proportion of agiven network connection is to be dedicated to agiven service. There are those who feel that QoSshould be handled by Internet routers, while oth-ers insist that this is a matter of access control,and thus should be included in the firewall.Quoting [2]: “Moreover, some vendors, notablyCheck Point, have built their QoS engine usingthe same technology that is in their firewall. Thephilosophy here seems to be, access control isaccess control.”

Policy and FirewallsThere are two levels of network policy thatdirectly influence the design, installation anduse of a firewall system: higher-level policy andlower-level policy [9]. The former is the networkservice access policy, which lays down whichservices are to be accessible to whom, and howthey are to be used. The latter is the firewalldesign policy, which describes how the firewallwill implement the network service access pol-icy, and precisely how it will take access deci-sions in accordance with it. Firewalls typicallyimplement one of two design policies. The fire-wall may permit any service not expresslydenied, or it may deny any service not expresslypermitted.

Service access policy may, for example, decreethat there shall be no access to a site from theInternet, but allow access from the site to theInternet. Alternatively, it may decree that accessfrom the Internet shall be restricted to certainselected services in the site. The latter is themore widespread of the two.

Today’s business environments are, however,dynamic. Organisations are continually changingto adapt to new circumstances brought about byreorganisations, mergers, acquisitions, etc.Therefore there are regularly new policies to beenforced, and, to remain effective, today’s fire-walls must be able to adapt to them.

4 Trends Threatening Fire-walls – and Counter Trends

4.1 Trends Threatening FirewallsCommon network denial of service attacksinclude mail bombs, ping floods, and attacksusing known software bugs, all of which arereported to be on the increase. This fact alonemeans that traditional firewalls performingpacket analysis using rules and patterns are nolonger adequate protection against network-based attacks, in addition to which, accordingto recent risk surveys [18, 17], more than halfof all breaches today are perpetrated by somelegitimate user already behind the firewall.

The traditional assumption that all inside thefirewall are friendly and all outside it potentiallyhostile, is now becoming somewhat outdated.Internet connectivity has expanded, Extranetscan allow outsiders access to areas protected byfirewalls, and some machines require greateraccess to the outside than others, which ofteninvolves a change in the internal IP address.Another threat is the use of end-to-end encryp-tion since the firewall is unable to peer throughthe encryption.

In the literature [3], some people have gone sofar as to suggest that a more adaptive approachwould be to drop firewalls altogether on thebasis that they are obsolete, or that the use ofcryptography obviates the need for them.Bellovin [3] disagrees with this view, and sodo we.

4.2 Counter Trends and ArgumentsBellovin [3] argues that firewalls are still power-ful protective mechanisms for the following rea-sons:

• Most security problems are due to buggy code– in 1998, 9 of 13 CERT advisories concernedbuffer overflows and two of the rest werecryptographic bugs – and cannot be preventedby encryption or authentication. A firewallshields most such applications from hostileconnections.

• Firewalls are also useful at protecting legacysystems. While applications that requirestrong authentication should provide theirown, there are too many older protocols andimplementations that do not. Saying thatstrong cryptography should be used is true butirrelevant. In the context of such applications,it is simply unavailable.

• More subtly, firewalls are a mechanism forpolicy control. That is, they permit a site’sadministrator to set a policy on external


access. Just as file permissions enforce aninternal security policy, a firewall can enforcean external security policy.

As already stated, we concur with the above, andcite the following additional arguments.

Cryptography notwithstanding, the use of fire-walls is deeply entrenched in a number of organ-isations and is part and parcel of their securityset up, and will continue to be so for some yearsyet. While it is true that cryptography is the heirapparent to the firewall, the number of as yetunresolved issues prevents the assembling of acomprehensive solution for securing distributedcomputing resources around Public Key Infra-structure (PKI) and encryption. In addition, theprocess of standardisation within the area of PKIis not proceeding particularly rapidly. Thus,even those organisations favouring technologiesother than firewalls will just have to bite the bul-let and live with them for the moment.

Another factor is the ongoing development ofnew features and services at present being con-tinually added to firewalls. These reduce a num-ber of the limitations listed above and increasethe firewall’s flexibility while allowing it toretain its original function unimpaired. Exam-ples, to mention but a few, that illustrate thispoint are:

• The proposal of a distributed firewall [3],using IPSEC (IP Security), a policy language,and system management tools, that preservescentral control of access policy while reducingor eliminating any dependency on topology.

• Phoenix’s Adaptive Firewall Technology [15],as noted above, provides self-adapting controlof network access, thus establishing an effec-tive network security policy by examiningevery packet and adapting rules “on-the-fly”based on information in the packet passingthrough the network interface.

• FORE Systems’ Firewall Switching Agent [7],in combination with Check Point’s Firewall-1[5], provides 20 Gbit/s of firewall switchingbandwidth while delivering wire-speed rout-ing, switching, and class-of-service delivery.

• OMG’s [14] CORBA Firewall Security [12],which brings firewalls to distributed objecttechnology and provides a standard approachby which a firewall identifies and controls theflow of IIOP (Internet Inter-ORB Protocol),which has become the de facto standard inter-operability protocol for Internet, providing“out-of-the-box” interoperation with ORBs

(Object Request Brokers), thereby increasingthe security of CORBA-based applications [1].

These trends in the development of firewallsmake them important mechanisms to ease thetransition to flexible and truly distributed secu-rity solutions, such as CORBA Security Services[13], thus sparing traditionally-minded network/firewall administrators much discomfort. Afterall, the laboratory test results described in“Super firewalls” [11] show that today’s high-end firewalls are tougher, faster, and easier touse.

5 ConclusionsNotwithstanding the limitations of firewalls andthe fact that they are neither the panacea of everysecurity aspect of a network, nor the sole suffi-cient bulwark against network intrusion, anddespite development trends that threaten them,they are still a powerful protective mechanism,and will continue to play an important and cen-tral role in the maintenance of network securityfor some years yet, and any organisation thatignores them does so at its peril.

They continue to change and develop, and newfeatures are regularly added as the need arises. Ifdevelopments follow the present trend, they willcontinue to combine configurable access controland authentication mechanisms with their tradi-tional functions, thus providing more powerfuland flexible protection for networks to makethem secure.

References1 Abie, H. CORBA Firewall Security: Increas-

ing the Security of CORBA Applications.Telektronikk, 96 (2), 2000.

2 Avolio, F M. Firewalls: Are We Asking TooMuch? http://www.crossnodes.com/icsa/perimeter.html.

3 Bellovin, S M. Distributed Firewalls. DraftPaper version, 7 July 1999.

4 Chapman, D B, Zwicky, E D. Building Inter-net Firewalls. Sebastopol, Calif., O’Reilly,1995.

5 Check Point Firewall-1, version 3.0. WhitePaper, June 1997. Checkpoint (2000, June19) [online] – URL: http://www.checkpoint.com/products/whitepapers/wp30.pdf.

6 Cheswick, W R, Bellovin, S M. Firewallsand Internet Security, Repelling the WilyHacker. Reading, Mass., Addison-Wesley,1994.


7 FORE Systems. Firewall Switching Agent.White Paper, October 1998.

8 Fulmer, C. Firewall Product Overview.(1999, December 30) [online] – URL:http://www.waterw. com/~manowar/vendor.html.

9 ICSA. ICSA Firewall Policy Guide V2.00,Security White Paper series. ICSA (1999,December 15) [online] – URL: http://www.icsa.net/services/consortia/firewalls/fwpg.shtml.

10 Moran, T. Fight Fire with Firewalls. Micro-soft Corporation (1998, July 27) [online] –URL: http://msdn. microsoft.com/work-shop/server/proxy/server 072798.asp.

11 Newman, D. Super Firewalls. Data Commu-nications, Lab Tests. (1999, May 21)[online] – URL: http://www.data.com/.

12 OMG. Joint Revised Submission, CORBA/Firewall Security+Errata. OMG Document.OMG (1998, July 6) [online] – URL:ftp://ftp.omg.org/pub/docs/orbos/98-07-03.pdf.

13 OMG. The CORBA Security Service Speci-fication (Rev. 1.2). OMG (1998, January 15)[online] – URL: ftp://ftp.omg.org/pub/docs/ptc/98-01-02.pdf.

14 OMG. The Object Management Group.(2000, June 20) [online] – URL:http://www.omg.org/.

15 Phonex Adaptive Firewall Technology,Multi-Layer Stateful Inspection. WhitePaper. Progressive Systems, Inc. (2000,June 20) [online] – URL: http:// www.progressive-systems.com.

16 Schreiner, R. CORBA Firewalls WhitePapers. TechnoSec Ltd. (1998, December15) [online] – URL: http://www. technosec.com/whitepapers/corba/fw/main.html

17 Thompson, M J. Corporate Network Secu-rity (1998, September 21) [online] – URL:http://www.thestandard.com.au/metrics/display/0,1283,750,00.html

18 Warroom Study. Security in Cyberspace :Hearings before the Permanent Subcommit-tee on Investigations of the Committee onGovernmental Affairs. United States Senate,104th Congress, 2nd Session, 1996. ISBN 0-16-053913-7. (http://www.warroomresearch.com/researchcollabor/infosecuritysurvey.htm)

53

1 IntroductionNowadays networks are subject to continualchange and modification as they are adaptedto changing circumstances and new situationsbrought about by reorganisations, acquisitions,outsourcing, mergers, joint ventures and strate-gic partnerships. In addition, networks are in-creasingly connected to the Internet. Due tothese developments, the maintenance of securityhas become a far more complicated matter thanhitherto. Common Object Request Broker Archi-tecture (CORBA) has become the de-facto stan-dard. Its extensive infrastructure supports all thefeatures required by new business situations ofthe type mentioned above, and its increasing usein open systems necessitates the development ofsophisticated security technologies at the inter-face between networks of different securitydomains such as between Intranet and Internetor Extranet. One of the best ways to ensure inter-face security is the use of a firewall.

Conventional network firewalls (see [1] for anoverview of firewall technologies) prevent un-authorised access and attacks by protecting thepoints of entry into the network. Currently, how-ever, there is no standard mechanism by which afirewall identifies and controls the flow of IIOP,since IIOP has become the de-facto standardinteroperability protocol for Internet providing“out-of-the-box” interoperation with ObjectRequest Brokers (ORBs). The Object Manage-

ment Group (OMG) [10], a non-profit consor-tium with a current membership exceeding 840organisations, whose purpose is to promote thetheory and practice of object technology in dis-tributed computing systems, is the body respon-sible for setting standards and specifications forCORBA Firewall Security. The purpose of theOMG’s CORBA Firewall Security is to providea standard approach to control IIOP trafficthrough network firewalls, allowing outsideaccess to CORBA objects, thereby increasingtheir security. This article discusses CORBAFirewall Security with the emphasis on suchissues as the specific problems associated withit, how CORBA communication can easily andsecurely be handled by firewalls, how currentfirewall techniques are used to control CORBAbased communications and their potential limita-tions, and how to overcome such potential limi-tations. It also describes various aspects of fire-wall traversal, IIOP/SSL, callbacks, desiredproxy behaviour, chaining or pass-through modefor IIOP/SSL, and CORBA interworkingthrough firewalls.

In addition, this article assesses the CORBAFirewall implementation technologies availableon the market, such as WonderWall of IONA,Inprise’s Gateway, ObjectWall of Technosec,NAI’s ORB Gateway, etc. This discussion isessential to an understanding of current trends inthe development of CORBA firewall products.

CORBA Firewall Security: Increasing theSecurity of CORBA Applications*)

H A B T A M U A B I E

Habtamu Abie (42) is ResearchScientist at the Norwegian Com-puting Centre. He has previouslyworked as Senior Engineer andResearch Scientist at TelenorR&D (1997– 1999) and as Sci-entific Associate and ScientificFellow at CERN in Geneva,Switzerland (1989–1993). From1994 to 1997 he also held aresearch position at ABB Corpo-rate Research and worked as aSoftware Development Engineerat Nera AS and Alcatel TelecomNorway AS. He received hisEngineering Diploma in Electri-cal Data Processing from GjøvikEngineering College (1983), andhis B.Sc. (1985) and M.Sc.degrees (1988) in Computer Sci-ence from the University of Oslo.He is also working towards hisPh.D. in Computer Science atthe Department of Informatics,University of Oslo and UNIK. Hispast and present research inter-ests encompass security for dis-tributed systems, distributedobject computing, architectureand methodology, formal meth-ods and tools, data acquisitionand control systems, hard real-time systems, and mobile andpersonal computing.

[email protected]

Traditional network firewalls prevent unauthorised access and attacks by protecting thepoints of entry into the network. Currently, however, there is no standard mechanism bywhich a firewall identifies and controls the flow of Internet Inter-ORB Protocol (IIOP), thathas become the de-facto standard interoperability protocol for Internet providing “out-of-the-box” interoperation with ORBs, and is based on vendor-neutral transport layer. The OMG’sintention in proposing its CORBA Firewall Security is to provide a standard approach to thecontrol of IIOP traffic through network firewalls, allowing controlled outside access toCORBA objects, thus increasing their accessibility and security. This article describes andanalyses the OMG’s CORBA Firewall Security, paying special attention to such issues asthe specific problems associated with it, how current firewall techniques are used to controlCORBA based communication, their potential limitations and how these might be overcome,and the various aspects of firewall traversal. In addition, a possible CORBA firewall applica-tion scenario is presented. Some CORBA Firewall compliant products are emerging on themarket, and this current trend in the implementation of CORBA firewall products will also bedescribed.

*) The work was carried out while the author was a Research Scientist at Telenor R&D.

Telektronikk 3.2000


2 CORBA Firewall Security– an Overview

CORBA is widely available, provides an exten-sive and mature infrastructure, and plays a cru-cial role in integrating many existing enterprises,and has thus become today’s most importantsystem integration technology for distributedapplications. The increasing use of CORBA inopen systems requires sophisticated securitytechnologies to isolate networks or sub-networksthat are in different security domains. A securitydomain here means a network or sub-networkunder common administrative control, with acommon security policy and security level. Thedomain boundary may be between Intranet andInternet or Extranet. The appropriate means toenforce security policies at the boundaries be-tween security domains are firewalls.

The aim of OMG’s CORBA firewall is toimprove accessibility to CORBA applicationservers when there is a firewall separating aserver from a client. It makes it easier to enableand control client-firewall-server communicationunder a broader range of circumstances with sig-nificantly reduced administrative burdens. Inter-operable CORBA communication is via theGeneral Inter-ORB Protocol (GIOP), which onthe Internet is implemented by IIOP (a mappingof GIOP to TCP transport). Because firewallscontrol IP networking communication, andbecause ORBs communicate via IIOP, a largepart of the activity of the CORBA Firewall isdedicated to the various operations involved inhandling IIOP traffic through a firewall [8].

The main function of the CORBA Firewall isthus to recognise an IIOP message, process it,and then allow it to pass through providing fine-grained access control. CORBA firewall tech-nology is applied to both inbound1) and out-bound2) protections. It processes requests fromobjects outside the firewall wishing to invokeoperations on objects inside the firewall, andrequests from client objects inside the firewallwishing to use CORBA-based applications out-side the firewall on the Internet or Extranet.

As already pointed out, in a CORBA environ-ment, firewalls protect objects from clientobjects in other networks or sub-networks.A firewall will either grant access from anothernetwork to a particular object or deny it. Whenit grants access, it can do so at different levelsof granularity. For example, access to selectedobjects may be granted, but not to others, and,similarly, access to selected operations within agiven object may be granted, but not to others.Firewalls have two distinct functions: inboundand outbound protections. Outbound protectioninvolves allowing authorised client objects toinitiate communication with objects outside theenclave (see below), while preventing those notauthorised to do so from doing so. Inbound pro-tection involves granting authorised outsideclient objects access to inside objects whiledenying unauthorised outside objects access.With no outbound protection, clients would beable to access any outside resource, and with noinbound protection the contents of an enclavewould be totally unprotected against the (fre-quently malicious and destructive) machinationsof the world at large.

Figure 2-1 shows the basic concept of CORBAobject invocations through firewalls in an Inter-net environment. An enclave, as shown in thefigure, is a group of CORBA objects protectedby the common firewall which controls all net-work communication between them and the out-side world. Enclaves can be nested, so that anenclave may contain other enclaves arrangedhierarchically on the basis of different accesspolicies. The figure shows a client object callingan operation on a server object in another en-clave. The client object can communicatedirectly with all objects in its own enclave,but must communicate through the firewallwith objects outside.

It should be noted that outbound protectioninvolves granting or denying inside objectsaccess to the outside world, but in most casesdoes not involve restricting which operationsthey are permitted to invoke on which outside

1) Inbound protection is used to control external access to internal resources.2) Outbound protection is used to limit the outside resources to be accessed from within the enclave.

Figure 2-1 Object invocationsthrough firewalls over theInternet

InternetClient objects

Clientenclave

Client-sidefirewall

Server objects

Server-sidefirewall

Serverenclave


objects. On the other hand, inbound protectioninvolves not only denying or granting outsideobjects access to inside objects in the enclave,but also restricting which operations they arepermitted to invoke on which inside objects.

3 Specific Problems Associ-ated with CORBA Firewalls

Unlike traditional firewalls, CORBA FirewallSecurity addresses some of the specific problemsassociated with addressing, callbacks, encryp-tion, cascading of firewalls, transparency, andintegration into security systems [8, 11].

3.1 AddressingToday’s standard firewalls with static configura-tions are not well suited for dynamic CORBAapplications because they work on the assump-tion that a client will always use a fixed, desig-nated port on the basis that a given type of serveralways listens at that particular port. An HTTPserver, for example, always listens at port 80. ACORBA server object, however, does not listenat a specific, designated port. While it is possibleto bind a CORBA object to a specific port in thecase of simple applications, this is not possiblein most cases, because CORBA applications andORBs generally use objects launched at arbitrar-ily selected ports.

Since it is not usually possible to predict whichhosts and ports will be used for inter-enclaveCORBA communication, it is difficult to config-ure firewalls in this situation. While the Interop-erable Object Reference (IOR) provided by theserver, containing host/port addressing informa-tion, is sufficient within the enclave, since nofirewalls are involved, it does not help clientobjects from outside as they are unable to reachthe server object directly. Instead of the actualaddress of the server, the client needs a proxifiedaddress, the address of the firewall. The firewallwill process the request and forward it either tothe server or to the next firewall. The address ofthe outbound firewall on the client side can beconfigured manually, but the IOR containing theaddress of the inbound firewall on the serverside must be supplied by the server.

3.2 CallbacksTraditionally in a client/server system, there is avery clear and sharp distinction between clientand server. The server accepts connections fromthe client, but not vice versa.

This is not the case in a CORBA object system,a system of communication objects. In manycases it is desirable for a CORBA object serverto contact a client object, for example, to facili-tate asynchronous information flow. This isachieved by the client creating a callback object,the reference to which, an IOR containing theaddress of the callback object’s inbound fire-wall, is passed by the client to the server. Theserver can then contact the callback objectthrough its own outbound firewall and the call-back object’s inbound firewall.

It should be noted that this is not possible wherethe client-side ORBs have been downloaded asJava applets since these applets are not permittedto accept inbound connections or to create ob-jects in the client space, and neither do they haveany knowledge of the inbound firewall.

3.3 EncryptionEncryption technology is the ideal protectiontechnology, especially for protecting communi-cation over the Internet or other insecure net-works against tapping and tampering. In CORBAcommunication, if the CORBA requests containconfidential information the use of encryption isthe only way of protecting it.

Where firewalls are involved, there are three dif-ferent patterns of encrypted connection: 1) be-tween client and server, 2) between firewall andfirewall, and 3) between client and firewall andfirewall and server. This means that CORBAfirewalls must be able to handle any combina-tion of these three patterns.

3.4 Cascading of FirewallsIn many cases an invocation of an operationpasses from client to server through more thanone firewall. Figure 3-1 shows such a situation.In the figure we see how an invocation passes

Figure 3-1 Cascading of fire-walls in nested enclaves

Internet

Department enclaveswith client objects

Companyenclave

Companyfirewall

Server objects

Server-sidefirewall

Serverenclave

Departmentfirewalls


from a client object in the enclave of a group, forexample the Research Lab, over the Internet, to aserver object in a server enclave. It passes fromthe client object to the firewall of the ResearchLab, then to the firewall of the department, thento the firewall of the organisation, then over theInternet to the server side firewall, and finally tothe server object. Such cascading presupposesthe ability of invocations to pass through a seriesof firewalls even when the latter do not use thesame technology.

3.5 TransparencyA CORBA firewall should be transparent tousers (application programmers, administratorsand end-users). Schreiner [11] has proposed atransparent firewall that allows a client object touse the normal IOR of the server object insteadof a proxified address. The client attempts toconnect to the server object as though no fire-walls were present. The firewall intercepts therequest and launches a proxy object, whichrelays the request to the server object.

In Schreiner’s opinion this will make things sim-pler for programmers and administrators since itobviates the need for proxification and will onlywork if the incoming side uses an officiallyassigned IP address. It occurs to me, however,that the use of officially assigned IP addresseswill limit the use of dynamic IP addresses. Willthe use of interceptor and smart agent technolo-gies be the trend in the development of the newgeneration of firewall technologies?

3.6 InteroperabilityAs described earlier, firewalls have two distinctduties, inbound protections that are used to con-trol external access to internal resources, andoutbound protections that are used to limit theoutside resources that should be accessed fromwithin the enclave. In order for an ORB to estab-lish a connection to an object in another ORB,outbound and inbound firewalls that need to betraversed must be known.

Information about outbound firewalls is speci-fied in the client side ORB, and informationabout inbound firewalls may also be specified inthe case of Intranet and Extranet configurations.

In general, however, the client side knows noth-ing about the server side, so that the only inter-operable way of giving the client access to theinformation about inbound firewalls is to havethis information included in the IORs providedby the server.

3.7 ManagementA CORBA firewall needs a secure interfacethrough which administrators can configure itremotely and manage security policies. Thefunctionality of this interface should permit thesecurity policy to be configured dynamically.Preferably the firewall should be auto-config-urable. Such functionalities are of paramountimportance in the dynamic world of the Internet,since closing down a site is inconvenient and canbe costly. The management functionality mustalso support key management interfaces if thefirewall is to be involved in the encryption anddecryption process as described above. CORBAfirewall management should also be integratedinto the organisation’s overall security manage-ment systems, especially into CORBA SecurityServices [9] management.

4 The OMG Firewall ProposalThe Joint Revised Submission on CORBA Fire-wall Security (submitted in response to the OMGFirewall RFP (Request for Proposal)) [8] speci-fies the use of IIOP in network firewalls for con-trolling access to CORBA-based applicationsfrom Internet, Intranet or Extranet, and specifiesand describes how inter-ORB interoperabilitythrough such firewalls can be achieved. Accord-ing to the Joint Revised Submission, firewallsare broadly speaking of two kinds (in contrast toFigure 4-1), transport level and application levelfirewalls. The former permit or deny access todifferent resources using different applicationlevel protocols on the basis of addressing infor-mation in the headers of transport packets, andthus on the basis of where things are comingfrom or going to, and not what is being accessed.The latter, on the other hand, are in additionrestricted to granting or denying access to partic-ular application level protocols, such as IIOP orHTTP, and to those resources known to theapplication protocol. Consequently, they cangrant or deny access on the basis of both add-ressing information and specific resources.

Figure 4-1 shows the operation of three differenttypes of firewall. Each type operates on the basisof information available at a specific level, app-lication level, transport level or network level.At the transport and network levels, IIOP can behandled like any other TCP/IP-based applicationprotocol. This means that well-known firewalltechniques like packet filters and transport-levelproxies can be used.

Figure 4-1 3 Levels ofdifferent firewalls

Application

Transport(IIOP/TCP)

Network (IP)

Application proxy objects(socket, request header & body)

IIOP/TCP proxy, SOCKS(socket & request header)

Packet filter(IP header)


On transmission, the message body at the appli-cation level is encoded in CDR (Common DataRepresentation). CDR then translates IDL (Inter-face Definition Language) data types into a byte-ordering independent octet string. For such anoctet string to be decoded back to IDL data type,the interface definition of the object is needed.This information, however, is not as a rule at thefirewall with the result that the firewall is unableto decode the message body. This means that anIIOP proxy cannot base filtering decisions on therequest body [11].

Since the mechanisms involved in interactionwith a firewall will vary with the type of fire-wall, it is necessary to have a precise definitionof which types of firewall are supported inCORBA if ORB interoperability is to beachieved. In this connection, the current jointrevised firewall submission proposes three typesof firewall (see below) for use in different situa-tions [8, 11], a TCP firewall for simple and staticapplications, a SOCKSv5 [16] proxy for client-side firewalls, and a GIOP application levelproxy for enforcing fine-grained security poli-cies (especially on the server-side).

4.1 TCP FirewallsA TCP Firewall is a simple firewall that operatesat the transport level, basing its access controldecisions solely on information in TCP headersand IP addresses. When a connection request isreceived on a given port of the firewall, the fire-wall establishes a connection to a particular hostand port. In the course of this process the fire-wall uses the combination of host address andport (<host, port>) to authenticate the client onthe basis of the IP address alone. Having estab-lished the connection, the firewall will allowGIOP messages to pass through uninterrupted.In other words, ORB protocols are of no signifi-cance to a TCP firewall.

A simple form of ORB interoperability throughTCP firewalls can be achieved without any mod-ifications to CORBA. TCP firewalls must bestatically configured with host/port addressinformation in order to process access requests.The server can then be configured to replace itsown host/port address with that of the firewallin its IOR for use outside the enclave. How thisis implemented varies with the situation. Onemethod is to proxify the IOR manually. Theclient thus receives an IOR containing the add-ress of the firewall rather than that of the server,and sends GIOP messages to the firewall (whichforwards them to the server) under the impres-sion that is where the server is.

Due to the tradition of TCP/IP using one port perservice, it is common practice to identify a TCPservice by the port number used for the server.

As a result, most of today’s firewalls make low-level access control decisions on the basis ofport used. Since there is no well-known “IIOPport”, this practice does not facilitate ORB inter-operability through TCP firewalls. As part of itsproposed solutions, the OMG has defined a rec-ommended “well-known IIOP port” and a “well-known IIOP/SSL port”. This will enable clientenclaves with TCP firewalls to permit access toIIOP servers by enabling access to this portthrough their firewalls.

The OMG’s firewall RFP points out that, whilethese ports are not mandatory since IIOP serverscan be set up to offer service through other ports,the ports serve as a basic guideline for server orTCP, SOCKS or GIOP proxy deployment, andmake it possible for client enclaves to identifyor filter immediately the traffic as IIOP withoutprocessing.

4.2 SOCKS FirewallsThe SOCKS [16] protocol is an open Internetstandard (IETF RFC1928) which performs net-work proxying at the transport layer, mainly onthe client-side. SOCKS creates a proxy which istransparent to either party, and which serves as adata channel between clients and servers basedon TCP or UDP. In this case a client can havecontrol over which server it wishes to connectto, in contrast to the situation when normal staticmapping of TCP connections by a TCP proxy isused. A SOCKS firewall could then reasonablybe referred to as a “dynamic TCP proxy”.

SOCKS consists of a SOCKS proxy server onthe firewall and a client-side library. In the clientprogram the normal network calls of the socket-interface have to be replaced by the correspond-ing calls of this SOCKS library, and the processis called ‘socksification’. The server is un-changed. The socksified client calls the corre-sponding functions of the SOCKS library. TheseSOCKS functions communicate transparentlywith the client and server over the SOCKS proxyserver on the firewall.

Figure 4-2 shows a typical scenario of a clientcommunicating with an application serverthrough a SOCKS firewall. There are six phasesto the communication process: In the first, theclient authenticates itself to the SOCKS proxyserver, and if successful, the process proceeds to

Figure 4-2 SOCKS proxyfirewall traversal scenario

Client application

linked with

SOCKS client

library

SOCKS proxy

server

Relay data

Application

server

1

2

3

5

4

6


phase two, in which the client requests a connec-tion to an application server. In the third phase,the SOCKS proxy grants the client’s requestand, in the fourth, creates a connection to theapplication server. In phases five and six clientand server exchange data transparently over theSOCKS proxy. In practice the SOCKS proxy isrelaying data between them. From the server’spoint of view, the SOCKS proxy server is theclient, and from the client’s point of view, it isthe server. SOCKS also supports authenticatedtraversal of multiple SOCKS proxy servers.

SOCKS supports strong authentication of clientsusing GSS-API compliant security mechanismssuch as User/Password, Kerberos, SESAME[15], or SSL [17]. The client and SOCKS servercan enter into an authentication-method-specificsub-negotiation. If SSL is deployed, the client’scertificates can be passed through the connec-tions to allow the SOCKS server and the appli-cation server to authenticate the client directly.A SOCKS proxy can base transparent accesscontrol on both IP address information and userinformation stored in its server’s and the client’sconfiguration files.

From the perspective of SOCKS, IIOP is simplyan example of a TCP-based application protocol.Thus, SOCKS is already capable of serving as aproxy mechanism for IIOP, enabling IIOP trafficto traverse firewalls. So, to handle the simplecase of a CORBA client invoking an operationon a CORBA object across a firewall (a specialcase of Figure 4-2), the only requirements arethat the CORBA client must be linked with aSOCKSified TCP library (that provides an iden-tical API for sending TCP/UDP traffic and re-implements these functions to interact with aSOCKS firewall), and that the firewall must sup-port SOCKS (which most existing firewalls do).An additional change is that the client host mustbe configured to route SOCKS requests to theappropriate proxy server. This is controlled bythe client-side configuration file [8].

The information on the security provided bySOCKS firewalls, gleaned from recent researchand experiment [13], is as follows: “As a serverside firewall, it doesn’t protect the server ORBfrom malicious traffic in the TCP octet stream,and doesn’t allow a fine-grained enforcement ofsecurity. These can both be added to the SOCKSserver, but today’s SOCKS doesn’t support it.On the client side an outbound firewall normallydoesn’t need this feature, so this would be a rea-sonable application of the SOCKS firewall.”

4.3 GIOP Proxy FirewallsThe two firewall techniques described abovework on the transport level with no knowledge

of the content of the TCP connection betweenthe client and server (with the reservation thatSOCKS can be extended to act as an applicationlevel firewall). Neither of them is able to checkwhether the content of the TCP stream is validIIOP. Hence, neither of them provides any realdefence against the malicious client or allowsfine-grained enforcement of security policies.

A GIOP Proxy is an application level firewallthat understands GIOP messages and the specifictransport level Inter-ORB Protocol supported(i.e. a TCP GIOP Proxy understands IIOP mes-sages). A GIOP Proxy Object is a fully-fledgedCORBA Object which provides operations forfirewall navigation. Note that this CORBAObject does not require a full ORB to be imple-mented in the firewall, as long as it behaves in away that is consistent with the semantics of aCORBA Object, and understands the GIOP pro-tocol and a transport mapping (such as IIOP) [8].

A GIOP Proxy firewall relays GIOP messagesbetween clients and server objects. A GIOPmessage consists of a GIOP header, a messageheader and a message body. The messageheader, which is important for the GIOP proxy,contains the operation to be called, the objectkey to identify the target object, and the request-ing client. The GIOP proxy makes access controldecisions or fine-grained filtering decisionsbased on the information in the message header.For example, it could block requests to an objectwith a particular object key, or it could blockrequests for a particular operation on a specificobject.

To establish a connection to a server, a clientestablishes a connection to the GIOP proxy.

If the GIOP Proxy is an outbound one, the ORBshould be configured manually with the IOR ofthe proxy object. If the GIOP Proxy is an in-bound one, the IOR provided by server to theclient should contain the IOR of the proxy objecton the firewall. The server places this informa-tion in a tagged component, which it thenincludes in the IOR it provides.

The GIOP proxy first authenticates the client,and then, if successful, connects to the server.Now the client sends a GIOP message to theproxy. The proxy examines this message to seewhether it conforms to the security policy, and,if it does, sends it on to the server object. Theproxy can, in addition, log the request and thecommunication if this is desired.

4.3.1 Connection StylesThere are two styles of connection througha GIOP Proxy: normal and passthrough.


• A Normal connection is one in which theclient connects to the firewall, which in turnconnects to the server. The client perceives thefirewall as the server, and the server perceivesthe firewall as the client, neither being awarethat it is connected to a mediator. It is the fire-wall’s job to ensure that both the connectionsare correctly maintained, and to raise the rightexception and inform the client in the event ofa request being blocked or denied.

A GIOP proxy in this mode can examine theGIOP message and do fine-grained filtering asmentioned above. This gives rise to two secu-rity issues. Firstly, the client may not trust aGIOP proxy, and hence would not want theproxy to examine the traffic. Secondly, theclient and server may be using a particularauthentication and/or encryption mechanismthat is unknown to the proxy. Both of theseproblems can be solved by the concept of apassthrough connection.

• A Passthrough connection is one in whichthe GIOP proxy does not terminate the con-nection at the GIOP level. The differencebetween a TCP proxy and a GIOP proxy oper-ating in this mode is that the latter providessecurity enforcement at the CORBA objectlevel rather than at the transport level. Likethe former, it simply forwards GIOP messageswithout processing or examining them, orraising exceptions, once the connection hasbeen established.

The passthrough mode is mainly used forencrypted communication.

An OMG compliant GIOP proxy has to supportboth normal and passthrough connections, butmay reject the latter if the security policy dic-tates so.

4.3.2 CallbacksThe OMG firewall RFP also proposes two solu-tions for handling callbacks over a GIOP fire-wall: Bi-directional GIOP and GIOP Proxyobject.

The proposed Bi-directional GIOP solution in-volves allowing a server to reuse a client’s con-nection to send GIOP request messages. This isa very simple approach because if the client cancontact the server, callbacks are possible withoutfurther measures on the client side and onlyworks if the server object and the object makingthe callback to the client are on the same host.

The second proposed solution, more generic andsecure than the first, involves the use of a GIOP

Proxy object at the client side too, making acallback similar to a normal request (but in theopposite direction) from the server to the client,allowing security enforcement at the client side.

4.3.3 IIOP/SSLThe standard protocol in use today for the en-cryption of requests sent over the Internet isSSL. SSL supports strong authentication basedon asymmetric cryptography and standard X.509certificates, while symmetric encryption is usedon the IIOP message itself. ORB interoperabilityis frequently based on IIOP/SSL. Therefore,GIOP Proxy firewalls that forward IIOP requestsmust support the use of SSL as a transport mech-anism for secure invocations, and the proxyadministrator must have an interface to theproxy in order to be able to specify differentlevels of access control for different users, clientobjects and target objects. The proxy shouldinclude client and server side authentication forproxified connections, access to client and serverX.509 certificates, and access control to proxies.

For proxy firewalls to support the use of SSL anumber of requirements must be met. The first isthat the certificate of the client must be accessi-ble at each link in the proxy chain, and at theserver. The second is that each (inbound) proxyin the chain must be able to impose its ownaccess policy on the traffic passing through it.The third is that Certificate Authorities (CAs)must be known to both parties and trusted bythem. In addition, either the certificate policiesat both sides must be compatible, or it must bepossible for the parties to negotiate a commoncertificate policy acceptable to both.

Proxies that support the use of SSL fall into twocategories: trusted and untrusted.

An untrusted proxy can forward a message froma client by pass-through connection. This meansthat the proxy has no access to the encryptedmessage. While this ensures the integrity of thecommunication between client and server(which is necessary when one or both of theobjects are sceptical of the proxy), it gives theproxy little scope for access control, since it isunable to apply its access control list fully.

A trusted proxy, on the other hand, can, in addi-tion to forwarding messages using this samepass-through mechanism, also forward messagesby establishing a separate connection to theserver. This enables a trusted proxy to apply fullaccess control, which means that when a trustedproxy is used, access control can be applied atthe server, or at the proxy on a per operationbasis.


5 CORBA Firewall Traversal

5.1 Firewall Tag ComponentsIn a CORBA-based system, client objects connectto server objects by using an IOR. An IOR con-tains the address of the target object, such as ahost/port pair. For an object to be able to passthrough firewalls, the IOR must contain accessinformation for these inbound firewalls. In a situ-ation where there are multiple enclaves, i.e. cas-caded firewalls, it may be necessary for the IORto contain access information for all the firewallsto be traversed, although, according to the OMG’sfirewall RFP, it is strictly speaking only necessaryfor the IOR to contain access information for thefirst inbound firewall to be encountered by theobject, i.e. the outermost inbound firewall.

The TAG_FIREWALL_TRANS component,contained in an IOR, designates a single point ofentry into the network of the target object, andmay appear several times, once, or not at all inan IOR. The presence of multiple firewall com-ponents in an IOR indicates that there are multi-ple points of entry into the target’s network,through any one of which the client can reach thetarget object. The TAG_FIREWALL_TRANScomponent is encoded as an encapsulatedsequence of FirewallMechanism structures.This sequence is important since it describesthe chain of known inbound firewalls to be tra-versed, and therefore dictates the order in whichthey must be traversed. Each firewall mecha-nism in the sequence contains a FirewallPro-fileId and a sequence of firewall profile data.The latter contains information about the typeof firewall supported. The OMG’s firewall RFPcurrently defines three types of firewall, TCP,SOCKS and GIOP proxy.

5.2 Firewall Traversal AlgorithmCORBA Firewall Traversal enables CORBAobjects to communicate with each other acrossdifferent security domains and different combi-nations of different types of firewall, and henceachieves ORB interoperability through firewalls.Since each type of firewall has its own specificmechanisms for allowing connections through it,it is necessary to be acquainted with these mech-anisms, and to know how firewalls of differenttypes work in combination. The rules necessaryfor the traversal of any combination of the abovementioned types of firewall are laid down in theOMG’s firewall RFP [8].

A client object will determine whether it needsto traverse a firewall in order to call a targetobject, and will do this by examining the IOR itis assumed to possess. If the client object is inthe same domain as the target object it wishes tocall, it can make a direct invocation. If the twoobjects are not in the same domain, this is not

possible. If the client object has in its configura-tion information about an outbound firewall tobe traversed, it will send the request to that fire-wall. In the absence of such information itchooses the first FirewallMechanism in theTAG_FIREWALL_TRANS field of any fire-wall component in the IOR.

Having determined which is the first firewallto be traversed, the behaviour the client objectexhibits will be dependent upon the type of fire-wall involved. For further information on thetraversal algorithm for each of the three OMGcompliant types of firewall, see [8].

5.3 HTTP TunnellingHTTP tunnelling is a mechanism for traversingclient-side firewalls [4] by encapsulating IIOPpackets in HTTP. In the Web environment fire-walls are normally configured to pass HTTPtraffic, and to block the passage of messagesusing other protocols, including IIOP. One wayof allowing an IIOP message to pass through afirewall not configured to pass IIOP traffic, isto encapsulate, or tunnel, the IIOP message inHTTP. This makes possible communicationbetween CORBA objects through the firewallwithout any reconfiguration of the firewall.

The client ORB encapsulates the IIOP request inHTTP (encodes it into HTTP), which allows it topass through the HTTP proxy at the client sidefirewall. At the server side there is an HTTP-to-IIOP-gateway which decodes the request fromHTTP to IIOP, and forwards it to the targetobject. When the target object replies, the gate-way encodes it into HTTP and sends it back tothe client [11].

There are, of course, additional processing over-heads associated with this technique due to theencoding of the IIOP message into HTTP, andthe decoding of the HTTP message into IIOP.An additional disadvantage is that it does notsupport callbacks.

6 CORBA Firewall ApplicationOne of the benefits of CORBA is the ease withwhich it is able to integrate with legacy systemsthrough object wrappers which define object-ori-ented interfaces for legacy applications to enablethem to interoperate with other objects in a dis-tributed object computing environment. Thismeans that a CORBA firewall can enable legacysystems behind the firewall of an enterprise tointeract safely with application objects running onsystems outside the firewall. For example, userson the Web can access services of objects that arepart of the internal system of an enterprise, and anexternal third party can access objects for the pur-pose of remotely monitoring and controlling theiractivity on behalf of the enterprise.


One of the most important characteristics ofCORBA is its wide availability and its provisionof an extensive and mature infrastructure, whichenables it to play the crucial role it does in theintegration of distributed systems. CORBA fire-walls can therefore fulfil the function of enforc-ing different security policies at the boundariesbetween integrated domains.

Figure 6-1 shows a situation in which four dif-ferent organisations engaging in joint researchactivities communicate over the Internet usingCORBA firewalls. Companies B, C and D usecascaded firewall access, which enables them toenforce different access policies for differentdepartments, while company A uses single fire-wall access for its server objects, allowing it toenforce access policy at only one single point ofentry for the entire company. This means thatthe research department, for example, of com-pany B can be permitted to access the domainof the research department of company C, whileother departments of the same company C can-not. Thus a relationship of limited trust can beestablished between partner companies. Thoseorganisations using CORBA-based solutions intheir information systems will benefit from theuse of CORBA firewalls. These include, to men-tion but a few, healthcare, telecommunications,financial, manufacturing and government entities.

One may reasonably wonder why it should benecessary to have such defence in depth consist-ing of so many cascading internal firewalls whenthe company’s network is already adequatelyprotected by the outermost inbound firewall. Theexplanation is quite simple. In spite of the tradi-

tional assumption that all those behind the fire-wall are friendly, and all those outside it are atleast potentially hostile, more than half of allbreaches of security are perpetrated by legiti-mate users behind the firewall, according torecent risk surveys [19, 18].

7 Emerging CORBA FirewallImplementations

CORBA Firewall Security compliant productsare emerging on the market and this sectiongives an overview of these. This discussion isessential to an understanding of current develop-ments in CORBA Firewall Security trends.

7.1 WonderWall of IONAWonderWall is an IIOP proxy with a bastionhost as its basis, whose job is to decide whichobjects are to be permitted to communicate withwhich objects across which security domains [4].

It filters all messages arriving on the server’swell-known port on the basis of request messageheader, and provides fine-grained control secu-rity. WonderWall supports the exchange of en-crypted IIOP messages using Orbix transformermechanism, and has a facility for logging mes-sages, which allows the tracing of the history ofsuspicious message exchanges and provides auseful debugging and monitoring facility. A gen-eral feature of WonderWall’s security practice isthat all messages are blocked unless specificallyallowed. It uses proxies, reinforced with specialsecurity features, to foil sophisticated attacks onthe network. In addition WonderWall supportsHTTP tunnelling of IIOP.

Figure 6-1 CORBA firewallapplications over the Internet

fig.2

Internet

Department enclaveswith objects

Company Cenclave Company

firewalls

Server objects

Company Aserver enclave

Departmentfirewalls

Company Denclave

Companyfirewalls

Researchfirewalls

Company Benclave

Research

R&D


7.2 Visibroker Gatekeeper of InpriseTraditionally, to safeguard network security,Java applets have not been permitted to commu-nicate with objects other than those in their ownenclave of origin. Gatekeeper is a gatewaythrough which Java applets can communicateacross Intranets or the Internet with CORBAserver objects outside their own enclave of ori-gin without compromising network security.

Gatekeeper uses an IIOP proxy server, and sendsall traffic through a single port [2]. It supportsSSL, which it uses to secure the Internet com-munication between a client object or a Javaapplet, and the firewall. Gatekeeper supportscallbacks, HTTP tunnelling and GUI-based con-figuration, and provides location transparency.

7.3 Custom Firewall SolutionsThese may take the form of TCP proxy fire-walls; for example SOCKS or TIS Gauntlet’sgeneric plug proxy. They have the advantage ofusing IIOP/SSL and providing application trans-parency, and the disadvantage of lacking appli-cation level filtering, having a low level of secu-rity and requiring firewall configuration [11].

TIS Plug-gw as a CORBA firewallThe plug-gw of the TIS Firewall Toolkit can beused as a very simple transport level IIOP fire-wall proxy. It needs proxified IORs, which canbe hard if one does not have the ORB’s sourcecode and the environment is dynamic. It doesnot support secure callbacks [12].

SOCKS as a CORBA firewallAs pointed out earlier, SOCKSv5 [16] is one ofthe current OMG Firewall Joint Submission’s sug-gested firewall mechanisms. In recent experimentsSOCKS has been successfully socksified [13].

7.4 ObjectWall of TechnoSecObjectWall is a tool kit to be used in combina-tion with other firewall tools, such as SOCKS,to construct secure firewalls for CORBA basedapplications. It supports transparent proxies atinbound and outbound sides, callbacks, centralpolicy management (i.e. it only grants access toan object if the security policy defined by theadministrator allows it) and firewalls with sev-eral levels of defence, and provides proxiesand packet filters. It also supports the dynamiclaunching of proxies at runtime.

ObjectWall consists of two parts, EnforcementModules and Policy Manager. The former arestandard firewall tools, packet filter, NAT (Net-work Address Translation), and TCP level prox-ies with CORBA interface. The latter, the PolicyManager, has the task of checking whether therequests are in accordance with security policy[14].

7.5 ORB Gateway of NAIThe ORB Gateway functions like a firewallproxy in that it controls the access of CORBAoperations to an enclave, but does so with ahigher degree of granularity in its control overthe CORBA access policy than is typical of aproxy. The access policy is expressed inDTEL++, like OO-DTE, and each request is cat-egorised according to this policy. The domainsto which an object is granted access are deter-mined by the category in which the object hasbeen placed on the basis of the degree of trust-worthiness of the authentication mechanism. Anunauthenticated object may be granted access toa limited domain with few privileges, whilestrongly authenticated objects will be allowedmuch freer access.

The ORB Gateway currently supports SSL asan authentication mechanism, but in the future,according to NAI, DCE, IPSec and Kerberoswill be used.

The ORB Gateway is a single point of externalaccess to the object services of an enclave whichvets access requests on the basis of the nature ofthe request and of the attributes of the objectfrom which the request comes, and implies con-trol of traffic between ORBs of multiple en-claves rather than gateway or proxy controlof traffic with the outside world [5].

7.6 OO-DTE of NAIObject-Oriented Domain and Type Enforcement(OO-DTE) [6] provides scaleable, role basedaccess control for CORBA systems, and is anobject oriented extension of DTE, under whicheach resource is assigned a type and each pro-cess runs under a domain. What types of re-source the processes of a given domain are per-mitted to read and write is specified by the DTEpolicy. Analogously in OO-DTE a CORBAoperation is assigned a type, and the client objectand server object (called processes by NAI) eachruns in its own domain. The client object caninvoke an operation if it is permitted to invokean operation of that type, and similarly, theserver object can implement that operation if it ispermitted to implement an operation of that type.

As mentioned above, the language for express-ing OO-DTE policy is called DTEL++.

There are two versions of OO-DTE alreadyimplemented, a DTE-kernel based system thatprovides non-bypassable access for CORBAsystems, and an above-kernel OO-DTE systemthat performs access control in an Orbix filterwithout the non-bypassability feature. The twoversions are, however, interoperable and use thesame access control policy.


NAI state that they are currently working on theaddition of SSL to above-kernel OO-DTE andthe improvement of security policy administra-tion, and that the policy distribution and the syn-chronisation tools presently under developmentwill allow a centrally administered DTEL++ pol-icy to be automatically distributed to CORBAsystems within the enclave.

7.7 Gauntlet 5.0 of NAIGauntlet 5.0 for UNIX (Solaris & HP-UX) fromNAI [7] is an IIOP proxy for Gauntlet. Thisproxy forwards messages sent between CORBAobjects across Gauntlet firewalls, only afterascertaining that they meet CORBA’s IIOPstandard, thus ensuring that only valid IIOP mes-sages travel across the firewall. This protects thenetwork by ensuring that IIOP-designated portsare used solely for IIOP traffic, and by reducingthe exposure of CORBA objects to invalid mes-sages that could disable them.

Gauntlet 5.0 is compatible with IIOP 1.1. Itaccepts only well formed IIOP messages, whichit passes unchanged to both clients and servers inaccordance with the policy expressed in its ad-ministrative tools and netperm table, and, in theevent of communication failure or a messagebeing rejected, it generates an appropriate errormessage. Gauntlet operates transparently forboth inbound and outbound connections andsupports callback requests from servers to clientsusing bi-directional IIOP, and the “NORMAL”mode of IIOP proxy connection, but the currentversion does not support the “PASSTHRU”mode.

According to NAI information, Gauntlet hasbeen tested for correct interoperation with clientand server applications based on the ORBsOrbix v2.3, OrbixWeb, and VisiBroker v3.3(C++ and Java).

7.8 MPOG of NAIThe Multi-Protocol Object Gateway (MPOG)[3] is an application proxy server that has beeninstalled on Network Associates’ Gauntlet fire-wall. It provides access control for operations ondistributed objects, and its architecture allowsreuse of policy data base and access controltechniques for multiple distributed object tech-nologies such as DCOM, CORBA and JavaRMI. It has facilities for message routing basedon the CORBA, Java RMI or DCOM interfacerequested.

For handling security protocols, MPOG cur-rently has two protocol handlers, a non-securehandler and an SSL handler. The non-securehandler uses an unencrypted communicationchannel which can be used in an environment

where encryption of messaging and authentica-tion of users may not be necessary. The SSLhandler supports SSL for authentication betweenclient and MPOG, and between MPOG andserver, and for negotiating the supported crypto-graphic parameters between client and server, insituations where security is an important consid-eration.

As stated in [3], the MPOG access control mech-anism separates the access control decision fromthe distributed object message handling, andsupports OO-DTE domain derivation, trust man-agement, and per-object and role-based accesscontrol.

8 ConclusionsBecause of CORBA’s popularity as a distributedobject technology supporting cross-language andcross-platform interoperability and integrationof enterprise-wide distributed applications, it isbeing increasingly used for the development ofapplications over the Internet, Intranet andExtranet in specialised market areas, such ashealthcare, telecommunications, manufacturingand financial services.

The OMG recognises the need to safeguard thesecurity of CORBA objects, and the fact thatfirewalls are still a powerful protective mecha-nism that will continue to play an important andcentral role in the maintenance of Internet secu-rity for some years yet. As a result they havespecified CORBA Firewall Security with a viewto bringing firewall technology to the world ofdistributed object computing technology, en-abling firewalls to identify and control the flowof IIOP traffic, and thus enabling CORBA appli-cation objects behind a firewall to interact safelywith objects outside the firewall. CORBA fire-walls can also make fine-grained access deci-sions based on the attributes and operations ofobjects.

Firewalls continue to change and develop, andnew features are regularly added as the needarises. If this development follows the presenttrend, CORBA firewalls will continue to com-bine configurable access control and authentica-tion mechanisms with their already existingfunctions, thus providing more powerful andflexible protection mechanisms for the Internet,Intranet and Extranet. In the future it is probablethat they may also handle moving agents, andmay perhaps be able to provide migration trans-parency.

OMG CORBA firewall compliant products areemerging on the market, and will continue to doso.


References1 Abie, H. An Overview of Firewall Technolo-

gies. Telektronikk, 96 (2), 2000.

2 Inprise’s VisiBroker Gatekeeper. Borland(1999, December 15) [online] – URL:http://www.borland.com/visibroker/gate-keeper/

3 Lamperillo, G. Architecture of DistributedObject Firewall Proxy. NAI Labs, December30, 1999.

4 IONA Technologies PLC. WonderWallAdministrator’s Guide. IONA (1997, Decem-ber 10) [online] – URL: http://www.iona.com/

5 NAI, Network Associates Labs. An ORBGateway. NAI Labs (2000, June 20) [online]– URL: http://www.nai.com/

6 NAI, Network Associates Labs. Object-Ori-ented Domain Type Enforcement (OO-DTE). NAI Labs (2000, June 19) [online] –URL: http://www.nai.com/ nai_labs/asp_set/applied/arse_corba.asp

7 NAI, Network Associates Labs. Gauntlet 5.0for Unix, an IIOP proxy for Gauntlet. NAILabs (2000, June 19) [online] – URL:http://www.nai.com/asp_set/products/tns/gauntletunix_intro.asp

8 OMG. Joint Revised Submission,CORBA/Firewall Security+Errata. OMGDocument. OMG (1998, July 6) [online] –URL: http://ftp.omg.org/pub/docs/orbos/98-07-03.pdf.

9 OMG. The CORBA Security Service Speci-fication (Revision 1.2). OMG (1998, January15) [online] – URL: http://ftp.omg.org/pub/docs/ptc/98-01-02.pdf.

10 OMG. The Object Management Group.OMG (2000, June 19) [online] – URL:http://www.omg.org/

11 Schreiner, R. CORBA Firewalls WhitePapers. TechnoSec Ltd. (1998, December 15)[online] – URL: http://www. technosec.com/whitepapers/corba/fw/main.html

12 Schreiner, R. TIS plug-gw as a CORBA fire-wall White Papers. TechnoSec Ltd. (1998,December 15) [online] – URL: http://www.technosec.com/whitepapers/corba/tis_plug_gw/cfwexp1.html

13 Schreiner, R. SOCKS as a CORBA firewallWhite Papers. TechnoSec Ltd. (1998,December 15) [online] – URL: http://www.technosec.com/whitepapers/corba/socks/socks_exp.html

14 Schreiner, R. ObjectWall : Integrated Protec-tion of Dynamic CORBA Applications.TechnoSec Ltd. (1998, December 15)[online] – URL: http://www.technosec.com/products/Objectwall.html

15 SESAME, A Secure European System forApplications in a Multi-vendor Environ-ment. SESAME (2000, June 19) [online] –URL: http://www.esat.kuleuven.ac.be/cosic/sesame/

16 SOCKS V5. SOCKS (2000, June 19)[online] – URL: http://www.socks.nec.com/

17 SSL3.0 Spec. Netscape Communications(2000, June 22) [online] – URL: http://home.netscape. com/eng/ssl3/3-SPEC.html

18 Thompson, M J. Corporate Network Secu-rity (1998, September 21) [online] – URL:http://www.thestandard.com.au/metrics/display/0,1283,750,00.html

19 Warroom Study. Security in Cyberspace :Hearings before the Permanent Subcommit-tee on Investigations of the Committee onGovernmental Affairs. United States Senate,104th Congress, 2nd Session, 1996. ISBN 0-16-053913-7. (http://www.warroomresearch.com/researchcollabor/infosecuritysurvey.htm)

65

IntroductionTelenor defines risk as “the possibility of losscaused by threats or unwanted events” [1]. How-ever, risk is a fuzzy, abstract and highly subjec-tive concept that is inherently difficult to mea-sure and sometimes next to impossible to cometo terms with.

One reason for the difficulties in understandingrisk is the fact that risk comes from a variety ofsources: political, cultural, financial, legal, tech-nical, environmental, competitive and personalframework. Another reason is that one risk maybe a business requirement in one context, but athreat to the same business requirement in a dif-ferent context.

Good risk management will improve the com-petitive edge of a business, product or service.The improved competitive edge comes from bet-ter project management, fewer nasty surprises,fewer accidents, lower costs while at the sametime improving quality, meeting deadlines,meeting budgets, better customer communica-tion, etc. Consultancy firms, hoping to land a“hefty contract with lots of money attached”,are quick to point to these benefits of risk man-agement.

Small wonder, then, that some people view riskmanagement more as magic than science, andare deeply suspicious of the claims that riskmanagers promote. Risk management is neitherscience nor magic. Risk management is a repeat-able business process that systematically exam-ines all the various products, processes, businesssurroundings and business objectives at all levelsof the company. No more, no less.

What is Risk Mmanagementin Telenor?Telenor defines risk management as the businessprocess of managing risks by identifying, ana-lysing and controlling costs related to risks. Therewards of an on-going risk management regimeinclude

• Better knowledge of the risks one faces;

• Better understanding of the interactionbetween the business and its environment;

• Better understanding of the business’ criticalsuccess factors.

This understanding could be used in many ways.For instance, it is difficult to cost justify lossreduction measures unless one knows the risksone faces. In addition, it is equally difficult toselect reasonable risk financing strategies with-out knowing the risks one faces. Selecting a rea-sonable risk balance between different products,services or branches is impossible without arealistic understanding of the business environ-ment. Discontinuing a product or service withoutregard to the business’ critical success factorscould turn into a nightmare. Thus, knowledgeand understanding lead to an improved competi-tive edge and the benefits mentioned in the in-troduction. However, risk management must bean on-going business process in order to harvestthe benefits.

Risk management is a flexible business process.You can use risk management to manage risksassociated with a single product or service or tomanage aggregate business risks.

The primary goal of risk management in Telenoris to minimise the aggregate risk cost, which isthe sum of all individual risk costs in the busi-ness. The first challenge is to balance futurecosts caused by an unwanted incident againstcosts of attempting to prevent the incident fromhappening in the first place. The next challengeis to balance all the individual risks and costs insuch a way that the grand total is minimised.

The optimal protection level point, as a riskmanager sees it, is the lowest point in the curvelabelled “total costs”. This is illustrated in Figure1.

A secondary goal is quite simply to identify risksand then selectively “fixing any unacceptableproblems”. This is typically a support activity inthe business process of managing aggregate riskexposure. It is a necessary activity, but it quicklyturns into an isolated series of suboptimalisa-tions. However, this is also an important steptowards developing a mature risk managementoriented business attitude.

Telenor’s Risk ManagementModelTelenor’s risk management model illustrates thebusiness process of managing risks. The riskmanagement model is based on a refinement ofthe classical ‘analyse – act – evaluate’ cycle. As

Telenor’s Risk Management ModelE R I K W I S L Ø F F

Erik Wisløff (39) works in thefield of risk management atTelenor R&D. Prior to this heworked in the security domainat AIRMATCOMNOR.

[email protected]

Telektronikk 3.2000


illustrated in Figure 2, the model consists of fivemajor steps.

Risk management should not be isolated fromthe rest of the business. An obvious drawbackof the model is that it does not visualise animportant risk management practise: communi-cation. All relevant risks must be communicatedto the involved stakeholders, and stakeholdersmust communicate their interests to the riskmanager.

Objectives, Strategies andRequirementsThe first step in the risk management model is todefine the business objectives, strategies andrequirements.

Contrary to popular belief, the object of riskmanagement is not to avoid risk at all cost. Theobject is to avoid or transfer unnecessary orunacceptable risks, while accepting selectedrisks. Taking calculated risks is an excellentbusiness practise. Accepting risks blindly, or try-ing to remove all risk, is a very bad habit. There-fore, risk management cannot be effective with-out consciously deciding which level of risk isacceptable.

The applicable goals, strategies and businessrequirements define the background – be theywide-ranging business goals or narrowly definedproduct requirements. This background is a nec-essary foundation for the acceptance criteria.

The acceptance criteria come from the objec-tives, strategies and requirements, and they willbe used to decide whether a risk should beaccepted or not. Acceptance criteria can bedescribed qualitatively (“we will not break anylaws”) or quantitatively (“We will not acceptmore than n instances of abc”). Acceptance cri-teria can also be used to develop risk indicatorsand decide the trigger levels for the risk indica-tors.

Understanding the objectives, strategies andrequirements is vital for the risk managementcycle. This understanding must be communi-cated to the next stage in the model, the riskanalysis.

Risk AnalysisRisk analysis is the second step in the risk man-agement model, and is an essential tool in riskmanagement. The goal of a risk analysis is toidentify and analyse risks, compare the riskexposure with the acceptance criteria and sug-gest loss reduction measures to the unacceptablerisks. This gives the decision-maker the neces-sary background to make a decision on how heor she wants to treat risks. Acceptable risksshould be monitored. Risk analysis is discussedin some detail in another article, and furtherreading is available at Telenor’s Risk manage-ment homepage [A] or Telenor’s TeleRiskhomepage [B].

There are different ways to do a risk analysis –qualitative or quantitative, with formal methodsor without formal methods – but the idea is tohave a repeatable process that gives high qualityanswers at a reasonable cost.

Protection level

Economic loss causedby unwanted incidents

Cos

t

Total costs(loss + protection)

Economic cost ofprotection measures

Figure 1 Minimising totalcosts

Follow-up and evaluation

Risk financing

Funding Traditionalinsurance Retention Financial

insurance

Acceptablerisk?

Risk treatment

Yes

No

Avoid Prevent Reduce Transfer

Risk analysis

Objectives, strategies, requirements

Acceptancecriteria

Figure 2 Telenor’s riskmanagement model


Mitigation StrategiesThe third step in the risk management model isto select a mitigation strategy. One can achieverisk reduction by applying a relevant mitigationstrategy toward the unacceptable risks. Telenor’sfour mitigation strategies are

• Avoiding the risk altogether. If a risk is totallyunacceptable and risk reduction is not possibleby any other means, then it is necessary toavoid the risk, for instance by discontinuinga product or service.

• Preventing the risk from materialising. Thismitigation strategy corresponds to reducingthe frequency or likelihood of a risk material-ising. An example of this strategy is thewidespread use of virus control to preventmalicious software from harming a PC.

• Reducing the consequence if risk does materi-alise. Backup of servers is a classical exampleof consequence reduction. Even if malicioussoftware does take out a server, up-to-datebackups minimise harm.

• Transferring the risk to a third party. Insur-ance, contracts and disclaimers are traditionalmethods of transferring risk to a third party.

Usually a mix of the mitigation strategies willgive the best result. The importance of the finan-cial mitigation strategies is highlighted by thesituation where it is impossible to avoid or pre-vent an unacceptable risk, and the decision-maker accepts the risk. At this point, the offen-sive risk manager should prepare fallback strate-gies and suggest financial mitigation measures.

Risk FinancingThe fourth step, risk financing, is necessarywhether the mitigation costs are payable up frontor they turn up when a risk materialises. Riskfinancing in Telenor primarily falls into one ofthe four main strategies:

• Funding the mitigation is usually used if“something” is done to prevent, avoid orreduce a risk. The funding can be self-financ-ing or financed by the customer. It is possibleto build up reserves without having to paytaxes when the funding is unfunded or fundedby way of a Captive.

• Traditional insurance is commonly used. Aninsurance company usually accepts the costsassociated with a risk materialising. Of course,they expect payment for accepting this risk.

• Retention is the sum or cost the business hasto carry by itself in order to get a lower insur-ance premium.

• Financial insurance is somewhat opposite totraditional insurance. With financial insur-ance, an insurance company charges a lumpsum to cover aggregate risks. Sometimes thecosts of the materialised risks are less than thelump sum. In this case, they return the differ-ence minus a fee. However, should the costsbe higher than the lump sum, then the insur-ance firm cannot reclaim the difference fromTelenor.

Financing is necessary for risk reductions andacceptable risks. If the risk is too low, it is possi-ble to remove risk reduction controls thus lower-ing the cost of financing risks.

As a rule it is necessary to keep the mitigationcost lower than the cost suffered if a risk materi-alises. The risk manager might know a lot aboutrisk and risk mitigation, but the finance officeris the financial expert. Therefore, there are closelinks between risk management in Telenor, thefinance officer and insurance in terms of TelenorForsikring AS, the Captive of Telenor.

Monitor and ReviewThe final step is monitoring and reviewing. Riskmanagement is a continuous process, an on-going cyclical activity. The background, risksdiscovered during the risk analysis, risk mitiga-tion and risk financing must be monitored con-tinuously and reviewed regularly.

In addition to this, the risk manager must com-municate regularly with all stakeholders and anyother interested parties.

Supporting FrameworkRisk management is heavily dependent on seniormanagement involvement. The board of direc-tors approved Telenor’s original risk manage-ment policy 17 March 1995. This policy is re-placed by the current policy, approved by theboard of directors, dated 18 September 1999 [2].

An important benefit of good risk managementis that one is on top of the situation. There is lessuncertainty, one addresses only the unacceptablerisks and there will be fewer crises and nastysurprises. However, even a good frameworkneeds support. Telenor’s risk managementframework is supported by methods, guidelines,leaflets, word lists, template files, etc. The RiskManager Forum plays an important role as anarena where the risk managers meet and discusstopics of interest.

Concluding RemarksThe perception of risk management appears tobe changing globally, as does the concept anddefinition of “risk”.


In the coming years it is likely that risk manage-ment will have two parallel perspectives. Thefirst perspective is the defensive side, where oneattempts to minimise aggregate risk costs. Todaythis is the primary focus of risk management inTelenor. The second perspective will be theoffensive side, where risk managers activelysupport risky business ventures by identifyingrisks, opportunities and exits, preparing fallbackstrategies while aggressively supporting anincreased risk exposure. The offensive perspec-tive reflects the adage that it is not possible tomake money without taking risks.

Risk is traditionally associated with a negativeimpact and unwanted incidents. Today, manyrisk management forums attempt to embrace theconcept of risk as both a positive and negativefactor. The argument for this varies, but more orless appears to follow these lines: risk is not nec-essarily the incident itself, rather: it is the conse-quence of an incident. Thus, if an incidentoccurs, the outcome is either a downside (loss)or an upside (gain). The opposition points outthat while this may be correct, one is better off ifthis is called uncertainty management with twodistinct and separate processes: the traditionalrisk management minimising the downside, andopportunity management maximising the upside.

Telenor has set out to take advantage of theseemerging trends by setting up a project to pro-mote a corporate business risk managementmethodology. This methodology will includerisk management practices for “uncertainty”management, while taking advantage of both thedefensive and offensive perspectives to riskmanagement.

References1 Faglig plattform for risikoanalyser i Telenor.

Telenor Infotorg. (2000, June 26) [online] –URL: http://134.47.108.143/staber_og_selskaper/sikkerhet/dokumentene/24/10/telerisk20.doc

2 Konsernprosedyre for risikostyring iTelenor. Telenor Infotorg. (2000, June 26)[online] – URL: http://134.47.108.143/staber_og_selskaper/sikkerhet/doku-mentene/67/49/konsernprosedyre_for_risikostyring.doc

Suggested ReadingA Telenor Infotorg website for Risk manage-

ment, select Risikostyring in the menu bar athttp://134.47.108.143/staber_og_selskaper/sikkerhet/index.htm.

B Telenor Infotorg website for TeleRisk (riskanalysis), select TeleRisk in the menu bar athttp://134.47.108.143/staber_og_selskaper/sikkerhet/index.htm.

C AS/NZS 4360, which embraces the conceptthat risk is neutral (can have an upside anddownside). AS/NZS 4360 is a much citedrisk management standard.

D BS7799, which only views risk in the tradi-tional sense (downside). BS7799 is on trackto becoming an ISO standard.

E CORAS, an IST project proposal for a plat-form for risk analysis of security critical sys-tems at http://www.telenor.no/fou/prosjekter/coras/coras.htm.

F Risk management site at http://www.riskmanagement.com.au.

69

Risk analysis is an essential activity in the riskmanagement business process. Risk analysisidentifies threats, assesses how often they willmaterialise, assesses the impact the threat willhave if it does materialise, presents the individ-ual threats in an easily understood risk exposurestatement and identifies possible loss reductionmeasures. The object of a risk analysis is to sup-port a decision-process by explicitly stating therisk exposure.

Important deliverables of the risk analysis arethe identified threats, the risk exposure of eachthreat and appropriate loss prevention measures.

Among the benefits of performing a risk analysisis a better understanding of the target of evalua-tion (TOE) and the possibility to cost justify lossprotection measures. However, an on-going RiskManagement regime must be in operation to har-vest the full benefit of a risk analysis.

Telenor’s Risk Analysis ModelTelenor’s risk analysis model is described inFaglig plattform [1]. The model is in part in-spired by Norsk Standard for risikoanalyse [2],and is compatible with [2] and the more recent

Australian standard [3]. The model is illustratedin Figure 1.

The risk analysis consists of several sequentialsteps, beginning with a description of the TOE.The result of the analysis is a written report thatusually includes recommended loss reductionmeasures.

Describing the Target of EvaluationThe first step is to define the target of evaluation(TOE). The TOE can be anything – a businessprocess, a physical object, a logical object orsocial interactions. A precise description usuallyincludes

• The name of the TOE and the stakeholders;

• An unambiguous purpose for the analysis;

• A rough draft of the TOE and how the TOEinteracts with the surroundings;

• All relevant facts, conditions or circumstancesof importance to the analysis. This is informa-tion about the TOE or the TOE’s surround-ings, and may be technical, political, legal,

Risk Analysis in TelenorE R I K W I S L Ø F F

Erik Wisløff (39) works in thefield of risk management atTelenor R&D. Prior to this heworked in the security domainat AIRMATCOMNOR.

[email protected]

Figure 1 Telenor’s risk analysis model

Acceptablerisk?

Recommend lossreduction measures

Yes

No

Exposure description

Consequence analysisFrequency analysis

Threat analysis

Describe the targetof evaluation

Monitor andreview

Acceptancecriteria

Telektronikk 3.2000


financial, social, environmental, humanitarianand/or organisational information;

• A clearly stated boundary between what isincluded and what is not included in the riskanalysis.

The quality of the analysis is heavily influencedby this first step. If a critical part of the TOE isforgotten or deliberately omitted the analysismay be invalidated. Missing or inadequately de-scribed parts of the TOE usually produce con-fusion and arguments instead of a good under-standing of the TOE. Arguments are also com-mon when people do not accept the limits of theanalysis.

This step is important, because it synchronisespeople’s understanding of the TOE and laysdown the ground rules for the threat identifica-tion phase.

Unfortunately, the layperson is seldom preparedto spend time on this step because “everyoneknows what the TOE is”. Maybe, but it is a rareoccasion when everyone knows what the TOEactually is, understands what it really does, cor-rectly describes the critical success factors, pre-cisely describes the customer, etc.

Threat AnalysisThe second step is the threat analysis, whichTelenor splits into two half steps.

The first half step involves identifying the threatsto the TOE. A threat is a present or future vul-nerability, activity, accomplishment or event thatcould have a negative future impact on the TOE.

It is essential to use a structured approach in thethreat identification phase. Significant threats areusually overlooked when the threat identificationphase is unstructured, thus lowering the credibil-ity of the analysis. An unstructured approachalso leads to repeatedly returning to the threatidentification process, thus increasing costs.

Telenor recommends Hazard and Operabilitystudies (Hazop) [4] as a basis for threat identifi-cation. Hazop is a technique for structuring abrainstorming process, and is well suited whenanalysing complex objects. A skilfully executedHazop will supply an exhaustive list of threats,what causes the threats to materialise and to acertain extent the consequences of the threats.However, Hazop is not recommended if the ana-lyst does not have previous experience with thistechnique.

For the layperson, Telenor recommends usingspecially designed threat identification tech-

niques [5] even though this is a less structuredapproach to threat identification.

The next half step is an analysis of what causes athreat to occur. A separate brainstorming sessionmay be necessary unless the causes were estab-lished during the threat identification phase. Inthis session one tries to answer the question“what can cause this threat to materialise”.

The depth of the causal analysis is determinedby the length of the causal chain. The directcause of the threat is sometimes enough, but itmay be necessary to establish a chain of causesbefore the causality is sufficiently examined.

Frequency and Consequence AnalysisThe third and fourth step consists of analysingthe frequencies and consequences related to eachthreat. The model shows these steps side by side,because it is a matter of personal preference andpracticality whether one is completed before theother begins, or if they are analysed in parallel.

The frequency analysis examines each threat todetermine how often the threat is likely to occur.The frequency analysis should be quantitative,but lack of time and hard data usually preventsthis. The preferable alternative is to quantify arange of frequencies – for instance high, medium,low – and allocate each threat to one of thelabelled ranges. If this is impossible, a qualita-tive description of the likelihood of each threatis called for.

The consequence analysis focuses on the dam-age a threat can set off, preferably expressed ineconomic terms. An indirect consequence occurswhen the triggered threat sets off a chain ofevents before the consequence shows up, where-as a direct consequence is set off by the trigger-ing threat. Sometimes it is necessary to look forboth direct and indirect consequences before thetotal loss is determined. In any case, it is essen-tial to determine the consequences because noloss prevention measure should cost more thanthe loss it prevents.

The consequence analysis should also outlinethe mechanisms or barriers that are supposed toprevent the damage. This knowledge is usefulwhen selecting measures to minimise the conse-quences when a threat is set off.

Exposure DescriptionThe previous steps analysed threats, frequenciesand consequences. The next step is to present thethreats in terms of risk exposure. The risk expo-sure is a description of the impact a materialisedrisk will have. There are three main points toconsider:


Firstly, the aggregate risk exposure for a giventime period should be presented when the previ-ous analyses are quantitative. Aggregate risk ex-posure is defined as

Aggregate risk exposure = ΣT (frequency * consequence)

where ΣT is the summation of the T threats (inthis article a threat includes vulnerabilities andunwanted events), frequency is the number ofexpected incident in a given time period andconsequence is the economic consequence perincident.

Secondly, the exposure description should beas clear, concise and informative as possible.Therefore, while the aggregate risk exposure isprecise, it is not informative in terms of individ-ual threats. To this end, the individual risks canbe presented in a table, a matrix or in a verbalnarrative.

Thirdly, the exposure description must followa format similar to the decision-maker’s accep-tance criteria. Acceptance criteria are ideally ex-pressed by the decision-maker before the riskanalysis starts, and they represent the level ofrisk the decision-maker can accept.

There is usually not enough data to support stat-ing the aggregate risk as a single number. Inaddition, many of the finer points of the analysisare lost when the result is aggregated into a sin-gle number. Tabulated risks are effective onlywhen the decision-maker is comfortable withthis format, and verbal descriptions are often tooverbose. Therefore, Telenor recommends using arisk matrix to present the acceptance criteria andthe risk exposure; see Figure 2.

The two axes are frequency and consequence.The granularity of the axes must be suitable forthe purpose of the analysis. Usually four or fivesuitably labelled intervals are sufficient. Eachthreat is then plotted according to the result ofthe frequency and consequence analysis.

It is vital to ensure that the verbal label oneassigns to the intervals is acceptable to thereader. For instance, the label Insignificant isprobably offensive when the consequence of athreat is life threatening injuries or permanentdisability.

It is also necessary to explain what the labelsmean. For instance, Possible might mean “be-tween 1 and 10 occurrences per decade”, andSubstantial could be “between NOK 100,000and NOK 250,000 per incident”. The expectedeconomic risk of a threat plotted in the cell pos-sible/substantial in this example is between

NOK 250,000 and NOK 10,000 per year. Theanalyst will have to assign a qualitative meaningto the label if it is not possible to quantify thethreats. For instance, Disastrous might mean“National media will have a feeding frenzy lead-ing to significant loss of reputation to Telenor,discontinued service of the TOE and customersclaiming substantial monetary compensation inaddition to a significant number of customersfleeing from other Telenor products or services”.

A decision-maker usually hesitates to implementremedial action unless the cost of loss preven-tion is less than or equal to the risk exposure.Therefore, the risk exposure should be stated ineconomic terms whenever possible – in additionto the risk matrix.

In a real world of risk analysis it is often neces-sary to assign both qualitative and quantitativedefinitions to the labels.

Deciding Whether a Risk is AcceptableDeciding what is acceptable is the decision-maker’s responsibility. As mentioned previ-ously, the decision-maker should express theacceptance criteria before the analysis begins.When this is done, the risk analysis team candetermine whether a risk is acceptable or not,without setting up a meeting with the decision-makers.

A recommended format for the acceptance crite-ria is the risk matrix. The unacceptable riskexposure is quite simply shaded, in Figure 3 theunacceptable risk exposure is shaded in a darkercolour. The decision-maker’s intentions are eas-ily understood: Any threat plotted in a shadedarea is unacceptable.

Recommending Loss ReductionMeasuresThe plotted acceptance criteria, which describethe level of risk a decision-maker accepts, andthe risk exposure of each individual threat willreveal whether

Insignificant

Substantial

Serious

Disastrous

Figure 2 Risk matrix

Co

nse

qu

ence

Frequency

Improbable Possible Usual Common


• The risk exposure is too high; in which case itis necessary to prevent loss. A loss reductionmeasure is an action taken or a physical safe-guard installed before a loss occurs.

• The risk exposure is acceptable; in which caseone should monitor the risk. No loss reductionmeasures should be recommended for anacceptable risk.

• The risk exposure is too low; in which caseone should consider removing unnecessaryloss prevention measures. The argument forthis is to shift a resource from unnecessarymeasures to more productive risk reductionmeasures.

The recommended loss reduction measuresshould be grouped according to the risk mitiga-tion strategies (avoid, prevent, reduce, transfer).

Telenor’s Corporate Frameworkfor Security Risk AnalysisTelenor’s senior management has formallyapproved company-wide policies making riskanalysis mandatory. So risk analysis is supportedby senior management. The challenge to thepractitioner is to balance the depth of analysiswith the expected benefits of performing theanalysis, and to avoid “paralysis by analysis”.

Telenor’s risk analysis framework is twofold.On the one hand it consists of corporate-widepolicies, guidelines and tools. On the other handthere are the policies, guidelines and toolsunique to each business area. Below, we outlinethe corporate risk analysis tools, biased towardsthe security domain.

Security Risk AnalysisThe corporate policy for systems security [6]instructs all owners of information systems toperform a security categorisation of their system,and perform a risk analysis according to thesecurity category. The three security categories,with corresponding depth of analysis, are

A Especially security critical – a thorough risk analysis is required, possiblywith a series of focused risk analysis of spe-cific vulnerabilities.

B Security critical – a Standard risk analysis is required.

C Not security critical – a Minimal risk analysis is required.

This categorisation offers a win-win situationwhere managers can use the security category tofilter and prioritise information, and the ownerof an especially security critical system will getmanagement’s attention while managers of othersystems are relieved of unnecessarily detailedreporting. Thus the total effort a system ownermust put into a security risk analysis is also min-imised since the bulk of Telenor’s systems fallsinto category C or B.

In practice, the categorisation is a simple andstraightforward task, requiring an interdisci-plinary team which assesses the security profileof the system according to the assessment proce-dure. The procedure explores five domains;economy, marketplace, dependencies, the legalframework and the security profile of the sys-tem. These five domains are explored from boththe customers’ and Telenor’s point of viewthrough a number of questions. Each domainis assigned an integer value between 1 and 5,the values are added and, depending on the sum,the security category is either A, B or C.

The current security categorisation system wasdeployed in late spring 1999 and has given somesurprises. The biggest surprise is that users gen-erally perform a categorisation faster in real lifethan expected, while the quality of work meetsor exceeds the expectations.

An interesting result is that the categorisationprocedure which translates the security attributesconfidentiality, integrity and availability into thefive domains appears to be an eye-opener forusers unfamiliar with security.

There are interesting variations in how the usersperform the categorisation. Some users meticu-lously work through the full set of questions foreach of the five domains, document all answersin detail and then work out a “correct” value foreach domain and finally select the appropriatesecurity category. Other users skip questionsthey do not like, slap an integer value they arehappy with on each domain, and summarilyselect the appropriate category – and are donewith the job. In one case users in different busi-ness areas have categorised almost identical sys-

Insignificant

Substantial

Serious

Disastrous

Co

nse

qu

ence

Frequency

Improbable Possible Usual Common

Figure 3 An example of a riskmatrix with decision criteria


tems as category B, with only a one point differ-ence, using very different approaches. Whenquestioned informally, the meticulous user saidthat they learned a lot about their system and itsenvironment, and that the resulting report wouldbe used as part of the system documentation.The other user reported that the classificationprocedure was acceptable, but that they did notlearn very much from the exercise and that themain benefit was that their security officer wassatisfied.

Risk Analysis During ProductDevelopment and IntroductionThe product development and introduction pro-cess, or P3 as it is more commonly referred to inTelenor, calls for risk analysis both of the pro-ject risks and a security risk analysis of thefuture product or service.

The project risk analysis follows an intuitiveprocess, and is quite straightforward.

On the other hand, the security risk analysisbegins with a security categorisation whichdecides the depth of analysis. A review of thesecurity risk analysis is required for each formalphase evaluation the project is subjected to.

Given enough time and that the product or ser-vice is categorised A or B, the security risk anal-ysis is repeated one or more times before theproduct or service is launched.

Risk Analysis in PracticeAll risk analyses are company confidential inTelenor. Confidentiality is necessary becauseone is very vulnerable after a risk analysis. Notonly has the analysis uncovered weaknesses, ithas also exposed and documented the mecha-nisms that can be used to exploit the weakness.

Instead of looking into specific risk analysis, thisarticle will highlight the methodology behindTelenors Minimal Risk Analysis and some of thelessons learned.

The Minimal Risk AnalysisUsers complained that the previous corporaterisk analysis framework was too demanding,time consuming, inflexible and too focused onsecurity risk analysis. Informal discussions withdisapproving users pinpointed problems such asuntrained analysts using semi-formal analysismethodologies, guidelines written by experts forexpert use and too voluminous template files. Inaddition to this, the users had little or no chanceof performing a risk analysis within real-worldtime constraints. In short; they felt the corporaterisk analysis standard was impractical and theo-retical.

The Minimal Risk Analysis (MRA) was devel-oped as a response to these complaints. The pri-mary objective was to propose a generic riskanalysis framework that would give a methodi-cal user a high success rate. The secondary ob-jective was to have the Minimal Risk Analysistake less than one week to plan, execute anddocument. This contrasts the then current corpo-rate methodology requiring a specialist analystusing perhaps 200 – 300 man-hours in a two tofour month time scale.

The resulting design of the MRA is three-part:

1 A process guide; directing the user througha proven sequence of activities;

2 A template file; giving the user a skeletonreport;

3 Threat assessment guidelines; assisting theuser in uncovering threats.

The Minimal Risk Analysis is object oriented.The TOE is described as an object consistingof sub-components which interact with and areinfluenced by external objects. As a minimum,each object or sub-component will be describedby its internal structure, its function and its inter-action with other objects or sub-components.The following threat identification phase sys-tematically explores each object to identifythreats.

The Minimal Risk Analysis differs from theStandard Risk Analysis in three areas:

• Formal methods are not mandatory in a Mini-mal Risk Analysis. This means that risk analy-sis expertise is not required, though it is help-ful. However, the lack of formal methods doesnot mean that the analysis is unstructured. Theuser has a guideline for the work process, atemplate file for the report and structured aidsto the security threat identification.

• Acceptance criteria are not developed beforethe risk exposure is written. With a finalizedrisk exposure the decision-maker quickly seeswhich risks are acceptable or unacceptable.

• Causal analysis is omitted from the threatanalysis phase since the causal analysis is notvery useful for the acceptable threats. A causalanalysis is occasionally necessary to identifycost-effective treatment strategies for unac-ceptable threats, but treating an unacceptablerisk is often quite straightforward.

Practical use shows that a Minimal Risk Analy-sis of acceptable quality can be performed with-


in a one week time-frame, using approximately20 – 30 man-hours in addition to the threat iden-tification meeting.

As yet, no formal evaluation of the effectivenessof a Minimal Risk Analysis has been undertaken.

However, user feedback indicates that the Mini-mal Risk Analysis methodology is acceptablein the “real world”, while the quality of the riskanalysis appears to be adequate. In addition it isbecoming clear that the first few times a user isin charge of a Minimal Risk Analysis they feelthey would benefit from some kind of expertsupport.

Typical ProblemsRisk analysis should ideally be performed when-ever something changes in the TOE environ-ment. This can be personnel changes, reorgani-sations, changes in technology or market be-haviour, new laws and so on. A more practicalapproach is to perform a new risk analysis when-ever there are significant changes either in theTOE or in its environment. In real life, peopleare busy designing new products, solving prob-lems, reporting to management and so on. So therisk analysis tends to be postponed, sometimesindefinitely because the TOE causes so manyproblems that there is barely time to fix onebefore a another crops up ...

Another problem is finding the right people, thepeople who do know what the TOE is. They, ormanagement, give other tasks higher priority.Ironically, occasionally these highly prioritisedtasks are problems – making the best expertswork reactively ...

Risk analysis is an interdisciplinary activity.Sadly, on occasions the quality of a risk analysisis below the quality the decision-maker requiresbecause the interdisciplinary focus is lost in the“need for speed”.

Cause and EffectDifferentiating between cause, effect and conse-quence is not always easy.

Imagine this chain of events; you receive soft-ware with malicious code by e-mail, you openthe e-mail and run the software. Unfortunately,the virus protection does not catch the maliciouscode, the malicious code destroys your files andyou have no access to the backup files. Worseyet, your friendly IT-support person is unavail-able due to acute sickness, you cannot reach thedeadline for the bid you are working on and youlose an important contract. Your boss thenpromises you a “lengthy, uncomfortable meetingwith much shouting, waving of arms and point-ing of fingers”.

What is the threat in this scenario? What is thecause? What is the consequence? Is there aneffect? Anything goes as long as a single threathas one ore more causes and leads to one ormore consequences. Moreover, one cause cantrigger several different threats, while one con-sequence can be triggered independently by anumber of threats.

Actually, it is often a matter of perspective. Agood description of the TOE and an unambigu-ous purpose for the analysis will go a long waytoward giving the answer. This is one of the rea-sons why a precise and correct description of theTOE is important.

Management DecisionsManagement decisions should be based onexplicitly expressed decision criteria. The man-agement may be eager to express their decisioncriteria early on. This is a good sign – providedthey actually manage to come up with decisioncriteria relatively easily.

However, when the business environment orTOE is very complex, the decision criteria areeasier to express at a late stage of the analysis.This is also the case when it is apparent that themanagerial logic is fuzzy or inconsistent. Whenthe risk exposure is presented in the risk matrix,the risk analysis team should grab hold of theprincipal decision-maker, and have him/herpoint at the unacceptable cells. This usuallyworks. The interesting thing is that the manageris usually grateful because he/she gets a clearerunderstanding of their “gut feeling”.

Risks and ProblemsIt is worth noting that a risk is not the same as aproblem. A risk is something that has not hap-pened, and it may not happen at all. A problemis something that has happened, that causes con-cern and which (normally) cannot be ignored.Sometimes a threat analysis meeting is boggeddown by participants looking for solutions tosomething they see as a problem. On the otherhand, decision-makers sometimes dismiss a riskbecause the risk is not yet a problem – but this isnot necessarily the same as accepting the risk.

Work in ProgressCurrently several key issues are being addressed;

• The Standard risk analysis package is beingrevised, to make it more user friendly.

• A methodology for performing quantitativerisk analysis has been developed and has beentested in a live risk analysis in Telenor. Thetest was successful, and the methodology withsupporting simulation tools are being im-


proved and prepared for practical use. Thiswork is a joint effort between Telenor andNorconsult.

• New threat assessment guidelines are in devel-opment. Guidelines for project risk, deliveryrisk and business process risk will bedeployed during 2000.

• Telenor R&D is the project manager of a con-sortium proposing to EU that the consortium,through the IST framework, “... provide anintegrated methodology to aid the design ofsecure systems and thus establish trust andconfidence in our products”.

• A methodology for Business Risk Analysisis being developed and is expected to be de-ployed in 2001.

References1 Faglig plattform for risikoanalyser i Telenor.

Telenor Infotorg. (2000, June 26) [online] –URL: http://134.47.108.143/staber_og_selskaper/sikkerhet/dokumentene/24/10/telerisk20.doc

2 Norsk Standard. Krav til risikoanalyser/Requirements for risk analyses. (NS5814.)

3 Australian standard. Risk management.(AUS/NZ 4360:1999.)

4 Risikoanalyseteknikker. Telenor Infotorg.(2000, June 26) [online] – URL: http://134.47.108.143/staber_og_selskaper/sikkerhet/dokumentene/24/44/risikoanalyseteknikker_v1-0.doc

5 Trusselidentifikasjon sikkerhetsrisiko.Telenor Infotorg. (2000, June 26) [online] –URL: http://134.47.108.143/staber_og_selskaper/sikkerhet/dokumentene/24/58/trusselid_sikkhet_ver_10.doc

6 Konsernstandard for systemsikkerhet.Telenor Infotorg. (2000, June 26) [online] –URL: http://134.47.108.143/staber_og_selskaper/sikkerhet/handbok/retningslinjer/vedlb08.htm

Feature - Telenor

Documents