guidelines for authors - unob.czspi.unob.cz/old/last/ostatni/proceed2003.pdfsecurity and protection...

Security and Protection of Information 2003 1

Contents

Introduction.................................................................................................................................5

Invited Speakers

Austrian e-Government and Citizen Card Initiatives ...............................................................7

Herbert Leitold

Intrusion Detection Systems and IPv6....................................................................................15

Arrigo Triulzi

Introduction and security perspective on peer to peer protocols...........................................23

Eric Vyncke

Contributed Talks

Security Aspects of Homogeneous Environments ..................................................................31

Hanuš Adler

Secure videoconferencing system...........................................................................................39

Tomas Boucek, Jaroslav Dockal, Petr Dousek, Tomas Konir

The Research and Implementation of Distributed Active and Cooperative Intrusion Detection System.....................................................................................................43

Qihao Deng, Qingxian Wang, Jingeng Guo

Hacking vs. Pen-Testing. Experiences, similarities and differences.....................................49

Kamil Golombek

Electronic notary services........................................................................................................55

David. C. Hájícek

Extending Security Functions for Windows NT/2000/XP.......................................................61

Martin Kákona

New Self-Shrinking Generator ................................................................................................69

Ali Kanso

Side Channel Attacks on CBC Encrypted Messages in the PKCS#7 Format......................75

Vlastimil Klíma, Tomáš Rosa


Secure Splitting Block (SSB)...................................................................................................85

Libor Kratochvíl

Symetric Key Infrastructure ....................................................................................................97

Karel Masarík, Daniel Cvrcek

Authentication of Paper Printed Documents using Paper Characteristics ..........................103

Matúš Mihal’ák, Ivan Kociš

Critical Infrastructure Modelling ..........................................................................................107

Ludek Novák, Robert Gogola, Antonín Šefcík

Balanced LKH for Secure Multicast with Optima Key Storage..........................................115

Josep Pegueroles, Francisco Rico-Novella

Time Stamping Autority.........................................................................................................123

Jaroslav Pinkava

A New Approach of Signing Documents with Symmertic Cryptosystems and an Arbitrator....................................................................................................................133

Nol Premasathian

Ways of Doubling Block Size of Feistel Ciphers Used in Some Candidates for the AES .............................................................................................................................137

Bohuslav Rudolf

New Nominative Proxy Signature Scheme for Mobile Communications ............................149

Seung-Hyun Seo, Sang-Ho Lee

True Random Number Generation Using Quantum Mechanical Effects............................155

Ludek Smolík

A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications .............................................................................................161

Jirí Sobotík, Václav Plátenka

Military Information Operations ...........................................................................................169

Ryszard Szpyra

Uniform approach to mandatory security of event management systems ...........................179

Pavel Štros


Evaluating trusted electronic documents ..............................................................................187

Petr Švéda

Advantages of modular PKI for implementation in information systems ............................191

Petr Vanek, Jirí Mrnuštík

Enforcement of NATO INFOSEC requirements into policy and architecture of CZ MoD CISs ....................................................................................................................199

František Vosejpka

An Effective Active Attack on Fiat-Shamir Systems............................................................207

Artemios G. Voyiatzis, Dimitrios N. Serpanos

Steganalysis of Images based on Randomness Metrics ......................................................215

Tao Zhang, Xijian Ping

Partners

TrustPort Certification Authority ..........................................................................................221

AEC

Cisco Systems a IPv6.............................................................................................................225

Jaroslav Martan

Security Management „enVision“ firmy Network Inteligence............................................229

Petr Ružicka

Encryption for all needs .........................................................................................................231

Lars Moldal

Místo poradenské firmy pri ochrane utajovaných skutecností............................................237

Miroslav Fryšar

Network security manager.....................................................................................................241

David C. Hájícek

Zabezpecení prístupu k utajovaným skutecnostem..............................................................245

IBM Ceská Republika


Bezpecnostní sítové incidenty – reakce v reálném case a využití systému IDS ................249

Jan Müller

Využití MS ISA Server nejen pro VPN a firewall.................................................................255

Microsoft

Proaktivní ochrana McAfee...................................................................................................259

Vladimír Brož

Bezpecné uložení klícu ...........................................................................................................263

Patrik Micech

Legato NetWorker automatický systém zálohování pro CSA.............................................267

Zdenek Lerch

Rešení bezpecnosti perimetru pomocí iForce Solutions for Security...................................271

Sun Microsystems

Zákaznická reference .............................................................................................................277

Symantec GmbH

Jak bezpecné je SSL? ............................................................................................................281

VUMS DataCom


Introduction

It is once again a great pleasure to present the proceedings of the 2nd scientific NATO Conference “Security and Protection of Information”, held on April 28-30, 2003, at the Brno Trade Fair and Exhibition Center. The Conference had been organized by Brno Military Academy and is held under the auspices of the of the Chief of Command and Control Division of the General Staff of the Army Czech Republic and Security Director of the MoD, Brigadier General Vlastimil Picek.

This Conference is part of an accompanying programme of the IDET (International Fair of Defence and Security Technology and Special Information Systems) fair. The first information security Conference was held in 2001 and was attended by 252 participants from 14 countries. The high quality of this 2nd Conference in 2003 is guaranteed by the Steering Committee, which consists of the most respected authorities in the information security field in the Czech Republic and is headed by Colonel Karel Strejc. All papers were submitted anonymously to the Programme Committee so as to ensure review and selection solely on the basis of merit.

The Conference was organized to promote the exchange of information among specialists working in this field and to increase awareness regarding the importance of safeguarding and protecting secret information within the Armed Forces of the Czech Republic as well as in the Czech Republic generally. Companies and businesses that produce or sell security technology and services have provided significant assistance in preparing this conference.

The issues that the Conference deal with can be divided into three thematic areas: information security in general, computer network security and cryptography. We have chosen as invited speaker several of the best security specialists in Europe and have also included papers by Eric Wincke (Belgium), Arrigo Triulzi (Italy), Herbert Leitold and Reinhard Posch (Austria).

The Armed Forces of the Czech Republic (CAF) consider it necessary to hold international conferences and workshops dealing with security and protection of information regularly in the Czech Republic. The aim of such conferences is both to inform the wider military public and specialists and to provide a forum for exchange of information and experience. This means that the purpose of all our security conferences is not only to offer up-to-date information, but also to bring together experts and other military and civilian people from many fields who share a common interest in security.

V Brne, 7. 4. 2003 Jaroslav Dockal, PhD

Chairman of the Programme Committee


Austrian e-Government and Citizen Card Initiatives

Herbert Leitold

[email protected]

Secure Information Technology Center – Austria Graz, Austria

Reinhard Posch

[email protected]

Federal Chief Information Officer - Austria Vienna, Austria

Abstract The omnipresence of personal computers (PCs) and the Internet has encouraged public authorities to provide citizens with means of using information and communication technologies (ICT) to contact the public services. In such e-Government environments security is a major concern. In particular the unequivocal identification of the citizen that requests services from the authorities and the authenticity of the data that is communicated are major concerns.

In this paper we describe how the Austrian federal government meets the security challenges that appear when advancing to e-Government. The strategic decisions and organizational structures that have been implemented to achieve coherent solutions are described. The main vehicles employed are electronic signatures and identification based on the citizen registration system. The Austrian citizen card concept that builds an underlying security infrastructure based on smart card technology is presented. The paper discusses how identification is provided with respect to data protection requirements. Moreover a concept is presented that relies upon open interfaces to achieve technology-neutrality and forward-compatibility. An example of an e-Government application is given to illustrate the flexibility of the concepts that have been followed. The authors have been involved in the development of the concepts described in this paper, as well as have been involved into standardization initiatives for electronic signatures that have been established in Europe.

Keywords: e-Government, citizen card, citizen identification, identity link, security layer.

1 Introduction The Austrian federal government has recently carried out several major steps towards including ICT into the business processes of public authorities for both the authority’s applications and for improving the business relationship between the citizens and the administrative bodies. Such support of public services by means of ICT is commonly referred to as e-Government. Among the courses that have been set are trend setting strategic decisions, as well as statutory provisions. The major decisions that form the basis for large scale deployment of e-Government are given below, as follows:

• The Austrian signature law [1] which is based on the EU electronic signature directive [2] and which entered into force beginning of 2000 defines that an electronic signature that fulfils certain technical requirements fulfils the requirements of writing in the same manner as a handwritten signature in a paper-based environment. The technical requirements of such electronic signatures – we refer to such electronic signatures as ‘secure electronic signatures’ throughout the remainder of this paper – are laid down in the signature order [3].

• In a November 2000 cabinet council an unanimous decision has been reached to use smart card technology to improve the citizen’s access to public services. This led to an approach which is referred to as the ‘Austrian citizen card concept’ [4] where numerous smart card initiatives such as the Austrian public identity card, the Austrian health insurance card, and private sector borne smart cards such as automatic teller machine cards will fulfill the basic requirements to be used with e-Government applications. We will precise these basic requirements is section 4.

• A number of official proceedings statutes have been amended to enable the use of electronic media in public services. Among these are provisions on how the citizen registry may be used for identification purposes which has been defined in the administration reform law [5]. The identification process will be further discussed in section 2. Moreover, the notification delivery law [6] has been adapted to allow for conclusion of proceedings by electronic means.


Besides the expression of the political will of advancing toward e-Government and besides the legal provisions a coordinated strategy is required to achieve lasting solutions. Given the multitude of applications carrying different characteristics an uncoordinated deployment carries the risk of isolated applications that cut itself off sweeping solutions that are based on a common infrastructure. Moreover, the federal state machinery that allocates responsibilities to the federal ministries, to the provincial governments, and to the municipalities results in a number of players that gain from coordinated e-Government strategies.

In order to support such coordinated strategies a so called ICT board has been established in 2001. The board consists of the chief information officers (CIO) of the ministries and a chairperson. The chairperson of the board is entrusted the duties of a CIO of the federal government as a staff position and reports to the cabinet through the chancellor, the vice-chancellor, respectively. Cooperation with the federation of the cities and of the municipalities, as well as with the federal states is provided. In this structure, which is illustrated in figure 1, coordinated decisions are possible that each stakeholder identifies oneself with and therefore the implementation in the various competences is provided. An operational unit has been established that implements the decisions of the board.

CIOchancellary

CIOministry

CIOministry

CIOministry

CIOministry

CIOministry

CIOministry

CIOministry

CIOministry

ICT board

Federal government

CIOministry

CIOministry

CIOministry

CIO federal government

Chancellor Vice-chancellor

Fede

ratio

n of

citi

es a

nd

mun

icip

aliti

es;

Fede

ral s

tate

’s IC

T ch

iefs

Fede

ralis

tic in

stitu

tions

Operations unitReporting,

Specificatons, implementationQuality assurance

Figure 1: Organisational structure of the coordinated e-Government strategy.

The ICT board that is depicted in figure 1 is a coordinating unit that translates the political provisions to the technical level by passing resolutions that – with the assistance of the operations unit – lead to specifications. Among the areas covered are some that carry specific security requirements:

• Multi-channel access: The citizen may approach the authorities by various means. While Web-based access and email will be predominant in initial phases, other access methods are conceivable. The strategic coordination needs to define general requirements in particular regarding the basic security requirements.

• XML forms: Standardized forms based on the extensible markup language (XML) [7] are being developed. The flexibility of XML and standardized electronic signature formats for authentication [8] [9] make XML suitable in e-Government environments.

• Electronic notifications: Official proceedings need to take into consideration that citizen’s life matters may change, such as the fact of possession of a PCs. Thus electronic notifications need to preserve validity even when being printed on paper. Standardized XML forms and style sheet transformations [10] assist in defining forms that can be transformed back and forth from its electronic representation to paper, whilst being capable of preserving electronic signatures appended to it.

• Electronic delivery: Secure means of delivering electronic notifications are being defined which can provide non-reputability of receipt in the same manner as registered letters.


Besides the aspects sketched above, official proceedings are in particular concerned with unequivocal identification of the citizen and authenticity of the data. The remainder of this paper discusses how these aspects are implemented in the Austrian e-Government initiatives: In section 2 unequivocal identification of the citizen is addressed. Section 3 continues by discussing the role of electronic signatures and assurance of the components involved. In section 4 the concept of a so called security layer is introduced: The citizen card is discussed as an collection of requirements arising from e-Government applications. By means of an open interface on a high abstraction level a solution to the problem of integrating new security technologies as they appear on the market is discussed. An example of an e-Government application following the concepts that are described in this paper is given in section 5. Finally, conclusions are drawn.

2 Unique Identification – a Prerequisite Many official proceedings require that the citizens are unmistakably identified. Identification may for instance be needed to ensure that the person approaching the authority is the one filing the application, such as applying for a driving license, or that the person is eligible to receive certain information, such as her penal record.

In paper-based proceedings with personal appearance, the identity can be evidenced by means of identity cards, deeds, or a witness. When advancing to e-Government personal appearance certainly shall be substituted by other means. One might consider a public key infrastructure (PKI) issuing citizen’s certificates suitable for identification purposes. However, although PKI certificates such as X.509 are unequivocal e.g. due to the serial numbers, the certificate holder is usually just indicated by the name. This does not give unmistakable identification of the person when considering equal names. Even if the certification service provider (CSP) carries out registration based on personal appearance and identity cards, unequivocal identification of the citizen than requires that the authority within the course of the official proceeding has access to both the certificate and the registration records of the CSP.

Access to the registration records of the CSP would be granted, if the CSP services are provided by governmental organizations. Such an approach has been unfavorable: On the one hand, such an approach would to some extend result in closed systems, where private sector CSPs established in the market are excluded from the e-Government marketplace. On the other hand, providing CSP services would extend the authority’s scope of duties beyond its core competences.

With the introduction of a central citizen registry in Austria in 2002, a unique identifier called a central registration number (CRN) has been established that in principle allows unequivocal identification of the citizen and thus eliminates the need to access an CSP’s registration record. This idea has been followed. However, data protection concerns need to be taken serious. The storage of the CRN with the proceeding’s files is inhibited by law. While simply using the CRN for identification is therefore not possible, the amended official proceedings law [5] permits to make use of a derived identifier that is specific for each type of official procedure and that does not allow to calculate the CRN. Such a procedure-specific identifier (PSI) is constructed by merging the CRN with an identifier of the proceeding, such as a tax declaration ID, and applying a cryptographic hash function. This is illustrated in the following figure 2.

The CRN is part of a record that is referred to as the ‘persona-binding’. The persona-binding consists of the name, the date of birth, and the CRN of the citizen and is electronically signed by the federal ministry for the interior to preserve authenticity. The persona-binding is under control of the citizen – it is stored with the Austrian citizen card that is discussed in section 4 and may be protected by the citizen by authentication codes, such as a personal identification number (PIN).


persona-bindingcentral registration number

official proceeding(e.g. tax declaration ID)

cryptographichash

merge

CRN

IDtax-decl

PSItax-decl

pers

on-

spec

ific

proc

ess-

spec

ific

pers

on-s

peci

fic

with

in th

e pr

oces

s

Figure 2: Construction of a procedure-specific identifier (PSI) for a tax declaration.

With combining the CRN with the procedure-specific ID – the tax declaration ID in the sample case illustrated in figure 2 – the citizen is uniquely identified within the official proceeding. Thus the PSI has the quality of e.g. a tax payer’s account within the tax office’s application. Likewise a PSI constructed from the CRN and the process ID of an application for a preventive medical checkup has the quality of a social security number in the health insurance’s application. What is gained due to the cryptographic hash is that neither the CRN can be derived from the PSI, nor can the official proceedings – in our sample cases ‘tax declaration’ and ‘application for preventive medical checkup’ – be connected due to using the same personal identifier, which would be inadmissible.

3 Electronic Signatures – Legal Validity and the Role of Assurance Official proceedings are characterized by requirements of writing and signatures. The European electronic signature directive [2] paved the way for legal recognition of electronic signatures in the same manner as handwritten signatures, if certain technical and organisational requirements are fulfilled. Basically, there are two requirements; one is related to the certificate and one to the signature-creation device.

1. The electronic signature needs to be based on a so-called qualified certificate – a certificate that has specific minimum contents and which is issued by a CSP that fulfils certain requirements. These requirements are laid down in Annex I of the Directive [2] with respect to the contents of the qualified certificate and in Annex II as far as the CSPs are concerned.

2. In addition, the signature needs to be a so-called advanced signature – which specifies general functional requirements of the signature – and needs to be created by a so called secure signature creation device (SSCD). The requirements for SSCDs are laid down in Annex III of the Directive [2].

If both requirements are fulfilled, we refer to such an electronic signature as a “secure electronic signature” that creates the same legal effect in relation to electronic data as a handwritten signature in relation to paper documents. Whilst the Directive did not specify a specific term for such signatures, the term “qualified signature” is used, as well. We however stick to the term secure electronic signature in this paper, as it is the terminology followed by the Austrian electronic signature law. Anyhow, the devices involved in the process, such as the SSCD or the trustworthy systems used by the CSP, are assessed by so-called notified bodies.

In order to harmonise the criteria to be followed for SSCDs and CSPs throughout Europe, the European electronic signature standardization initiative (EESSI) has been established [11]. The European Committee for Standardization (CEN) and the European Telecommunications Standards Institute (ETSI) have been entrusted to develop technical standards that support the European electronic signature directive.

Amongst the standards that have been developed are inter alia Common Criteria (CC) protection profiles that can be used by the notified bodies to assess the conformance of SSCDs with the requirements laid down in Annex III of the Directive – the so-called SSCD-PPs [12]. The SSCD-PPs lay down that a CC evaluation assurance level 4 (EAL 4) augmented by requirements to resist a high attack potential are appropriate for SSCDs. Although the process of declaring those SSCD-PPs a reference number in the official journal of the EU


and thus a standard that the EU member states shall assume eligible for defining compliance with the Directive, if a product meets these criteria, a basis has been established to define such assurance criteria within the EU.

The Austrian signature law [1] follows the European Directive – as any EU national legislation has to. Thus, legal certainty is provided throughout the EU with respect to the equivalence between secure electronic signatures and handwritten signatures and the legal basis for processes that require the written form is given.

In addition to the requirements for SSCDs, the Austrian law requires that security-relevant elements such as the PIN entry to create a signature and the trustworthy viewer component need to meet certain criteria. Details of the technical requirements are given in the signature order [3], such as the signature suites eligible. For instance Rivest, Shamir, Adleman (RSA) [13] and digital signature algorithm (DSA) [14] with 1023 bit keys are considered secure until end of 2005, DSA variants based on elliptic curves [15] [16] with 160 bit keys, respectively.

4 Security Layer – a Technology-Neutral Interface Obvious candidates to fulfil the requirements for SSCDs that readily are capable of implementing the algorithms required and capable of giving the required physical protection of the private keys are smart cards. However, technology evolves rapidly and other solutions for SSCDs may show up in the market, such as personal digital assistants (PDAs) or cell phones. The parameters of the algorithms such as the key sizes may change. The interface to the smart card such as the commonly used cryptographic token standard [17] may be subject to revisions, or the storage capacity of smart cards certainly will increase over time. To adapt all the e-Government applications whenever such technology changes occur, such as integrating the modules for larges key sizes, certainly will turn out a costly experience. A technology-neutral approach is advisable that avoids such problems when integrating new technologies.

Actually, the e-Government application anyhow does not need to be aware of technology changes. From a process perspective, to assess whether the requirement of written form is met by electronic means, the application needs confidence that the secure electronic signature has been verified, regardless whether the SSCD is a smart card, or regardless whether RSA, DSA, or elliptic curve cryptography has been employed. Both the creation of a secure electronic signature at the citizen’s PC and the verification of the secure electronic signature at the server side can be delegated to a module that is accessed via an interface on a high abstraction level. We refer to such a module containing the security-relevant functions of signature creation and signature verification as a security capsule. The interface to access the security capsule is called the security layer.

PIN-pad

SSCD and environment

security capsule

high-level interface: security layer

personabinding

viewer

smart-card

private key for secure el. signature

second private key

info-box 1 ... info-box n

Figure 3: The security layer as a technology-neutral interface.

An example of a security-capsule is illustrated in figure 3. The SSCD consists of the smart card implementing the private key for the secure electronic signature; its environment consists of the PIN-pad to create a signature and a trusted viewer component to display the data to be signed. Creation of a secure electronic signature can


than be triggered on a high abstraction level by communicating the document to be signed via a high-level interface – the security layer – and requesting signature-creation.

In addition to signature creation components, figure 3 shows a second private key which e.g. can be used for ‘general electronic signatures’ that are not assumed to substitute a handwritten signature, or for establishing session certificates for a TLS connection. Moreover, storage containers that may hold the persona-binding for identification purposes with the PSI scheme discussed in section 2 are shown, as well as further data storage denoted ‘info-boxes’ that may hold mandates, certificates, or other data. All these functions, such as establishing session keys for content encryption, or reading or writing info boxes may be done on a high abstraction level via the security layer.

Actually, figure 3 shows the minimum requirements that have been defined as the Austrian citizen card concept. A smart card (or any other technical solution) is considered an Austrian citizen card, if the following requirements are fulfilled:

• the citizen card needs to be capable of creating secure electronic signatures, i.e. the citizen card needs to be a SSCD,

• a second private key for authentication or confidentiality needs to be implemented,

• info-boxes to store the persona-binding (including the citizen’s CRN), or for certificates, mandates or other data need to be provided,

• all these functional blocks need to be accessible via a single interface, the so-called security layer.

The security layer is specified as a request/response scheme coded in XML. Examples of such XML requests are the request of creating a secure electronic signature following the cryptographic message syntax (CMS) [18] or XMLDsig syntax [8], the verification of a CMS or XMLDsig signature, or access to an info-box. The corresponding responses are the signed data, an indication of the signature verification result, or an indication of the info-box r/w request, error codes in case of a failure, respectively. A number of so-called transport bindings have been specified; i.e. the protocols to access the security capsule. These are mainly based on transmission control protocol, internet protocol (TCP/IP). The transport bindings include access via simple TCP sockets for the transmission of the XML requests and responses, HTTP, or HTTPS.

With that scheme, technology-neutrality and forward-compatibility are provided in a manner that the changes required when major technology progresses need to be considered are limited to a single entity – the security capsule. This shall enable easy inclusion of upcoming technologies by keeping the costly back-office applications unchanged. In the following section we give an example on how authentication and identification is implemented in that concept.

5 An e-Government Example In this section, we give a case study on how the concepts that have been introduced in this paper can be employed to implement e-Government. We take requesting penal record as our sample case. Actually, this a quite frequent process, as e.g. fresh penal records are required for tenders when placing public bids. The sample case ‘penal record’ has not just been chosen for its frequent occurrence. When neglecting payment of the administrative fee, which we do for concerns of simplicity, it is a quite simple process: Once the citizen is uniquely identified by the server, the citizen’s penal record can be delivered. In addition, confidentiality of the data transmitted is required. Identification is required and the active component for creating the process-specific identifier PSI may run at the server side.


citizen’s PCInternet

Web-browser

HTTPS

security capsule

Web-serverPenal record

server

public authority

security capsule

1

23

4identifi-

cation servlet

Figure 4: e-Government example.

Figure 4 illustrates the process. Initially, at both sides the citizen’s PC and the authority’s Web-server a security capsule is running. In addition, the authority’s Web-server has an active component installed for controlling the identification and authentication process. In our sample case, the active component is a JAVA servlet. To initiate the delivery of a penal record, four steps – indicated as circles in figure 4 – are required, as follows:

1. The citizen accesses the Web-server of the public authority. To initiate the process the citizen connects to the active component (the identification servlet) using a HTTPS connection, such as via a link at the Web-server. Thus, confidentiality of the data communicated is provided at that stage.

2. The identification servlet authenticates itself by creating a so-called secure communication token (SCT). The SCT consists of the unique resource identifier (URI) of the identification servlet and a time mark. The SCT is signed by the security capsule at the public authority’s site and is transferred via the TLS connection.

3. The citizen’s Web-browser accesses the citizen’s security capsule. This is done under the Web-server’s control by either javascript or by HTTP redirects. The signature appended to the SCT signature is verified and the citizen’s persona-binding is appended to the SCT. The resulting structure, we refer to it as the identity link, is signed with the citizen’s security capsule and transferred to the identification servlet. Note, that both releasing the persona-binding and creating the electronic signature may require entering authorization codes, such as the citizen entering a PIN. This is done under control of the security capsule and transparent to the application.

4. Finally, the identification servlet verifies the citizen’s signature appended to the identity link. The signature verification process includes retrieval of certificate status information such as a certificate revocation list (CRL). The identification servlet extracts the CRN from the persona-binding and constructs the process-specific identifier PSI. This data is forwarded to the back-office application – the penal record server in our sample case.

Although we neglected the administrative fees in the beginning of this section for concerns of simplicity, its inclusion does not complicate the procedure too much. The payment of the administrative fees may be enclosed as a XML confirmation of payment signed by a bank. Such signed confirmations of payment are currently being implemented.

6 Conclusions The paper has discussed the e-Government approaches that are followed by the Austrian government. The legal provisions and strategic decisions that have been made to enable electronic means in the business relationship between the public authorities and the citizen have been presented. These are mainly the signature law and official proceedings statutes that have been amended, as well as the trend-setting decision to employ smart cards as means of easing the citizen’s access to public services. The structures to enable coordinated proceeding have been presented.

Regarding technical aspects, the paper has presented the method of deriving an identifier from the citizen’s central registration number in a way that the citizen is uniquely identified within that certain official proceeding,


but which maintains data protection requirements. In addition, the role of electronic signatures has been defined as vital in official proceedings.

The Austrian citizen card concept has been discussed as a model that provides technology-neutrality by means of an open interface called the security layer. This interface hides the internals of the citizen card implementation from the e-Government application. Thus, technological progresses can easily be integrated by replacing a single entity – called the security-capsule. The flexibility of the concept has been demonstrated on a simple e-Government case study – a request for a penal record.

References [1] Austrian signature law: Bundesgesetz über elektronische Signaturen (Signaturgesetz - SigG), BGBl. I Nr.

190/1999, BGBl. I Nr. 137/2000, BGBl. I Nr. 32/2001.

[2] Directive 1999/93/EC of the European Parliament and of the Council of 13. December 1999 on a community framework for electronic signatures.

[3] Austrian signature order: Verordnung des Bundeskanzlers über elektronische Signaturen (Signaturverordnung - SigV), StF: BGBl. II Nr. 30/2000.

[4] Posch R., Leitold H.: Weissbuch Bürgerkarte, Bundesministerium für öffentliche Leistung und Sport, IT-Koordination des Bundes, June 2001.

[5] Administration reform law: Verwaltungsreform Gesetz, 2001 amending the general offical proceedings law: Allgemeines Verwaltungsverfahrensgesetz (AVG), BGBl. Nr. 51/1991.

[6] Notification delivery law: Bundesgesetz vom 1. April 1982 über die Zustellung behördlicher Schriftstücke, BGBl. I Nr. 137/2001.

[7] Murata M, Laurent S. St., and Kohn D.: XML Media Types, IETF Request For Comment RFC 3023, 2001.

[8] Eastlake D., Reagle J., and Solo D.: XML-Signature Syntax and Processing, W3C Recommendation, 2002.

[9] ETSI SEC: XML Advanced Electronic Signatures (XAdES), Technical Specification ETSI TS 101903, 2002.

[10] Clark J.: XSL Transformations (XSLT), W3C Recommendation, 1999.

[11] European Electronic Signature Standardization Initiative: EESSI explanatory document: Description of deliverables, EESSI Steering Group, 2000.

[12] European Committee for Standardization: Security Requirements of Secure Signature Creation Devices (SSCD-PP), CWA 14169, 2002.

[13] RSA Laboratories: RSA Cryptography Standard, PKCS #1 v2.1 draft 2, 2001.

[14] National Institute of Standards and Technology: Digital Signature Standard (DSS), NIST FIPS Publication 186-2, 2000.

[15] American National Standards Institute: Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA), ANSI X9.62-1998, 1998.

[16] International Organization for Standardization: Information technology – Security techniques –Cryptographic techniques based on elliptic curves – Part 2: Digital signatures, ISO/IEC FCD 15946-2, 1999.

[17] RSA Laboratories: Cryptographic Token Interface, PKCS #11 v2.11, 2001.

[18] Hously, R.: Cryptographic Message Syntax (CMS), IETF Request for Comment RFC 2630, 1999.

Intrusion Detection Systems and IPv6∗

Arrigo Triulzi

[email protected]

Abstract

In this paper we will discuss the new challenges posed by the introduction of IPv6 to Intrusion DetectionSystems. In particular we will discuss how the perceived benefits of IPv6 are going to create new challengesfor the designers of Intrusion Detection Systems and how the current paradigm needs to be altered toconfront these new threats. We propose that use of sophisticated dNIDS might reduce the impact of thedeployment of IPv6 on the current network security model.

Keywords: Intrusion Detection Systems, IDS, NIDS, Firewalls, Security, IPv6.

1 IntroductionThe field of Intrusion Detection is generally divided into two large categories: Host-based Intrusion De-tection Systems (HIDS ) and Network-based Intrusion Detection Systems (NIDS ). The HIDS label isoften used for tools as diverse as anti-virus programs, the venerable UNIX syslog and intrusion detectionsoftware such as portsentry. The NIDS label is similarly abused extending from firewalls to networkintrusion detection software proper such as Snort [8]. A further specialisation is that of “distributed”NIDS, or dNIDS, which addresses large NIDS systems distributed over a wide network or designed follow-ing a distributed-computing paradigm. An excellent example of the latter category is Prelude IDS [10]1.We shall be discussing NIDS and in particular the rising need for dNIDS in the context of IPv6.

Historically, long before the appearance of Snort and other tools of the trade, most of the world wasusing tcpdump [11] for intrusion detection on the network: a “down to the bare metal” packet dumpingutility. The very first Network Intrusion Detection System, called Network Security Monitor, was writtenby Todd Heberlein and colleagues at UC Davis under contract with LLNL between 1988 and 1991 [2, 1].It was then extended to create NID which found widespread use in the US military [5]. This was rapidlyfollowed by Shadow, written by Stephen Northcutt and others during 1996 [3, 4, 6] again for use by theUS military. From Shadow onwards there has been an explosion of free and commercial NIDS productswhich is beyond the scope of this brief introduction (the more historically minded reader will find moredetailed information in [12]).

There has been little effort to expand the current set of NIDS to support the IPv6 protocol, mainlydue to a lack of demand. Despite years of forecasts of “doom and gloom” when discussing the famousexhaustion of IPv4 addresses there has been little uptake of IPv6 with the exception of countries such asJapan which have been very active in promoting it [13, 14]. This has meant that very little non-researchtraffic has actually travelled over IPv6 and hence the impetus for new attacks making use of IPv6 featureshas been absent.

A trivial example is the author’s personal mail server and IDS web site [15] which has been reachableon IPv6 since December 2001: there has been only a single SMTP connection over IPv6 in over a year.This is to a mail server with an average of a thousand connections per day.

At first glance this might indicate that there is little point in pursuing IDS under IPv6 but this shouldinstead be thought of as an opportunity to be ready before the storm hits as opposed to catching upafterwards as in the IPv4 space.

2 IPv4 and IPv6The discussions around IPv6 started a while back, despite what the current lack of acceptance mightsuggest, with the first request for white papers being issued in 1993 as RFC1550 [16] using the name

∗or “Why giving a sentry an infinite block list is a bad idea”.1Although they do define themselves as a “hybrid” IDS as they combine some HIDS facilities within a dNIDS design.


IPng, for “IP New Generation”. By the end of 1995 the first version of the protocol specification waspublished as IETF RFC1883 [17] which formed the basis for the current IPv6 deployment. For a detaileddescription of the header formats the reader is referred to [21].

The key differences between IPv6 and IPv4 can be summarised briefly as:

• Simplified header,• Dramatically larger address space with 128-bit addresses,• Built-in authentication and encryption packet-level support,• Simplified routing from the beginning,• No checksum in the header,• No fragmentation information in the header.

We shall now take a critical look at the specific differences which are relevant to the IDS professional.

2.1 Simplified header

The comparison between an IPv4 header and an IPv6 header is striking: the IPv6 header is cleaner, withfewer fields and in particular everything is aligned to best suit the current processors. The rationale behindthis change is simple: memory is now cheap, packing data only means harder decoding on processorswhich assume data is aligned on 4 or 8 byte boundaries.

The header is simplified by removing all the fields which years of experience with IPv4 have shown to beof little or no use. The best way to visualise the cleaner and leaner IPv6 basic header is to look at sometcpdump output representing the same transaction (an ICMP Echo Request packet) between the sametwo hosts over IPv4 and IPv6.

14:39:29.071038 195.82.120.105 > 195.82.120.99: icmp: echo request (ttl 255, id 63432, len 84)

0x0000 4500 0054 f7c8 0000 ff01 4c6e c352 7869 E..T......Ln.Rxi

0x0010 c352 7863 0800 1c31 3678 0000 3e5f 6691 .Rxc...16x..>_f.

0x0020 0001 1562 0809 0a0b 0c0d 0e0f 1011 1213 ...b............

0x0030 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 .............!"#

0x0040 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%&’()*+,-./0123

0x0050 3435 3637 4567

14:40:04.096138 3ffe:8171:10:7::1 > 3ffe:8171:10:7::99: icmp6: echo request (len 16, hlim 64)

0x0000 6000 0000 0010 3a40 3ffe 8171 0010 0007 ‘.....:@?..q....

0x0010 0000 0000 0000 0001 3ffe 8171 0010 0007 ........?..q....

0x0020 0000 0000 0000 0099 8000 60fe 4efb 0000 ..........‘.N...

0x0030 bc5e 5f3e 2f77 0100 .^_>/w..

The first obvious difference is in the version nibble, a six instead of a four. We then notice how the IPv6header appears to consist mainly of zeros. This is because the first eight bytes only contain essential data,everything else being relegated to so-called “extension headers” if need be. In this particular case thepacket contains no extension headers, no flow label, simply the payload length, next header (indicatingan ICMPv6 header), and hop limit (64, hex 40 in the packet dump). This is followed by the 128 bitaddresses of source and destination comfortably aligned on 8-byte offsets making the header disassemblyefficient even on 64-bit CPUs.

¿From an IDS perspective this is excellent because on modern CPUs taking apart the IPv4 header todetect subtle packet crafting is very inefficient due to the alignment of the data fields. With IPv6 thedecomposition of the various fields of the header and extension headers can take place efficiently. Thiscan only mean a gain in per-packet processing speed, an important measure when Gbit/s interfaces arebrought into play.

Performance is further enhanced by the lack of fragmentation information in the header: this means thatthe basic header does not need to be decoded for fragmentation information. Indeed, fragmentation isnow dealt with by extension headers. This does not necessarily make the fragmentation attacks developedfor IPv4 stacks obsolete (see [23] for a discussion of these attacks) as incorrect datagram reassembly canstill take place.

16 Security and Protection of Information 2003

2.2 Larger address space

At first glance the fact that IPv6 offers 2128 addresses might seem a blessing after all the problems withaddress exhaustion in IPv4. The indiscriminate allocation of IPv4 addresses, which were initially thoughtto be plentiful, brought us protocol violations such as Network Address Translation, at times also referredto as “masquerading”, and other “patches” to work around the problem.

If the computers currently connected to IPv4 were moved over to an IPv6 infrastructure then in effectall that would happen is a renumbering of hosts. A consequence of IPv6 is to be more than a substituteof IPv4 and bring us closer to the concept of “ubiquitous networking”: the larger address space as anincitement to connecting everything to the Internet. A number of companies are already working onso-called “intelligent homes” and in particular Internet-connected home appliances. The deployment ofIPv6 will make it possible for households to be assigned ample addresses for each of their appliances tobe directly connected to the Internet and report on the state of the fridge, the washing machine and soon.

Let us now wear the paranoid IDS implementor’s hat: to connect to the Internet each of these appliancesmust run an embedded operating system with a TCP/IP stack of some description. Furthermore it needsto have sufficient processing power to offer something like a simple web server for configuration and userinteraction. Let us further imagine that there is a security flaw with this software which allows a remoteuser to take over control of the appliance and use it as a Distributed Denial of Service host (see [22] foran exhaustive discussion of DDoS). Assuming Internet-connected home appliances become widely usedthen we are effectively facing the possibility of an attack by an innumerable amount of simple systemswhich will not be trivial to patch2.

Furthermore IPv6 has, by design, simplified the way a device can find its neigbours on a network segment.A pre-defined link-local “neighbour discovery” procedure for allocating an IPv6 address using ICMPv6has been drawn up which uses the 48bit Ethernet address as a differentiator between hosts . A NIDSnow loses what little chance it had of discovering devices having a dynamically provided address as theallocation is no longer “public”, simply changing an Ethernet card can easily blind address-based rules3.

¿From this we can draw the conclusion that a number of very useful features of IPv6 can seriously turnagainst the IDS community as it gains a foothold in the Internet and more devices, in particular embeddeddevices, are produced with IPv6 Internet connectivity.

2.3 Authentication and Encryption

Authentication and encryption are available in IPv4 through the use of IPsec [18, 19] which has not beenwidely deployed until recently. The main field of application has been that of VPN tunnels and this limitedinterest has meant that until most router vendors had implemented it there were few users. Furthermore,these few were mainly users of implementations running on open source operating systems. The mainfactors blocking the widespread use of IPsec have been the complicated setup and key-exchange protocolwhich, although necessary for proper security, did require more knowledge than the average systemsmanager possessed.

This has meant that the IDS community has been mainly concerned with channels protected by SSLor TLS (see [20] for a formal definition of TLS). For example an attack over HTTP which is visible toa NIDS installed between the source and the destination becomes invisible if transmitted over HTTPSas the standard “string in the payload” matching will fail. A number of solutions to the encryptedchannel problem have been postulated: from session key sharing by the web server allowing “on-the-fly”decryption to server-side storage of keys for later off-line decryption of captured packets. One solution isto use ssldump [30] to decode SSL but of course you need control of both endpoints to obtain the sessionkeys.

The deployment of IPv6 has the potential to worsen the “encrypted attack problem” quite dramaticallyas IPv6 has had authentication and encryption built-in since its inception4. One of the default extension

2Remote updating of software does not improve the situation much as various incidents with Microsoft’s Windows Updatefacility have shown (see, amongst the many, [27]).

3Note that DHCP is being extended to IPv6 as DHCPv6 but the availability of “neighbour solicitation” as defaultprovides a far greater challenge.

4One should note that a few features of IPv4 were rarely used as intended, for example Quality of Service and indeed,amongst the IP options, a “Security” option which is often referred to as “something used by the US DoD” and deals withclassification. A quick look at a Unix system’s include file /usr/include/netinet/ip.h is a recommended read.


headers for IPv6 is the “IPv6 Authentication Header” (AH ) which is nothing other than the same AHmechanism as used in IPsec but for IPv6.

As IPv6 deployment increases it will be interesting to see if, unlike IPsec, the AH mechanism is morewidely used and, in particular, if trust can be moved from the weak “secure web server” model5 to theprotocol layer for a large number of applications.

This is a double-edged sword for the IDS community. It is very tempting to think that widespreadavailability of encryption and authentication improves security but all this does is move the goal posts.There is no guarantee that the traffic being carried by the authenticated and encrypted link is legitimateand furthermore it will now be illegible as far as the NIDS is concerned. The solution of “sharing thekeys” as in the web server scenario becomes the nightmare of sharing the keys of every host on an IPv6network with the NIDS.

3 Intrusion Detection

Intrusion Detection is moving in two opposite directions: one is the “flattening” towards the low-end ofthe market with vendors attempting to sell “shrink-wrapped” IDS packages, the other is the “enterprise”attempting to pull together all security-related information for a large company.

Both suffer from the same problem: customers are used to viewing IDS as “something which looks like anAnti-Virus”. This view is strengthened by the behaviour of most systems: you have rules, they trigger,you attempt to fix the problem and you upgrade or download the rules. The fundamental problem is notso much the perception of IDS as the perpetration of a dangerous methodology.

Let us consider an example from a real life situation which is closest to IDS: the concept of a sentry at acheckpoint. When instructing a sentry one defines certain criteria under which something (be it a personor a vehicle of some description) is to be allowed to pass the checkpoint. One does not attempt to defineall unauthorised behaviour or vehicles as the list is fundamentally infinite. This works quite well andimprovements to the system are given by making the “pass rules” more stringent and well-defined.

3.1 White-listing – Describing normality

So why do IDS systems (and Anti-Virus systems for that matter) attempt to define all that is bad?

The answer is not as simple as one would wish: it is a mixture of historical development and the lure of“attack analysis”. Historically in computing Intrusion Detection has always been the alerting to somethingbeing amiss, for example “bad logins”. This was a good example of “white-listing” or the alerting onanything which was not known. Unfortunately “white-listing” has the disadvantage of generating a lot ofmessages and people started ignoring the output of syslog under Unix. As the alerting moved onto thenetwork the idea somehow changed into the equivalent of an anti-virus (which at the time was already awell-developed concept for MS-DOS systems) losing the “white-listing” concept on the way.

Let us now elaborate the second point: the analysis of a new attack or indeed the search for new attacksis fashionable, interesting and challenging. It is therefore a matter of pride to be the first to publish therule which will catch a new attack. Given the choice a security analyst would much rather play with anew attack than spend his time laboriously analysing the network to write “white-listing” rules.

If we consider the ruleset released with Snort version 1.9.0 (see [9]) we find definitions for 2321 rules.All of these rules are “alert” rules, defining traffic to be blocked. Then towards the end of January 2003the Internet was swamped by a new worm targeting Microsoft SQL server installations (see [7] for anin-depth analysis). Anyone running the base Snort ruleset would have never noticed but neither wouldsomeone who had just updated his rules for the simple reason that no rule had yet been written.

Furthermore there is no limit to this process: new attacks are published, new rules are written and addedto the list. Hence there is no upper bound on the number of rules.

How many sites really required remote access to their Microsoft SQL Server? Possibly a handful. So whywas the IDS not instructed to alert on any incoming (or indeed, outgoing) connection to the relevantport?

5The security of SSL certificates issued by so-called “trusted parties” has been sadly found lacking in the crucial stepof verifying the identity of the person or company requesting a certificate. These failures in identity verification make itdifficult to equate “trust” with SSL certificates despite the marketing efforts.


The key paradigm shift which is required is precisely that NIDS move from a “flag what is known tobe bad” mechanism to “flag what is not explicitly allowed”. This mimics closely what has happened infirewall design. Originally firewalls were setup to block specific ports, reflecting the academic nature ofthe Internet, they are now setup to block everything except what is deemed safe in most installations. Thedrawback of a white-listing setup is that the number of “false positives” will increase dramatically eachtime a network change takes place without informing the security team. This does have the beneficialside-effect of enforcing proper communication between the networking and security groups. There arealso sites for which white-listing will be fundamentally impossible (such as an ISP’s co-location centre)until much more sophisticated “auto-whitelisting” software becomes available; but any site with a securitypolicy, a small number of well defined external access points and internal routing points should be ableto define suitable white-lists.

Finally a further benefit: the number of rules required to define white-lists is limited and known. Thisallows a correct measurement of the performance of a NIDS under realistic conditions. As more NIDS areconnected to high-speed networks the issue of packet processing speed becomes of paramount importance.The larger the set of rules which needs to be applied against every single packet the slower the NIDSwill perform. If a NIDS is not dropping packets with 1000 rules it is not necessarily the case that itwill continue doing so with double the number. In particular as more and more content-based rulesare deployed (which require expensive string-matching) the performance can only decrease further. Onesolution is of course to throw hardware at the problem but that is only a palliative cure, a better solutionis attack the problem at its root by deploying white-lists.

3.2 Ubiquity – Monitoring needs to be pervasive

Once the paradigm has been shifted it needs to be completed. This entails the understanding that anisolated NIDS is of little use, just like a lone sentry asked to patrol an immense perimeter.

For Intrusion Detection to be truly effective it is necessary to move from the sporadic installations designedto tick a box on the security policy to a proper monitoring system. There should be NIDS installationsat every entry point into the network, be it external or indeed internal. There should be no situation inwhich there is a negative answer to the request “pull the data from that network segment”.

Once a NIDS permeates the network it becomes possible to follow “alarm flows” and have more thanthe sporadic data points which a NIDS and maybe a few firewalls can offer. If ubiquitous monitoring isdeployed with white-listing then it suddenly becomes possible to monitor abuse throughout the networkand indeed “follow through” abuse in the network. It will no longer be possible for an internal issue togrow out of all proportions before it is noticed, often as it tried to “escape” via the firewalls.

3.3 Aggregating, correlating and reducing data

The larger the enterprise the heavier the requirements from an ubiquitous NIDS deployment, in particularin terms of staffing needs.

Once data is collected there is very little point in it being left on the collecting devices. The firstrequirement for an advanced NIDS deployment is to have a central “aggregation engine” which takes allthe data from the sensors. This should probably be a database and most NIDS vendors these days offerthis capability.

Having the data in a central location means that it is now available for correlation: a perimeter-widescan for open ports should most definitely not be reported as a number of individual events but as asingle instance of multiple events. The instance is a “port scan”, the multiple events are the individualalerts issued by the sensors. This correlation can be made as sophisticated as required, for examplecorrelating by originating subnet rather than single host or by correlating using routing “autonomoussystem” numbers.

Once the data is correlated it can be reduced: if the scan is to multiple locations but the mechanismis identical there is no need to store all the individual packets. It is sufficient to store a representativepacket and then reference the collecting sensors to preserve the entity of the event.

Without these three crucial steps an advanced NIDS deployment can only fail under the weight of itsown data and the expense in identifying and locating it across the whole network.


3.4 Network knowledge, advanced analysis and management

Transforming the collected data is still not enough. The bane of all NIDS installations is the incidenceof false positives. Attempting to reduce false positives can often lead to the implementation of rulesetswhich are dangerously restricted in scope. As we discussed previously white-listing can increase theincidence of false positives unless appropriate communication between the networking and security teamsis in place.

One solution to the false positive problem is to add knowledge of the network to the NIDS. A largenumber of products used by networking teams store information about the systems on the network fromthe system type to the operating system. This information should be fed into the NIDS to help itdiscriminate between attacks which should merely be logged as “informational” and those which insteadrequire immediate action.

A trivial example is that of a web site running Apache. It is definitely of interest to catalogue attacksagainst Microsoft’s IIS web server being used against this web site but clearly they do not pose muchof a threat. Conversely an Apache attack should definitely command immediate attention. Even basicdiscrimination by “log level” can improve the quality of security analysis and response dramatically. It ismuch simpler to address a small number of problems which have been made immediately obvious by thehigh log-level than having to look for the same problems in the midst of thousands of irrelevant attacks.

Once such a sophisticated system is in place then much more advanced analysis is possible. One interestingoption is that of “Differential Firewall Analysis” [24] where the correctness of firewall operation is verifiedby means of NIDS placed on both sides of the system under monitoring. The rationale behind such ananalysis is that the worst case scenario for a firewall is that it is breached via a flaw in its software. Therewill be no record in the logs of this breach but the intruder will have penetrated the system (or indeed,a user on the inside might be connecting to the outside) and will remain totally undetected. DifferentialFirewall Analysis attempts to alert to such flaws by verifying and correlating traffic on both sides of thefirewall.

Finally, how does one manage a system of this size? It is clear that there is no hope of managing rulesetsindividually: there needs to be a centralised rule repository from which rules for the sensors are “pushed”and activated in unison. This prevents those situations in which half of the sensors are running on thenew ruleset and the other half on the older version rendering analysis impossible. Direct interactionwith the individual sensors should be prevented with all management, from code updates to individuallyturning sensors on and off, controlled from a single centralised location where all state is kept. This isalso a huge step towards 24x7x365 availability: if state is kept in a centralised location then it becomesmuch simpler to deploy replacement sensors or indeed fail-over to spares when failures occur.

3.5 Deploying Intrusion Detection suitable for IPv6

The introduction of IPv6 into an environment with a sophisticated NIDS deployment as the one we havebeen describing represents less of a worry. The most important hurdle is perhaps that of authenticationand encryption: a sophisticated NIDS would want to at least verify the validity of the AH in each packetif not check the contents of the ESP. This is perhaps the least tractable of problems: despite the presenceof hardware cryptographic acceleration cards and support for them in a number of open source operatingsystems (in particular OpenBSD, see [25, 26]) there is a noticeable difference between offering fast cryptosupport for SSL and SSH key generation and decrypting packets on the fly at megabit/s rates.

4 Conclusions

Besides integrated cryptography there is little else to differentiate IPv6 from IPv4 technology from anNIDS point of view with the exception of the larger address set. It is the uses of IPv6 technology whichpresent the greatest challenges as they might finally achive what used to be the golden grail a few yearsago of “everything on the Internet” which IPv4 did not fulfil. This will make “white listing” of paramountimportance as the definition of thousands of blocking rules based on source addresses will simply no longerbe possible. Furthermore the proliferation of connected devices will make accurate, pervasive and timelymonitoring a core necessity for any enterprise or large network.

The single largest contribution to network security in a large environment is education. There is nosubstitute for generating awareness of dangers such as the blind opening of attachments or the installation


of unauthorised software. It has also been the security industry’s greatest failure that, as more and moresophisticated tools became available, the issue of education has remained.

The deployment of IPv6 will place increased pressure on the requirement for a paradigm change fromthe current localised solutions to a much more distributed system and in particular from the “anti-viruslookalike” to a system finally resembling a proper sentry.

An NIDS should only ever be deployed as part of an information security policy that it needs to monitor,just like a sentry is part of a physical security policy. Similarly, as we do not hand a sentry a list of everyperson banned from crossing a checkpoint, we should not attempt to define rules for every possible typeof “bad traffic”. We should instead concentrate on working out what traffic is allowed on a network anddefine everything else as bad. With IPv6 the size of the address range (2128 possible addresses) and themuch more dynamic nature of IPv6 addressing would make blacklisting in firewalls an almost impossibleexercise.

It would be commendable if the current IPv6 test back-bone, 6Bone, started deploying dNIDS to seewhat challenges await us before widespread deployment of the new protocol. If we consider the trendtowards large distributed computing (European Data Grid, Asian Data Grid and other similar projects,see [28, 29]) which will require more and more address space and network communication, then dNIDSwill have to become the security monitoring solution. The amount of processing power and networkbandwidth make these grids a formidable opponent should they fall into the wrong hands (and DDoSis precisely about creating “attack” grids). This threat means that in a distributed environment it ispointless to address monitoring at a few, disconnected, points on the grid. It has to be pervasive andubiquitous, reporting centrally to the CERT responsible for that particular grid which needs to be ableto take prompt and informed action before the problem spreads.

It is perhaps surprising that NIDS design has come a full circle. Careful reading of the early papers onNID and Shadow describe nothing other than dNIDS systems with the exception of a centralised alertdatabase and enterprise-class management facilities. It is the author’s belief that the reason for this isthat, finally, the understanding that a NIDS is not anti-virus software by a different name is starting todiffuse in the industry.

5 Acknowledgements

The author would like to thank the Programme Committee for the kind invitation to SPI2003 and Dr.Diana Bosio and Dr. Chris Pinnock for valuable comments to the text.

References[1] Todd Heberlein. “NSM, NID and the origins of Network Intrusion Detection”. Private Communica-

tion, July 2002.

[2] Todd Heberlein et al. “A Network Security Monitor”. Proceedings of the IEEE Computer SocietySymposium, Research in Security and Privacy, pages 293-303, May 1990.

[3] Stephen Northcutt. “The History of Shadow”. Private Communication, July 2002.

[4] Stephen Northcutt and Judy Novak. Network Intrusion Detection. 2nd Edition, Chapter 11, pages198-199 and 220-221. New Riders, 2001.

[5] Stephen Northcutt and Judy Novak. Network Intrusion Detection. 2nd Edition, Chapter 11, page198. New Riders, 2001.

[6] Stephen Northcutt. Intrusion Detection Shadow Style. SANS Institute, 1999.

[7] Marc Maiffret. “SQL Sapphire Worm Analysis”. eEye Digital Security, January 2003,http://www.eeye.com/html/Research/Flash/AL20030125.html.

[8] Marty Roesch et al. Snort – The Open Source NIDS.http://www.snort.org/.

[9] Marty Roesch et al. Snort – The Open Source NIDS. Release 1.9.0, October 2002,http://www.snort.org/dl/snort-1.9.0.tar.gz.

[10] Yoann Vandoorselaere, Pablo Belin, Krzysztof Zaraska, Sylvain Gil, Laurent Oudot, Vincent Glaumeand Philippe Biondi. Prelude IDS.http://www.prelude-ids.org/.


[11] tcpdump. http://www.tcpdump.org/.

[12] Paul Innella. “The Evolution of Intrusion Detection Systems”. SecurityFocus, November 2001,http://www.securityfocus.com/infocus/1514.

[13] “Overview of IPv6 Projects around the World”. IPv6 Forum,http://www.ipv6forum.org/navbar/links/v6projects.htm.

[14] “UK IPv6 Resource Centre – Whois service”. Lancaster University and IPv6 Forum,http://www.cs-ipv6.lancs.ac.uk/ipv6/6Bone/Whois

[15] Arrigo Triulzi. “IDS Europe”. https://ids-europe.alchemistowl.org/.

[16] S. Bradner and A Mankin. “IP: Next Generation (INng) White Paper Solicitation”. IETF, December1993,http://www.faqs.org/rfcs/rfc1550.html.

[17] S. Deering and R Hinden. “Internet Protocol, Version 6 (IPv6) Specification”. IETF, December 1995,http://www.faqs.org/rfcs/rfc1883.html.

[18] S. Kent and R. Atkinson. “IP Authentication Header”. IETF, November 1998,http://www.faqs.org/rfcs/rfc2402.html.

[19] S. Kent and R. Atkinson. “IP Encapsulating Security Payload (ESP)”. IETF, November 1998,http://www.faqs.org/rfcs/rfc2406.html.

[20] T. Dierks and C. Allen. “The TLS Protocol Version 1.0”. IETF, January 1999,http://www.faqs.org/rfcs/rfc2246.html.

[21] Adolfo Rodriguez, John Gatrell, John Karas and Roland Peschke. TCP/IP Tutorial and TechnicalOverview. Chapter 17. IBM & Prentice Hall, October 2001,http://www.redbooks.ibm.com.

[22] Dave Dittrich. “Distributed Denial of Service (DDoS) Attacks/tools”. University of Washington.http://staff.washington.edu/dittrich/misc/ddos/.

[23] Jason Anderson. “An Analysis of Fragmentation Attacks”. SANS Reading Room, March 2001,http://www.sans.org/rr/threats/frag attacks.php.

[24] Arrigo Triulzi, “Differential Firewall Analysis”. In preparation, February 2003.http://www.alchemistowl.org/arrigo/Papers/differential-firewall-analysis.pdf.

[25] “Cryptography in OpenBSD”. The OpenBSD project. http://www.openbsd.org/crypto.html.

[26] Theo de Raadt, Niklas Hallqvist, Artur Grabowski, Angelos D. Keromytis and Niels Provos. “Cryp-tography in OpenBSD: An Overview” in Proceedings of Usenix, 1999.http://www.openbsd.org/papers/crypt-paper.ps.

[27] John Leyden. “Code Red bug hits Microsoft security update site”. The Register, July 2001.http://www.theregister.co.uk/content/56/20545.html.

[28] “The European Data Grid Project”. CERN. http://eu-datagrid.web.cern.ch/eu-datagrid/.

[29] “The Asian-Pacific Grid Project”. http://www.apgrid.org/.

[30] Eric Rescorla. ssldump. http://www.rtfm.com/ssldump/



Introduction and Security Perspective of Peer-To-Peer Protocols

Eric Vyncke

[email protected]

Cisco Systems Belgium

Abstract Since a couple of years, there is a new network application: peer-to-peer networking. This is a new paradigm for communication; the usual client to server interaction is now replaced by a pure client to client (a.k.a. peer-to-peer) communication. The main application is currently to share files; alas, quite often illegally obtained movie or music files. Besides this obvious copyright infringement, the protocols used are not always secure. This paper will first describe commonly used protocols and will explain a couple of vulnerabilities in the existing protocols. Strategies to address the security issues are also described and commented.

Keywords: security, copyright, content, buffer overflow, denial of service, peer-to-peer, network.

1 Introduction to peer to peer networking

1.1 What is peer to peer networking?

The common method to share either information or resource (like CPU) is to store them on a centralized place called the server. In the case of information, this can be a file server or a web server. Resource server can be a large mainframe or a Unix server accessed by dumb terminal emulation, X Windows terminal or even client server applications.

When information needs to be shared, it has to be uploaded to the server. When information needs to be retrieved, the client accesses the server to fetch a file. The same happens when a fast and powerful CPU resource needs to be used, the client will connect to a CPU server.

This model has its own limits: it is complex to publish information, the information must be stored in a remote server (hence increasing bandwidth utilization), … But, it is also very powerful regarding control and security: centralized audit of all retrieved files, optional centralized authentication and authorization, …

In order to make the publication and retrieval operations simpler, the peer to peer networking simply allows all clients to share its information. A distributed search mechanism is implemented so that other peers can locate the information wanted. Then, one peer can connect to another peer to retrieve the file. Usually, as soon as the peer fetched the file, it automatically shares this file. This allows a neighbouring peer, which also wants the same file, to start downloading it from its neighbour.

Peer to peer applications are also able to download the same file from multiple peers by retrieving different chunks from different peers, hence, reducing the download time.

This new paradigm is not limited to file sharing, it can also be done for CPU sharing. E.g., there are a couple of distributed applications that can run in a massively parallel way. Examples are for cipher brute force attack, folding proteins [4], running fast Fourier transform on cosmic noise to find potential extra-terrestrial intelligence [5], …

1.2 Who is writing peer-to-peer applications?

There are business and scientific interests for CPU sharing, hence, companies like Microsoft, Intel and IBM are members of a couple of forums (Global Grid Forum [6], P2P Forum, …).


Until now, there is neither business nor scientific interest for file sharing peer-to-peer networking. The main interest came from (usually) illegal file sharing for movies or music. Hence, individuals develop most of those applications.

Some of the developers are doing it really for free but others are doing it to earn some money. They are using a specific business model, which is called 'adware', i.e., software paid by advertisements. Indeed, the application is displaying advertisements (fetched from an Internet server) while the application is running.

There is a big exception: Kazaa, which is not developed by an individual but by a company. The revenue of this company is also coming from advertisements displayed by the application.

2 Protocol description

2.1 A three tiers architecture

Most of the peer-to-peer applications are using three tiers architecture:

• seed hosts: a few hosts with static IP addresses or host names which maintain and serve the list of other peers that are using dynamic IP addresses;

• search servers: multiple hosts with dynamic IP addresses, they maintain the list of the shared files; their main role is to allow search operations;

• peer hosts: a huge amount of hosts with dynamic IP addresses, they share their local files and retrieves files from other peers.

It can be seen that a few hosts, the seed hosts, must always be active and addressable. Those hosts are either hard coded in the application or can be configured by the user (using IRC, forums, web,….as the source of information).

The search servers are usually elected by the protocol based on the CPU performance, the network connectivity, … For some applications, the peers and search servers can be collocated.

While there are usually just a couple of seed hosts, there are hundreds of thousands of peer hosts.

2.2 Usual steps to execute

When a new computer wants to join the peer-to-peer network, it usually takes the following steps:

1. seed: connect to a seed host to get the IP addresses of a couple of other peers (and possibly search servers);

2. register: publish its own IP address to the seed host;

3. connect: to a couple of other peers (and possibly search servers);

4. publish: the list of local files to search servers;

5. search: for desired files on other peers or on search servers;

6. retrieve: files from several peers in parallel to go faster.

Of course, operations 5 and 6 can be repeated.

Some protocols will not execute all those steps, i.e., Gnutella has no concept of search servers, so the step 4 does not exist.

2.3 Description of Gnutella

While Gnutella1 is not the most popular protocol, it is the more distributed one; there are only two kinds of nodes: peers and seed hosts. This is the reason why only Gnutella is described in this paper.

1 Gnutella appears to be named after the famous chocolate brand!


Gnutella protocol specification is publicly available and there is even a long-term project to publish this protocol to the IETF. There are also future extensions to handle the next generation of IP protocol: IPv6. Gnutella is implemented in several applications: Limewire, Bearshare, … both on MS-Windows and Linux operating systems.

2.3.1 Seed and registration

Every Gnutella node (called servent from server and client) generates randomly its own unique identification. This identification is called ClientID.

Upon start, the servent connects to user configured seed host using a protocol called gwebcache. The seed host will give 20 IP addresses of other active servents.

2.3.2 Connection

The new servent will then connect to the other servents by using a TCP connection, each of the TCP connection will be identified by a connection id, conn-id. There is neither authentication nor confidentiality provided on the TCP connection. Since all servents are connected to all other servents through those persistent TCP connections, the Gnutella network is really a partially meshed network.

As soon as the servent is connected to other servents, it will also listen to incoming TCP connection from newer servents.

The Gnutella protocol is implement by a couple of messages. Those messages have their own random identification, msg-id, which is assumed to be unique in the network. Note: the message usually does not contain any information about the originator (no IP address, no name, no clientID, …) in order to provide anonymity.

Every servent maintains a table of existing message identification and from which TCP connection it has been received: <msg-id, conn-id>. Upon receive of a message:

• if the msg-id is not yet in the table, the message will be flooded, i.e., forwarded to all other TCP connections; a new entry <msg-id, conn-id> will be added to the table;

• else, the message is forwarded to the connection associated to this msg-id. This is typically used for replies.

Note: this is very similar to the learning bridge process of IEEE 802.1.

As the topology is partially meshed, there are loops in the Gnutella network; hence, all messages include a time to live, TTL, field. This TTL is initialised at a small value by the message originator and decremented by each forwarding servent. As soon as the TTL reaches 0, the message is simply discarded. This simple technique prevents a message to travel forever in the network.

2.3.3 Search

When a servent wants to search for files matching a pattern (like '*.avi' file specification), the search pattern is flooded over the network in a message. This servent will be called the consumer servent in this paper.

All servents receiving and forwarding this search message will have to reply if they have files matching the search pattern. The reply message will be routed back to the source based on the <msg-id, conn-id> tables. This message contains the list of matching local files, the ClientID and IP address of the servent have the files. Those servents will be called remote servents in this paper.

2.3.4 File retrieval

The consumer servent will first try to open a direct TCP connection to the remote servent(s). This connection will use a protocol very similar to HTTP.

Obviously, if the remote servent is protected by a firewall preventing connection initiated from the Internet, this connection will fail. But, Gnutella has a way to bypass firewalls. This is the push message. This message is sent over the Gnutella network to the destination ClientID. Then, it is up to the remote servent to open a TCP connection to the consumer servent. This connection originates from the inside of the firewall and will usually be permitted.


Note: two servents protected by two firewalls will never be able to exchange files.

3 The threats This paper is not about the obvious copyright infringement when peer-to-peer is used to share copyrighted material. But, it will rather describe other security threats.

3.1 Contents sharing

The configuration of peer-to-peer application includes the specification of the local file system directory to share. Some users are naïve enough to share their whole disk including confidential documents… This is worrying since peers outside of the firewall will be able to retrieve this document through the push message.

Some applications were also poorly written and were sharing more than expected! E.g., Bearshare could be exploited by a directory traversal when file to be retrieved was called '..\..\config.sys' (the '..' is usually a short cut to change to the upper directory).

The retrieved content can also contain virus and Trojans. Specially, when the user is dumb enough to execute a file retrieved anonymously from an unknown location!

But, this also applies to non executable contents; e.g., a multi-media .ASF files can also dynamically open URL (which could download hostile java applet, …).

3.2 Worms

Peer-to-peer network are usually well connected and fast. This is a target of choice for worms.

There have been already a couple of worms for those networks. The spread mechanism is easy: every infected peer simply replies 'yes I have this file' for all search requests and sends the worm renamed as the searched file. Examples include Worm.Kazaa.Benjamin and Gnutella.Mandragore.

3.3 Covert channel

Hackers use some Internet Relay Chat, IRC, networks to control remote trojanized PC. They use IRC networks as a covert channel to initiate denial of service attacks from those thousands of remote PC.

As the peer-to-peer networks are even larger than IRC ones, it can be expected that they will shortly be used as a covert channel to control trojanized PC.

3.4 Bandwidth hog

But, the major issue with peer-to-peer networking is about the network bandwidth utilization…

This is specially applicable to schools and Universities where students are downloading numerous large movie files (typically about 600 Mbytes). The existing networks were not provisioning for such network application. This means congested links and a slower response time for all other applications.

The Internet Service Providers are also complaining because their business model and network provisioning assumed that residential users (on ADSL or cable modems) were mainly downloading files while with peer-to-peer, they are also uploading files. This is forcing some ISP to change their tariff structure and to go to a volume based tariff, which is heavier to manage than the previous flat rate. A large European ISP measured that 40% of its traffic was identified as peer-to-peer in July 2002.

But, on the security, this also means that security devices have to handle much more traffic than expected. This is of particular importance for network intrusion detection systems, NIDS. NIDS are sniffing all traffic on a network and checks for attacks (for monitoring, alerting or pro-active prevention of attacks). As the NIDS algorithms are quite complex, a lot of NIDS will give up when the traffic is too high. So, they can miss a real attack in the mass of innocent peer-to-peer traffic.


3.5 Application security

The peer-to-peer applications have probably a couple of vulnerabilities (buffer overflow, directory traversal,…) due to bugs in the software code.

When those vulnerabilities will be discovered and exploited through the peer-to-peer network, a remote attacker could gain control of thousands of hosts. Those hacked hosts could be used to initiate a denial of service attack or as stepping-stones to crack into other machines.

The fact that the source code of most applications is not available makes things even more dangerous since nobody is able to check the security of the code.

3.6 Auto Update

In order to make things simpler for their users, some peer-to-peer applications actually use the network to propagate the newer version of the applications. In some cases, the user is not even notified that a new version is installed in background.

As the new version is rarely authenticated, it could be possible to inject a faked new version containing Trojans or back doors.

This is specifically applicable to the adware where the adware engine is independent of the whole application. Hopefully, there are a couple of tools that can remove adwares from an existing host (notably lavasoft).

4 Blocking peer-to-peer networking? Nowadays, all peer-to-peer protocols can use dynamic and/or configurable TCP ports. This means that firewalls cannot block those applications when the user configures them on non default ports like port 80 (also used by HTTP).

4.1 Throttle strategy

If the default ports are blocked by a firewall or by a packet filtering router, the user will notice that something is wrong. He will look on the web for a solution and will configure the application to use non default ports.

So, the throttle strategy is simple:

• do not block the default port [1]: so, user will keep using those ports;

• but, rate limit the traffic on those ports to a very small amount of the available bandwidth

It is pretty common for network device like routers and switches to throttle some traffic. This strategy addresses only the bandwidth threat. It does not prevent all other issues. It is mainly used by Universities and schools.

4.2 Block all strategy

In the block all strategy, the security policy is stricter: block all traffic to the Internet and only open some well known ports (web, mail, …) and force the traffic to go through an application proxy. If the firewall allows only HTTP traffic, even if the peer-to-peer application is configured to use TCP port 80, the proxy will block the connection since the protocol is not fully HTTP compliant.

This strategy is already in place like banks or other security savvy organizations. Peer-to-peer security issues in their premises do not impact them.

Nevertheless, if their employees are using the same laptop computers at work (with such a strict security policy) and at home (where there is no security policy enforcement at all), the organization is at risk. Hence, there is a real need for intrusion detection and prevention in the internal network.


4.3 Block seeding

The block seeding strategy relies on the only static information used by peer-to-peer applications: the static IP addresses (or host names) of the seed hosts. If the security policy prevents any traffic to the seed hosts, then the internal hosts cannot join the peer-to-peer network.

The issue is of course to have a list of those seed hosts. For some applications like Kazaa or WinMX, it is easy. But, for Gnutella and eDonkey this is mostly impossible has there are numerous seed hosts and they are changing every week or so.

So, this strategy is mostly hypothetical until some vendors offer as a service the list of those hosts (like the black list of spam relays).

4.4 Traffic pattern recognition

The last technique is about traffic pattern recognition. As far as the author knows, there is no implementation of this technique yet.

It is based on the fact that peer-to-peer communication has a typical pattern:

• Long lasting TCP connections;

• Single connections to remote hosts;

• A lot of traffic.

Routers and firewalls using techniques like Netflow or IP flow export [3] could spot the peer-to-peer hosts after a couple of minutes and either block or throttle the traffic addressed to this IP address.

5 Conclusions Peer-to-peer networks are a relatively new paradigm for communication. They offer resilience, throughput, anonymity, and performance. Some protocols, like Gnutella, are also well designed for their purpose.

Besides the obvious copyright infringement issue, they also have some security threats. Alas, it is currently mostly impossible to identify some IP traffic as peer-to-peer to apply a specific security policy to it.

The current mitigation techniques include:

• Throttle strategy: do not try to block but rather throttle the traffic so that users will keep using the default ports;

• Block all strategy: block all traffic except an explicit list of TCP ports, peer-to-peer protocols will be blocked;

• Block seed hosts: block all IP traffic to the seed hosts but difficult to have the list of all seed hosts;

• Traffic pattern recognition: recognize the typical traffic pattern and either block or throttle.

In summary, this is still a research area since the peer-to-peer developers are also trying to modify the protocol to evade any policy enforcement.


References [1] Ballard, J: File Sharing Programs/Technologies, in http://testweb.oofle.com/filesharing/index.htm,

2001.Seidel, E: The Audio Galaxy Satellite Communication Protocol, in http://homepage.mac.com/macdomeeu/dev/current/openag/agprotocol.html, 2001.

[3] Quitteck, J., Zseby, T., Claise, B. and Zander, S., Requirements for IP Flow Information Export, draft-ietf-ipfix-reqs-09.txt, work in progress, IETF, 2003.

[4] Pande, V, Folding@home Distributed Computing, in http://folding.stanford.edu/, Stanford University, 2002.

[5] UC Berkley, SETI@Home Search for Extraterrestrial Intelligence, in http://setiathome.ssl.berkeley.edu/, 2003.

[6] Global Grid Forum, in http://www.gridforum.org/L_About/about.htm, February 2002.

http://testweb.oofle.com/filesharing/index.htm

Security Aspects of Homogeneous Environments

Hanus Adler

[email protected]

Actinet Informacnı systemy, s.r.o.U Bulhara 3

Praha 1, Czech Republic

Abstract

Rapid development of computer technologies over the last decade, together with the rise of interconnectednetworks among which Internet is the most prominent, brought along major problems that were notanticipated, or were largely underestimated, at the time when currently popular software packages werebeing developed. While the problems, or design flaws, have always caused some damages and much griefto the affected organizations, only in the last few years they became a global phenomenon costing millionsof dollars in damages worldwide.

The fast growth of the Internet and the fact that never before had so many people such an immensepotential to communicate with other people anywhere in the world is almost certainly the primary causefor this development. Nevertheless, it is quite clear that it is significantly aided by the fact that thecomputing environment people are commonly using is now nearly homogeneous all over the planet, andthat the quality of this environment is undoubtedly well below reasonable expectations.

Over the recent years, computer industry has gone a long way towards uniformity and homogeneity.While it may have seemed desirable for many mainly economic reasons, it has proved rather dangerousfrom many other viewpoints. Today, even the economic reasons are questionable.

This contribution aims to describe the problems and dangers associated with homogeneous environments,and to argue that the currently popular worldwide usage of such environments causes significant damagesand should be avoided whenever possible. Possible countermeasures and solutions now available will bealso discussed.

Keywords: IT security, Virus, Trojan Horse, Homogeneity vs. Diversity.

1 IntroductionAt approximately 2:00 PM GMT-5 on Friday March 26 1999 webegan receiving reports of a Microsoft Word 97 and Word 2000

macro virus which is propagating via email attachments.

—CERT Advisory CA-1999-04

On the morning of Friday, March 26, 1999, hardly any common computer user was aware that there wassomething called a macro virus. Three days later, everyone felt like an expert on them, because of theconstant attention TV and other media were giving to the Melissa macro virus over the weekend.

While Melissa was not the first such virus, and wasn’t even particularly mean, there was something thatmade it different from previous ones, and one of the most successful viruses to date. The novelty wassimple and elegant—the virus just took some 50 addresses from user’s address book and mailed itself tothose addresses with a subject that was likely to attract the recipient to click on it.

How was that possible?

The author did not have to search for addresses in all the various places mail clients could be storingthem on the hard disk, nor dissect various text or binary formats that they could be using. It was enoughto rely on the prevalence of a single operating environment and one application suite with its internalprogramming language. Using the macro language, it was easy to develop a virus that would retrievevictim’s e-mail contacts and re-send itself to them.

Melissa’s author simply recognized the right moment at which a great percentage of corporate users wereforced to use the same software for documents and communication, and general awareness of securityissues was low. Microsoft Windows, Microsoft Office, Outlook, Outlook Express, Exchange were becoming


a de facto standard on most desktops throughout corporations, and were easily available to home usersas well, which enabled virus authors to develop and test their code without needing access to special HWor SW that would normally be unavailable to home users.

What also contributed to the success of Melissa was that although in 1999 there was still a significantnumber of people that used a different mail client, thanks to Microsoft’s eager pushing of their productsin all encompassing bundles, even those who didn’t actually use Outlook often had it installed as part ofMicrosoft Office on their machines—ripe for misuse.

Microsoft Visual Basic that became part of the Office suite provided tools that enabled practically ev-eryone to carry out most complex tasks with their computers without actually having a good knowledgeof programming in assembler or C.

Finally, the Internet provided an environment where a virus or worm could propagate rapidly usingstandardized protocols for information exchange—SMTP being the first, peer-to-peer file sharing andchat protocols like SMB, ICQ and others to follow.

Melissa was just the first virus that successfully demonstrated the dangers of homogeneity, connectivityand programmability1 put together in the commonly available combination of the ubiquitous Wintelplatform, Microsoft application suite and the Internet.

2 DangersHomogeneity, connectivity, programmability.

—Carey Nachenberg, Symantec Corp., 1999

2.1 Workstations

2.1.1 Wintel“There are no significant bugs in our released software

that any significant number of users want fixed.”

—William H. Gates III, Microsoft Corp., 19952

To define the dangers threatening today’s popular computing environments, we must identify their vul-nerable parts.

Various estimates suggest that some 90% of common user workstations run one of the Microsoft Windowsfamily of operating systems on Intel hardware platform. These are mostly fully equipped PC’s, not thinclients. On practically every such workstation, there is a copy of Microsoft Office used for creating andreading documents, spreadsheets, presentations etc. Microsoft Outlook (or Outlook Express) is commonlyused for e-mail communication, and most of their users also use Microsoft Exchange server for groupwaretasks.

Let’s call this environment “Wintel” in the following text.

Most of the Wintel workstations, especially in corporate environments, are interconnected with each other,with internal servers, partner networks, and with the Internet. Also homes now often have some Internetconnection, and the number of permanently connected home users steadily grows as affordable permanentconnection becomes available through Cable TV, ADSL, Freenets and other community networks.

There are several important problems associated with Wintel environment:

1. it is marketed as easy to use, best choice for less knowledgeable users, and those who do not wantto know anything about the tools they are using,

2. it hides important information from the user,3. it commonly does important things without asking the users, behind their backs,4. on the other hand, it is perpetually asking the user to confirm reading most unimportant info

messages and actions,5. depending on the OS version, it may have none or little security mechanisms implemented,6. bug fixes are not readily available (some bugs are never fixed, other fixes may be released with

considerable delay)1See “The Evolving Virus Threat” by Carey Nachenberg at http://csrc.nist.gov/nissc/2000/proceedings/papers/

019.pdf2See http://www.cantrip.org/nobugs.html


7. security mechanisms implemented on the recent OS versions are rarely used correctly (or at all),8. it is mostly backward compatible even for MS DOS based applications,9. practically every machine can be expected to run a similar set of mostly Microsoft applications

whose lack of security was repeatedly demonstrated in the past,10. over-integration of applications eases misuse,11. its applications often make it extremely easy for a user to run untrusted code,12. users are encouraged to use dangerous formats and ways for information interchange.

As a result, people are showing a tendency to

1. refuse to learn how to use their computers and the Internet in a secure manner, having been leadinto belief that MS Windows and MS applications are so easy no education is necessary,

2. ignore important messages (Windows require the user to click “Yes” or “OK” buttons so often thatafter a while no user is actually reading the text of the messages any more),

3. ignore suspicious behaviour of their system,4. ignore security-related information sources and importance of bug fixes,5. freely run executables and open documents received by e-mail without any real idea whether they

can securely identify the sender and the sender’s trustworthiness6. carry out normal work as users with administrator privileges7. send zips, crypted files as executable files, and write e-mails in Word or text/html instead of

text/plain, which consequently lowers general recipient awareness of the dangers associated withsuch formats in e-mails.

Although most of the corporate networks employ security administrators, have some kind of a securitypolicy in place and make great effort to implement security measures protecting their users from attacks,all the security effort can be easily thwarted by a simple action of an unsuspecting, naıve Windows user.

Although recent Windows versions can implement packet filters and personal firewalls for Windows are onthe rise, home computers are still often unprotected, and even behind the personal firewalls, vulnerableto many attacks.

2.1.2 Other Platforms“Whip me. Beat me. Make me maintain AIX.”

—Stephan Zielinski

Number of non-Wintel platforms on users’ desktops is rather low. Largest share probably goes to AppleMac, however thanks to the nature of Linux and similar systems, which can be downloaded from theInternet for free and used on an unlimited number of computers, it is quite impossible to be quite sureof that.

Also, though most of these systems, including MacOS, are now Unix-based, they substantially differentiatebetween each other on many accounts. Even those systems that stem from the same foundation, likeLinux systems, are often quite different from distribution to distribution, or even from one to anotherinstallation.

These systems were designed as multi-user from the very start, and even though Unix security isn’tperfect, user space programs would normally only affect files and programs owned by the UID1 withwhose rights they are executed. As it is very uncommon for a Unix user to own any programs, only theaffected user’s data could be compromised or destroyed.

There are few applications that would be used by every Unix-based system user, and even though someare very popular, like desktops (Aqua, KDE, Gnome and CDE) and browsers (Mozilla and other Geckobased ones, KDE’s Konqueror, Apple’s Konqueror-based Safari), none of them is actually used by anoverwhelming majority of users, although some plugins like Flash are a possible threat for all of theirusers. As for e-mail clients, Mozilla, Evolution, KMail, Mutt and Pine seem to be among the leadingprograms, but none is used by a substantial majority of users.

While there are quite a lot of Office suites for Unix based systems, most people are using either MicrosoftOffice (which is only available for MacOS) or OpenOffice.org, which is largely compatible with MS Office.

1UID = User ID, an account number on Unix-based systems


Other popular packages include TEX (LATEX), Adobe Acrobat Reader or xpdf. Although MS Office andOpenOffice.org are probably the most vulnerable entry point to the non-Wintel world, they are not usedby everyone either.

Currently, no universally applicable threats to the non-Wintel platform workstations are known—partlybecause of the much smaller number of desktop users, but also because these platforms present a muchwider spectrum of applications in common use than the Wintel platform, there are many different pro-cessors in use, and last but not least also because users of these platforms (with the exception of MacOSusers) nowadays are more knowledgeable than Windows users, which makes them less vulnerable to someforms of attacks.

2.2 Servers

2.2.1 Wintel“We don’t do a new version to fix bugs. We don’t.

Not enough people would buy it.”

—William H. Gates III, Microsoft Corp., 19951

The situation is slightly different on the server market. First of all, servers are maintained by adminis-trators who usually have at least some knowledge of security. Servers accessed from untrusted networksnormally do not run applications like MS Outlook or MS Office,2 and do not usually run too many serverapplications at one server.

Nevertheless, the applications that are normally run are easy to guess on a great majority of Wintelservers:

• MS IIS for WWW and FTP servers• MS IIS for a webmail frontend to MS Exchange• MS Exchange for e-mail transfer and groupware functionality• MS SQL or MSDE as database backends• MS DNS server (based on bind)

These applications are often too complex for the intended task, and over-integrated with the system orwith each other in many quite unexpected ways.

For example, Microsoft’s IIS is often used for Web servers, but includes also FTP server and Gopherserver in one large program. One of the attacks on Web served from IIS servers actually made use ofa DoS against the FTP server code. If the servers were programmed as separate programs, the worstscenario would result in an unreachable FTP server. By connecting these servers together into one singleserver, Microsoft’s design decision enabled a successful attack on FTP to bring down all other IIS serviceswith it.

Wintel servers are always running some services that are not strictly necessary on a server. The WindowsGraphical User Interface cannot be switched off, and although it is actually possible to remove MicrosoftNetworking, the system complains with a false warning that scares most less experienced administratorsfrom doing it. Indexing server is often run behind IIS without being used.

For remote administration, Windows administrators often resort to telnet or VNC on the older variantsof Windows, which means poorly authenticated and unencrypted connections are made to the servers.Since Windows 2000, Microsoft has bundled a Terminal Server into Windows which brought a majorimprovement, however it still lacks a file transfer capability which forces the administrators to complementit with FTP, SMB or other insecure file transfer services.

Windows services are often using Administrator or System account to run, which means that by com-promising the server programs, an attacker usually gains enough rights to manipulate the whole server,or at least most of its services.

As SQL Slammer proved, many of the Wintel servers are running the same insecure service openedeither to the Internet, or within large corporate networks. A virus or worm is thus able to count on anabundance of very similar targets and the effort required to endanger a large number of Wintel serversnot significantly higher than an attack on a single server.

1See http://www.cantrip.org/nobugs.html2It must be noted, however, that e.g. some versions of MSDE (limited free runtime of MS SQL) have been observed to

require MS Office to install.


2.2.2 Other Platforms

Unix based servers are also suffering from little variety of the software they are running. Most of the Webservers are run on Apache (though there are a number of iPlanet, Roxen and others), a great majority ofDNS servers run a version of bind. A large majority of Unix servers also depend on OpenSSH (and withthat, on zlib and OpenSSL).

Many older Unix machines used to run sendmail for e-mail handling, but quite a lot of them have switchedto more secure alternatives like Postfix or Qmail by now.

Fortunately, different CPU architectures and many differences in the Unix variants are making a universalattack difficult. Even those attacks that are successful may be limited by the good practice of runningevery service under a different UID which has only those rights that are necessary for the service torun. Some administrators also run publicly available services in a so-called chrooted environment,1 whichfurther isolates the service from the server.

In comparison with the Wintel world, attacks are limited in scope by several factors, but across a singlehardware platform and one operating system, some attacks may endanger a rather significant number ofservers as well, although by compromising one service, the attacker may not always be able to compromiseanything else on the server.

2.3 The infrastructure

One of the most recent attacks, SQL Slammer deserves slightly more attention than others, because itimpacted not only vulnerable systems and networks of negligent administrators, but practically everyoneon the Internet—by using up all available bandwidth, the attack effectively became the first globalDDoS, though this was probably only a side effect. One could argue that this DDoS was so successfulbecause the Internet infrastructure in itself is a very homogeneous environment. ¿From the protocols, allbuilt on IPv4, to hardware which is mostly Cisco based, the Internet is just as vulnerable as any otherhomogeneous entity.

3 Learning from the Past“The PC industry—and Microsoft—have done a terrific job of

training us to live with shoddy and buggy products, somethingwe do not tolerate in our cars, TVs, or phones.”

—Jai Singh, Editor of CNet’s NEWS.COM, July 1998

Although Melissa was the first attack so successful to become well known to general public, it was onlyone in a long line of attacks whose common denomination was that they were aided by homogeneity.

Starting with the legendary Morris worm, over Chernobyl, Love Bug, Explore.Zip to Nimda, Code Red,SQL Slammer and various other recent attacks, the level of homogeneity of the victim’s environment hadalways considerable impact on the damages.

It is nevertheless a sad fact that the reaction of the vendors was, and still seems to be, inadequate, oreven counterproductive. For most software developers,2 the notion of security is perceived as a nuisance,something that hinders and slows down development, prevents adding functions, makes interoperabilitydifficult and, last but not least, has little impact on their salaries. From a developing company viewpoint,liability is mostly a non-issue thanks to carefully crafted disclaimers and licensing conditions. After all,users don’t expect software to be flawless and few of them would be able to distinguish mere bugs fromdesign flaws anyway.

Therefore, security is often an afterthought, if it is considered at all during software development. It isoften left out completely with reference to third party security devices, like anti-virus software, firewalls,intrusion detection etc.

Instead of concentrating on making their products secure, software developers are thoughtlessly addingfeatures, improving and re-organizing user interface, changing licensing schemes, renaming the productsand release new versions prematurely, without adequate testing, as Marketing Departments are apparentlytaking over R&D. Many products, even security products, are poorly documented and/or emit all kinds of

1chroot is a command that allows an administrator to run a program with a different root directory. The program thenhas no access to files above or beside the chosen directory.

2We should possibly exclude developers of so-called “trusted” products like e.g. Trusted Solaris, where security is takenextremely seriously.


undocumented cryptic error messages, possibly in an attempt to coerce customers into buying expensivesupport packages. To make things worse, companies are often trying to cover up bugs, and do not releasethe information they have nor workarounds or bug fixes for the problems in a timely manner and atsuitable fora. Some companies even engage in despisable new fashion of suing those who discover andpublish bugs and flaws of their products, in what seems to be a desperate attempt to hide their ownfailures, further limit liability and hinder research and free speech in the scientific community.

As the largest software developer in the world, Microsoft is without doubt responsible for much of theproblems that are now plaguing the Wintel platform. Although far from accepting the responsibility,after almost thirty years in business Microsoft finally recognized the need for security last year and gavetheir developers a one-month pause to learn about security and review their code for possible bugs. Whileit was certainly a big step forward in the right direction, it is not yet clear what effect it is going to havein the long term. One month is neither enough to review all the millions of lines of code, nor acquire the“security first” approach to development that is needed, especially for developers who must deal with allthe design decisions inherited from the past.

4 Conclusions“Microsoft’s biggest and most dangerous contribution to the software industry

may be the degree to which it has lowered user expectations.”

—Esther Shindler, OS/2 Magazine

What allowed so many vendors to behave irresponsibly? Was it indeed lack of customer interest in securityas suggested by Bill Gates in 1995? And if it is, shouldn’t vendors automatically have disregarded suchlack of interest and automatically subordinated their development to requirements of security experts intheir customers’ best interest? In any case, they have not, and now we are learning the consequences.

We should be also learning how to prevent or at least minimize the consequences, and how to secure moreresponsible behaviour of both vendors and customers for the future.

It seems that in the past, software developers lacked proper incentives to pay security enough attention.Following are suggestions that could gradually improve the situation:

1. Education of both Users and Administrators

(a) Regular user education on elementary rules how to use the Internet securely is necessary toreduce the impact of worms and viruses that may often rely on user misconduct.

(b) Administrators should be educated on security even if they are not primarily security adminis-trators. They should follow both vendor and public security sources—both to further educatethemselves on incidents and developments in the security field, and to be informed about possibleproblems in software in their care.

(c) Vendor decision makers and developers should be educated on security and learn to use theknowledge to avoid insecure designs.

All the groups must acknowledge the fact that education is a never ending process, as new kindsand methods of attacks are being developed all the time.

2. Preventing Homogeneity

(a) For every application, the most suitable platform should be selected, and slight preference shouldbe given to platforms different from those that are currently in use. For example, if a companyuses MS Exchange for their internal mail and groupware servers, it would be advisable that aPostfix on Linux or FreeBSD is used as the mail gateway to the Internet instead of anotherMicrosoft Exchange. If a Webmail front end to the mailing system runs on MS IIS, other webservers like Apache might be a good choice for the company Internet presentation. And ifMicrosoft Windows are the operating system at most of the company desktops, it is advisableto use some Unix variant with Samba file sharing software as the file servers.

(b) Proprietary data formats should be avoided if possible, especially when data exchange withexternal subjects are planned, because using them may lock up users with one vendor, thuspromote homogeneity and in case vendor’s security record deteriorates, make transition to adifferent vendor difficult.

(c) Whenever a decision maker or project manager selects platform and/or a software package,he/she should check for vendor history to prevent future problems if vendor is not able tobehave in a fair and responsible manner in case of security incidents or problems. Attention


should be brought to recent security issues of the chosen product and an overview of vendorreactions should be made.

3. Legal ResponsibilityJust as many other aspects of life, also software development must follow the same patterns of rightsand responsibilities.For commercially available software, there should be a legal framework that would override legaldisclaimers most vendors are pushing onto the customers:

(a) First of all, commercial software, just as any other commercial products, should be bound bywarranty rules of the country. All bugs and design flaws a vendor is aware of would have tobe published and fixed, and the documented fixes should be available to the customers free ofcharge at least within the warranty period.

(b) Second, software vendors should be legally liable for damages caused by or allowed by bugs ordesign flaws in their software, except1 in cases when they are behaving responsibly by somelegal definition—e.g. that all bugs must be openly published as soon as one of the followingconditions is met:• when a bugfix or workaround is available,• an exploit is or seems to be in the wild, or• the problem is over a month2 old.

(c) Standard anti-monopoly regulations should be strictly applied to vendors with large marketshare to prevent possible missuse of monopoly power, boost competition and thus reduce ho-mogeneity of used hardware and software.

The computer industry, both hardware manufacturing and software development, is still quite young,and it is developing extremely fast. However, over the last decade it started to influence everyday life ofalmost everybody, and thanks to the Internet, its products have spread beyond all expectations. Just asother industries in the past, also the computer industry shall have to adapt to the needs of non-experts,common people without the slightest understanding of things they are using.

Even though computer education becomes better every year, for most people it is quite distant anduninteresting, and most of the education concentrates on topics like “How to use Word to write a letter”.Therefore, the developers, administrators and decision makers will have to employ all their skills tomake the computer environment not only user-friendly, but mainly as safe as possible for a commonuser. Preventing creation of fully homogeneous environments in which all the users can fall victims ofa single attack should form an important part of the strategy. Users should be encouraged to choosetheir tools from a set of alternatives defined by administrators. Operating Systems (if needed at all onworkstations, because thin clients are in many respects more secure for common users), Office Suites,Mail and Groupware clients, Web Browsers, chat clients etc. should depend on user choice, provided thatthe administrators are able to secure standards-based interoperability between the programs.

Heterogeneous environment may be more expensive from the administration and maintenance standpoint,however allowing growth of a monoculture, though cheaper and easier in the short run, is likely to havedangerous and expensive consequences later.

1The exception is necessary, as bugs are unfortunately inevitable and even though proper pre-release testing shoulddiscover at least the most grave errors, it is quite certain that at least some bugs always make it to the release. Similarly,although design flaws should be eliminated by thorough preparation before a project is started, there are many factors, likelack of experience, or information and discoveries not available at the time of the project beginning, that may ill-affect thedesign. However, once a design flaw is identified, it should be removed or worked around as soon as possible, and avoidedin the future so that as little damage as possible is caused.

2It could be a different period, a fortnight, three weeks, however one month period has become quite an acceptedcommunity standard.



Secure videoconferencing system

Tomas Boucek, Jaroslav Dockal, Petr Dusek, Tomas Konir

[email protected]

Department of Special Information Systems Brno Military Academy, Kounicova 65

612 00 Brno, Czech Republic

Abstract The growth of the Internet increasingly opens up the feasibility of using such multimedia applications as audio/videoconferencing systems. On the downside, it is very dangerous to use such systems in an insecure environment in many fields where security or privacy or confidentiality are required. That is why, in order to meet the needs of professionals in these fields, we decided to create a secure audio/videoconferencing system. This system is based on the modular crypto-library and modified freeware and this paper paper will discuss how we solved audio/videoconferencing security issues and will then explain how to add support for X.509 certificates into the crypto-library.

Keywords: audio/videoconferencing system, crypto-library, X.509 certificate.

1 Introduction Meetings in many areas such as in the military (command or staff meeting), in the medical field (medical consilium) and so on, often require a high level of confidentiality. One of the commercial videoconference products could be bought for these purposes, but this would require organizations to pay a high initial investment and many organizations around the world simply cannot afford to pay for such software. Interestingly enough, the Internet already uses technology that provides a way to solve this problem more effectively and that is why we developed a new system that is not only cheaper, but also more effective than existing commercial software.

2 Two parts of our solution Development of a new solution could by done in two ways: by using already created software and adapting or creating an entirely new solution. We chose to use the first approach and our solution has two basic parts: a cryptographic part and a software part.

The first part is a modular crypto-library, which is easy to use and provides basic cryptographic functions such as various ciphers, hash functions, and random number generators. At first we looked at already existing solutions, but unfortunately we had to reject all of them, because they fell short of our requirements (multiplatform, easy to use, and not too expensive). When choosing the algorithm for data transmission, we placed priority on security, speed and openness of the algorithm. For example, we offer a wide range of options for programming algorithms, including AES (Advanced Encryption Standard) for symmetric encryption. Our crypto-library has a version with a help program which was gradually rebuilt to be usable in every future project. The crypto-library’s bigest advantage hovewer is its independence of hardware and software platforms.

The second part of our solution is a modification of existing audio/video-conferencing software, which makes communication possible by secure connection without any other support from the operating system or network software. The suggested software is based on the multicast product RAT (Robust Audio Tool, see [1]), which is used for voice transmission, and VIC (Videoconferencing Tool, see [2]), which is used for picture transmission. Enhanced software makes possible both the encryption of transmitted data that prevents eavesdropping, and authentication by both communicating parties that prevents unauthorized access.

The videoconference system was built on a network infrastructure that makes communication between two or more participants of a discussion possible by means of a reflector (a server which registers members of the communicating group and assures retranslation of data without making requests to special network services). At


the same time, it guarantees the protection of transmitted data before unauthorized interventions occur, such as eavesdropping or insertion undesirable data. In view of the request for simplicity, it was decided to improve the current existing solution with the completion of protection functions rather then to create an entirely new solution. On the server side a variant was chosen where the security software was placed directly into the code of the program. However, because this software will not be further developed, we had to find a more effective solution. We decided on another solution for the client-side software; because this software is being continuously improved, we decided to separate the modules to facilitate simple modifications.

3 Measurements and tests We measured the speed of the encryption in experiments and compared it with the speed required for transmission of information. The speeds necessary for transmission of pictures are in the region of hundreds of kilobytes per second and for voice in the range of tens of kilobytes per second. The transmission is very sensitive to the variation of the delay of the signal, especially for voice transmissions. The solution of the encryption algorithms in the program was realized by making the speed of encryption constant and thus the influence of varying transmission speeds was eliminated. The encryption speed itself is important only in symmetric ciphers and that is why we focused on them. We measured the speeds of three configurations (see Figure 1), which correspond to very weak, average and powerful PC clients. For the weak computer we selected a Pentium 100 MHz, for the average computer we chose a Athlon 1.2 GHz and for the role of powerful PC we used a PC with a Pentium4 2.4 GHz processor. Accoding to our measurements, other parameters of computers do not have a significant influence on our application. The results of the measurements goes to show that the weakest computer is already fully satisfactory, when we take into account necessary overheads (hovewer, in case of video, the weakest computer would not be an ideal solution, because videocodecs are very demanding of their own accord).

Algorithm Figure 1 Results of tests

0 50000 100000 150000 200000

AES

AES192

AES256

BLOWFISH

CAST5

IDEA

TWOFISH

TWOFISH256

XOR

ENIGMA

DES

3DES

SKIPJACK

Speed [KBps]

Pentium 4 - 2400Athlon - 1200Pentium 100

Figure 1: Results of tests.

Tests and theoretical analyses showed us that our first version of the solution, a method based on a password, with careful selection of encryption algorithms, is vulnerable only to a “Man in the Middle” attack. The best defence against to this attack is to have the same information at both communicating sides before connecting. Implementation of this idea will be satisfied by the addition of support for X.509 certificates into the crypto-library.

4 Addition of certificates The addition of X.509 certificates we has two advantages; firstly, dialog that has already been authenticated will proceed encrypted; secondly, the client and server will be mutually authenticated. So long as we provide a safe key exchange, it is possible to push a potential “Man in the Middle“ from the position of a dangerous attacker to


the role of powerless onlooker who is unable to even follow the proceeding communication, much less to attack it.

The next very important benefit of the certificates is that they allow a person to assign access rights not only by fixed membership in the user groups, but also dynamically by so-called attribute certificates. Attribute certification authority assigns these certificates on the basis of the system roles. We assign only two roles in the simplest mode: the administrator and user. In systems used for more general purposes the number of the roles will be increased to four; the two previously mentioned, plus moderator and guest.

The duties of the administrator are traditional: administration of the system and adding and removing users. Apart from this, he takes care of the administration of certification authority and supervises user priviledges. The moderator could become a user who creates a conference room, controls the discussion and has the ability to make decisions about which users or groups obtain which priviledges and therefore how much they are allowed to contribute to the discussion. During this discussion the moderator also has the ability to add and remove participation priviledges. His task is to look after the continuity of the discussion and if he has the priviledge to participate, he is allowed to speak and others can follow him; otherwise he follows the speaker. The user is allowed to request the word and if he receives it, he can also speak. The guest is in a role of observer. He is allowed to follow the discussion, but he cannot enter into it.

5 Conclusion We suggested a modification of the freeware audio/videoconferencing system and added some security features to it. The experimental tests proved the usability of our system in practice. We started with using our system in the academic sphere and we plan future applications for hospitals.

References [1] RAT Robust Audio Tool http://www-mice.cs.ucl.ac.uk/multimedia/software/rat/.

[2] VIC Video Conferencing Tool http://www-mice.cs.ucl.ac.uk/multimedia/software/vic/.

[3] S. Farrell, R. Housley: An Internet Attribute Certificate Profile for Authorization. Network Working Group IETF, RFC 3281, April 2002.

[4] ITU Recommendation X.509 | ISO/IEC 9594-8 „Information Technology – Open Systems interconnection – the Directory: Public-key and attribute certificate frameworks“. ITU Feb 23, 2001.


The Research and Implementation of Distributed Active and Cooperative Intrusion Detection System

Qihao Deng, Qingxian Wang, Jingeng Guo

[email protected]

Department of Computer Science University of Information Engineering , P.R.China

Zhengzhou City, P.R.China

Abstract There has been a shift from a centralized framework to a distributed in the field of intrusion detection. In this paper, we introduce the development of distributed IDS. And then some typical distributed prototype systems are analyzed. At last we present a framework for a distributed active and cooperative intrusion detection system with no centralized analysis components, and the nodes in our system collaborate in a point-to-point fashion to identify emerging hostile pattern. Our framework consists four main kinds of components: directory service, intrusion pattern transform module, sub-IDS, and cooperative detection engine. The directory service is the central place for providing system-wide information to cooperative detection engines, and is critical for the scalability of our system. In this framework, IPML based on XML is designed to express distributed intrusion patterns, and these patterns are transformed into data that cooperative detection engine can use. And this helps domain experts express their knowledge about intrusion scenarios in a more intuitive way. Distributed attacks described by IPML are decomposed into smaller units (called basic detection events) that correspond to the distributed events indicating the attacks, and these units are observed in the places where corresponding events happened by cooperative detection engines. The sub-IDSs are used to provide basic detection events (such as some alerts and TCP session event) for cooperative detection engines, and we can also integrate third-part IDS as sub-IDS into our design.

Keywords: computer security, distributed intrusion detection, IPML, XML, cooperative.

1 Introduction The rapid growth of the network not only provides means for resource and information sharing, but also brings new challenges to the intrusion detection community. Due to the complexity and the amount of audit information generated by large-scale systems, traditional intrusion detection systems (IDS), which were originally designed for individual hosts and small-scale networked systems, cannot be applied to large-scale systems directly. And distributed and coordinated attacks (e.g., the Mitnick attack) are increasingly popular among hacker; such attacks are difficult to detect and to defend against, because evidence of these attacks is often scattered over several hosts. So there has been a shift from a centralized framework to a distributed in the field of intrusion detection.

In this paper, we introduce the development of distributed IDS. And then some typical distributed prototype systems are analyzed. At last we present a framework for a distributed active and cooperative intrusion detection system with no centralized analysis components, and the nodes in our system collaborate in a point-to-point fashion to identify emerging hostile pattern. Our framework consists four main kinds of components: directory service, intrusion pattern transform module, sub-IDS, and cooperative detection engine. The directory service is the central place for providing system-wide information to cooperative detection engines, and is critical for the scalability of our system. In this framework, IPML based on XML is designed to express distributed intrusion patterns, and these patterns are transformed into data that cooperative detection engine can use. And this helps domain experts express their knowledge about intrusion scenarios in a more intuitive way. Distributed attacks described by IPML are decomposed into smaller units (called basic detection events) that correspond to the distributed events indicating the attacks, and these units are observed in the places where corresponding events happened by cooperative detection engines. The sub-IDSs are used to provide basic detection events (such as some alerts and TCP session event) for cooperative detection engines, and we can also integrate third-part IDS as sub-IDS into our design.


2 Distributed Intrusion Detection Systems analysis Spafford and Diego Zamboni [5] define a distributed intrusion detection system as: “A system where the analysis of the data is performed on a number of locations proportional to the number of hosts that are being monitored.”

Most early distributed IDSs collect the audit data in a distributed manner but analyze the data in a centralized place (e.g., DIDS, NADIR, NSTAT, and ASAX ). Although audit data is usually reduced before being sent to the central analysis unit, the scalability of such systems is still limited. When the size of the distributed system grows large, not only some audit data may have to travel a long distance before arriving at the central place, but also the central analysis component of the IDS may be overwhelmed by large amount of audit data. Besides, the transmission of audit data certainly wastes the network bandwidth, which is supposed to carry out normal network activities.

Recent systems paid more attention to the scalability issue (e.g., EMERALD, GrIDS, AFFID, and CSM). In order to scale up to large distributed systems, these systems place IDS components in a distributed system. Each of These components gets audit information from a limited number of sources (e.g., one host ) so that it will not be overwhelmed by large amount of information. Different components are often organized hierarchically; lower level IDS components disseminate its detection result to certain higher level components so that the intrusion related information can be correlated together.

The current distributed IDSs are limited in several ways:

1. There is a hierarchy in the data analysis. Data analysis takes place at all levels of the hierarchy. This means that in the wake of a new distributed attack, changes may have to be made in modules at many levels [8].

2. Data refinement takes place across levels with each level only reporting the notable events to the higher level. If the refinement is strict, we may end up losing some system-wide notable events and if the refinement is loose, the higher level analysis modules will be flooded with large amounts of data form the lower levels. Finding an a priori suitable compromise may be difficult.

3. Most of the distributed IDSs use rule based languages to describe the suspicious, activities to be detected. Although these languages are usually declarative and simpler than pure programming languages, they are still difficult to use. Describing a complex suspicious activity requires cautiousness and time. In addition, the correctness of the cooperative rule sets becomes difficult to verify when the rule sets get large. This not only affects the efficiency, but also limits the deployment of such systems.

4. In hierarchical distributed intrusion detection systems, the failure of the higher level node will yield a single point of failure.

To solve these problems, we present a framework for an XML-based distributed active and cooperative intrusion detection system with no centralized analysis components, and the nodes in our system collaborate in a point-to-point fashion to identify emerging hostile pattern.

3 Overview of Distributed active and Cooperative Intrusion Detection System

The system we designed is named Distributed Active and Cooperative Intrusion Detection System (DACIDS). In this system, an intrusion is defined as pattern of basic detection events that can occur ant multiple hosts. A basic detection event is characterized as the occurrence of something of interest that could be the sign of an intrusion (e.g., the receipt of a certain IP packet, a failed authentication or a alert of sub-IDS). Such events could either stem from a local misuse or an anomaly incident. The system can use third-party IDS as sub-IDS to perform the local detection and feed their event data into our cooperative detection engine. And we are developing host-based and network-based sub-IDSs.

By relating events form multiple places, our system can detect a number of attacks that would remain unnoticed by only focusing on local activity. Relating events between different places might also increase the chance for anomaly detection sensors to catch an attack.

Our distributed patterns and the detection algorithm can describe and detect situations where a sequence of events occurs on multiple hosts. The decentralized pattern process finds distributed patterns by sending messages between nodes where interesting events occur. Therefore, each node of the protected network has to


run a process (cooperative detection engine) that executes the distributed pattern detection algorithm. The renunciation of dedicated central components and the effort of designing a fully distributed system is rewarded by good scalability and fault tolerance properties of our system. When a single node in our system fails (or is compromised), it stops its local detection and ceases to forward pattern information. This prevents the detection of pattern instances where events occur at the compromised host, but rest of system remains intact. In addition, messages are not sent to designated nodes but exchanged between equal peers. This allows to distribute the complete message traffic over the network without some predefined central bottlenecks.

4 Intrusion Pattern Markup Language (IPML) and Pattern Graph In order to perform intrusion detection, the representation of intrusion behaviour is a very important issue for a computer based intrusion detection system. Different intrusion behaviour representations for different intrusion detection systems make integration of intrusion behaviour knowledge hard to achieve. An expressive intrusion behaviour description language would help us to accumulate expert knowledge about intrusion. And the representation of intrusion behaviour must be extendible to facilitate reuse of expert knowledge about intrusions, which means that it can be refined and extended to cover new intrusions. In addition, a standardized expression language will help us to maintain an intrusion representation. So we defined an XML based Intrusion Pattern Markup Language (IPML) to express expert knowledge about intrusion patterns.

Since XML is a standard language that is clearly understandable, so is IPML. Thus, the IPML parser can be easily implemented by simply modifying the existing XML parser. In our system, the intrusion pattern described in IPML can be translated into a data structure that can be processed directly by cooperative detection engine, because the structure of XML is regular expression. Furthermore, IPML documents can be easily reused, and IPML can be extended to describe new intrusion pattern due to the standardized property of XML.

XML provides a more readable and structural format for IPML. Experts can use IPML to express their knowledge about intrusion patterns, and others can understand the meaning of the intrusion patterns easier due to structure of XML is clear. Figure 1 shows the XML DTD about network packet information.

<? Xml version=”1.0" encoding=” GB2312 ” ?>

<!ELEMENT Packet (Time, Direction, Accept, Type, SourceIP, SsoucePort, DestIP, DestPort, Length, TTl)>

<!ELEMENT Time (#PCDATA)>

<!ELEMENT Direction (#PCDATA)>

<!ATTLIST Direction Value (IN|OUT|FOR) #REQUIRED>

<!ELEMENT Acceptability (#PCDATA)>

<!ATTLIST Acceptability Value (Accept|Deny) #REQUIRED>

<!ELEMENT Type (#PCDATA)>

<!ELEMENT SourceIP(#PCDATA)>

<!ELEMENT SourcePort(#PCDATA)>

<!ELEMENT DestIP(#PCDATA)>

<!ELEMENT DestPort(#PCDATA)>

<!ELEMENT Length(#PCDATA)>

<!ELEMENT TTL(#PCDATA)>

Figure 1: XML DTD about network packet information.

In order to be able to process an intrusion pattern, it has to be translated form IPML into a data structure suitable for our system. This is done by transforming a scenario into an acyclic, directed graph (called pattern graph). An attack scenario describes sequences of basic detection events located at different hosts that are connected by host correlation events. Each single event specified by an IPML scenario is represented as a node of the resulting


graph. The nodes of each host sequence are connected by directed edges. An edge leads form a node representing a certain event to the node which represents the immediate successor of that event in the IPML pattern description (i.e., XML document).

The resulting graph shows a tree shape and all paths through the graph end at the last event. Each node receives a unique identification number that consists of a part that identifies the attack scenario itself and a part that identifies each node with the scenario.

5 DACIDS Architecture DACIDS composes of sub-IDS, directory service, cooperative detection engine, XML parser and intrusion pattern transform module. Figure 2 shows the architecture of DACIDS.

Sensor 1 Sensor n

Detecti onengi ne 1

Detecti onengi ne n

Cooperati ve detecti on engi ne

Patterntransform

modul e

XMLparser

IPMLdocuments

IPMLDTD

Useri nterface

communi cati onmodul e

Directory service

regi ster

retri eve

Communi cate wi th cooperati vedetecti on engi nes on other hosts

. . .

Figure 2: DACIDS architecture.

Sub-IDSs composes of sensors and detection engines. Sensor are responsible for collecting corresponding data from different data sources, such as system log, network traffic, system call sequence, and file access. Detection engines can use all kind of detection technique according to the type of the sensor, including misuse based and abnormity based.

The cooperative detection engine, the kernel component in our system, is responsible for matching distributed intrusion pattern and retrieving directory service. “active” called in our system means the cooperative detection engine can send message to other cooperative detection engines for corresponding detection according to its needs.

The directory service is the central place for providing system-wide information to cooperative engines. The directory service provides two types of information: sub-IDS configuration and basic detection event configuration. The sub-IDS configuration information specifies sub-IDSs that are running and their places (IP address). The basic detection event configuration information specifies basic detection event instances provided by every running sub-IDS. The purpose of the directory service is to make our system scalable. Since distributed attacks usually consist of several sessions that spread across several hosts and cannot be reliably detected from a single place, the cooperative detection engine that detect them should be installed at various places, possibly


across several different administrative domains. To achieve the scalability, interoperability, and distribution of the system, we adopt the directory service to provide global information that needs to be shared by cooperative detection engines. After our system starts, all sub-IDSs on every corresponding host will register to directory service.

6 Attacks Detection The purpose of the cooperative detection engine is to identify actual events that satisfy an attack pattern written in IPML. When a set of events fulfills the constraints of an intrusion pattern an alert is raised. Notice that instead of simply sending a message to a central system administration console (that yields again a single point of failure), more sophisticated responses can be implemented. The node itself can issue commands to reconfigure the firewall or to terminate offending network connections, thereby eliminating the single point of failure introduced by the central console of a human operator.

The detection algorithm implementing in the cooperative detection engine does not deal with basic detection events itself, instead, it operates on messages. A message is a compact, more suitable representation of an event. Most attack descriptions rely only on a small subset of the event’s attributes for correlation (e.g., only IP addresses instead of the complete IP header). In IPML, only attributes that are assigned or compared to variables are of interest to the further detection process. Therefore, there is no need to operate on the complete event objects.

Obviously, a single basic detection event can match the description of multiple event patterns in an attack pattern. Thus, if more than one description is matched, several message instances (one for each matching pattern) are created. Whenever a message is created, all relevant attributes (i.e. the attributes that are assigned or compared to variables in the IPML documents) are copied into it. Then, it is forwarded to the node representing the matching event description for further processing.

Each message can be written as a triple <id, timestamp, list of (attribute ,value)>. The id of the message is set to the identification of the node of the pattern graph. The timestamp denotes the time of occurrence of the original event and the attribute/value list holds the values of the relevant event attributes which have been copied from the original event attributes. The id of a message defines its type. Different actual message instances with an identical id are considered to be of the same message type.

It is possible that messages of different types receive different attributes form a single event – depending on which ones are actually used in the attack description. In addition, the attribute/value list can be empty when the corresponding IPML document does not reference any variables at all. For example, a port scan event that targets port 80 from IP address 202.196.63.1 would cause the creation of the message instance <0/0,time_of_occurrence, ( SrcAddr, 202.196.63.1)> that has the type 0/0.

We can use a example (detecting the Mitnick attack) to describe the process of distributed active and cooperative detection. In such an attack, the attacker first launches a DOS attack to prevent a trusted host form accepting incoming TCP connection request (i.e., SYN packets), and then tries to connect to another (trusting ) host using the IP address and TCP port being flooded as source IP and source port ( via IP spoofing ). The attack pattern can be expressed by a pattern graph with two nodes. Node n1 and n2, which are depicted depicted with solid circles, represent two kinds of events. Node n1 represents a DOS attack on an instance of the basic detection event TCPDOSAttacks, and node n2 represents a local TCP connection event observed on the trusting host. The timed condition associated with n2 says that it is form the port being attacked (or any port if all TCP port are disabled) and destined to the trusting host, and the source host is trusted. When a sub-IDS observe a DOS attack, it will send a alert to local cooperative detection engine. Then the cooperative detection engine send the alert to user interface, and retrieve all intrusion pattern processed by pattern transform module. When the alert (one basic detection event) partly match a intrusion pattern (i.e., Mitnick attack), then lookup host correlation event for a attribute (i.e., destination host address). If the destination host address can not be gotten, the cooperative detection engine retrieves the directory service to know which hosts were equipped with the sub-IDSs which provide local TCP connection information. Then some message, which describes the attack name and the status detected currently, is sent to those cooperative detection engines. The cooperative detection engines, which received the message, will get the local TCP connection information from the corresponding sub-IDSs, then use the information to match Mitnick attack pattern. If Mitnick attack pattern is matched completely, then a alert will be sent to user interface.


7 Conclusion We present a distributed intrusion pattern detection frame to relate events that occur at different host. A decentralized research prototype IDS named DACIDS is designed, which aims at detecting distributed attacks that cannot be detected using data collected in any single place. IPML has been defined to provide a standardized representation of distributed intrusion patterns and to solve problems related to intrusion detection systems, including pattern representation, computability, extendibility and maintenance.

In our future work, we will continue to refine the implementation of DACIDS and seek solutions to address its limitations. In particular,we would like to improve the cooperative detection algorithm.

References [1] Spafford E.: An architecture for Intrusion Detection Using Autonomous Agents; [COAST Technical

report]. June 1998.

[2] Jai Sundar Balasubramaniyan, Jose Omar Garcia-Fernandez, David Isacoff, Eugene Spafford, and Diego Zamboni: An architecture for intrusion detection using autonomous agents. In Proceedings of the Fourteenth Annual Computer Security Applications Conference, pages 13–24. IEEE Computer Society, December 1998.

[3] J. Lin, X. S. Wang, and S. Jajodia: Abstraction-based misuse detection: High-level specifications and adaptable strategies. In Proceedings of the 11th Computer Security Foundations Workshop, pages 190-201, Rockport, MA, June 1998.

[4] D. Frincke, D. Tobin, J. McConnell, J. Marconi, and D. Polla: A framework for cooperative intrusion detection. In Proceedings of the 21st National Information Systems Security Conference, Crystal City, Virginia,October 1998.

[5] Eugene H. Spafford and Diego Zamboni: Intrusion detection using autonomous agents. Computer Networks, 34 (4): 547-570, October 2000.

[6] Peng Ning, X. Sean Wang, and Sushil Jajodia: A query facility for common intrusion detection framework. In Proceedings of the 23rd National Information Systems Security Conference, Baltimore, MD, pages 317 – 328, Oct 2000.

[7] Peng Ning, Sushil jajodia, Xiaoyang and Sean Wang: Design and Implementation of A Decentralized Prototype System for Detecting Distributed Attacks, http://www.csc.ncsu.edu/faculty/ning/pubs/

[8] Rajeev Gopalakrishna: A Framework for Distributed Intrusion Detection using Interest-Driven Cooperating Agents, www.raid-symposium.org/raid2001/slides/ gopalakrishna_spafford_raid2001.pdf

[9] Wenke Lee: A Data Mining Framework for Constructing Features and Models for Intrusion Detection Systems, Columbia University, 1999

[10] Julia Allen, Alan Christie: State of the Practice of Intrusion Detection Technologies, Technical Report CMU/SEI-99-TR-028, Networked Systems Survivability Program, Jan 2000.

http://www.csc.ncsu.edu/faculty/ning/pubs/


Hacking vs. Pen-Testing Experiences, similarities and differences

Kamil Golombek

[email protected]

Pavel Krečmer

[email protected]

BDO IT a.s. Olbrachtova 5/1980

140 00 Prague, Czech Republic

1 Foreword Penetration testing, shortly ‘pen-testing’ is quite often understood as a black art. Maybe it isn’t as “popular” as hacking itself, or at least there is no famous film about “white-hat hackers” like “Sneakers” with Robert Redford or “Swordfish” with John Travolta, but pen-testing isn’t as glamorous as most people think. Usually it is very hard work, much harder than a hacker’s.

Even we will concentrate in this paper on penetration testing, it is important to say, that penetration testing is just one part of security tests, which are generally accepted. To find exact place of penetration testing among other security tests is not within the scope of this paper. More information can be found in http://cs-www.ncsl.nist.gov. Generally if we speak about more common things, we will use the term “security testing”, if it is just about penetration testing, we will use of course the term “penetration testing”.

1.1 Dynamics of testing

The dynamics of security testing have changed greatly since the first administrators tested their own Internet security in the early 1990s with the SATAN automated tool.

• Customers have become “clients”.

a. The term “customer” is used before contracts are signed, during sales meetings and during the assessment. You are ethically responsible for confidentiality of information you learn about the customer.

b. The term “client” refers to the legal status of your obligation to your customer. After the contract is signed, your customer becomes a “client” and your ethical responsibility to confidentiality becomes a legal responsibility.

• Security testing is now a legitimate profession.

• The role of the security tester is no longer just security testing.

2 Comparison From one point of view there is a very little difference between hackers and pen-testers. Pen-tester has a background in ethical and legal obligations. This is just one difference between the pen-tester and hacker.

2.1 Skills

The legal viewpoint is not the only one, which can be used in comparison of pen-testers and hackers. Individuals can differentiate in skills, knowledge, mind, approach etc. To speak a little bit about skills and knowledge, we can use following categorization of “hackers”:

1. First – tier hackers, or super hackers, are best programmers and experts. They have a deep understanding of IP protocols and used OS and programming languages. They are able to find new holes or vulnerabilities and to create their own code. They usually don’t seek publicity, but they are known because many others use their hacking utilities.

2. Second - tier hackers have a technical skill level equivalent to system or network administrators. They usually know several OS, know how to use some exploits and have some knowledge of programming language. They are much more common than first – tier hackers and they often rely on them.

http://cs-www.ncsl.nist.gov/


3. Third –tier hacker, also “script kiddies” are the most populated but also the least respected group. The main principle they use is “download and try”. They usually don’t understand consequences and because they often use untested scripts against real networks, they can cause big problems. Their knowledge about IT is usually quite low, but what they lack (or lose) in skills they gain in motivation, free time etc. If they are successful, they think they are “elite”.

In this division, pen-testers from lines of security consultants are (or should be) somewhere between second and first tier (first is more exceptional).

2.2 Legal viewpoint

Furthermore pen-testers have access to critical systems and data and their techniques and tools can seriously affect real production systems. So what they need more than skills and knowledge is their integrity and credit. Without a track record of honesty and integrity no one can do this job.

2.3 Methodology

To continue in comparison, a hacker can find only one hole, often he doesn’t care about accidentally damaging systems, wiping files or so on. A pen-tester on the other hand must find not one but all holes (an ideal case, of course), he must record everything, try to keep the tested system from disruption, and even more he has to provide some guarantees. To make this job even harder, a pen-tester must be prepared for debriefings where auditorium is not his colleague but a little bit confused customers.

For that reason any pen-tester should use some kind of manual and checklist. The manual must (or should) cover at least following areas of security tests:

• Physical Security

• Internet Technology Security

• Information Security

• Communications Security

• Process Security

To accompany all final reports, there should be checklist in place. This checklist will show modules and tasks completed, not completed and not applicable. The checklist is then signed by the tester and provided with the final test report to the client. Other reasons for checklists are:

• Serves as proof of thorough testing

• Makes a tester responsible for the test

• Makes a clear statement to the client

• Provides a convenient overview

• Provides a clear checklist for the tester

2.4 Limited resources

Can the situation be worse? Of course, it can! A hacker very often has an unlimited amount of time but we, pen-testers, often hear only “I suppose you can do it in one afternoon ...” Time is always against pen-testers.

And it’s not only against them, but against administrators and other technical staff. There is lot of information about hacking, exploits, tools, methods. Mainly they are “somewhere” in the Internet. If busy administrators, security officers or other professionals don’t have time to find them, hackers win.

There are other good sources of information, like books, special courses etc. Some people say it’s too dangerous to serve compact information in this form to “script kiddies”. They forget that they already have them! The next truth is that after reading one book or attending one course nobody is an expert in pen-testing or first tier hacking. The last question can be “Is it good or interesting for administrators to understand more pen-testing?” Let’s look on it.


3 Basic security testing

3.1 Important phases

If common administrators or security officers had basic skills, tools and knowledge of pen-testers, they would probably better understand security of their systems and probably they would know better what they really need (or want) and how to protect themselves.

For basic orientation are in next two paragraphs described common phases of penetration tests. Usually it is important to explain to client a difference between vulnerability analysis on one side and complete “manual” penetration tests. You must go throw all phases to start penetration tests but sometimes client want only vulnerability scanning, which is much faster and easier job.

General pen-testing methodology can be described in next three points:

1. Network enumeration – discover as much information as possible about target

2. Vulnerability analysis – identify all potential places of attack

3. Exploitation – attempt to compromise as much as possible

Other views on pen-testing, but also on hacking are:

1. Reconnaissance – gaining as much info as possible

2. Scanning – modems, ports, known vulnerabilities

3. Gaining access – buffer overflows, cracking passwords, sniffing, etc.

4. Maintaining access – Trojan horses (application, traditional, kernel-level)

5. Covering the tracks – hiding in OS, covered channels etc.

3.2 Easy parts

It is obvious that quite easy and quick is to perform everything up to scanning, even for busy administrators. There are a lot of automated and nice tools for doing it. Everybody can have a favorite one. We would like to mention here Nmap (www.nmap.org) for port scanning and Nessus (www.nessus.org) for vulnerability scanning. Both are considered “No. 1” tools, they are well supported and they are free.

It’s important to say that this is not pen-testing! Using automated tools can only show a possible way, it can’t say if it is the easiest one or only one. Automated tools are quite often not very clever and give quite large number of “false positives”. For a beginner in pen-testing it can be frustrating to see an extremely long list of “security holes”. In general it’s not good to trust everything and maybe worse to ignore all. The more experienced administrator has the higher chance to distinguish between a security hole and a false positive and find a balance.

4 Personal experience If everything is so easy (and we don’t do it just because we don’t have time ...), do we need pen-testers at all? My answer is yes. There were more points in mentioned methodologies. There are so many ways to cover tracks or maintain already gained access that it requires a lot of experience, testing and studying. Also it takes much more time to gain access itself (of course exceptions exist) because one thing is to find the most probable entry point and another to enter it.

If we think about security testing in practice, it is important to mention several “golden” rules or principals.

• Solutions must be practical and realistic

• Tests must be creative yet methodical

• Analysis must be based on business justifications

• Testing must comply to the various laws.

• The security tester must promote trust with the client.

• The determined risk must be measurable and quantifiable.

• The security tester must promote freedom and not paranoia.

http://www.nmap.org/

http://www.nessus.org/


If you want to do more than vulnerability testing, you have to be able to prepare well your attack, you have to choose right tools and exploits and much more. That is why our opinion is that it must be a full time job to keep up to date pen-tester tools, knowledge, skills and techniques.

4.1 Common problems of pen-testers

Firstly we would like to speak about common limits of security tests. They are basically same everywhere, Czech Republic is not an exception. All testers always try to solve or at least “not to forget” most of the items from this list. But there is always some residual risk.

1. Loss of business – sometimes, even you do your best, there can be system dependencies and by testing one time you can cause “down time” during tests.

2. Wasted resources – because of the first problem there should be somebody who take care about system and have to react to alarm states. If it is a “blue”1 test, it is no wasting any more, because administrators can learn some important things from pen-testers and usually they appreciate.

3. False sense of security – it is not definitive since a successful test score does not mean perfect security

4. It is really superficial - it means nothing if nothing gets fixed

5. Process failures – it can halt internal procedures like patching and other administration tasks

6. Politics - security test cannot help a bad internal political situation because if the boss is right, he's right

During our practice we have met all of mentioned problems. As you can see, in some cases we can help to our client to solve the problem or to minimize it, like points 1, 2 and 5. If we must face problems from the rest of the list, usually only “vis mayor’s” impact can help.

4.2 Czech conditions

The next points are our observations from Czech IT security environment. Because of that fact we did not afford to generalize them in some common rules.

1. Security awareness – from a pen-testing point of view, much less “red team” testing is required than “blue team”. The reason is quite simple – red teams test more people’s reactions than system itself and people here are not happy when somebody should test them.

2. Bad expectations – too many people don’t understand what pen-testing is. We meet ideas like:

a. “It’s just a potential problem, you can’t proof it just now,” and “I’m not going to solve it. I’m too busy”.

b. “If you weren’t able to get inside, your test wasn’t well designed.”

3. Bad inside communication – often you meet a security officer of a company who requires “blue” penetration tests but “forgets” to announce it to his administrators. After that administrators close everything for the time of the tests. This state doesn’t reflect the normal operations and all results are useless (even they look good). But administrators gain their “extra” money, because system sustained.

4. Bad handling with test reports – from a pragmatic point of view the pen-tester presents his report, gets salary and it’s over. From a practical point of view is suitable to perform two phases of test and let security officer check some temporally test report after first phase and maybe to agree each other next directions or targets to make invested money more effective. Instead of it even manager’s reports aren’t read. Only acceptable answer can be “O.K.” or “not”.

5 Conclusion To conclude this paper, security through penetration testing can be done on many levels. Despite new exploits being published every day, from easy to very complicated, there are many old ones. We must admit that everyone can close old and easy security holes with “basic” tools and knowledge and with some help from automated tools. So it’s worthy to know them. Thus you close doors against many “script kiddies”. If you want

1 Blue Teaming involves performing a penetration test with the knowledge and consent of the organization’s IT staff. Red Teaming involves performing a penetration test without the knowledge of the organization's IT staff but with full knowledge and permission of the upper management.


to have or just proof a higher degree of security of your systems, it’s recommended to entrust security consultants with it. And if you know “basics”, your communication with them will be better and more effective.

So don’t worry and hack’em all!

References [1] T. J. Klevinsky, Scott Laliberte, Ajay Gupta: Hack I.T. – Security Through Penetration Testing, ISBN

0201719568

[2] Peter Herzog: Open-Source Security Testing Methodology Manual, GNU Public Licence, http://www.isecom.org/

[3] John Wack, Miles Tracey: DRAFT Guideline on Network Security Testing, NIST CSRC 800-42

Information about authors Kamil Golombek (*1974) was graduated as MSc (1998) at the Military Academy in Brno. His professional career was started at the General staff of the Czech Armed Forces where he occupied various INFOSEC positions (1998 – 2000). Till 2002 he worked for Czech Military Intelligence Service as INFOSEC expert. At present he is a consultant in BDO IT, focusing on pen-testing.

Pavel Krečmer (*1973) was graduated as MSc (1997) at the Military Academy in Brno. His professional career was started at the Ministry of Defense of the Czech Republic, where he occupied various INFOSEC positions (1999-2001). At present he works as consultant in BDO IT.


Electronic notary services

David C. Hájíček

[email protected]

GiTy, a. s. Mariánské náměstí 1


Abstract One of the most important and discussed issues of data exchange and storage problems is how to provide for their security. There is legislation in the Czech Republic that helps secure confidentiality and privacy. However, the issue of unquestionability is not approached. Sure, when using a guaranteed electronic signature it is easy to find out, whether the document has been signed by an authorized person or later changed. But what is the opportunity to check, when the document has been executed and signed?

The problem of long-term data storage is of similar character. Nobody can say, Ýes, the document has been stored in this particular time.´ There is no need to point out what danger looms behind that issue. For example – it is not possible to do electronic business. Without credible time indication it is easy to say Í am not the author of this contract.´ Or who would like to re-sign all the documents after the validity of his electronic signature has expired?

In some countries (e.g. Germany, USA) this issue is solved by certain institutions. Mostly by applying their legislation regarding the electronic signature. But in the Czech Republic the situation is somewhat different. It is not our aim to examine our Électronic Signature Act´. To find a solution only...

Keywords: Time-stamp authority, certification authority, digital time-stamping, digital signature, electronic signature, trusted third party, TSA, CA, DTS, DS, ES, TTP.

1 Electronic notary services

Motto: „It is very important to identify and solve the troubles regarding the imperfect legislation. We can only rely on our lawmakers, but nobody will make up for the loss of profit. The simplest thing we can do is to think over our requirements and opportunities, and to find somebody who could help us.“

Perhaps nobody today doubt about the fact, that data are one of important assets. Not exceptionally, they are much more valuable than hardware devices where they are stored in and a software which process them. Many of great companies pay yearly astronomical amounts to protect their data. Except building security, specialists focus on network security topology. Their install firewalls, VPN gateways, intrusion detection systems, network and security management tools, and many others systems.

They create security guidelines, critical plans and regeneration plans. They perform on cyclic security audits, security mechanism inspections and they prepare system innovations, which may increase their information system security.

To protect the data in a network environment they cipher them using symmetrical and asymmetrical cryptography. And a PKI bears on that. Let’s go to discuss about PKI in a Czech environment.

PKI (public key infrastructure) is an infrastructure, which allows to users protect their data and guarantee their accuracy and integrity using asymmetrical cryptography. It means, that every body has a pair of keys: Private part and Public part. They depend on each other. Using private key, user is able to sign his document (accuracy and integrity) and the only way how to check whether supposed user is a signatory is to apply his public key to a text. And if some document may be secured, it’s sufficient, when it’s ciphered by addressees public key.

Then he’s the only person able to decrypt the secret contained in ciphered document.

If you are using asymmetrical cryptography, you need something, what is called “Certification authority” (CA), as you know. The name “certification” has of course own sense. Information about owner, his public key


included, is stored in a certificate. This certificate is stored in CA’s database with information about its validity. This trusted third party (TTP) is responsible to say “yes” or “no” only when anybody ask it for a validity of signatory’s public key. Everything seems to be OK, but...

Let’s imagine the following situations:

1. You’re a business man, who is used to sign his documents and contracts electronically. You have got a “guaranteed electronic signature” (GES, see Czech legislative – especially law number 227/2000 digest) key pair, which has got his own validity period (e. g. 1 year). So, after your key validity time period your contracts don’t have a valid signature... They have to be resigned?

2. You realize a contract with your business partner. You have made terms that you will send him goods after his digital subscription of agreement and he will send you money during two weeks. Your business partner sent you, CA said “OK” a document and you sent him goods. But after three weeks money aren’t at your account. And your business partner told you: “I’ve revoked my certificate two weeks ago (CA can confirm this fact). I’ve never signed this document. It could been signed after my revocation by any hacker.” How to prove him the exact time of his signature?

3. You are the user of electronic auction in the Internet. How to prove in which time have you offer a price for some goods? An administrator is able to manipulate with log file.

It can be found a lot of other situations – see [Stau01], where status of time is very important but it’s not assured. The reason of that fact is, as you know, irresponsible approach of our enactors. But EN can be solution of most of known time problems.

What can EN service provide: verify whether a concrete document existed in a specific time, if you like before a specific time (so-called time authentication).

How could bee a EN service realized: via digital time-stamping (DTS) or/and time-marking. The both methods proclaim the existence (signing) of document before defined time. The first of them – time-stamping method – is usually realized via a certificates rendered for a document. The second way builds a structure [HaSt91] proving

D

28. 9. ‘83

!EN

D

Private key of Alice

Public key of Alice

Certificate

D

Digital signature

Public key of Alice

CERTIFICATION AUTHORITY

BOB ALICE ?=

D

Figure 1: Example of EN service.


the same fact. Both methods can be combined with exact time delivered from some confidential source (e. g. GPS, [Poupa]).

Digital signatures and time authentication is much more difficult than mentioned operation on a paper. Digital document has no physical media, so it’s necessary to find out an alternative method. A digital document can be also very simply copied and every copy is the same as an original. To modify a digital document you don’t be an excellent falsifier too.

There are several tricks how to guarantee a time authentication. Our conception of EN is the time-stamping authority (TSA) using relative time rank [iNot02].

Here is an example for better image of EN service (figure 1):

Alice Brown wants to send signed and time-authenticated document D to Bob Smith. According to the Czech legislature she count a hash1 of D: hD=h(D). Then Alice applies her private key using asymmetrical algorithm2 SD=sign(hD). Now, to provide document confidentiality, Alice send SD (not the whole document in plaintext) to an EN. Electronic notary submit a document certificate (example 1) confirming his existence before mentioned time and insert SD to a trusted structure (scheme 1, where Ln are hashes of Documents yn combined with Ln-1).

For Bob is now simple to decide whether he will believe into a document D, which has been signed by Alice in a specific time.

Fundamental principles of digital time-stamp generator are expressed in figure 2. As you see, it is very important to have a trusted device. It have to be auditable, attack resistant and well documented. Detail description is contained in [Stau02].

To understand how our EN service [iNot02] works, it’s important to explain the main conception. This system is built on one main server (DTSS) and three protocols: Stamping protocol (SP) – allows time-stamp request, Verification protocol (VP) – provide for 2 time-stamp time sequence nad Audit protocol (AP) [Stud02]. There is no user authenticity requirment.

When user requests for time-stamp via SP, EN counts a hash using SD and a pseudo-random bit sequence – unique generated for his concrete SD t: TSD= h(SD + t). There is used a binary linking scheme [Bls98], [iNot02] in our system, because of high time and computing requirements.

Then EN exposes an certificate for TSD, sends it to a user and inserts TSD into a main structure (scheme 1). After that, Document D is explicitly fixed in a time. For higher trustfullness of this method, it is possible to sort insert into a main hash some non-reproducible event – e. g. solar erosions. To increase confidentiality it’s possible to publis summary hash in some confidential journal (www.surety.com prints every weeks the summary hash in Sunday New York Times, since 1992). After this, it’s simple to provide that the structure cannot be falsified.

1 a standard hash function can be used – MD5, SHA-1, ... One-way Hash function is defined by CA and Alice at the start of their cooperation. It may be collision free and easy to calculate 2 algorithm accepted by both parties – for example RSA, RC4, ... Signing algorithm is always defined during key generation and registration procedure

Figure 2: Digital time-stamp generator (DTSG).

http://www.surety.com/


Person who wants to check whether the proclaim document origin time is correct simply confirm it via VP.

Thanks our legislature, there are no rules defined for an EN service, but Electronic signature law can be used. There are specified requirments for CA, so EN may be realize at least at the same assurance level. The iNotary system is established on EAL4 [CC], required for CA.

EN is an essential part of functional PKI infrastructure, as a CA is. It’s damage that our legislature forgoten it but it’s sure that it have to be realized as soon as Czech users begin use a PKI.

<notary> <timestamp round=”r” number=” n#p”> <notary-server name=”iNotary”>

<base> <value> Ln#p </value>

</base> <head> <linking-item number=”n1#p1”> (L|H)n1#p1 </linking-item>

... <linking-item number=”nt#pt”> (L|H)nt#pt </linking-item> </head> <tail>

<linking-item number=”n1’#p1’”> (L|H)n1#p1 </linking-item>

... <linking-item number=”nt’#pt’”> (L|H)nt#pt </linking-item> </tail>

</timestamp> </notary>

Example 1: Time-stamp no. n#p (round r) – [Stud02].

Scheme 1: Linear linking scheme.


Literature [Stud02] I. Studenský: Služba elektronického notáře. Thesis, Fakulta informatiky MU v Brně, Brno

2002

[Stau02] J. Staudek: Časová razítka a jejich důvěryhodnost. Technical report, Fakulta informatiky MU v Brně, Brno, 2002

[Stau01] J. Staudek: Čas a důvěryhodnost digitálních dokumentů. Technical report, Security 2001, AEC Praha, 2001

[iNot02] D. Hájíček, P. Hekerle, I. Studenský: Documentation of iNotary system, infocount, s. r. o., Brno, 2002

[Bls98] A. Buldas, P. Laud, H. Lipmaa, J. Villemson: Time-stamping with binary linking schemes. Advances in cryptology – CRYPTO’98, 1462 of LNCS: 486-501, 1998. Springer-Verlag.

[HaSt91] S. Haber, W. S. Stornetta: How to time-stamp a digital document. Journal of Cryptography, 3(2): 99-111, 1991

[CC] ISO/IEC 15408 – Common Criteria

[Poupa] M. Poupa: Vše o času. Technical report, http://home.czu.cz/~poupa/oma50.html

Other sources • NIST Internet Time Servers. http://www.boulder.nist.gov/timefreq/service/time-servers.html

• Secure Network Time Protocol (stime). http://www.ietf.org/html.charters/stime-charter.html

• Electronic notary. http://www.surety.com

• Electronic notary, GiTy, a. s., infocount, s. r. o. cooperation project. http://www.gity.cz/iNotary

• Czech law number 227/2000 digest (electronic signature)

http://home.czu.cz/~poupa/oma50.html

http://www.boulder.nist.gov/timefreq/service/time-servers.html

http://www.ietf.org/html.charters/stime-charter.html

http://www.surety.com/

http://www.gity.cz/iNotary


Extending Security Functions for Windows NT/2000/XP

Ing. Martin Kákona

[email protected]

S.ICZ a. s., J. Š. Baara 40, České Budějovice, Czech Republic

Abstract The paper describes the possibilities of adding security extensions to operating systems based on the Windows NT technology.

Some of the current security measures within these operating systems and their respective weak points are discussed. Possible improvements to the current architecture and methods of integrating new security mechanisms into the operating system are also outlined.

Examples introduce solutions which strengthen the security of existing components of the operating system by adding proven cryptographic functions. Special attention is paid to the protection of key data and the indivisibility of cryptographic functions. Protection against information disclosure during malfunction of the operating system is stressed.

The paper also focuses on hardware cryptographic devices, their support by the operating system and their importance from the viewpoint of the overall system security.

Keywords: CryptoAPI - Cryptographic Application Programming Interface, CSP – Cryptographic Service Provider, FSFD – File system Filter Driver, EFS – Encrypting File System, Chip Card, Smart Card, Key Container, Cryptographic Adapter, GINA, Secure Desktop.

1 Introduction This paper will discuss selected security subsystems of operating systems based on Windows NT, their advantages, weak points and possible improvements. For the purposes of this paper, no strict distinction will be made between Windows NT, Windows 2000 and Windows XP operating systems. This is based on the fact that the core of all of these OS's is identical as far as security is concerned. Individual differences of those systems are above the extent of this paper and will be discussed only where necessary. In the following text, we will mostly refer to Windows 2000, a version of the Windows NT OS containing the full range of security subsystems described here. When referring to Windows NT, we mean the entire operating system group of Windows NT/2000/XP.

2 Authentication User authentication under Windows NT uses a module called Winlogon.EXE. This module provides authentication for the LSA subsystem, which manages Access Control. See Figure 1 for a structure diagram. An important characteristic of the Windows NT authentication is the fact that the user undergoes authentication within a so called Secure Desktop. This represents an important security feature and solves the problem of uncontrolled infiltration of authentication data. Switching to the Secure Desktop uses SAS (Secure Attention Sequence), which is, in its correct implementation, unmonitorable by the operating system applications. The SAS must be knowingly initiated by the user. This involves the famous Ctrl+Alt+Del keyboard shortcut, or for example an insertion of a chip card into the reader unit. (The second possibility is not as simple as it sounds and will be discussed later in this paper in the chapter about Smart Cards).


Figure 1: Authentication modules structure.

Besides authentication using the Winlogon module, Windows NT also provides the possibility of direct authentication from applications, as shown on Figure 2. This option is not completely secure and applications using it should be avoided. The main problem with this type of authentication is the fact that it is not done in the Secure Desktop and thus may be infiltrated by an eventual malicious application. The entire interaction with the user is left to the client application and the user can not control it.

Figure 2: Direct Application Authentication.

Let us have a look at authentication from another perspective. Which protocols are used for the authentication process itself? In Windows NT-type systems, several authentication protocols are implemented. Native protocols include: LM, NTLM v.1, NTLM v.2 and Kerberos v.5. LM Authentication and NTLM v.1 protocols, which are provided in Windows systems for compatibility reasons only, should not be used. These protocols contain several significant errors and their use is unsafe.

Let us concentrate on the comparison between the NTLM 2 and the Kerberos protocols. We will not quote details of the individual protocols because they have not been published by Microsoft. For our purposes, general information contained in platform documentation [2] and definitions in literature [1] will be sufficient.

The NTLM protocol is known for being a challenge/response-type protocol and the fact the user password is not transferred when it is used. The strength of this protocol will therefore depend on the quality of the encryption used to encrypt the challenge and on the method of generating the key used for this purpose. Kerberos is basically a challenge/response-type protocol as well. The difference is that under NTLM, the authentication is a two-point type (client versus server), while three-point authentication is used for Kerberos (client versus KDC and then versus the server). Kerberos is therefore not so much of a security feature for Windows OS, as is commonly assumed, but rather a practical feature enabling effective secondary authentication of the user with more servers and services. Another difference between the protocols is their encryption algorithms. The NTLM v.2 protocol uses the HMAC_MD5 algorithm with a 128 bite key and Kerberos uses the RC-4 algorithm with a 128 bite key and/or 56 bite key for international versions. In both cases the cipher-keys are derived from


the Logon Password using the hash function. A 128 bite cipher-key corresponds to an alphanumeric password with approximately 21 characters! The length of passwords should not be underestimated, for example a brute force attack against a 6-character password on a single processor computer takes less than 3 days. This is based on the presumption that DES and RC-4 algorithm weaknesses discovered to date can not be used, as they are eliminated by the password hash function. The above example shows that the quality of User Passwords is the key to Windows OS security and that passwords must be stored in Security Tokens, because high quality passwords can not be remembered by humans.

The main possibility for improvement of authentication processes under Windows NT is the replacement of the GINA module providing interaction with the user. This would enable saving of the password on a suitable medium, for example a chip card, which ensures both its protection and required quality. The second possibility, also involving Smart Cards, is to use the PKINIT extension of the Kerberos protocol. In this case the encryption does not use a password image as in the classic Kerberos version, but the KDC sends a Session Key to the user encrypted by that user's Public Key. Thus the secret information does not leave the Smart Card. This process is described in detail in [6]. We will discuss Security Tokens more detail later.

3 Cryptography Windows NT OS contains the CryptoAPI cryptography subsystem, a robust implementation of a cryptography functions library based on Public Key Cryptography. CryptoAPI is described in detail in literature [3]. The original purpose of CryptoAPI, which Microsoft still strives to achieve, was to unify cryptography functions into an uniform API and thus enable their uniform implementation. This not only unifies the ciphering algorithms implementation, but also data formats and other implementation details.

Figure 3: The CryptoAPI Architecture.

The CryptoAPI subsystem may be extended to include other algorithm implementations using CSP modules via a CryptoSPI interface, as shown on Figure 3. Figure 4 shows three possible CSP implementations.

Figure 4: Possible CSP Implementations.

User

Mode

Kernel

Mode

Hardware

Equipment

CSP Interface Layer

CSP Interface Layer

CSP InterfaceLayer

CryptographyCore

CryptographyCore

CryptographyCore

Inner Interface Layer


The left-hand side shows a standard implementation. All CSP's which are native part of NT and most commercially available CSP's are implemented in this way.

The central part shows a compromise where the CSP itself is implemented as a Wrapper only and the cryptography functions are implemented by a driver at the core level of the operating system, which provides a better division of cryptography from applications.

The solution shown on the right-hand side implements cryptographic functions on another piece of hardware from that on which the operating system is running. Such solution is very resistant to operating system errors. When the OS generates an error the cryptography module is not in immediate danger. It is for example ensured that the key is not compromised during an OS malfunction, because on correct implementation the key never leaves the cryptographic hardware. Such a situation could only occur as a result of faulty firmware on the cryptographic hardware. This firmware, however, is much less complicated than the host OS and may be programmed as more robust and it can be tested extensively.

A combination of complete implementation of cryptography functions in a specialized hardware with the previous method, that is implementation of cryptography functions in to the kernel mode driver, is also possible. In such case it is advisable that only key derivates leave the cryptography hardware. This ensures that during an OS malfunction only the keys used to decrypt/encrypt data processed by the OS at that moment and that data may be compromised.

I would also like to call attention to and aspect concerning the use of CryptoAPI. Unfortunately, some applications do not use CryptoAPI in the way it designed. They may expect a certain concrete implementation of the encryption mode, or require outdated data formats, or algorithms against which attacks have been published. The fact that applications are not universally programmed makes the CSP programmers retort to tricks which then make their CSP's incompatible with other implementations. But this is justifiable when a security-prioritised solution is needed.

The use of CryptoAPI also concerns PKI. Because CryptoAPI is based on asymmetric cryptography, we must build and operate an entire infrastructure to be able to use it. Description of individual measures and rules is above the scope of this paper, I would just like to point out that in certain cases the use of symmetric cryptography is more effective. The main is the protection of private keys must always be a priority.

4 Directory Services & IPSec Directory Services in the Windows 2000 OS are implemented in the Active Directory (AD). I mention Active Directories here to call attention to security risks associated with their use. From the security point of view, there are two interesting aspects:

• AD’s may be used to store user password images, secret and public keys, certificates, and other sensitive data.

• AD’s are replicated between servers.

From the above it is clear that AD's contain private information belonging to different users. During replication and protection of the replicating channel using IPSec (the only built-in replication protection measure) the data is transferred over a point-to-point channel and one shared key is used to protect the transfer of different data. I see this as a potential security risk, because the minimum resulting security of all secure systems dependent on information stored in AD's is only as good as the AD replication protection we use.

In a network environment using AD's, it is advisable to store users' private secret information in tokens, even if that means losing the advantage of central administration and distribution of this data.

5 File Encryption File encryption in Windows NT OS is implemented using the EFS. This extension of the NTFS file system is described in detail in [4] and its possibilities and weak points have been described in the NSA Report [5]. EFS is more a method for encryption a local drive than a real implementation of file encryption. Unlike Disk Encryption, the EFS offers the separation of locally stored data (on one drive) belonging to different users at the level of individual files. On the other hand sharing of encrypted data between several users is practically impossible when using the EFS, because the GUI can not be used to specify storing of several DDF’s (Data Decryption Fields) for files in one directory.


The practical value of such a system is questionable as it does not enable transfer of encrypted files to another medium (for example a CD-ROM or a network server). Removal of the residual information, for example in the Page File, is also not satisfactorily solved by Windows. The only practical use is protection of data from being stolen with the use of physical access to the disk. But when using EFS, we must still control physical access to the disc because of the residual information. When we assume that the attacker does not have physical access to the disc, the need to encrypt files is redundant, because a regularly operating OS is capable of controlling access rights to the files.

Another big disadvantage of the EFS is the fact that it does not provide the possibility to select or modify the cryptography used in it. EFS is a typical example of a Windows subsystem which does not use CryptoAPI. CryptoAPI is used with EFS to implement key sharing, but it is reduced to the use of a single CSP, which can not be changed. A single Key Container is also used for all files. A workstation may not be operated in several modes, only in the reserved mode where the access to classified data remains the same level for the entire logon period of one user. The Key Container can not be saved to a Smart Card or another token. The DESX symmetrical encryption algorithm can not be changed either, because for implementation reasons it is not part of CryptoAPI but is implemented directly in EFS.

The Windows could therefore be extended to include File Encryption independent on the file system and ensuring transfer of encrypted files over the network and other mediums.

The file encryption is only effective if we transfer complete files over the network. Should partial transfers be used and should an attacker be capable of monitoring such partial transfers, in other words should the attacker gain access to different versions of the same file, he would be capable of identifying the location of the modified data in the file with the accuracy the size of a cipher block size, or the size of a chaining block. Such identification could compromise the information dependent on location of the file. The same applies to EFS, because EFS implements chaining by 512 bytes.

Let us imagine that an attacker gains access to a computer hard disc two times in a row and does not know the cipher-key. He is not capable to decrypt the data, but the position of changed sectors could give him some information, especially if he has the file which the change was made to in an open form. An example we could have a map available for the general public on which someone have marked a certain location of secret object and information concerning that location are secret. From the changed ciphered data in this example we can determine that location without the knowledge of cipher-key (with an accuracy given by the map scale and the size of the data block over which chaining is done).

Correct implementation of file encryption therefore also includes ensuring of correct application operation. Two approaches are possible, either a new file is created every time a file is changed, or the changes must be saved at the end of the file. In the former case, new encryption for the new file is initialised, because two identical files must never have the same encrypted image. In the later case, diversification of the encrypted image of identical and repeating data sequences in the file must be ensured. Correct application operation and correct encryption implementation results in the changed file only offering information about the size of the realized changes.

6 Smart Card Support The following problems are usually encountered when using Smart Cards:

• A secure authentication of the user to the chip card must be ensured.

• Secret information transferred by a chip card to the OS mustn’t be compromised.

• The user must have control of when and for what purpose the secret information stored on the chip card is used.

Windows NT OS includes an universal subsystem supporting chip cards – PC/SC. Figure 5 shows its structure. The figure shows that interface is provided by group of Dynamic Loadable Libraries (DDL), which applications call from the User Mode. The level of security of communication with a chip card therefore depends on the application communicating with the card, because the DLL's run in the context of that application.


Figure 5: PC/SC Structure.

The main usage of Smart Cards in the system is under CryptoAPI. As explained above, the safest implementation of a CryptoAPI is on the right hand-side of Figure 4. From this the configuration shown on Figure 6 follows. The CryptoAPI concept is based on the principle of secret keys not leaving the CSP. In this case the use of the PC/SC subsystem which has its interface in the User Mode is not advisable for communication with the chip card. It is also not advisable for the user interaction with the chip card (PIN entering, secret key use report) to be implemented in the User Desktop. As we know, a Secure Desktop is provided for such interactions in Windows NT. For example the insertion of a chip card into the reader unit should not be communicated to the user's desktop so that it can not be infiltrated by applications running under that desktop.

Figure 6: Correct Integration of Smart Cards into Windows NT.

The correct implementation of a chip card is to include it into the OS core under the CSP module and into the GINA module, which is capable of processing the SAS from the insertion of the chip card into the reader unit.

CryptoAPI

CSP1

Key containers

CSPn

Key containers

Application1 Applicationk

GINA

HW Driver

Smart Card

User Interface


And last a note about generation of private keys. The above example shows that it would be beneficial for the private key not to leave the data medium (Smart Card) and be generated directly on it. But that would require the Smart Card to include a Random Generator capable of generating random numbers from which the secret key may be derived. Smart Cards available at the present time do not include generators with sufficient reliability. To be more exact the functionality is usually not documented and tested extensively. For these reasons it is advisable to leave this function to the cryptographic adapter in hardware CSP implementation.

7 OS Integrity Checks The Windows NT OS is capable of ensuring its integrity using Access Control as long as OS is installed on the NTFS and the installation meets the security requirements. Problems start when the operation system is not running.

It is therefore necessary to ensure safe OS start and prevent its modification while it is not running. Disabling of modification during power off is easy to ensure using seals. The station's BIOS is then responsible for the time between power on and start of the OS loader. It is also possible for this control function to be provided by the Extended BIOS of the encryption hardware (implemented as a firmware extension). This option should be preferred as the encryption adaptor code may be easily verified and is certified, unlike BIOS on individual stations.

8 Conclusion We have shown possible improvements of security functions of Windows NT-based operating systems. Note that most of these solutions are based on additional hardware and/or firmware. This is a result of the complexity of Windows NT OS and the resulting difficult verification of its source code. The solutions described here are all based on minimization of the code necessary to ensure the system's security functions. At the same time the code must be located so that an eventual error in the operating system does not corrupt the security subsystem.

References [1] J. Kohl, C. Neuman: RFC1510. Network Working Group, 1993.

[2] Platform SDK documentation: Logon Authentication. Microsoft, 2000.

[3] Platform SDK documentation: Cryptography. Microsoft, 2000.

[4] Mark Russinovich: Inside Encrypting File System. Windows NT Magazine, Duke Communications, 1999.

[5] G. Bucholz, H. Parkes: Guide to Securing Microsoft Windows 2000 Encrypting File System. NSA, SNAC, 2001.

[6] White paper: Windows 2000 Kerberos Authentication. Microsoft, 1999.


New Self-Shrinking Generator

Ali Adel Kanso

[email protected]

Department of Mathematics, HCC King Fahd University of Petroleum and Minerals

Hail, P. O. Box 2440, Saudi Arabia

Abstract A new construction of a pseudorandom generator based on a single linear feedback shift register is investigated. The construction is related to the so-called self-shrinking generator. It has attractive properties such as conceptual simplicity, exponential period, and exponential linear complexity. The lower bounds are provided for the appearance of all patterns of reasonable length, and for some correlation attacks. The output sequences of this construction may have some applications in cryptography and spread spectrum communications.

Keywords: Stream ciphers, linear feedback shift registers, self-shrinking generator, and shrinking generator.

1 Introduction In [1] a pseudorandom generator, the so-called self-shrinking generator, has been introduced by Meier and Staffelbach for potential use in stream cipher applications. The self-shrinking generator is attractive by its conceptual simplicity as it is based on a single linear feedback shift register (LFSR) [2]. Let LFSR A be the linear feedback shift register defining the self-shrinking generator. Let (At) = A0, A1, A2, A3, … be the original output sequence of LFSR A. The output sequence of the self-shrinking generator is generated by shrinking the original sequence (At) as follows: The sequence (At) is considered as pairs of bits (A0, A1), (A2, A3), (A4, A5), …. If a pair (A2i, A2i+1) equals the value (1, 0) or (1, 1), it is taken to produce the bit 0 or 1, respectively. On the other hand, if the pair is equal to (0, 0) or (0, 1), it will be discarded.

In this paper, a new self-shrinking generator (referred to as NSSG) is introduced. The NSSG is a sequence generator composed of one single linear feedback shift register, say LFSR A, whose output sequence is shrunken in a similar way as is done for the self-shrinking generator of Meier and Staffelbach.

For the new self-shrinking generator the original sequence (At) of LFSR A is considered as pairs of bits (A0, A1), (A1, A2), (A2, A3), …. If a pair (Ai, Ai+1) equals the value (1, 0) or (1, 1), it is taken to produce the bit 0 or 1, respectively. On the other hand, if the pair is equal to (0, 0) or (0, 1), it will be discarded.

Let (St) = S0, S1, S2, … denote the output sequence of the NSSG of component sequence (At).

The new self-shrinking generator can be implemented as a special case of the shrinking generator of Coppersmith etal [3]. Recall that the shrinking generator uses two LFSRs A and B as basic components. The output bits are produced by shrinking the output of B under the control of A as follows: The output bit of B is taken if the current output of A is 1 otherwise it is discarded. Let (At) = A0, A1, A2, A3, … be the output sequence of the m-stage LFSR A with initial state A0 = A0, A1, …, Am-1 and feedback polynomial f(x) defining the new self-shrinking generator. According to the rules of the new self-shrinking generator, the sequence (At) = A0, A1, A2, A3, … defines the control sequence, and the sequence A1, A2, A3, … defines the generating sequence being controlled. Both sequences can be produced by the original LFSR A when loaded with the initial state A0 = A0, A1, …, Am-1 in the control register and the initial state A1 = A1, A2, …, Am in the generating register since one is a shift by one place of the other sequence.

This implies that the new self-shrinking generator can be implemented as a shrinking generator with two linear feedback shift registers having same characteristic feedback polynomial.

But the converse does not hold since a shrinking generator implemented as a new self-shrinking generator must have control sequence a translate of the generating sequence and this is not the case for a general shrinking generator.


2 Properties of the Output Sequence (St) of the NSSG In this section we analyse some of the properties of LFSR-based new self-shrinking generator. Suppose that LFSR A is a primitive m-stage linear feedback shift register with initial state A0 and characteristic feedback polynomial f(x) [2]. Let (At) denote the output sequence of A. Then (At) is an m-sequence of period M = (2m –1). Let (St) be the output sequence of this NSSG.

In the following lemmas, the period and the linear complexity of the output sequence (St) are established. Finally, it is shown that the output sequence of the NSSG has good statistical properties.

2.1 Period and Linear Complexity of (St)

We prove exponential bounds on the period and linear complexity of sequences produced by the NSSG. In the case of the period this bound is tight; for the linear complexity there is a gap by a factor of 2 between the lower and upper bound.

The importance of long period is to avoid repetition of the sequence after a short period of times. An exponentially large linear complexity avoids one of the more generitic attacks on pseudorandom sequences and/or stream ciphers. Any sequence of linear complexity l can be entirely reconstructed out of 2l known bits by using Berlekamp-Massey algorithm, which in time O(l2) finds the shortest linear feedback shift register that can regenerate the entire sequence.

Next, we consider the period of the output sequence of the new self-shrinking generator.

Since the original sequence (At) is an m-sequence of period M = (2m –1). Then the new self-shrunken sequence (St) will also be periodic. In fact, after (2m –1) bits of the original sequence, the sequence pairs (A0, A1), (A1, A2), …, (A2

m-2, A0), has been processed, and the next pair will be (A0, A1) again. Hence, the shrunken sequence is

repeating. Within this period each possible output pair (Ai, Ai+1), for 0 ≤ i < (2m –1), of the original sequence (At) has occurred exactly once. It is well known that in a full period of an m-sequence of period (2m –1) each of the pairs 11, 10, and 01 appears exactly 2m-2 times, and the pair 00 appears exactly (2m-2 –1) times. By the definition of the new self-shrinking rule, it follows that the period of the new self-shrunken sequence (St) divides 2m-1.

In the next lemma, we show that the period of (St) is exactly 2m-1.

Lemma 1 The period P of a new self-shrunken sequence generated by a primitive m-stage LFSR is equal to 2m-1.

Proof: Since the m-stage linear feedback shift register is chosen to produce an m-sequence, then every non-zero m-bit pattern appears exactly once in a full period M = (2m –1) of the original m-sequence. Hence, in a full period of the original sequence the m-bit pattern 111...1 appears exactly once. From the definition of the new self-shrinking rule, it follows that over a full period of the original sequence the (m –1)-bit pattern 111...1 appears exactly once in a cycle of length 2m-1 of the new self-shrunken sequence (St).

Therefore, the period of the new self-shrunken sequence (St) is P = 2m-1.

Definition 2 The linear complexity L of a periodic sequence (St) is equal to the degree of its minimal polynomial. The minimal polynomial is defined as the characteristic feedback polynomial of the shortest LFSR that can generate the sequence (St).

Lemma 3 The linear complexity L of a new self-shrunken sequence generated by a primitive m-stage LFSR satisfies: L > 2m-2.

Proof: Let Q(x) denote the minimal polynomial of the new self-shrunken sequence (St). From the previous lemma the period of a new self-shrunken sequence (St) generated by a primitive m-stage LFSR is P = 2m-1. Hence over GF(2), (xP –1) can be written as (xP –1) = (x –1)P. Thus, the condition Q(x) divides (xP –1) implies that Q(x) is of the form Q(x)=(x –1)L where L is the linear complexity of the sequence (St). We claim that L > 2m-

2.

Assume L ≤ 2m-2. Then Q(x) = (x –1)L would divide ),1()1(22 22 −=−

−− mm

xx but then the period of (St) is at most 2m-2 [see 4] contradicting lemma 1.

Therefore, the linear complexity L of the new self-shrunken sequence (St) satisfies: L > 2m-2.

2.2 The Statistical Properties of (St)

Suppose that the original sequence (At) is an m-sequence of period M = (2m –1). In this section, we count the exact

appearance of the number of ones and zeroes in a full period P = 2m-1 of the new self-shrunken sequence (St). We


also show that in a full period of (St) any subsequence 121 ,....,,, −+−++ ββ iiii SSSS of length

)1( −−≤ kmβ (i.e. mk ≤++ )1(β ), where k is the total number of zeroes in the

subsequence 21 ....,,, −++ βiii SSS , occurs )1(2 +− βm times for k = 0, and at least i

i i

ik−

=∑

+−λ

λ

2)1(

0times

otherwise, where ).1( ++−= km βλ

Note that .!)!1()!1(

!)!1()!1()1(

ikik

iiikik

i

ik

−+−

=−+−+−

=

+−

The appearance of ones and zeroes in a full period of the output sequence (St):

Since the original sequence (At) is an m-sequence of period (2m –1), then in a full period of (At) the 2-bit patterns 11 and 10 appear exactly 2m-2 times. By the definition of the new self-shrinking rule, it follows that the number of ones and zeroes in a full period of the new self-shrunken sequence (St) is 2m-2.

Thus, the generated sequence (St) is balanced.

Lemma 4 Let the original sequence (At) be an m-sequence of period (2m –1). Let (St) denote the new self-shrunken sequence generated by self-shrinking the sequence (At).

In a full period of (St) any subsequence 121 ,....,,, −+−++ ββ iiii SSSS of length )1( −−≤ kmβ (i.e.

mk ≤++ )1(β ), where k is the total number of zeroes in the subsequence 21 ....,,, −++ βiii SSS , occurs:

)1(2 +− βm times, for k = 0,

and

at least i

i i

ik−

=∑

+−λ

λ

2)1(

0times, otherwise.

Where ).1( ++−= km βλ

Proof: The original sequence (At) is an m-sequence of period (2m –1). Thus, in a full period of (At) each non-zero subsequence of length h ≤ m occurs 2m-h times, and the all-zero subsequence of length h < m occurs (2m-h –1) times [2].

Suppose we want to determine a lower bound on the number of times any subsequence

121 ,....,,, −+−++ ββ iiii SSSS of length β occurs in a full period P = (2m –1) of the new self-shrunken sequence (St).

By the definition of the new self-shrinking rule, the generator produces an output bit whenever this bit is proceeded by 1 in the original sequence (At).

Let k be the total number of zeroes in the subsequence 21 ....,,, −++ βiii SSS .

For 0=k , the subsequence 121 ,....,,, −+−++ ββ iiii SSSS (for ))1( m≤+β , in which

1,1.... 121 ===== −+−++ ββ iiii SSSS or 0,1.... 121 ===== −+−++ ββ iiii SSSS , will occur in

(St) whenever the subsequence ββ +−++ jjjj AAAA ,,....,, 11 , in which

,....,,,,1 )2()1(211 −+−++++ ==== ββ ijijijj SASASAA and )1( −++ = ββ ij SA , occurs in the original

sequence (At). Obviously, this will occur )1(2 +− βm times in a full period of (At). Hence, the subsequence

121 ,....,,, −+−++ ββ iiii SSSS will occur )1(2 +− βm times in a full period of (St).


For ,0≠k the subsequence 121 ,....,,, −+−++ ββ iiii SSSS (for mk ≤++ )1(β ) will occur in the new self-

shrunken sequence (St) at least whenever the subsequence )()1(1 ,,....,, kjkjjj AAAA ++−+++ ββ (of length

)1( ++ kβ less than or equal to m), in which each bit of ,....,,, 21 −++ βiii SSS and 1−+βiS is proceeded by 1,

occurs in a full period of the original sequence (At). Moreover, the subsequence 121 ,....,,, −+−++ ββ iiii SSSS

will occur from subsequences in which each 0 in )1(1 ,....,, −+++ kjjj AAA β is replaced by subsequences of 0's of

length y where )1(1 +≤≤ λy and ).1( ++−= km βλ [When doing that we have to make sure that the length of these subsequences of the original sequence (At) does not exceed m].

The total number of these subsequences in a full period of the original sequence (At) is: i

i i

ik−

=∑

+−λ

λ

2)1(

0.

The subsequence 121 ,....,,, −+−++ ββ iiii SSSS may also occur from other subsequences such as

)()1(1 ,,....,, kjkjjj AAAA ++−+++ ββ (for mk >++ )1(β ).

Therefore, in a full period P = 2m-1 of the new self-shrunken sequence (St) any subsequence

121 ,....,,, −+−++ ββ iiii SSSS of length )1( −−≤ kmβ (i.e. mk ≤++ )1(β ), where k is the total number

of zeroes in the subsequence 21 ....,,, −++ βiii SSS , occurs )1(2 +− βm times for k = 0, and at least

i

i i

ik−

=∑

+−λ

λ

2)1(

0times otherwise, where ).1( ++−= km βλ

3 Cryptanalysis A suitable stream cipher should be resistant against a known-plaintext attack. In a known-plaintext attack the cryptanalyst is given a plaintext and the corresponding cipher-text (in another word, the cryptanalyst is given a keystream), and the task is to reproduce the keystream somehow.

The most important general attacks on LFSR-based stream ciphers are correlation attacks. Basically, if a cryptanalyst can in some way detect a correlation between the known output sequence and the output of one individual LFSR, this can be used in a divide and conquer attack on the individual LFSR [5, 6, 7, 8].

In this section we discuss some approaches for possible cryptanalytic attacks and their complexities.

Assume that the original sequence (At) is produced by a primitive m-stage LFSR (i.e. (At) is an m-sequence of period (2m –1)). For cryptographic applications the key consists of the initial state and preferably the characteristic feedback polynomial of the LFSR. In order to assess the security of the generator we assume that the characteristic feedback polynomial is known. With this assumption we estimate the difficulty of finding the initial state of the LFSR.

We start with a general method for reconstructing the original sequence from the knowledge of a portion of the new self-shrunken sequence (St).

Assume that S0, S1, …, Sn-2, Sn-1 is the known portion of (St). The bit S0 is produced by a bit pair (Aj, Aj+1) of the original sequence where the index j is known.

Our aim is to reconstruct the original sequence in forward direction beginning with position j. As we know S0 we conclude that Aj = 1 and Aj+1 = S0. For the next bit pair (Aj+1, Aj+2) there remain one possibility if Aj+1 = S0 = 1 that is Aj+2 = S1, otherwise (if Aj+1 = S0 = 0) there remain two possibilities that is Aj+2 = 0 or Aj+2 = 1, and so on.

Let k be the total number of zeroes in the subsequence S0, S1, …, Sn-2.

For 0≠k , it can be shown by induction on k that in order to reconstruct the subsequence S0, S1, …, Sn-2, Sn-1 we have a total of:

)2()2(),( 1 −+−=Ψ − kmmkm k


possible solutions.

For 0=k , to reconstruct the subsequence S0, S1, …, Sn-2, Sn-1 we have only one possible solution (i.e. 1),( =Ψ km ).

If a cryptanalyst obtains m consecutive bits of the new self-shrunken sequence (St) then, as (St) is balanced,

approximately half of these consecutive bits will be 0’s (i.e.2mk = ).

So in order to reconstruct these m consecutive bits we have approximately a total of:

)22

()2()2

,(1

2 −+−=Ψ− mmmmm

m

possible solutions.

For security reason it is suggested to consider characteristic feedback polynomials of high hamming weight [7]. If the characteristic feedback polynomial is considered as part of the secret key, the reconstruction of the initial state has to be combined with an exhaustive search over all primitive characteristic feedback polynomials of

degree m. Therefore, the complexity of the attack is increased by the factor m

m )12( −ϕ, which is for large m

may be approximated by 2m. Hence, the total complexity is: 2m ).2()2(2),( 1 −+−=Ψ − kmmkm km

Thus, for maximum security, the key of the NSSG should consist of the initial state and the primitive characteristic feedback polynomial. Subject to these constraints the NSSG has a security level approximately equal to ).,(2 kmmΨ

4 Related Work Interesting example of existing LFSR-based constructions for comparison with the new self-shrinking generator is the self-shrinking generator of Meier and Staffelbach [2].

The advantage of the new self-shrinking generator over the self-shrinking generator is that, given an m-stage LFSR A with initial state A0 and primitive feedback polynomial f(x) of degree m that makes up a self-shrinking generator and a new self-shrinking generator. If the original sequence (At) of A has period M = (2m –1), then for the self-shrinking generator in order to obtain a full period of the output sequence we have to clock LFSR A 2M times, while for the new self-shrinking generator we only have to clock LFSR A M times. Also the output

sequence of the self-shrinking generator has period P that divides 2m-1 and satisfies

≥ 22m

P , and linear

complexity 1

22−

>m

L , while the output sequence of the new self-shrinking generator has period P = 2m-1 and linear complexity L > 2m-2.

The disadvantage is that the self-shrinking generator is more secure against correlation attacks than the new self-shrinking generator [see 1].

5 Conclusion From the theoretical results established, it is concluded that a NSSG with primitive LFSR generates sequences with large periods, high linear complexities, and good statistical properties. These characteristics and properties enhance its use in some applications in cryptography and spread spectrum communications.


References [1] W. Meier and O. Staffelbach: “The Self-Shrinking Generator”, Lecture Notes in Computer Science 950

(EuroCrypt 94), Springer-Verlag 1994, pp. 205-214.

[2] S. W. Golomb: ”Shift Register Sequences”, Aegean Park Press, 1982.

[3] D. Coppersmith, H. Krawczyk, and Y. Mansour: “The Shrinking Generator”', Proceedings of Crypto 93, Springer-Verlag, 1994, pp 22-39.

[4] R. Lidl, and H. Niederreiter: “Introduction to Finite Fields and Their Applications”, UK: Cambridge University Press, 1986.

[5] J. Golic, and M. Mihaljevic: “A Generalized Correlation Attack on a Class of Stream Ciphers Based on the Levenstein Distance”, Journal of Cryptology, 3, 1991, pp. 201-212.

[6] J.Golic: “Towards Fast Correlation Attacks on Irregularly Clocked Shift Registers”, Lecture Notes in Computer Science 921 (EuroCrypt 95), 1995, pp. 248-262.

[7] W. Meir, and O. Staffelbach: “Fast Correlation Attacks on Certain Stream Ciphers”, Journal of Cryptology, 1, 1989, pp. 159-176.

[8] T. Siegenthaler: “Correlation-Immunity of Non-linear Combining Functions for Cryptographic Applications”, IEEE Trans On Information Theory, 30, 1984, pp. 776-780.


Side Channel Attacks on CBC Encrypted Messages in the PKCS#7 Format

Vlastimil Klíma 1 and Tomáš Rosa 1,2

{vlastimil.klima, tomas.rosa}@i.cz 1 ICZ a.s., V Olšinách 75, 100 97 Prague 10, Czech Republic

2 Department of Computer Science and Engineering, Faculty of Electrical Engineering, Czech Technical University in Prague, Karlovo náměstí 13, 121 35 Prague 2, Czech Republic

Abstract Vaudenay has shown in [5] that a CBC encryption mode ([2], [9]) combined with the PKCS#5 padding [3] scheme allows an attacker to invert the underlying block cipher, provided she has access to a valid-padding oracle which for each input ciphertext tells her whether the corresponding plaintext has a valid padding or not. Having on mind the countermeasures against this attack, different padding schemes have been studied in [1]. The best one is referred to as the ABYT-PAD. It is designed for byte-oriented messages. It removes the valid-padding oracle, thereby defeating Vaudenay's attack, since all deciphered plaintexts are valid in this padding scheme. In this paper, we try to combine the well-known cryptographic message syntax standard PKCS#7 [8] with the use of ABYT-PAD instead of PKCS#5. Let us assume that we have access to a PKCS#7CONF oracle that tells us for a given ciphertext (encapsulated in the PKCS#7 structure) whether the deciphered plaintext is correct or not according to the PKCS#7 (v1.6) syntax. This is probably a very natural assumption, because applications usually have to reflect this situation in its behavior. It could be a message for the user, an API error message, an entry in the log file, different timing behavior, etc. We show that access to such an oracle again enables an attacker to invert the underlying block cipher. The attack requires single captured ciphertext and approximately 128 oracle calls per one ciphertext byte. It shows that we cannot hope to fully solve problems with side channel attacks on the CBC encryption mode by using a “magic” padding method or an obscure message-encoding format. Strong cryptographic integrity checks of ciphertexts should be incorporated instead.

Keywords: CBC, symmetrical encryption, padding, ABYT-PAD, ABIT-PAD, PKCS#7, cryptanalysis, side channel attack, confirmation oracle.

1 Introduction Vaudenay's attack [5] has been further studied in [1], where several extensions of and countermeasures were proposed. The only effective padding types defined there were referred to as the ABYT-PAD (arbitrary-tail padding) for byte-oriented messages and the ABIT-PAD for bit-oriented messages. The ABYT-PAD was defined in the following way; let the last byte (bit) of the message be X; pick an arbitrary distinct byte (bit) Y and add one or more bytes (bits) Y as needed to the end of the message. The receiver reads the last byte (bit) of the plaintext and removes all successive bytes (bits) which are the same as Y from the end of the plaintext. The main benefit of this padding is that there is no incorrectly padded plaintext. Therefore, it is no longer possible to use Vaudenay's attack based on a valid-padding oracle, because such an oracle doesn't tell us any new information (its output has a zero entropy overall). However, even when using these methods, there are a lot of other vulnerabilities and possible attacks. In [1] it was underlined that such attacks are pervasive when the integrity of ciphertexts is not guaranteed. As an example, the authors of [1] designed a so-called "cryptographic relay" (a device), which consists of two cryptographic schemes. The first one uses the substantial padding scheme described above, while the second uses a length-preserving scheme (e.g. CTR mode). The device decrypts the ciphertext coming from the first scheme and then re-encrypts it using the second scheme. Because the second scheme does not hide the original plaintext length, it is possible to use this information for an attack on the first scheme. In this paper, we show that it is not necessary to design such an abstract scheme to carry out a successful attack. We simply combine the well-known cryptographic message syntax standard PKCS#7 [8] with the use of the ABYT-PAD padding scheme instead of the PKCS#5 padding. Let us assume that we have access to an oracle PKCS#7CONF which tells us for a given ciphertext (encapsulated in the PKCS#7 structure) whether the decrypted plaintext is correct or not according to the PKCS#7 syntax. This is probably a very natural assumption, because applications usually have to reflect this situation in its behavior. It could be a


message for the user, an API error message, an entry in the log file, different timing behavior, etc. We show that by having access to such an oracle an attacker can invert the underlying block cipher for a particular arbitrary key, thereby deciphering the secret encrypted message. This attack requires a single captured ciphertext belonging to the key and approximately 128 oracle calls per one ciphertext byte. This kind of attack can be extended to other padding schemes (i.e. ABIT-PAD, etc.). Surprisingly, our attack is allowed by those PKCS#7 (v1.6) properties that are planned to improve version v1.5. According to the new version (v1.6) there are not only data-octets (bytes) encrypted (as in the previous version), but it also encrypts the length-octets and type-octets. The main idea of the attack is to carefully combine the changes at the beginning and the end of the encrypted message. Then we use the PKCS#7-confirmation oracle, which tells us whether the change was correct or not in the sense of the PKCS#7 v1.6 format. This information thwarts the original good property of the ABYT-PAD scheme that all deciphered plaintexts are valid. The "improvement" of version 1.5 of the standard thus brought a new kind of attack. It follows that an improvement that is good under a local estimation may turn out to be a bad choice under a broader context evaluation. On the other hand, we do not express the opinion that our attack is a problem of the step of moving from the PKCS#7 v1.5 to the PKCS#7-v1.6 standard. The conclusion of our paper is that, just like the area of asymmetrical cryptography, we cannot hope to fully solve these problems with side channel attacks just by using a "magic" padding method or an obscure message-encoding format.

The rest of the paper is organized as follows; firstly we introduce the necessary notation and description of the PKCS#7 format (§2) and the confirmation oracle PKCS#7CONF (§3). An attack is then presented in §4. In §5 we summarize the complexity of the attack and its extensions. Countermeasures are presented in section §6 and a conclusion is made in §7.

2 Preliminaries

2.1 Notation

We will denote CT the ciphertext C without an initializing value (IV), thus C = (IV, CT). We will assume the block cipher, which works over n-bytes blocks, where n is a positive integer. We will denote EK(B) and DK(B) enciphering and deciphering of a data block B under a secret (symmetric) key K. We will denote ENC-CBCK and DEC-CBCK enciphering and deciphering of the whole plaintext and ciphertext in the CBC mode, respectively. To be consistent with the ASN.1 notation, we will talk about octets with the assumption that the term octet means the same as byte in this paper. We will use "BIG ENDIAN" ordering of bytes inside the data block, i.e. b1 will be the most significant byte in the n-byte block B = (b1, ..., bn). Hexadecimal numbers are denoted using the prefix 0x, the exclusive OR operation is denoted ⊕. We will use it for bits, bytes and blocks of bytes. If the blocks are indexed, we use the second index to pick the byte from it, for instance CTs,n is the last byte of the block CTs. Note that C1 = IV and CT1 = C2 is the first “payload” block corresponding to the plaintext P1 in our notation.

2.2 Description of PKCS#7 data structures, padding scheme and our assumptions

2.2.1 PKCS#7

As stated in [4], the standard PKCS#7 describes the general syntax for cryptographically protected data, e.g. data which is encrypted, digitally signed, etc. Data syntax is described using the notation ASN.1 [6]. It admits recursion, so that one envelope (c.f. [4]) can be nested inside another. The values produced according to this standard are intended to be BER-encoded [7], which means that the values would typically be represented as octet strings. The syntax is general enough to support many different content types. PKCS#7 defines the six following ones: data, signed data, enveloped data, signed-and-enveloped data, digested data, and encrypted data. These content types are defined using the notation ASN.1 and they are used in a number of applications, programs, protocols etc. For instance, we may take the banking protocol SET or the standard for a secure electronic mail S/MIME. We will concentrate on the content type "enveloped data". It contains the data (a binary content) encrypted by the symmetric encryption key, where this key is transmitted using a public-key algorithm. We will assume that the data is as usually encrypted by a block cipher in the CBC mode.


2.2.2 ASN.1 encoding

Before encryption, the data being encrypted is ASN.1 encoded first, usually by using the BER/DER encoding [7]. In most cases encoding consists of adding some type-octets together with some length-octets before the data itself. The type-octets define the type of data (type of data structures) and the length-octets define the length of the data. This length means the length of the original data, which follows after the length-octets. The triplet (type-octets, length-octets, data-octets) is then padded and encrypted in the CBC mode.

2.2.3 Data types

There are a lot of data types that can be used in various applications for data being encrypted. These data types are usually publicly defined and their octet codes are thus well known for a concrete application. Probably the most often used one is the data type OCTET STRING, encoded as one octet with the value 0x04. Without loss of generality, we may assume that the data type is OCTET STRING for the purpose of our side channel attack description.

2.2.4 Data length

Similarly, the length of the original data being encrypted is encoded into one or more length-octets. If the data length is less than 128, then there is only one length-octet the value of which states exactly the data length. If the data length is higher than or equal to 128, then it is encoded as a 2 to 128 octets long string of the length-octets. In this case the first octet has the most significant bit set to 1 and its remaining bits express the number of the following length-octets. The remaining length-octets then express the data length in the integer base 256. For instance, if the length of the original data is less than 64 KBytes, then the first length-octet is 0x82 and the following successive two octets give the particular length in the base 256. The number of length-octets doesn't play any important role in our side channel attack. For the sake of simplicity, we will assume that the data being encrypted has only one length-octet.

2.3 Encryption in the PKCS#7 version 1.5 and 1.6

Let us have L bytes of data. We will assume their ASN.1 encoding as (0x04, L, data). Version 1.5 of PKCS#7 [4] was designed to enable PEM compatible formats, but this brought some inconveniences for applications. It required applications to "dip under" the ASN.1 and deal directly with the BER/DER encoding of data (signing, encryption). Such BER/DER "hacking" made it difficult for users of ASN.1 compilers to generate encoding/decoding subroutines, because the head of the data and the data itself were processed separately. Having accepted the ascendancy of S/MIME over PEM, and the desirability of avoiding low-level "hacking" of the BER/DER encoding, version 1.6 of PKCS#7 [8] modified the processing rules to operate on the entire BER/DER encoding of the data. In particular, this means that data-octets are encrypted together with the type-octets and length-octets as one binary stream (type-octets, length-octets, data-octets). It is anticipated that version 2 of PKCS#7 will also incorporate this change.

2.4 Using ABYT-PAD padding scheme

Before the encryption, we need to append an appropriate padding. Finally, we encrypt the quadruple (0x04, L, data, padding) in the CBC mode. Here we assume that the padding scheme used is ABYT-PAD [1], however the attack can be easily extended to some other schemes (for instance ABIT-PAD). According to [1], ABYT-PAD is defined in the following way.

Let the last byte of the plaintext be X and pick an arbitrary distinct byte Y. We add one or more bytes of Y as needed to the end of the plaintext in such a way that the new plaintext length is an integer multiple of n. Emphasize that at least one byte of Y must be appended. In the case of an empty plaintext, Y can be an arbitrary value. If the padding is not more than n octets long, we talk about a "short" ABYT-PAD padding. In the case of an unlimited padding length, we will talk about a "long" ABYT-PAD padding. The receiver reads the last byte of the plaintext and removes all the successive identical bytes from the end of the plaintext. In the following text, we will assume that the padding is the "short" one, i.e. the number of padding bytes has to be from 1 to n. However, it will become clear that it is easily possible to extend the attack to the long ABYT-PAD padding. We also assume that the symmetric key and the underlying block cipher are always the same during our attack.


3 Confirmation oracle PKCS#7CONF Assume that a sender encrypts messages using: the PKCS#7 data type "enveloped data", a block cipher in the CBC mode, and the ABYT-PAD padding scheme. The encrypted data is ASN.1 encoded, padded, and encrypted using a random symmetric key, and then the ciphertext CT is put in a specific place in the highly structured data block "enveloped data". The symmetric key is then encrypted using a public-key scheme and is also put in its specific place in the "enveloped data". The initialization value (IV) is saved in this structure, outside the ciphertext CT (in data type "Content Encryption Algorithm Identifier"), as well. In particular, we note that it is possible to change IV without disturbing any other content of the "enveloped data". Furthermore, we assume that when the attacker changes the length and the content of the ciphertext CT later on, she will also eventually change the appropriate length octets of all "higher" structures containing it. Thus, the changed ciphertext CT will be correctly encapsulated in the PKCS#7 structure. In the following, we will focus only on the receiver's dealing with the IV and CT items in the block "enveloped data".

Definition (PKCS#7 confirmation oracle PKCS#7CONF(C)).

Let us have the ciphertext C = (IV, CT).

We conjecture a PKCS#7CONF confirmation oracle, PKCS#7CONF(C): C → (ANSWER = “OK/BAD”), to encapsulate the following procedure:

1. P = DEC-CBCK(C); the plaintext P is obtained by deciphering the ciphertext C in the CBC mode under the symmetric key K

2. Remove the padding from the plaintext P; the resulting message is denoted as M.

3. Parse M according to PKCS#7:

• Check the type-octets of M; according to the assumptions in §2 we expect one concrete value to be here - 0x04. If it is not here, an error has occurred.

• Check the length-octets of M; we expect one length octet to be here (L), furthermore, L must be equal to the length of M, obtained in step 2. If it is not, an error has occurred.

4. If the two previous checks in step 3 are successful, the answer of PKCS#7CONF(C) is “OK”; otherwise it is “BAD”.

We note that no error messages are expected to occur in steps 1 and 2. For the sake of convenience, we will use the symbols O and PKCS#7CONF when referring to the PKCS#7CONF confirmation oracle interchangeably.

4 Attack description Let the attacker intercept a valid ciphertext C = (IV, CT1, CT2, ... CTs), s ≥ 1, and let (P1, P2, ... Ps) denote the corresponding plaintext. We will show that she can then compute X = DK(Y) for any arbitrary chosen Y obviously implying that she can decipher the whole intercepted ciphertext C.

Recall that we are working with short messages (one length-octet) with the short ABYT-PAD padding. However, we will show in section 5 how to modify the attack for longer messages and longer ABYT-PAD padding. The attack has several steps.

The first step is to be carried out only once, in the preparation phase. For simplicity, we assume that we have only one intercepted ciphertext C. If we had more ciphertexts, the preparation phase could be easier.

4.1 Preparation phase: Finding the valid length L of the message

Since C is a valid ciphertext, the corresponding message M (plaintext without padding) conforms to PKCS#7. Thus we have P1,1 = 0x04 and P1,2 = L, where L is the length of M. In this step we determine the value of L using a PKCS#7CONF oracle.

Let s ≥ 3. This condition guarantees that changes made in Cs-1 will not affect the first plaintext block containing the length octet. Let us denote LPAD the length of padding and LDATA the length of remaining data bytes in the last plaintext block, i.e. LDATA + LPAD = n. At first, we will successively test every byte from the end of the last plaintext block whether it is a padding byte or a data byte. When we find the first data byte from the end, we have the value LDATA and we stop testing. According to our assumptions, 0 ≤ LDATA ≤ n -1, because at


least one byte (Ps,n) is a padding byte according to ABYT-PAD padding. Therefore we begin our test with Ps,n-1 following the pseudocode written below. We will denote C' our changes in the original ciphertext C.

Remarks

• There is the possibility of further optimising this process by various methods, for instance by the interval halving method, similarly as in [1]. In this case, we would need O(log2n) oracle calls. On the other hand, it is only a marginal improvement, because this step is carried out only once in the preparation phase.

• When the intercepted ciphertext has only one block CT1, i.e. s = 1, we can use the same process as in case s ≥ 3, because we will have full control over changes in the first plaintext block.

• In the case s = 2, we can artificially lengthen the original ciphertext (IV, CT1, CT2), for instance, as (IV, CT1, CT2, IV, IV, CT1, CT2). It is only necessary to change the second byte of the primary IV appropriately, because we added 4*n bytes to the message M. For instance if n = 8, we artificially

CTemp = CTs-1

LDATA = 0

For j = (n -1) downto 1

{

CTs-1,j = CTempj ⊕ 1

If O(C') = "OK" then LDATA = j, break

/* Note.

The change will result in the corruption of the whole block Ps-1 and of the byte Ps,j.

If O(C') returns "OK", then the change of the original plaintext byte Ps,j to the value Ps,j ⊕ 1 didn't affect the length L. Therefore Ps,j is a data byte and we have LDATA = j.

If O(C') returns "BAD", the length L doesn't conform to the padding. There are two possibilities.

(i) Ps,j was the last data byte, but it has been artificially changed to the padding byte

(ii) Ps,j was the padding byte, which has been changed to a non-padding byte

We can decide between these two possibilities by setting CTs-1,j to the value CTempj ⊕ 2 and calling the oracle O again.

*/

CTs-1,j = CTempj ⊕ 2 and call O(C')

If O(C') = "OK" then LDATA = j, break

/* Note.

If it returns "OK", Ps,j was the data byte. If it returns "BAD", Ps,j was a padding byte. In this case we continue to test the next bytes on the left.

*/

}

L = (n - 2) + (s - 2)*n + LDATA

/* Note that (n-2) bytes are counted from the first block and LDATA bytes come from the last block. The resting (s - 2) blocks have the full length n.*/


added 32 bytes to it and we can fix the length easily by xoring the byte C1,2 with 0x20, because the length of the original message M was less than 14. Now we can follow the process above for s ≥ 3.

Now we have the plaintext byte P1,2 = L of the ciphertext C. The complexity of this step is maximally 2*(n - 1) oracle calls.

4.2 Computing X = DK(Y) leaving one byte of uncertainty

Now we use the first two blocks (IV, CT1) of the intercepted ciphertext C and create a new one C' = (IV, CT1, S, T, Y), where S and T are arbitrarily chosen and Y is the block which is to be decrypted. Let us denote P = (P1, P2, P3, P4) as the plaintext corresponding to the ciphertext C'. We have P1,1 = 0x04 and P1,2 = L, where L is known from the previous step. Using the following pseudocode, we determine X = DK(Y) leaving one byte of uncertainty.

At the end of the procedure we have

(4.2) X1 ⊕ T1 = X2 ⊕ T2 = ... = Xn ⊕ Tn = A,

where the values of Ti (and eventually also Sn) have been adjusted above. Note that for n > 32 we will need more length-octets, so it would be necessary to slightly modify this procedure.

In this step, we need 128*(n - 1) oracle calls on average. According to the procedure written above, the maximum number of oracle calls is clearly limited by the number 512*(n - 1).

ITemp =IV , TTemp = T, A = Xn ⊕ Tn

For i = (n - 1) downto 1

{

/* In this loop we derive the i-th byte P4,i, where P4,i+1 = ... = P4,n are padding bytes, all equal to A.*/

N = (n - 2) + n + n + (i - 1)

IV2 = ITemp2 ⊕ P1,2 ⊕ N

/* After deciphering C', the oracle O gets the number N in the place of P1,2. Thus it will expect i -1 data bytes and n - (i - 1) padding bytes in the last plaintext block P4. */

(*) For j = 0 to 255 do

{

Ti = TTempi ⊕ j

If O(C') = "OK" go to (**)

/* If O(C') = "OK", the plaintext is PKCS#7 conforming and Xi ⊕ Ti is the padding byte A. Thus we have Xi ⊕ Ti = Xi+1 ⊕ Ti+1 = ... = Xn ⊕ Tn = A and we can continue to derive the next byte. */

}

If (i >1) then Ti-1 = TTempi-1 ⊕ 1 else Sn = Sn ⊕ 1

Go to (*)

/* If the oracle O has always responded "BAD" in the preceding cycle, it means that when the correct value (A) occurred on the i-th byte, it accidentally also occurred on its left side. Therefore, we change the left byte and go back to (*). Now, the oracle must once respond "OK". */

(**) /* Continue to the next loop. */

}


4.3 Determining the remaining byte of uncertainty

Now we use the blocks T and Y created in the previous step. The ciphertext C = (T, Y) gives the one plaintext block consisting of n bytes having the same value A. We will now change T1, T2 and Tn to obtain a PKCS#7 conforming message. We construct the message in the way to have the length of n - 3 octets and one padding byte. We then determine the value of A in the following way.

Now, we restore the value T from TTemp and we substitute it with A into the system of equations (4.2), thereby deriving the value of X.

This step requires 128 oracle calls on average. It takes maximally 256 oracle calls.

5 Complexity of the attack and its extensions Recall that the complexity of the attack is at most 2*(n-1) calls in the preparation phase. This phase is carried out only once for a particular symmetric key. To decipher each ciphertext block, we then need 128*(n-1) + 128 = 128*n oracle calls on average. The maximum number of oracle calls per ciphertext block is bounded above by 512*(n - 1) + 256.

Now we summarize our remarks on possible extensions and modifications of the attack.

• In most cases of longer messages with more than one length-octet, we can easily derive the plaintext byte P1,2 = L in the preparation phase. In these cases P1,2 is the first length-octet and thus P1,2 is equal to the number of remaining length-octets + 0x80 (c.f. §2). We can estimate the number of remaining length-octets directly from the length of the ciphertext.

• Generally speaking, when longer messages (with any kind of ABYT-PAD padding ) with more than one length-octet are used, we can successively change the third, fourth, etc. byte of the IV and send the ciphertext to the oracle O. If we change the length octet, the oracle returns "BAD". If it returns "OK", we hit the first data octet. Now we have the number of length octets (W) and we get P1,2 = 0x80 + W immediately.

• If we may assume that the ciphertext contains at least n bytes of ABYT-PAD padding (one full block or more), we can artificially shorten the ciphertext (IV, CT1, CT2, ..., CTs-1, CTs) to the last two blocks only (CTs-1, CTs). We then use the procedure from §4.3 to determine the value of padding, i.e. we compute the value of DK(CTs) ⊕ CTs-1. Basing on this knowledge, we can continue directly to step 4.2, thereby bypassing step 4.1.

• A variant of this attack can be also derived for the ABIT-PAD padding. Since the only difference between ABYT-PAD and ABIT-PAD is the size of the elementary block unit, the derivation is a matter of changing the byte-oriented approach for a bit-oriented one. Note that the PKCS#7 format discussed here is byte-oriented in its nature, therefore even when using ABIT-PAD, we pad bytes. However, we may expect that the PKCS#7CONF based on ABIT-PAD would, in a certain way, allow an attacker to do the inversion of EK(B) bit-by-bit instead of byte-by-byte. Such an approach generally helps the attacker

TTemp = T

For j = 0 to 255 do

{

T1 = TTemp1 ⊕ 0x04 ⊕ j, T2 = TTemp2 ⊕ (n - 3) ⊕ j, Tn = TTempn ⊕ 1

C' = (T, Y)

/* Note that C' corresponds to the plaintext (A ⊕ 0x04 ⊕ j, A ⊕ (n-3) ⊕ j, A,..., A, A ⊕ 1). */

If O(C') = "OK" then A = j, break

/* If O(C') = "OK", the plaintext is PKCS#7 conforming. Thus, we have A ⊕ 0x04 ⊕ j = 0x04. We then easily obtain the unknown A as A = j. */

}


to improve the effectiveness of her attack. Such an improvement would be useful in case of extremely long padding string.

6 Countermeasures The attack presented here is based on the behaviour of a typical transport-layer application, which routinely receives a ciphertext, deciphers it, and decodes its data payload, which is then passed to the upper layers. If an error occurs during this processing (e.g. ASN.1 parser fails, the padding is incorrect, etc.), it is natural that the application informs its communicating peer. Ignoring these errors is theoretically possible, but in practice it wouldn't make a lot of sense. Moreover, such a failure would be probably detectable from the behaviour of the upper-layer application.

We emphasize that the attack discussed here is not only a particular problem for padding methods. Generally speaking, such an attack can be expected whenever the following conditions are fulfilled:

(i) there are some formatting rules set for plaintexts which must be checked,

(ii) an attacker can freely modify captured ciphertexts and re-send them to the communicating application,

(iii) the changes made in (ii) induce predictable changes of the corresponding plaintext.

The combination of the CBC mode with the PKCS#5 padding scheme was perhaps the most obvious way in which the conditions given above were fulfilled. The only thing that is still surprising is the amount of time it took for the cryptanalysts to disclose this weakness. To avoid other possible “surprises”, we should constantly verify these conditions when designing new encryption schemes. In this paper we addressed the situation where the first condition seems to be thwarted, since the padding method ABYT-PAD does not impose any checkable rules. However, the condition is easily restored if we incorporate the formatting rules given by the PKCS#7 standard. It clearly follows that despite being very tempting, we cannot hope to solve problems of attacks addressed here and in [1] and [5] by thwarting only the first condition written above.

A better way seems to be to focus on conditions (ii) and (iii). We can use the paper of Krawczyk [12] to conjecture that the best way is generally to thwart the second condition by using the authentication of ciphertexts. This countermeasure was also generally recommended in [1]. However, in some older applications it might not always be easy to introduce such a modification. Therefore, we looked at thwarting the last conditions. In [10] we designed a method that effectively prevents an attacker from making predictable changes of the plaintext by changing the ciphertext. Our method then enables any padding method that is limited to the last block to be used. The main idea of our approach is encrypting the last block in a different way and under a different key. This so-called strengthened encryption changes the definition of the encryption and decryption process, but it is still compatible with the original CBC encryption from the point of view of data structures and their length. From a practical viewpoint, we conjecture that for existing applications and protocols it is better to change the program codes or data semantic rather than the data structure itself. We must emphasize that our method works well, unless there are other structural checks of plaintexts. Therefore, generally we strongly recommend adding a cryptographic check of ciphertexts in the sense of [12].

7 Conclusions In this paper we have shown that we cannot hope to fully solve problems with side channel attacks on the CBC encryption mode by using a magic padding method or an obscure message-encoding format. Vaudenay showed in [5] that the CBC encryption mode ([2], [9]) combined with the PKCS#5 padding scheme ([3]) allows an attacker to invert the underlying block cipher, provided she has access to an oracle which for each input ciphertext states whether the corresponding plaintext has a valid padding or not. Countermeasures against this attack using different padding schemes were studied in [1] and the best method was referred to as the ABYT-PAD.

In this paper, we combine the well-known cryptographic message syntax standard PKCS#7 [8] with the use of ABYT-PAD in the place of the PKCS#5 padding scheme. We assume that the attacker has access to an oracle PKCS#7CONF which tells her for a given ciphertext (encapsulated in the PKCS#7 structure) whether the deciphered plaintext is correct or not according to the PKCS#7 (v1.6) syntax. This is a very natural and straightforward assumption, because applications usually have to reflect this situation in their behaviour. It could be a message for the user, an API error message, an entry in the log file, different timing behaviour, etc. We have shown that having access to such an oracle enables the attacker to invert the underlying block cipher and


decipher the encrypted message. It requires a single ciphertext for a particular key and approximately 128 oracle calls per ciphertext byte.

Surprisingly, the attack is allowed by those PKCS#7 (v1.6) properties that are designed to improve version v1.5. They are also planned for version 2. However, the improvement of the standard brought a new kind of attack. It follows that an improvement beneficial according to a local estimation may turn out to be a bad choice under a broader context evaluation. On the other hand, we do not express the opinion that our attack is a problem of the step of moving from the PKCS#7 v1.5 to the PKCS#7 v1.6 standard.

The attack described here can be also easily extended on other TLV-like schemes. The TLV stands for tag-length-value, which is a common nickname of many data protocols and formats used nowadays. Since TLV involves also many standards used in the banking sector, it indicates that existing systems in such areas deserve certain amount of attention according to the attack presented here.

The discussed problems with side channel attacks on the CBC encryption mode should be solved using strong cryptographic integrity checks of ciphertexts. Our contribution should be regarded as further evidence that these checks must be included in the new cryptographic standards and protocols.

Acknowledgements The second author is grateful to his postgraduate supervisor Dr. Petr Zemánek for his continuous support in research projects.

References [1] Black, J., and Urtubia, H.: Side-Channel Attacks on Symmetric Encryption Schemes: The Case for

Authenticated Encryption, In Proc. of 11th USENIX Security Symposium, San Francisco 2002, pp. 327-338.

[2] NIST Special Publication SP 800-38A 2001 ED, Recommendation for Block Cipher Modes of Operation, December 2001.

[3] PKCS#5 v. 2.0: Password-Based Cryptography Standard, RSA Laboratories, March 25, 1999.

[4] PKCS #7 v1.5: Cryptographic Message Syntax Standard, RSA Laboratories, November 1, 1993.

[5] Vaudenay, S.: Security Flaws Induced By CBC Padding - Application to SSL, IPSEC, WTLS..., EUROCRYPT '02, pp. 534-545, Springer-Verlag, 2002.

[6] ITU-T Recommendation X.680 (1997), ISO/IEC 8824-1:1998, Information Technology - Abstract Syntax Notation One (ASN.1): Specification of Basic Notation.

[7] ITU-T Recommendation X.690 (1997), ISO/IEC 8825-1:1998, Information Technology - ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).

[8] Extensions and Revisions to PKCS #7 (Draft PKCS #7 v1.6), An RSA Laboratories Technical Note, May 13, 1997.

[9] RFC 2268: Baldwin, R., and Rivest, R.: The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms, October 1996.

[10] Klíma, V., and Rosa, T.: Strengthened encryption in the CBC mode, Cryptology ePrint Archive: Report 2002/061, http://eprint.iacr.org/2002/061.pdf.

[11] Rosa, T.: Future Cryptography: Standards are not Enough, in Proc. of Security and Protection of Information, NATO-IDET, 2001, Military Academy in Brno, pp. 237 - 245, Brno, 2001.

[12] Krawczyk, H.: The Order of Encryption and Authentication for Protecting Communications (or: How Secure Is SSL?), CRYPTO' 01, pp. 310 - 331, Springer-Verlag, 2001.


Secure Splitting Block (SSB)

Libor Kratochvíl

[email protected]

S.ICZ a.s. V Olšinách 75


Abstract Data created by today’s information systems are not sufficient for their proper operation. Direct access of such systems to public data is needed. Systems often provide services to external subjects on-line as well. These features include communication with an external environment, which is usually considered insecure within the given system's security policy. Developers have to solve the problem of how to assure communication without connecting the system to an insecure environment. The following paper describes a possible technical solution to this problem based on a Secure Splitting Block device, an alternative to the commonly used firewall technology.

The SSB is device designed to exchange data files between isolated networks. Files are transferred without the need for physical transport of external data media while secure separation of communicating peers is preserved. The SSB may be applied in separated environments, especially those processing secret information. SSB’s main benefit is the possibility to run distributed applications requiring frequent data updates in a separated environment. Thanks to its architecture, implementation of the device into existing systems does not require a modification of their security policy, as long as physical media exchange was used previously. Built-in audit mechanisms also lower the risks associated with human factor within physical media exchange.

Keywords: communication, interconnection.

1 Introduction Building a contemporary Information System is always a compromise between functionality and security of a given solution. System architects oscillate between the two extremes of building a 100% secure system providing very little information and building a 100% user-friendly, insecure and open system. The functionality value of both of the above extreme options would be approximately the same - zero. Connection of an insecure system to a public environment (especially the Internet) would mean immediate attacks - especially the simplest DoS-type attacks. The owner of such a system would also have to face the legal consequences of leak and misuse of system information.

Another problem is the fact that only a very small part of information systems is capable of operating solely with data created by the system itself, or data entered into the system during commissioning. This of course also applies to systems processing confidential information, where the situation with input and output of information to/from the system is even more complicated because it is subject to measures authorized by the relevant national security agency.

Generally speaking, two basic types of solutions are used for secure data communication between information systems today. These two solutions are at the opposite sides of the spectre for both functionality and security. The first approach involves a controlled interconnection of systems directly at the network level. Interconnection control is based on filtering of communication protocols and/or implementation of application proxy gates. Configuration of the filtering element provides the required level of functionality and security across the entire spectre - from full interconnection to complete prevention of traffic. Such approach offers very low guarantee of preventing unwanted interconnections. Such connections may result from several causes, for example configuration errors, communication protocol errors or as a result of exploiting a interconnection device implementation error, because the transferred data interact directly with the interconnection device system. Such errors may result in a break of system’s security and/or leak of secret information. For these reasons the only application of this type of interconnection within secret information processing systems is in systems processing secret information at the same security level, see for example [1].


The second type of approach to communication between the system and the environment is to physically divide the system from the outside world and exchange information manually using physical transport of external data media. This approach provides a high level of security, but minimizes functionality. Its advantage is the fact that errors in configuration, interconnection device, or communication protocol are ruled out, but it introduces the human factor into the information exchange, which influences the channel error rate. The use of humans also limits audit functionality. The biggest limitation of this type of 'communication' is the fact that its latency does not allow for use with distributed applications dependent on frequent data exchange. This type of transfer is currently being used for limited data exchange between systems with different security levels.

The purpose of this paper is to introduce a system architecture of a device which would be capable of combining the advantages of both the above approaches to secure communication. The paper proposes requirements and evaluates the possibility of implementing a device enabling continuous, low-latency transfer of large volume of data without interconnecting the communicating parties. Such device could solve the problem of automated data exchange between systems working at different security levels, or systems maintained by separate and distrustful authorities.

2 Requirements The Introduction above contains the basic concept of a device enabling data communication, which meets the following contradictory requirements:

• Secure separation of communicating parties.

• Frequent exchange of large data volumes.

These requirements, seemingly impossible to fulfil at the same time, may be, under certain circumstances, implemented into a device enabling secure data exchange while reliably separating the communicating entities. The architecture concept must be based on the premise of developing a splitting, rather than an interconnection device. Implementation of such a device MUST NOT interconnect the two communication systems at any of the OSI model layers. The design must primarily concentrate on all the splitting functions, only secondarily on any transmission functions. For the purposes of this paper, the proposed device shall be referred to as Secure Splitting Block (SSB).

2.1 Communicating Entities

As for any design, the area in which the solution will be used must be defined first. For the SSB, the area of use is two general subjects exchanging data but not wishing to be interconnected. No security requirements for these two subjects exist as far as the SSB development is concerned. They could be any two independent information systems. The design aims to provide such a level of guaranteed security to make SSB suitable for bi-directional data exchange even between systems operating at different security levels.

2.2 Design Concept

The design concept was already defined by the above article. Any device to be connected to a system with a defined security policy must be entirely controlled by the authority responsible for that system. This requirement determines that the SSB device must consist of at least two independent but completely equivalent parts (blocks). Each of these parts is controlled by one authority, providing all control functions, including physical access, to that authority only.

An accurately defined interface must be provided between these two parts, providing only a pre-defined minimum and limited set of functions necessary to ensure the required functionality. The interface must be designed and implemented so that it respects complete independency of both connected SSB blocks and so that monitoring or controlling the operation of the opposite block or even the system to which it is connected is not possible. Such interface provides the “Point of Segregation“ of both systems.


LAN ALAN “A” LAN ALAN “B”

Security Domain “A” Security Domain “B”

Authorities

Logical and PhysicalWALL

File

Figure 1: SSB Philosophy.

The device must provide a functionality equivalent to the following: data to be transferred are first saved to a pre-determined computer within the network and then copied to a data medium as a file. The medium is then handed over to the opposite communication party, where the data is re-introduced into the system using a reversed order of action. From the above definition it is clear that the communicating parties will not be interconnected by any communication protocol and all data will be transferred in an unstructured data file which does not interact with the SSB system itself.

2.3 Design Principles

As for any design process, a set of basic rules, which the final product must meet, should be defined prior to commencement. For the implementation of SSB, these are at least the following:

1. The Technology Diversity Rule - To provide a high level of guaranteed security, the possibility of any arbitrary error causing a failure of the implemented security mechanisms resulting in the connected system being penetrated must be completely ruled out. The device must therefore consist of a minimum of two different types of hardware and software.

2. The Distrust Rule - The solution must not - in any of its parts - be dependent on the correct function of a sole security mechanism. A possibility of failure must be expected for all implemented parts - especially as far as its influence on failures of the secure splitting functions is concerned. A failure of a transfer function and subsequent loss of availability is not concerned a risk in this context. On the contrary, it is desirable that the eventual failure of any of the splitting functions results in a shutdown (inoperability) of the entire SSB device (instead of a possible penetration of the connected subject).

3. The Multiple Mechanism Rule - The implemented security mechanisms must be multiplied to the greatest possible extent, on the principle of (technically) different applications of the same mechanism in different parts of the device. A cascade of technically identical mechanisms with the same functionality is not considered a multiple mechanism.

The above “Technology Diversity“ rule already pre-defines the block diagram of the entire device. The device must consist of two identical parts (see “Design Concept“) and each of those parts must contain a minimum of two different hardware components. See “SSB Block diagram” on the figure below.


Transferserver

Point of

Segregation Transferserver

ResistanceLimit

Borderrouter

ResistanceLimit

Borderrouter

LANLAN

Block „A“ Block „B“

SSB Device

Figure 2: SSB Block Diagram.

Assessment of “Resistance Limit“ is based on the “Distrust Rule“ maximized to contain possible complete breaking of security of one of the used technology platforms. The “Resistance Limit” defines the maximum possible extent of penetration of the entire SSB device, which does not result in penetration into the network connected to the SSB.

The “Multiple Mechanism Rule“ and the fact that the solution is to be used for communication, defines the main system components. Since this is a communication device, one of its technology elements is a router, which provides both classic router functionality and usual firewall functions. The second platform must provide the required functionality and at the same time offer safety mechanisms similar to those of a normal firewall. A UNIX-type operating system server fulfils these requirements.

2.4 Data Transfers

The process of data transfers from one system to the other must consist of two completely separate activities. The first is communication between a networked computer and the SSB device itself. This communication uses standard communication protocols and its goal is to transfer the file between the network client and the SSB device block attached to it. This communication must comply with several requirements:

• All transfers may only be realized from authorized network nodes.

• Only authorized users may initiate data transfers.

• The communication must be cryptographically protected.

• The transfer protocol used must be a status-type protocol.

• All data transfers must only be initiated by a networked computer, never by the SSB device itself.

The second part of the transport process consists of the data file transfer between the SSB device blocks. This data transfer must be completely independent on processes within the two information systems connected to the SSB and on communication of the networked stations with the SSB device. The connection between both SSB device blocks must not use any network protocol or be controlled by any privileged process. The connection may be implemented using a simple serial link, controlled by a non-privileged process with the transferred files on a data medium as the only output and input. The following requirements must be met:

• The communication is completely independent and asynchronous.

• The transfer link does not allow any other services apart from single bytes data transfer.

• The data flow control is provided at hardware level.

• The transfer interface (“Point of Segregation“) is implemented in the controlling process.


2.4.1 Transfer Queue Architecture

For maximum functionality, the device must enable full duplex data transfers. Because the processes transferring data between the SSB device blocks must not be influenced by the clients-to-SSB communication, receipt and sending of data between SSB and network clients must be logically separated.

We may also expect the device to be used by more than one subject within each of the information systems attached to it. It will therefore operate several logical data flows. SSB must therefore include functions enabling division of individual data flows, their individual settings and control of user access. A communication queue model may be used to meet these requirements as shown on the figure below.

LAN A LAN B

Block “A” Block “B”

Use

r In

terf

ace

Transfer subsystem

User Interface

Tran

sfer

subs

yste

m

AB

IN

IN C::X

AB

OU

TOU

T

C

::

X

AB

IN

IN C

::

X

AB

OU

T OU

TC::X

Figure 3: SSB Transfer Queues.

FIFO-type queues are most suitable for SSB purposes. Two queues for one duplex data flow at each SSB device block will be used. The queues form a transfer channel between the processes providing communication with clients within the networks attached to the SSB and processes providing transfer of data to the opposite block. To keep the analogy between the SSB and the data media transfer method as close as possible, the queues must be implemented by using a data medium. This provides another division in the communication path and prevents any direct network connection between both communication parties. The following conditions must be fulfilled during practical implementation:

• Only regular data files are saved into the queues as they were received from the user. No meta information on their contents or subsequent processing is created or transferred.

• Processes at opposite ends of the queues do not share any configuration files.

• Processes at opposite ends of the queues do not communicate with each other - synchronization must only be based on the principle of a presence of a transferred file in the queue.

2.4.2 The Transfer Link and “Point of Segregation”

The serial transfer link must use a new type of connection hardware, which was not used as a network interface by the operating system before. The risk of a “forgotten code“, which could be used to implement a network protocol at this communication link, must be eliminated.

The “Point of Segregation” must be defined and implemented so that it expects possible attacks from the opposite SSB block administrator. All communication across this point must commence and be completed as a data file on a computer hard disc. This eliminates any eventual attacks to the level of the regularly transferred files with which the system does not interact further in any way. Because of the “Distrust Rule“, possible corruption of the process controlling the transfer line must be expected and relevant measures taken during development. The “Point of Segregation” must only provide the following functions:

• Sending of the request for file transfer and data file sending.

• Receipt of the request for file transfer and data file receiving.


Node

Plain serial line

Disc media

Transfersubsystem

process

User interfaceprocess

Disc media

Transfersubsystem

process


LAN

Node

LAN

Block “A” Block “B”

Figure 4: SSB Data Path Implementation.

2.5 Device Administration

The device architecture itself determines that its administration must be done by at least two independent authorities. When taking the “Distrust Rule“ into account, it is also evident that device administration must be delegated to several administrators within each of the responsible authorities. The block diagram clearly shows a division between the administration of the border router and the transfer server. The transfer server consists of the operating system itself and of application processes providing the required functionality. System administration and application administration should therefore also be divided. Three types of administrators will therefore be necessary:

• Border router administrator

• Transfer server operating system administrator

• User interface application administrator

Because the SSB is a device providing a high level of security, special requirements are placed on administration. First, remote administration of the SSB device must not be possible. The user interface application administration is an exception to this rule, because user logon is subject to conditions other than account settings in the application only (cipher-key, filter settings). All application processes also run in a secure environment under a non-privileged account. Any eventual configuration error or application administrator account misuse is therefore not capable of influencing the operation of other device parts, or penetrating the network attached to the SSB.

The SSB design concept requires it to function as an analogy to the process of data transfers using external data media, whose principle itself guarantees that both communication parties will not be interconnected in any way. The system will thus always provide a certain minimum security level. This puts special requirements on the system administration. System administration generally assumes the existence of a privileged user with no limitations from the system. This principle is not acceptable for a SSB-type device. During normal SSB operation, the administrator must not have unlimited user rights. The administrator is only allowed to implement actions that cannot influence system security, which in reality means monitoring from the system console only.

The administration tasks themselves may only be implemented when the system is in a special operation mode, under which no application or transfer subsystems are running and may not be explicitly started either. The device administration must be automated to a maximum level and must consist of a minimum number of pre-defined steps to prevent possible errors. For emergency situations, which are not defined under the normal administrator’s tasks, all available tools may be used to repair the system, but the probability of an error increases. Transition to normal operation mode must be ensured after any administration. This may only be done by restarting the transfer server’s operating system. Such restart must ensure that the system will enter a


consistent state after resuming operation, that is eventual administration errors will not have influence on normal system operation.

2.6 Audit and Archival

A SSB-type device must ensure a reliable audit of all actions and as a bonus provides archival of transferred data. The archival should be implemented as an optional parameter of the transfer queue configuration, because it may not be necessary to archive certain data flows during normal operation. This will save space on the archiving medium and therefore prolong the operating period between maintenance tasks. The data archival will have significant requirements on the data archival space and will be the most frequent cause of administration tasks.

Operation of the device must be conditioned by correct functioning of the audit subsystem. A situation when the audit subsystem is inoperative and the device still transfers data is not acceptable. The audit functionality must not be configurable and all subsystems must verify correct audit functionality prior to any activity. The following special requirements must be put on the audit and archival during implementation:

• Data are saved to an external medium which may be taken out of the device at any time.

• Data writing must only use “append-only” mode, if possible at the level of physical writing to the medium (equivalent to CD-R).

• Integrity of audit data on the medium must be verified during system start-up.

3 Solution Proposal Definition of all requirements is only the first step in a successful solution of a problem. To ensure the required assurance level, all requirements defined above must be correctly implemented using existing technology. If possible, some requirements should be extended. Several rules must be defined prior to development itself. These rules will significantly influence the resulting solution:

1. The Transparency Rule - concerns the transfer server and defines that none of its parts may contain a “black box“, everything must be verifiable in detail (does not concern hardware components). In reality this means that all software must be available in source code.

2. The Minimizing Rule - defines that all design proposals must minimize functionality of individual components so that only the minimum required overall functionality is provided.

3. The Assured Integrity Rule - defines that the system must always be at a defined minimum integrity level, which may not be corrupted. Prior to operating the system, full integrity must be ensured.

4. The Non-compatibility Rule - defines the tendency to implement technologies with the highest possible non-compatibility level with current standards.

5. The Rule of Limits - defines that the system acts as a finite automaton in all of its parts. It is possible to simulate and test all possible conditions the system may be in. The same applies to all configurable parameters.

3.1 Border Router

Besides router-functionality, it must also provide reliable IP filtering. The border router's goal is to:

• Limit access to the SSB to pre-defined IP addresses.

• Protect the transfer server from attacks from the connected network.

• Protect the connected network during eventual corruption of the transfer server system by implementing the “Resistance Level“

The router must be configured according to the “Minimizing Rule“ and must meet the following conditions:

• Remote administration or monitoring of the system is not allowed.


• Filters allow connections to be initialised in one direction only - from the connected network to the SSB.

• Packets may only be transferred to the SSB's user interface application.

• Filters must be provided at all router interfaces and defined for both communication directions.

3.2 Transfer Server

The transfer server’s operating system was defined by the “Transparency Rule“, which is applicable only to free-distributed versions of UNIX – OS’s, such as LINUX. Of course we can not just use one of the standard distributions, extend it with the required functionality and put it into the system. For the above rules to be fulfilled and the required assurance level ensured, implementation of the operating system must meet the following conditions:

• The entire system must be located on and run from a “read-only” medium (CD ROM) – “The Assured Integrity Rule“

• The system must contain necessary components only – “The Minimizing Rule“

• Source code must be available for all binary modules and the operating system's kernel itself – “The Transparency Rule“

• Applications can not be run and special devices used from write-enabled media – “The Assured Integrity Rule“

• The maximum continuous system operation period must be limited – “The Rule of Limits“

• An administrator logged in at the server console is the only interactive user.

3.2.1 Operating System Kernel

Compared to normal OS’s, the kernel of the SSB’s operating system must also meet special requirements. The main difference in the SSB functionality is the requirement to restrict some OS kernel functions to all users, including the administrator. The kernel must therefore contain some type of a security subsystem which enables definition of restrictions whose application is otherwise not possible in an operating system. Implementation of this subsystem must ensure that:

• The security subsystem can not be switched off during normal operation of the device.

• For administrative reasons, it must be possible to switch the operating system into a “security subsystem disabled mode”, but start of pre-defined processes must be disabled in this OS mode.

The OS core must be built to suit the “Minimizing Rule“ and fitted for the concrete hardware. The kernel must consist of a single compact module (static-linked), which may not be extended to include other functionality during system operation.

3.2.2 Security Subsystem

Besides restricting the administrators and providing extra security configuration possibility for the operating system itself, the security subsystem must also enable implementation of “The Multiple Mechanism Rule“. This rule also defines that the SSB operating system must not be left unprotected during an eventual failure of the security subsystem (see the “Distrust Rule“). Its required functionality may be summed up as follows:

• Administrator restriction.

• System calls restriction.

• Restriction on identity change for critical processes.

• Higher granularity of the access control to the file system.

• The “append-only” function for log files.

• Restriction of access to network services.


• Restriction of start of applications from write-enabled media.

3.2.3 SSB Application Processes

Implementation of application processes will influence the final level of separation offered by the SSB. The separation is already provided by inclusion of a plain serial link and a data medium into the transfer path. Incorrect implementation of service processes may create hidden alternative connections outside of the data medium (with is supposed to be the only connection between those processes) in each block. In keeping with the “Multiple Mechanism Rule“ and the “Technology Diversity Rule“, the data medium is not the only element ensuring secure separation. Eventual failure or a design error will therefore not result in interconnection of the communicating systems. Secure separation would then still be provided by border routers and especially the serial link providing the “Point of Segregation“.

Application processes must be highly resistant to their possible use for penetration of remaining system parts. Generally and according to the “Distrust Rule“, the possibility of penetration of individual running processes is taken in account, but the level of such penetration relative to the entire system must be limited to an isolated environment in which the relevant process is running. In reality this means that individual application processes must be run in divided environments with a minimum amount of available assets. Such environments must be strictly divided from each other and no application process may be capable of concurrent or gradual access to more than one of them. The “chroot”-mechanism can be used in practical implementation of such environments and the security subsystem will add further functions to this mechanism.

Implementation of the “Technology Diversity Rule“ also requires that the binary modules of the individual process groups are implemented using different techniques. That means part of the processes will be linked statically and part of them dynamically and different libraries and compliers will be used in their implementation. The following rule was defined to provide extra separation security:

1. The Simplex Transfer Rule - is defined for data exchange between the SSB application processes and requires that data file transfers between application processes at each of the SSB device blocks may only be one-way.

The above requirement on data transfers shows that application processes at each of the SSB device blocks must be divided to a minimum of two absolutely independent groups which must not influence each other at all. However, the “Simplex Transfer Rule“ requires a minimum of three communicating subjects.

Schedulerprocess

Transferprocess


Input Queue

Output queue

Transfer queue

Figure 5: SSB Interprocess File Flow.

3.2.3.1 User Interface Processes This process group ensures communication between the SSB and the users of the connected network and provides the possibility of transfer of data files between the users of the connected network and the queues at the SSB. The processes must ensure user access control for this application and to individual transfer queues, authentication of network stations and encryption of the transfer channel between the SSB and the


communicating client. Practical implementation of all of these requirements should use a Web server-based solution with SSL communication support. This solution fulfils all the rules defined in this paper.

The most important security factor of this group of processes as far as secure separation is concerned is the prevention of their access to the serial communication line connected to the opposite block.

3.2.3.2 Transfer Subsystem Processes This process group provides secure transfer of data files from the hard disc to the opposite SSB block. These processes have two main goals. The first is the secure implementation of the “Point of Segregation“, to ensure that the serial line may not be used to access the system’s network services or to corrupt them. The second goal is to plan individual data transfers depending on the configuration of transfer queues. Division of these processes into two separate parts ensures compliance with the “Simplex Transfer Rule“ and increases the secure separation assurance level.

The most important security factor of this group of processes as far as secure separation is concerned is the prevention of their access to the system's network services.

4 Implementation Example The example demonstrates the possibility of data exchange between information systems with different security levels. A typical example from intelligence services environment is the need to transfer data between an agent in the field and a secret information system. Such agents usually transfer encrypted messages over an insecure channel into the intelligence services’ central control room, where they are manually copied into the information system in which directions to be sent back to the agent are processed. Making the process automated using the current technology would involve a connection of the secret information system to insecure environment, which is not possible. Implementation of an SSB device based on the principles formulated in this paper enables the implementation of automated data transfer between the secret system and insecure environment and at the same time guarantees their secure separation.

Internaldatabase LAN

1. Pull data file

3. Import informationinto system

2.Encryption

SigningVerification

Integrity checkSignature verificationDecryption

2.

3. Push data file1. Select required

information

Applicationcluster

ClassifiedCIS

SSB

LAN Firewall

Unclassified (private)environment

Messagestoreserver

Messageforwarder

PublicArea

Agent

Figure 6: SSB Implementation Example.

The biggest problem arising from communication between systems operating at different security levels is data transfer from a system with higher security level to that with lower security level. Each piece of information transferred in this way must undergo a pre-defined process of lowering the security level at least to that of the target system. This process must be defined as part of the security policy of each system and implemented before the information is sent to the SSB. In our example, such process involves encrypting the directions returned to the agent using a certified method.


5 Conclusion When a SSB-type device is successfully implemented, a new opportunity will open for communication between independent systems whose functionality was previously limited for security reasons. This paper shows that a suitable combination of current technology methods may provide a device capable of combining the application advantages of firewalls with the security of data transfers implemented using physical transport of external data media.

Of course such a device can not provide an universal solution to all problems, because secret systems will always be very specific. Those who expected that using a SSB-type device would enable them to access the Internet from their computers within secret information systems will probably be disappointed. But less demanding users will be able to use public data sources (for example press agency servers) and obtain large amounts of up to date information from them directly into the secret system. The biggest advantage of the solution presented here is the possibility to use distributed applications dependent on frequent data exchange across divided environments.

An important aspect that was not mentioned previously are the operational conditions of such a device. It is not possible to overcome all problems which prevented secure communication before just by connecting a SSB device into the system. The SSB solution should be understood as a combination of the device itself and its implementation into the system. Availability of the proposed device is therefore a necessary but not the only prerequisite of possible automated data exchange between systems operating at different security levels.

When contemplating practical use of SSB devices, one must also consider the fact that there will be no network connection between the communicating systems while most current distributed applications require such a connection. Each distributed application operating across the SSB will probably have to be altered to be able to work in a mode similar to that used in distributed applications where manual data transfer on external media is used.

The design concept requires that the SSB device does not interact with the transferred data in any way. From this requirement it follows that the SSB does not provide the functions of integrity and identification of origin of the transferred data. It also does not provide the function of confirmation of receipt of data (their collection by the user from the output queue). Implementation of such functions is up to the communicating subjects, because SSB is a device intended solely for the purpose of secure data transfer while maintaining a secure division between both communicating parties.

References [1] INFOSEC Technical and Implementation Directive for the Interconnection of Communications and

Information Systems, AC/322-D/0030-REV2, 25 October 2002 (NU).


Symmetric Key Infrastructure

Karel Masařík, Daniel Cvrček

[email protected], [email protected]

Faculty of Information Technology Brno University of Technology

Abstract The denouncement of some properties of key management systems based on X.509 is growing in several last years. This article briefly summarises problematic features of X.509 standard. It is followed by description of key management system based on symmetric key infrastructure. The proposed scheme does not reject public key cryptography completely but is able to use it for authentication purposes. This proposed system is able to fully replace X.509 key management systems in most application environments. The key management system is followed by a communication protocol allowing secure message exchange and it is also utilised for key management procedures. The scheme is currently being implemented so the design as introduced can not be treated as detailed and complete.

Keywords: X.509, key management, symmetric cryptography, diffie-hellman, logging, audit.

1 Introduction It is crucial to return to the beginning and put questions why we are using key management systems based on X.509 (PKI from now on), while analysing problems related to PKI. The original idea – existence of a kind of yellow pages containing public key certificates turned out to be infeasible. There was an attempt for a printed register of certification authorities but it did not spread [x]. The main idea of PKI is to use trusted third party (replacement of yellow pages) for verification of principle‘s identity and its binding with a public key. Important presumption of X.509 approving was creation of world-wide system of unique names – distinguished names (DN). The original proposal did not expect any problems with DN ambiguity, because there was supposed existence of just one root certification authority. The same assumption eliminated problems with verification of certificates issued in different certification domains because there was just one such domain. There should be just one certification authority that is simply trustworthy.

Trustworthiness of a certificate is usually implied by certification policy that may be, but often is not part of each of the certificates. We make the certificate verification procedure simpler by not entering that attribute in the certificate, but it is necessary to set trustworthiness of each root certification authority manually. Certificates issued by commercial certification authorities contain only basic attributes (validity of verification key, purpose applicable on the certificate) that are easily verifiable. The operations with public keys and their certificates performed nowadays deny original ideas of PKI.

It is not surprising that there exist several attempts to change PKI or replace public key cryptography with symmetric one entirely. Let us take a look at the weakest link of PKI to define a set of mechanisms necessary for replacing it. The weakest point is represented by registration authorities and their clerks that verify certification requests. The only security mechanisms allowing control of the activity consist of paper records and copies of documents, i.e. paper logging.

The question arising in the given context is possibility to realise key management some other way. We can ask if it is possible to realise key management just with primitives of symmetric cryptography. A proposal from Christianson, Crispo, and Malcolm appeared in 2000 [14]. It contains mechanisms that are sufficient to realise some of functional properties of key management.

The most important limitation of symmetric mechanisms lies in the sharing of a key between two principals. This sharing disables non-repudiation property for messages exchanged between those two parties. We will solve the problem by routing all messages by several independent principals that in pairs share symmetric keys. Consistent logging of the communication passing through each subject allows not only to detect fraudulent behaviour but also find the originator of such behaviour.


2 PKI Properties PKI is fully determined by a trusted third party (certification authority) that fully defines security properties of the key management system. This fact brings advantages implied by the existence of security domain and “full” trust inside the domain. On the other side, failure of TTP forbids to conduct even the basic functions of key management. If a certificate owner wanted to spread information about his certificate non-validity without TTP, he would not be even able to determine the set of subjects using his certificate.

PKI allows local verification of certificates/signatures without on-line access to certification authority. However, it is necessary to communicate with TTP (revocation authority) or to have access to the site with valid CRLs, when verifying certificates. Existing schemes using revocation authority violate principle stating that signer must be able to provide all information necessary for the signature verification. The on-line access to revocation authority may overload TTP’s servers.

Unique identification of certificate owner is the necessary condition for certificate issuance. We do not see a problem in the relationship between TTP and certificate owner, but between signer and signature verifier. Do you know exact information identifying your partner? Rivest and others proposed solution by name uniqueness in a certain context. This approach breaks importance of the domain defined by certification authority and creates new domains around users not respecting any borders.

The non-repudiation is the most important advantage of asymmetric cryptography and there is no such an elegant mechanism able to replace it.

Other disadvantages of PKI are described in many articles. The main problem is implementation of key-pair revocation when there is a problem of decentralisation introduced by independent usage of public key certificate. It is a typical example of temporary PKI implementations schizophrenia. They are trying to gain advantage from public key cryptography and on the other side they force users to perform all procedures with an on-line communication with TTP. It results in all existing disadvantages. There is a high load of TTP and it is not possible to initiate any procedure by TTP because the existing decentralisation does not allow TTP to know sets of users dependent on public keys.

3 Properties of symmetric key management When we create a key management system based on symmetric cryptography, we are able to preserve most good properties of PKI and at the same time obtain a functionality not possible in PKI systems.

1. Revocation of symmetric keys is simple, because each owner of a key knows who else is using the shared key. This is sufficient to define a mechanism for direct notification. When using asymmetric keys it is necessary to act through TTP and hope that verifiers will be able to connect to the TTP to obtain information about key revocation. The whole procedure is much more complicated, indirect, slower, and with lower reliability – it is necessary to promote on-line revocation authority.

2. PKI (according to its motivation) allows local certificate verification. The praxis, however, demands on-line access to the TTP because accredited certification authorities must provide bullet-proof certificate verification in the moment of signature checking. Symmetric key management reduces the problem because a key is either valid or was explicitly declared as revoked.

3. Usage of asymmetric algorithms forbids anyone (including TTP) to masquerade for some other certificate owner (however, this is ensured only by administrative security and paper documents in the case of TTP!). The bad news is that there is no forward secrecy in the existing schemes and we feel it as a severe weakness. Backward secrecy is ensured only by TTPs through logging and audits against physical records. We are able to provide forward secrecy very easily in symmetric key management schemes.

4. Regarding non-repudiation, there is no easy solution. We propose a procedure based on a special communication scheme in the following paragraphs. The scheme assumes routing of each message by several intermediate nodes. Each message is secured with a key shared by sender and receiver and with keys shared by neighbour communication nodes. This combination allows unique determination of the message originator.

5. Asymmetric keys offer locality of trust unreachable by symmetric cryptography. Symmetric algorithms offer either relation of two principals or sharing of a key among more entities. The latter situation decreases probability to find originator of messages and overall security of the scheme.


PKI has definite advantage of easier authentication originated from the existence of public key. We are able to provide all other properties with symmetric key algorithms. The most difficult is non-repudiation that must be supported by communication logging by mutually untrusting (independent) parties. The parties may be represented by e.g. firewalls placed on borders of security domains.

When we agree on the assumption that key management is simpler with symmetric cryptographic algorithms we can implement most parts of key management with symmetric algorithms. Public key cryptography may be used where it is more convenient for authentication because of requirements on non-existence of physical contact or to minimise of KDC influence.

4 Design of Symmetric Key Management We understand key management system as a set of domains with a binary relation. That binary relation represents existence of shared secret between pairs of principals. Each secret key may have a symmetric public key that can be publicly distributed. Public keys are used for verification of relation validity between two particular principals.

Domains (defined by the principals) are mutually identifiable by secret key and name of the principal - {H(KAX | IDA), IDA}. The existing implementation of key management system uses authorisation server (AS) with functionality of KTC. There is created a shared secret between AS and a new domain when adding the new domain into the key management system. AS is able to remove a domain from the system to block its ability to send and forward messages. Strong role of the AS allows to spread information about exclusion of the domain to all other principals in the binary relation with the affected domain.

Each domain is able to operate as a communication point – mirror – functioning as a message transceiver. Messages consist from data with MAC value computed with the key shared between sender and receiver. The second part contains MAC computed by a key of neighbour principals. This MAC value changes as the message moves through net of principals. Each mirror securely logs the message, checks correctness of the MAC (created with a shared key it possesses) and generates a new second part of the message MACed with a key shared with the following mirror or final recipient.

4.1 Certificates

We create new shared secret between two domains, when adding a new domain into the scheme. In the most simple example, we can use the following certificates:

{IDA, IDB, IDAS, SSAB}Kas

{IDA, IDB, IDAS, SSAB}Kbs

where A, B are domains, AS is an authorisation server SSXY is shared secret and KXY are shared symmetric keys. That basic scheme allows AS to follow all communication between principals A and B. This negative effect can be partially eliminated with a more sophisticated scheme based on public key agreement scheme.

4.2 Key Agreement

Key agreement is the crucial process to be done during introduction of a new principal into the scheme. There are basically three ways how to do it:

1. physical contact with each principal I want to share a secret with – infeasible in many cases

2. use symmetric cryptography to make use of KDC or KTC to create a new share – that TTP (AS in our scheme) is able to decrypt all the communication between pairs of principals

3. use an asymmetric key agreement scheme while TTP is used to confirm identity of the so far mutually anonymous principals – TTP would have to mediate all communication relations to hide its fraudulent behaviour

We believe that the third option is the most appropriate. We can use the biggest advantage of asymmetric cryptography, when private keys do not have to be transmitted over unsecured channel.


4.2.1 DH Key Agreement Scheme

The basic protocol is very simple, let us assume that A and B are the principals to agree on a shared secret and AS is the authorisation server. There exists public modulus N for modular arithmetic operations and G as a generator.

A->B: GXa mod N

B->A: GXb mod N

First two messages may be exchanged directly between A and B. That is followed by secure exchange of information that can be derived from the created shared secret. We can use any secure protocol involving trusted third party. The following lines show Denning Sacco protocol (variation of the flawed Needham-Schroeder protocol) [16, pg. 47], where the hash (and second hash) of shared secret is used for the freshness property of the authentication.

A->S: {IDA, IDB, H2(GXaXb) }

S->A: {IDB, KAB, H2(GXaXb), {IDA, KAB, H2(GXbXa)}KBS}KAS

A->B: {IDA, KAB, H2(GXbXa)}KBS

B->A: {H(GXaXb)}KAB

Where KAS and KBS are actual shared keys between A – AS and B – AS, respectively. KAB is a session key used just for this message exchange. GXbXa is the shared secret, where mod N operation is assumed implicit.

The TTP has at least one additional task during this procedure. We need each of the principal to have a binary relation with several other principals. There are several schemes suitable for that data exchange. We can name e.g. …

TTP should ask appropriate principals to create new relations whenever necessary. This requirement may arise when a new principal is introduced into the scheme and also, when the number of principals/domains increases.

4.2.2 RSA encryption

A and B has generated an RSA key pair (PK, SK). There is also a key shared between principals A/B and AS. What follows is an outline of how the shared secret is

A->S: {IDA, IDB, PKA, T}KAS

S->B: {IDA, IDB, IDAS, PKA, T}Kbs – secret key certificate as described above

B->A: RSA{IDB, IDA, T, RB, PKB}PKA

A->B: RSA{IDA, IDB, T, RA}PKB

A, B: H(RA) xor H(RB)

This is just an outline of what should be exchanged by the protocol. T is a freshness information and RSA{X}K is an RSA operation (encryption of signing) with key K on data X. xor is bitwise operation on two binary numbers.

4.3 Message Transmission

Security of message transmission is based on shared secrets. Let us assume that A and B are sender and receiver of a message respectively, and M1, … Mn are mirrors that provide message forwarding. SSXY,i is an i-th secret shared between principals X and Y. KXY,i is i-th symmetric key between principals X and Y. Let H be a cryptographic MAC function and SM be keyed hash of a message M.

The first step toward sending a message is generation of a new shared key and a new shared secret.

KAB,i=H(0 | SSAB,i), SSAB,i+1=H(1 | SSAB,i)

KAM1,i=H(0 | SSAM1,i), SSAM1,i+1=H(1 | SSAM1,i)


This procedure of shared secret generation is used for message authentication between already known principals. The necessary assumption is the existence of secure keyed hash function and a secure random number generator.

We can now format a new message. The first part is destined for the receiver, the second part for the neighbour communication point M1.

H0=(SSAB,i | h(SSAB,i+1) | SM ) and the message encrypted by key KAB,i - M

H1=(SSAM1,i | H(SSAM1,i+1) | SM )

Each mirror Mi forwarding the message during its transmission verifies Hi, logs the message (together with H0) and generates a new MAC

Hi+1=(SSMiMi+1,i | H(SSMiMi+1,i+1) | SM )

The whole message {M, H0, Hi+1} is sent to the next mirror/receiver. If an error is detected during verification of the hash, the problem is reported to authorisation server that tries to detect originator of the incorrect data. The recipient is able to verify both MACs H0 and Hi+1. When a problem is detected (the results do not equal), it is again reported to AS.

The index of the shared secret is possible to increment after successful acknowledge of the message delivery. The described mechanism allows us to bind subsequent messages. The data produced during such a message exchange is possible to use for identification of a cheating principal/domain.

4.4 Logging

Trustworthiness of the scheme depends on secure logging of the traffic on all principals/domains. It must not be possible to change order of log entries or change their content. We use the following structure of the log entries to ensure the mentioned requirement.

• Message ID – allows its identification in the system and it is therefore prime key of the record. • Type of the message • Recipient and receiver ID • ID of the neighbour that sent the message and that the message will be sent to. • Two MACs of the data with keys KAB, KMi-1,i • MAC of the message path trace • Time – if applicable, or ordinary number of the record • Cumulative hash of previous log records

The most important is the cumulative hash that restricts manipulations with logs pretty well.

5 Trustworthy Hardware Exploitation of symmetric cryptographic algorithms is vulnerable regarding storage and operation with secret keys and shares. We hope the scheme to be as simple as possible to allow implementation of crucial operations into cryptographic smart cards. Implementation of the scheme, where each principal uses is trustworthy hardware module will be fulfilled next year as the second phase of the student project being solved.

The main purpose of hardware tokens will be secure logging of processed and forwarded communication traffic and co-operation with authorisation server, when detected illegal behaviour of a principal in the scheme.

6 Conclusion We propose a scheme for key management and message exchange that uses symmetric cryptography to the maximum extent while preserving properties usually available seen in public key infrastructures. The system that is actually being implemented according to the ideas described should offer simpler communication between principals and sufficiently powerful mechanisms for detection of problems and identification of cheating principals.


The appropriateness of the proposed scheme is dependable on application requirements. The current proposal tries to minimise power of TTP. It can be seen in the key agreement scheme and in the design of improper behaviour detection. The role of the authorisation server is supposed to be primarily control.

References [1] David A. Cooper: A Model of Certificate Revocation. Proceedings of the Fifteenth Annual Computer

Security Applications Conference, pg. 256-264, December 1999.

[2] David A. Cooper: A More Efficient Use of Delta-CRLs. Proceedings of the 2000 IEEE Symposium on Security and Privacy, pgs. 190-202, May 2000.

[3] M. Naor, K. Nissim: Certificate Revocation and Certificate Update. Proceedings 7th {USENIX} Security Symposium (San Antonio, Texas), January 1998.

[4] R. N. Wright, P.D. Lincoln, J.K. Millen, A.I. Lincoln: Efficient Fault-Tolerant Certificate Revocation. ACM Conference on Computer and Communications Security, pgs. 19-24, 2000.

[5] A. Arnes, S. J. Knapslog: Selecting Revocation Solutions for PKI. NORDSEC 2000, Reykjavik, Iceland, 2000.

[6] R. L. Rivest: Can We Eliminate Certificate Revocation Lists?. Financial Cryptography, pgs. 178-183, 1998.

[7] C.A. Gunter, T. Jim: Generalized Certificate Revocation. Symposium on Principles of Programming Languages, pgs. 316-329, 2000.

[8] A. Buldas, P. Laud, and H. Lipmaa: Elliminating counterevidence with applications to accountable management. Jounal of Computer Security (2002). To appear.

[9] ITU-T. Draft revised ITU-T Recommendation X.509 (v4). 2000

[10] Roger Clark: Conventional Public Key Infrastructure: An Artefact Ill-fitted to the Needs of the Information Society. submitted to the Euro. Conference in Information Systems 2001, Bled, Slovenia.

[11] Ellison C., Schneier B.: Ten Risks of PKI: What You're not Being Told about Public Key Infrastructure. Computer Security Journal, vol. XVI, November, 2000

[12] Bellare M., Miner S.: A forward secure digital signature scheme. Advances in Cryptology - Crypto99 Proceedings, LNCS 1666, Springer-Verlag, 1999.

[13] J.Lin, S. Kent, D. Balenson, B. Kalinski: Privacy Enhancement for Internet Electronic Mail: Parts I-IV. RFC1421-1424, 1993.

[14] Christianson B., Crispo B., and Malcolm J.A.: Public-Key Crypto-systems Using Symmetric-Key Crypto-algorithms. Security Protocols, 8th International Workshops Cambridge, UK, April 3-5, 2000.

[15] Cvrcek D., Real World Problems of PKI Hierarch: Security and Protection of Information 2001, Brno, 2001.

[16] Clark J., Jacob J.: A Survey of Authentication Protocol Literature: Version 1.0, November 1997, http://citeseer.nj.nec.com/clark97survey.html

Information about authors Karel Masarik is attending 4th year of M.Sc. studies at Faculty of Information Technology, Brno University of Technology. He is working on the project of implementation of key management system.

Daniel Cvrcek born in 1974. He graduated Faculty of Electrotechnics and Informatics, Brno University of Technology by acquiring Ph.D. in the area of authorisation model for large information systems in 2001. Main research interests include security of smart-cards and key management – public key infrastructures.


Authentication of Paper Printed Documents using Paper Characteristics

Matúš Mihaľák

[email protected]

Institute of Theoretical Computer Science ETH Zürich

Ivan Kočiš

[email protected]

Infotrans, Bratislava

1 Introduction In this article we present new method for authentication of printed documents which seems to be extremely strong against counterfeiters. The proposed method uses the best from digital documents security in the area of paper documents.

How can we utilize the digital world algorithms? Suppose we want to sign a contract. We prepare the text of the contract and if we agree with its content, we sign it using our private key. When printing the contract, we pass the text through special printing driver, which makes a hash of the text and signs the hash with our private key. This signature is then printed as the background of the contract on the paper sheet in the form of machine readable marks. The marks resemble 2D bar code and the technology of printing and reading the marks is called InfoMark [5]. These marks are then overlaid with the text. We can extract the information from InfoMark without any loss by using error-correcting coding. So the document contains the whole information for authentication and it can be done off-line.

To authenticate the content of the document, we scan the document, extract the marks from the image and decode the information from InfoMark information channel. We apply the public key of the signer and compare the result with hash acquired from the text of the authenticated document. We see, that nobody can modify the document, unless he has the private key. Nonetheless the problem is that photocopy of such a document is valid (original). It does not mind when signing contracts, because we do not care about the number of valid copies. But it minds when signing bank bill, because it is difference when there are one, two or more valid copies of one bank bill.

In [6,7] there was proposed a coarse idea how to get over this problem. We studied the problem in detail in [8] and come to some nice results, which we present now in this aricle. The idea is to bind the content of the document with a particular paper sheet, on which is the document printed. How can we do that? If we look on the paper sheet through the light (or if we scan the paper sheet transparently, see Figure 1), we can see a map of dark and light places with no regularity. These differences are due to a randomness of the manufacturing process of paper. This map can be handled similarly as human biometrics. So we can use it for unique ID of paper. But the problem is, that the capacity of InfoMark channel is limited, so we can’t use the whole image as an ID. We have to extract some features and use them as a proper paper ID.

Figure 1: Transparently scanned paper sheet at 1200 dpi scanner resolution.

We have tried several known approaches and proposed some new techniques for feature extraction from image of paper sheet as in Figure 1. We tried to find a trade-off between the extremely secure paper identification and the speed and size of authentication process. Also, we discussed the quality of such a protected documents.


2 Algorithm Feature extraction can be viewed as a transformation t on image f. The image characteristics t(f) are from d-dimensional space and the aim is to design t such that the amount of data will be much smaller that the size of the whole image and will still identify the image uniquely.

Local extremes Because the image of the scanned paper is quite rich on local changes, we proposed to use local extremes as a feature vector of an image of paper sheet:

tR(f) = {(i,j,θ) | -R < k,l < R: (-1)θ f(i,j) < f(i+k,j+l)}, where R is a parameter determining the size of the neighborhood square where the local extreme has to be global.

Moments Image description by moments holds a normalized intensity function f(i,j) as a bi-variate probability density function. Properties of a probability density function can be measured with statistical characteristics – moments. The (k,s)-th moment is defined as follows:

mks = Σi Σj ikjsf(i,j) We can use either more moments of an entire image or we can divide the image into more sub-images and use only small number if moments.

Fourier coefficients Looking on images also in frequency domain can bring us something new. This representation determines how much of the bases are contained in the image – here sinus and cosines functions. The coarse shape of the image is contained in the low frequencies, so we can take only small number of the first coefficients as a feature vector.

Feature comparison We used a percentage of local extremes as a comparison function for two feature vectors of local extremes. For moment and Fourier coefficients image description we used correlation coefficient to compare two feature vectors.

Signer Algorithm: 1. S scans the paper p sheet transparently and gets an image f.

2. S counts v = t(f).

3. S counts hash h=hash(D).

4. S signs the couple v,h using his private key ks

5. S encodes (v,h)ks using InfoMark and prints them on p.

6. S prints document D on p.

Verifier Algorithm: 1. V transparently scans a paper sheet p of document D’ and gets an image f.

2. V counts v’ = t(f).

3. V counts hash h’=hash(D’).

4. V extracts from InfoMark of D’ (using public key ks-1of S) feature vector v and a hash h

5. V compares v, v’ and h, h’.

6. If compare(v,v’)>T and h=h’, then say D’ is a valid document, otherwise D’ is a fake.


3 Results In Figure 2 we present some results on local extremes image descriptors. We tested on images of the size 256x256. IP denotes used image processing technique. 1/1 stands for no preprocessing and gauss 5 stands for gaussian filter of an radius 5. The value ε denotes the tolerance when comparing two local extremes in their x- and y- coordinates. In the column |F| there is a size of local extremes set. Highest fail is the highest percentage measured for images of different papers and Lowest match is the lowest percentage measured for images of the same paper. It corresponding average values are in the corresponding columns.

Figure 2: Experimental results for local extremes.

Bibliography [1] Gonzales, R.C.: Digital Image Processing. Addison-Wesley, 1987.

[2] Hlaváč, V. – Šonka, M.: Počítačové vidění. Grada, 1992.

[3] Lamoš, F – Potocký, R.: Pravdepodobnosť a matematická štatistika, Štatistické analýzy. 2. vyd. Bratislava: Univerzita Komenského Bratislava, 1998.

[4] Menezes, A. – Van Ooorchost, P. – Vanstone, S.: Handbook of Applied Cryptography. CRC Press, 1996.

[5] Úrad priemyselného vlastníctva Slovenskej republiky: Strojovo čitateľný záznam, spôsob jeho prípravy a použitia. Majiteľ a pôvodca patentu: Ivan Kočiš, Dušan Kočiš. Slovenská republika. Patentový spis, PV1154-99. 1999.

[6] Úrad priemyselného vlastníctva Slovenskej republiky: Dokument, spôsob jeho prípravy a zariadenie na autentizáciu a dôkaz registrovanej jedinečnosti tohto dokumentu. Majiteľ a pôvodca patentu: Ivan Kočiš. Slovenská republika. Patentový spis, PV1154-99. 1999.

[7] Mihaľák, M.: Against Illicit Photocopying of Paper Printed Documents. In: Poster at conference SOFSEM 2001. Piešťany, 2001.

[8] Mihaľák, M.: Extraction of robust features for recognition of scanned paper for document authentication. Master’s thesis, Comenius university. 2002.


Critical Infrastructure Modelling

Robert Gogela Luděk Novák Antonín Šefčík

[email protected] [email protected] [email protected]

BDO IT a. s. Olbrachtova 5/1980


Abstract One of the key points of Critical Infrastructure Protection is to have a deep knowledge of Critical Infrastructure (CI) interdependencies. CI modelling is a valuable tool for obtaining important and useful information about a real situation. This article explains the basic approaches commonly used in CI modelling. The focus is concentrated on two CI models – the CI Layer Model and the CI Element Chain Model.

Keywords: Critical Infrastructure, Critical Information Infrastructure, Critical Infrastructure Protection, Critical Infrastructure Modelling.

1 Introduction The nature of risks and vulnerabilities in modern information society is becoming more and more transnational today. An open dialog on newly recognized vulnerabilities at the physical, cyber, and psychological level is needed to create new knowledge and a better understanding of new risks and of their causes, interaction, probabilities, and costs.

Modern society increasingly depends on networked information systems. The information infrastructure is becoming one of the backbones of our societies. Whereas the opportunities for a wide application of modern Information and Communication Technology (ICT) are known and exploited, the negative consequences are not yet thoroughly understood. The global use of ICT means a broad dependence upon and among critical infrastructures. Also there are growing needs for security and protection.

The complicated interdependencies in a complex infrastructure’s environment require special vigilance. Consequently governments are starting to dedicate an extraordinary amount of attention to the Critical Infrastructure and its effective protection.

Critical Infrastructure (CI) includes all systems and assets whose incapacity or destruction would have a debilitating impact on the national security, and the economic and social well being of a nation.

Critical Information Infrastructure (CII) includes components such as telecommunications, computers/software, Internet, satellites, fibre optics, etc. The term is also used for the totality of interconnected computers and networks and their critical information flows.

Critical Infrastructure Protection (CIP) includes measures to secure all systems and assets whose incapacity or destruction would have a debilitating impact on the national security, and the economic and social well being of a nation.

Critical Information Infrastructure Protection (CIIP) is a subset of the Critical Infrastructure Protection. CIIP focuses on the protection of systems and assets including components such as telecommunications, computers/software, Internet, satellites, fibre optics, etc., and on interconnected computers and networks, and the services they provide.


2 CI Modelling Modelling involves the use of mathematical relationships to describe a system. The user needs to have a solid understanding of the system: specially the relationships between events, factors and variables within the model, and secondly the magnitude of those relationships.

A model is simplified representation of reality. In this sense, therefore, you must have a ‘model’ of the world (a notion on how the world works) before you can write detailed scenarios.

3 CI Layer Model The CI Layer Model shows parts of infrastructure systems or the totality of a nation’s critical infrastructures and their relationship to each other, and often serves as a global picture of interdependencies among the elements. The model includes the overall perspective and is mainly used as illustrations for how critical infrastructures are organized. The overall perspective of the model allows users to model global dependency and relationships within CI.

The CI Layer Model is a combination of the tree following critical infrastructure dimensions: (1) critical infrastructure sectors, (2) critical infrastructure administration areas, and (3) critical infrastructure management fields. There can be used different overviews based on a combination of the dimensions.

3.1 CI Sectors

The model divides the whole CI environment into eight critical infrastructure sectors (the first dimension). The CI sector represents a separate functional unit of the whole critical infrastructure focused on providing a defined kind of the critical services.

Critical Infrastructure Sector Basic description

Information and Communication Services

include telecommunication, information distribution and broadcasting services (mainly electronic), hardware and software components of data networks, etc.

Electric Power Services include electric power plants, electric distribution lines, transmission and substation networks, electronic power management systems, etc.

Gas and Oil Services include production, storage, and transportation of natural gas, oil, coal, heat, and other energy services, etc.

Banking and Finance Services include banks, insurance companies, lending and credit institutions, oversight and regulatory agencies and support systems that facilitates lending, borrowing, issuing, trading in or caring for money, purchase and sales of shares and bonds, credits and other representations of value, etc.

Transportation Services sector mainly includes all (air, rail, marine, and surface) transport components like aviation, highways, mass transit, railways, etc.

Water and Food Services include drinking water supply systems, water filtration, cleaning and treatment and transport systems, food distribution services, water management, etc.

Emergency and Health Services include emergency (medical, police, fire, and rescue systems), public health like prevention, laboratories, personal health services, nuclear safety, prevention of industrial hazards and pollutions, etc.

Government Services include national and civil defence, public administration, justice, public order, social security and welfare, etc.

Table 1: Critical Infrastructure Sector Overview.


There are other approaches to arrange critical infrastructure sectors. Some models use the five following sectors (1) Information and Communication Services, (2) Energy Services (including Electric Power Services and Gas and Oil Services), (3) Banking and Finance Services, (4) Transportation Services, (5) Vital Human Services (including Water and Food Services, Emergency and Health Services and Government Services).

Other model variations are based on the six sectors (1) Information and Communication Services, (2) Energy Services (including Electric Power Services and Gas and Oil Services), (3) General Services (including Banking and Financial Services and Water and Food Services), (4) Transportation Services, (5) Emergency and Health Services, (6) Government Services.

The first dimension helps to model and assess interdependency among CI sectors. The extent of a direct dependency between two CI sectors is assigned by a proper scale of magnitude values. The most common scales are based on 3 or 5 values. The 3-value scale uses the following levels: High – H, Middle – M, Low – L. The 5-value scale distinguishes these levels: Critical – C, High – H, Middle – M, Low – L, None – N.

ElectronicPower Services

Information andCommunication

ServicesBanking and

FinanceServices

Water andFood Services Transportation

Services

Gas and OilServices

Emergency andHealth Services

GovernmentServices

Figure 1: Graph of Sector Interdependencies.

The oriented graph (figure 1) and the matrix (figure 2) are helpful examples of results. Figure 1 presents the graph of key interdependencies among the CI sectors. The table in figure 2 is a sample of 3-value interdependency matrix.

IC Serv

ices

EP Service

s

GO Service

s

BF Service

s

Transp

Service

s

WF Serv

ices

EH Service

s

Gov Serv

ices

Information and Communication Services – H M M L L M MElectric Power Services H – H M M M M MGas and Oil Services H H – M H M M MBanking and Finance Services H H M – M L L MTransportation Services H H H M – L L MWater and Food Services M H M M H – M LEmergency and Health Services H H H M H M – MGovernment Services H H H M M L M –

Figure 2: Sector Interdependency Matrix.


There is a need to study the CI interdependencies more closely sometimes. In this case, it is possible to identify additional details and specify relevant items within each CI sector. The presented tools are useful for understanding various relationships inside any CI sector and its components.

3.2 CI Administration Areas

The second dimension of the layer model creates five administration areas. The area represents a part of the organization structure associated with CI management and control measures. The areas mostly correspond to a government and public administration arrangement, structure, etc.

Administration Area Basic description

Private Area involves private responsibilities associated with home and family issues.

Municipal Area involves responsibilities of local government, small organizations and/or companies with influence limited to a small territory.

Regional Area involves responsibilities of regional government, middle organization and/or companies with influence to a large territory within a state.

National Area involves responsibilities of state government, large organizations and/or companies with influence covered a whole state.

International Area involves international cooperation, cross-board relationships, global companies with worldwide influence and consequences.

Table 2: Administration Area Overview.

The second dimension brings a possibility to model and assess dependencies between the CI sectors and the CI administration areas. The dependencies represent any direct involvements and supervision controls of the CI administration area over the CI sectors. The value scales for the second dimension are the same like for the first one.

Private

Area

Munici

pal A

rea

Region

al Area

Nation

al Area

Intern

ation

al Area

Information and Communication Services M H H H MElectric Power Services L M H H LGas and Oil Services M M M H HBanking and Finance Services L M M H MTransportation Services M H H M LWater and Food Services M H M M LEmergency and Health Services M H H M MGovernment Services L M H H M

Figure 3: Sector – Administration Area Dependency Matrix.

An example of a two dimensional perspective is presented in the matrix on the figure 3. The matrix says that information and communication services are highly dependent on tree administration areas (municipal, regional,


national). These areas must provide proper information and manage related information and communication services distributing information to depended bodies.

3.3 CI Management Fields

The third dimension, if applicable, includes several management fields. The dimension describes information, management and steering characteristics connected with critical infrastructure environment, and shows various kinds of executive and operational context.

Management Field Basic description

Social Field signifies social, political and economical influences and impacts which affect people and their quality of life.

Organization Field qualifies government and business policies, strategies, structures, regulations and other management issues concerning to the critical infrastructure and represents interdependencies among critical infrastructures and their information and communication systems.

Information Field means an information and communication system (not necessary based on modern technology), which supports a given set of critical infrastructure services as a complex.

Application Field stands for an individual integral functional complex which provides a basic application background supporting a part of a critical infrastructure service.

Technological Field represents a technological components (hardware, software etc.) and their integration to a basic functional blocks.

Feature Field is a common foundation field, which describes the general character of the surrounding environment. Typical parameters express quality of road and rail networks, different facilities, nature and terrain characteristic, etc.

Table 3: Management Field Overview.

The management fields represent a level of studied CI components and range of their integration. The fields are important for studying a special part of the critical infrastructure, which is called Critical Information Infrastructure (CII). CII deals with information and communication technology (ICT) applied in and supported various critical infrastructures. In this case, the fields represent a different level of ICT complexity and its impacts on the critical information infrastructure.

Using of the fields is also discussed in the following model (see chapter 4).

4 CI Element Chain Model The CI Element Chain is the second model focused on a detail description of functional relationships within a critical service.

Critical Service (CIS) is that service whose interruption would have a serious adverse on a nation as a whole or on a large proportion of the population, and which would require immediate reinstatement.

In the CI Element Chain Model, the CI service is an explored service, which is a component of the critical services. The model describes CI primitive elements, connected with the critical service, and their bindings. The CI primitive elements are following (see figure 4):

• CIS Customer – uses some amount of CI Services from one or more CIS Providers through appropriate CIS Operators.

• CIS Provider – offers some CI resources/services for CIS Customers.


• CIS Operator – is a connection between one CIS Provider and one CIS Customer used for proper delivery of CIS.

• CIS Management Structure – is a steer element, which mediates administrative and control information among CIS Customer, CIS Provider, CIS Operator and other CI Members.

• CIS Support Structure – is a general environment necessary for providing and/or delivering CIS (i.e. transportation roads, gas or oil pipelines).

CIS Management Structure

CIS Provider CIS Customer

CIS Support Structure

Information Information Information

Regulation

Regulation

CIS Operator

Regulation

Figure 4: CI Element Structure.

The purpose of this model is to improve understanding of the operability of a critical service as an elementary piece of any critical infrastructure. The model helps to forecast and quantify effect linked with the critical service. A kernel is two relations: CIS Customer – CIS Operator and CIS Operator – CIS Provider. To provide CIS, these subjects need a defined amount for resources, which can be expressed as required CIS consumption, CIS quality (of service), CIS time of delivery, CIS location of delivery etc.

If the CIS Customer demonstrates its CIS demands, it is possible to calculate quantities of all resources required by the CIS Operator and CIS Provider. And the CIS Operator and the CIS Provider are just a CIS Customer, if they need to use any critical service to fulfil their services. According to this series, a chain of critical services is established and helps to quantify complex set of demands.

The Model includes the CIS Management Structure and CIS Supporting Structure. Both present complex dependencies related to the CI management fields (see table 3). The CIS Management Structure reflects high level fields (Social, Organization, and Information) and the CIS Support Structure relates to the lowest level called Feature Field.

In the CI Element Chain Model, the CI Service is described as a suitable relation among the CI primitive elements. By a chain of CI Services users can formulate complicated relations inside a studied segment of CI including it’s complex dependencies. For this reason, the CI Element Chain model is a helpful instrument for describing CI.

5 CI Simulations and Scenarios Modelling involves the use of formal relationships to describe a system. The user needs to have a solid understanding of the system: specifically the relationships between events, factors and variables within the model, and secondly the magnitude of those relationships.

The discussed CI Models describe a studied reality quite deterministic, so they bring limited knowledge of the behaviour of the critical infrastructures. The ultimate aim is to model the behaviour of the critical infrastructures as a complete and integral organism and understand CI reliance on information and communication technology.


This can be achieved through the application of such analytical tools and techniques as simulations and scenarios.

The simulations can be defined as the mimicking of a system with its dynamic and temporal processes in an “experimentable” model, with the overall aim of gaining insight that can be applied to real-life situations.

The scenarios are focused analyses of different futures presented in a coherent script-like fashion. They are not predictions but possibilities with the aim to trigger “what-if” thinking in a strategic process and thus handling uncertainty. They include coherent pictures of plausible future dealing with uncertainty about what the future could bring. A scenario can be desirable, an undesirable, or just a possible future or even a range of plausible futures.

Figure 5: Knowledge and Certainty Progress.

Generally speaking, the models can be used in designing scenarios so that the relations between different factors can be understood. The models are a simplified representation of reality constructed to explore particular aspects or properties. The scenarios are complex methodologies which integrate with and rely heavily on all aspects of future analysis and can be used for the full range of challenges. So the scenarios must be aimed at bridging the gap between the required implicit knowledge and the explicit knowledge of the empirical values included in the models.

6 Conclusion The CI modelling is a critical piece of CIP. The presented models serve for a better understanding of CI and it’s included dependencies. The CI Layer model describes the general overview and the CI Element Chain model concentrates on the required details. The basic advantage is in combinations of both models. The combination can be used as a skilful fundament of more sophisticated methods built on the simulations and scenarios.


References [1] The International Critical Infrastructure Protection Handbook: Exploratory Study, Swiss Federal Institute

of Technology, Zurich, 2001.

[2] The National Strategy to Secure Cyberspace, The President’s Critical Infrastructure Protection Board, Washington, 2002.

[3] Wenger, A., Metzger, J. and Dunn, M.: International Critical Information Infrastructure Protection Handbook, Swiss Federal Institute of Technology, Zurich, 2002.

[4] Architecture of an Integrated Model Hierarchy, ACIP, European Union, 2003.

[5] Using Scenarios to Support Critical Infrastructure Analysis and Assessment, ACIP, European Union, 2003.

[6] Šiška, V.: Critical Infrastructure Protection of Unclassified Information Systems, in Proc. Of Emergency 2002, article 29, 2002. in Czech

[7] Šmíd, J.: Critical Infrastructure Security in Information Society, in Proc. Of Emergency 2002, article 30, 2002. in Czech

[8] Towards a Centre for Critical Infrastructure Protection, CCIP, New Zealand 2001.


Balanced LKH for Secure Multicast with Optimal Key Storage

Josep Pegueroles

[email protected]

Francisco Rico-Novella

[email protected]

Departamento de Ingenieria Telematica. Universitat Politecnica de Catalunya. Jordi Girona 1 y 3. Campus Nord, Mod C3, UPC. 08034 Barcelona

Keywords: Key management, secure multicast conferencing.

1 Extended Abstract Perfect Secrecy can only be achieved in multicast groups by ciphering data sent to the group with a different key every time a member joins or leaves the group. A Key Server must send the new key to all the remaining members so bandwidth efficiency concerns appear. Logical Key Tree algorithms reduce the number of messages to be sent, but in many scenarios, rekeying after each membership change has no sense. Batch rekeying algorithms are proposed as a solution to these problems. However such methods need to maintain the Logical Key Tree balanced all the time in order to achieve maximum bandwidth efficiency. This paper presents a new technique for multicast batch rekeying. This technique reallocates the tree nodes in order to keep the tree balanced all the time.

Key management (KM) is an important issue in secure multicast communications today. It deals with the functionality of distributing and updating cryptographic keying material throughout the life of the multicast group [1]. Among the problems to be solved by KM is the secure distribution of keys between key servers and clients, with special focus on problems derived from the dynamism of the multicast group.

When adding security features to multicast communications a common secret shared by all the multicast group members is needed. The shared key provides group secrecy and source authentication. This key must be updated every time the membership of the group changes. When it does, Forward and Backward Secrecy (FS and BS) are provided. FS means that the session key gives no meaningful information about future session keys, that is to say no leaving member can obtain information about future group communication. BS means that a session key provides no meaningful information about past session keys and that no joining member can obtain information about past group communication [2].

Several works have been presented that address the issues of initially distributing the group key to all users and rekey when group membership changes. Most methods delegate this security management functionality to a centralized trusted entity called Key Server (KS) or Key Distribution Center (KDC).

A group of N users requires N messages each encrypted with a member private key in order to distribute initial group key. Same number of encrypted messages is needed for trivially distributing new group key when membership changes.

First studies in multicast key management try to reduce the number of required messages for rekeying. The most promising protocols are those based on multilevel logical binary trees of Key Encryption Key (KEK) [3] [4] [5]. When used in conjunction with a reliable multicast infrastructure, this approach results in a quite efficient key update mechanism in which the number of multicast messages transmitted upon a membership update is proportional to the depth of the tree. If KEK tree is balanced, depth of the tree is logarithmic in the size of the secure multicast group, O(logN).

However, for large groups, join and leave requests are very frequent and usually bursty in nature. For example, in Internet TV, at peak times, before and after important broadcasts, a high volume of sign-on/sign-off requests is expected. In such scenarios, individual rekeying after each join or leave is relatively inefficient.

To overcome this problem, Lam-Gouda proposed a new marking algorithm for batch rekeying [6]. In batch rekeying the key is not updated immediately but after a certain period on time. A departed user will remain in the group longer, and a new user has to wait longer to be accepted. All join and leaves requests received within a batch period are processed together at the same time.


Nevertheless, obtained results assume the KEK tree kept balanced across multiple batches. However, depending on the actual locations of the request, even if the KEK tree starts complete and balanced, it is possible that it may grow unbalanced after some number of batches.

This work presents a new method for batch rekeying that leads to complete balanced trees. The proposed algorithm preserves the Lam-Gouda algorithm simplicity and improves efficiency since no additional rebalancing algorithm is needed. Furthermore, keeping the tree balanced at any time avoids extra rekeying messages due to tree depth beyond O(logN).

The rest of this paper is organized as follows. Section 1 presents Logical Key Hierarchy methods as the most common way to increase bandwidth efficiency in secure multicast rekeying. As an example, two state-of-the-art techniques are discussed. Section 2 introduces the Batch Rekeying techniques as a method for achieving more bandwidth efficiency. Section 3 details the new Balanced Batch Rekeying algorithm. Finally in section 4, we combine Batch Rekeying techniques with Optimal Key Storage Method in order to increase bandwidth efficiency. In section 5 conclusions and future work are presented.

2 Rekeying problem in secure multicast environments The main problem when distributing a group key to a group of multicast users is the fact that a central key management entity must authenticate each receiver and securely distribute the session key to each of them.

This entity is usually called Key Server (KS) or Key Distribution Centre (KDC). The KS is a network trusted third party entity whose responsibility is to generate and distribute symmetric keys to multicast group members wishing to stablish a secure communication.

It also has to be able to identify and reliably authenticate requestors of symmetric keys. This involves encrypting the message containing the session key as many times as members the multicast group has (N). Once with each secret key shared between the KDC and the corresponding member (or alternatively, with the public key of the receiver). After that, the entire group can communicate secretly each other using the multicast session key.

In many scenarios such as Web-TV or multi-party network games, N may be very large, therefore, multicast key distribution leaks scalability.

Besides that, scalability problems become very important if it is considered that a new session key must be delivered to all the group members every time a user joins or leaves the group.

This is the only way of achieving Perfect Forward Secrecy and Perfect Backward Secrecy. That is to say, a member cannot access the group information after he has left the group (PFS) or before he joined it (PBS).

In the last years, many proposals have been published in order to overcome the scalability problem in Group Key Management [7] [8] [9]. However, the most promising protocols are those based on logical binary trees of KEKs [3] [4]. Next we briefly describe two of these techniques.

2.1 Logical Key Hierarchy: LKH

In key tree schemes two types of encryption keys are used: Session Encryption Keys (SEK) and Key Encryption Keys (KEK).

The first ones are used to cipher the actual data that members in the multicast group exchange, for instance multimedia content in a multicast videoconference session. KEKs are used to cipher the keying material that the members will need in order to get the SEK.

Normally, KEKs are structured in logical binary trees. All users share the root of the key tree and the leaf nodes are users' individual keys. We will name tree nodes following the next criterion (level number,position at level), so we will refer to root node as (1,1); sons of root node will be (2,1) and (2,2) and so on. An example of key tree is shown in Fig.1.


Figure 1: Binary Key Tree example with 7 members.

Consider a group of 7 users. The tree has 14 nodes, each node corresponds to a KEK. Group users are located at leaf nodes. Keys in the leaves are only known by single users. Key at node (1,1) is known by all members in the group. The rest of the keys are revealed only to users considered sons of the node.

For example, KEK in node (3,1) is known only by users in leaves (4,1) and (4,2), and KEK in node (2,2) is only revealed to users in nodes (4,5) to (4,7).

The LKH key management scheme works as follows. Consider the multicast group in Fig.1 with N=7 members M1..M7 and a centralized group controller (KS). Each member must store a subset of the controller's keys. These subset of KEKs will allow the member to get the new group key when it changes. A generic member (Mj) stores the subset of keys in the path from the leaf, where Mj is, to the root. In our example, member in node (4,1) will store the keys related to nodes (4,1),(3,1),(2,1) and (1,1).

When a new member (M8) joins the group he must contact the KS via a secure unicast channel. Then they negotiate a shared key that they will use in later interactions (key at leaf (4,8)). After that the controller updates the binary tree structure in which the new user has the leaf containing his key. See Fig 2a in which new keys are noted with quotes.

Now, the KS must reveal the updated keys to the corresponding users. He uses the existing key hierarchy, along with reliable multicast, to efficiently distribute them as follows. He sends two messages containing the whole set of updated keys, one to each of the members in nodes (4,7) and (4,8), via a unicast channel and using their individual keys.

After that, he constructs and sends a multicast message containing keys in nodes (2,2)' and (1,1)' ciphered with key in node (3,3), so only members in nodes (4,5) and (4,6) can decipher it.

Finally, he also constructs and sends a multicast message containing new root key (1,1)' and ciphered with key in node (2,1), so members in nodes (4,1) to (4,4) can decipher it. At this point, the 8 members in the multicast group know the subset of keys from their leaves to the root. Every member knows the root key, so this is used to cipher a multicast message containing the session key (SEK).

Now, assume that member M4 leaves the group. All keys along the path from node (4,4) to the root must be changed. Key in node (4,4) is simply deleted. As described in the former joining case, the updated KEKs are multicasted to the remaining group members encrypted under keys in sibling nodes of the updated ones.

In our example, KS first sends the whole set of updated keys to node (4,3) via a unicast channel, and using the individual key of member M3 to cipher it. After that, constructs and sends a multicast message containing (2,1)' and (1,1)'' ciphered with key at node (3,1), so only M1 and M2 can decipher it. Finally, he sends a multicast message containing (1,1)'' ciphered with key at node (2,2)', so members in nodes (4,5) to (4,8) can decipher it. At this point, all keys that M4 knew while he was a member of the group have been updated, so he has been excluded from any future communication.

Following the example it is easy to see how the binary tree-based key management scheme can update keys using 0(log2(N)) messages, where N is the number of members in the multicast group.


a)LKH joining member

b)LKH leaving member

Figure 2.

2.2 One way function trees: OFT

Following the same logical tree scheme, Balenson et al. [4] proposed a variation of this method for group key management. Their scheme uses a binary one-way function tree (OFT) to store the group's key hierarchy. The structure of the tree is very similar to LKH. The main differences between LKH and OFT is that keys in the tree are not independent.

Each interior node key in OFT follows the rule defined in (1)

kx = f( g(kleft(x)), g(kright(x)) ) (1) where left(x) and right(x) denotes the left and right child of the node x, respectively. The function g is one-way, and we call g(k(x)) the blinded function of key k(x). The function {\it f} is a mixing function, for example XOR.

Each member knows the unblinded node keys on the path from its node to the root, and the blinded node keys that are siblings to its path to the root. In our example, M6 has to store the blinded keys of nodes (4,5), (3,4) and (2,1). See Fig.3

Figure 3: Binary Key Tree with 8 members, constructed according to OFT rules.

Now, imagine M6 leaves the group, new blinded key values of nodes (4,5)', (3,4)' and (2,1)' must be sent from the KS to all the appropriate subsets of members.

It is important to remark that the efficiency of these tree-based key management schemes depends critically on whether the key management tree remains balanced, that is to say if distances from the root node to any two leaf nodes differ at most by 1.


In general, for a balanced binary tree with N leaves, the distance from the root to any leaf is log2 N. But if the tree becomes unbalanced, the distance from the root to a leaf can become as high as N. So keeping the key management tree balanced is important to achieve maximum efficiency of the technique.

3 Batch Rekeying With binary key tree techniques, individual rekeying has reached his lower bound in number of required messages for rekeying (O(logN)) [10]. Recently, some works have proposed batch rekeying to overcome this limit.

In batch rekeying algorithms join and leave requests are collected during a time interval and processed in a batch. Since the KS does not rekey immediately, a leaving member will remain in the group till the end of the batch period, and a new member will have to wait the same time to be accepted. However, this batch period can be adapted to dynamics in the multicast group.

On the other hand, batch rekeying techniques increase efficiency in number of required messages thus it takes advantage of the possible overlap of new keys for multiple rekey requests, and thus reduces the possibility of generating new keys that will not be used.

3.1 Lam-Gouda batch rekeying

In [6] Lam, Gouda et al. presented a very simple marking algorithm that updates the key tree and generates a rekey subtree. Briefly, their system can be summarized as follows. After each rekey interval the KS collects all Join and Leave requests and processes them according to the two possible cases.

If the number of leavings is greater or equal than the number of joinings, new members are allocated in the places of the departed members. Empty leaves are marked as null. All node keys in the path from the replaced leaves to the root are updated following the rules in LKH.

If the number of joinings is greater than the number of leavings a rekey subtree is constructed with all the remaining new members left after applying the algorithm described above. The rekey subtree is allocated under the departed user node with the smallest height.

3.2 Balanced Batch Rekeying

The algorithm explained in the previous section aims to keep the tree balanced through different batches by allocating the rekey subtree under the shallowest node in each rekeying. However, this rebalancing system is only valid when the number of joinings and leavings are very similar, in any other case a periodic rebalancing algorithm is needed.

In Fig 4, it is very easy to see how the tree grows unbalanced through different batches. In this simple example, in the first batch, same number of joinings and leavings is requested, so the tree is kept balanced. In Fig 4b M4 and M8 (in nodes (4,4) and (4,8) respectively) ask for departing the group, but no joining is requested; so nodes (3,2) and (3,4) become leaf nodes with private keys of members M3 and M7. In the third step, Fig 4c, three joinings and no leaving are asked again, this time, the rekey subtree is allocated under node (3,1), the shallowest one. Finally, in Fig 4d two of the members under node (1,1) want to leave the group. After the 4 batches only 6 members are left and therefore only a 4-degree key tree is needed, instead of that, the KS must keep a tree of degree 5.


a) Batch with same number of leavings and joinings b) Members 4 and 8 leave the group. No joining requested

c) Batch with 3 requested joinings and no leaving members

d) Batch with two leavings under node (1,1) and no joinings

Figure 4.

3.3 Proposed algorithm

In order to overcome this inefficiency we propose a new batch-rekeying algorithm that keeps the tree balanced for every batch. The algorithm updates not only node keys but also node naming or position, so after each batch rekeying nodes can change their original position following a very simple rule.

The KS computered system does not have much more processing load cause he only has to update the position of the nodes with simple rules. Besides that, keeping the tree balanced reduces the total amount of required program memory.

In the other side, the new algorithm slightly increases the number of operations to be done by individual members, cause they have to know all the time, the position in the tree that they are occupying in order to update it properly. However, this increase is not significant for single multicast members, even if they are devices with low computation capability.

Next, we will describe the atomic steps the KS and the individual members must follow to carry out the algorithm.

3.4 Key Server Side

There are four main actions that the KS has to do every batch: marking the rekeying nodes, prune the tree, make new rekey tree and construct and send the multicast rekeying messages.


Mark Rekeying Nodes

In the first step, nodes that should be removed have to be pointed out. After collecting the leaving requests, all nodes from leaving members leaves to root need to be updated, so they are marked for deletion. Notice that no replacement with joining members is carried out. This is why the important figure in this algorithm is the nodes that can be reused, and in Lam-Gouda algorithm replaced nodes also have to be updated.

Prune Tree

The prune action is very simple, it consists in deleting the marked nodes and keep the subtree structures that remain unchanged. After this action, the KS has to manage three types of elements: remaining subtrees (structures with more than one member), joining members and siblings of leaving members. As the tree is a binary tree, siblings of leaving members cannot reuse any KEK but his individual key, so they should be treated the same as new joining members.

Make New Rekey tree

Now, the KS has to construct the new rekey tree balanced following the next recursive criterion. Group all trees of depth j in twos. If any element is left, group it with tree of depth j+1 and treat the result as a tree of deep j+2. The criterion must begin with trees of minimum depth, that is to say, single elements, and be repeated until just only one tree is resulted.

Construct and Send Rekey Messages

Finally, the rekeying messages have to be sent. These messages should include three information fields: destination node, new position of destination node and rekeying material.

The destination node is the node to which sons the message is addressed. This field is used by single members to decide whether the rekeying message concerns to them or not.

The new position is the renaming field of the message. Using this information, users can rename themselves and their keying material. The rules used for renaming are explained in the next subsection. The Rekeying material field is the actual data of updated keys, calculated according to LKH, for example.

3.5 Multicast Member Side

Basically the multicast member only has to decide if a multicast rekeying message is sent to him, receive it and update his position and keying material.

Receive Rekey Message

A single member (located in node (m,n) will only listen to a message if the coordinates of the destination node field (say (i,j)) comply with the following conditions.

m ≥ i

(j·2 m-i)-(2m-i -1) ≤ n ≤ j · 2m-i

Update Position and Keys

After deciding if a message concerns him, node (m,n) and keys are renamed using the new position field (p,q) in rekeying message. The renaming follows the next expressions.

m=p+(m-i)

n=q · 2 m-i - [j · 2 m-i -n]

Re-used keys and new keys are also renamed according to relative position with new node name.


4 Combining Optimal Key Storage Recent works of Wang Bin and Li Jian-Hua have shown how the usage of pseudo-random functions can improve Key Storage in Key Manager. This system refreshes all the key tree every time a rekeying is done. However, the number of messages for rekeying are the same as used in LKH.

In this section we will explain how can this technique used in combination with the batch rekeying algorithm in order to increase bandwidth efficiency even more.

5 Conclusions In this research, we have presented a new rekeying technique for batch joining and leavings. The new method is based on Logical Key Hierarchy protocol but avoids rekeying for every single membership change. Unlike other existing batch rekeying methods, the proposed technique keep the Key Tree balanced all the time. Balancing the tree reduces the number of encrypted messages to be sent in order to distribute the new session key.

Acknowledgments This work is supported by the Spanish research council under project DISQET (CICYT TIC2002-818)

References [1] Wallner, Harder, Agee (1998): Key Management for Multicast: Issues and Architectures. RFC2627.

[2] R. Canetti, J. Garay, G. Itkis, D. Micciancio, M. Naor, and B. Pinkas: Multicast security: A taxonomy and some efficient constructions INFOCOM 99. Eighteenth Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings. IEEE, vol. 2, pp. 708-716, 1999.

[3] Harney, Harder: Logical Key Hierarchy Protocol (LKH). Mar 99. I-D Harney-sparta-lkhp-sec-00. Work in progress.

[4] Balenson, McGrew, Sherman: Key Management for large Dynamic Groups: One-Way Function Trees and Amortized Initialization. Aug 2000 I-D irtf-smug-groupkeymgmt-oft-00. Work in progress.

[5] Canetti, Malkin, Nissim: Efficient Communication Storage Tradeoffs for Multicast Encryption. Eurocrypt99 pp 456-470 1999.

[6] Li, Yang, Gouda, Lam: Batch Rekeying for Secure Group Communications. ACM SIGCOMM 2001, San Diego, August 2001.

[7] H. Harney, A. Colegrove, E. Harder, U. Meth, R. Fleischer: Group Secure Association Key Management Protocol (GSAKMP), draft-irtf-smug-gsakmp-00.txt, November 2000, Work in Progress.

[8] H. Harney, C. Muckenhirn: Group Key Management Protocol (GKMP) Specification}, IETF, RFC 2093, July 1997.

[9] T. Hardjono, B. Cain: Simple Key Management Protocol for PIM}, draft-ietf-pim-simplekmp-01.txt, Feb 2000, Work in Progress.

[10] Snoeyink, Suri, Varghese (2001): A Lower Bound for Multicast Key Distribution}. IEEE INFOCOM 2001.


Time Stamping Authority

Ing. Jaroslav Pinkava, CSc.,

[email protected]

PVT a.s., Veveří 102, 602 00 Brno

Abstract Basic aim of the paper – to give the overview of the problematic and review practical problems connected with TSA implementation. The standards documents are closely cited.

Keywords: time stamp, relying party, subscriber, verifier, time-stamp token, time stamp authority, TSA system, digital signing with cryptographic methods, time-stamping unit, time-stamp policy, reliable sources of time, coordinated universal time (UTC).

1 Introduction Most of the time-stamping systems use a trusted third party called Time-Stamping Authority (TSA). The time-stamp is a digital attestation of the TSA that an identified electronic document, subscribed with a electronic signature, has been presented to TSA at a certain time. Time-stamping is a set of techniques enabling one to ascertain whether an electronic document was created or signed at a certain time. The real importance of time-stamping becomes clear when there is a need for a legal use of electronic documents with a long lifetime. Without time-stamping we neither can trust signed documents when the cryptographic primitives used for signing have become unreliable nor solve the cases when the signer himself repudiates the signing, claiming that he has accidentally lost his signature key. During the last years, especially in the context of legal regulation of using electronic signatures, the organizational and legal aspects of time-stamping itself have become the subject of world-wide attention. In addition to defining the responsibilities of the owner of the signature, duties and responsibilities of the third party (Time- Stamping Authority, TSA) must be stated as well. Hence, there is an increasing interest in time-stamping systems where the need to trust the TSA is minimized. In order to make users liable only for their own mistakes, there has to be a possibility to ascertain the offender. Unlike physical objects, digital documents do not comprise the seal of time.

Thus, the association of an electronic document uniquely with a certain moment of time is very complicated, if not impossible. The best we can achieve with time-stamping is the relative temporal authentication (RTA) based on the complexity-theoretic assumption on the existence of collision-resistant hash functions. RTA enables the verifier given two time-stamped documents to verify which of the two was created earlier. Some ten years ago time-stamping was considered to be an uninteresting area since the only known time-stamping method employed completely trusted third party — the Time-Stamping Authority. Whatever the TSA said the clients had to believe. More people became interested in this field after the seminal publication [9] of Haber and Stornetta, where it was shown that the trust to the TSA can be creatly reduced by using so called linking schemes.

2 Basic terms Time stamp should prove:

• freshness (T was created after t1);

• existence (T was created before t2);

• order (T was created before S).

To prove the electronic signature was generated while the signer's certificate was valid, the electronic signature must be verified and the following conditions satisfied:

• the time-stamp has been applied before the end of the validity period of the signer´s certificate,


• the time-stamp has been applied either while the signer´s certificate was not revoked or before the revocation date of the certificate.

Thus a time-stamp applied in this manner proves that the electronic signature was created while the signer´s certificate was valid. This concept can be extended to prove the validity of a electronic signature over the whole of any certificate chain.

relying party: recipient of a time-stamp token who relies on that time-stamp token.

subscriber: entity requiring the services provided by a TSA and which has explicitly or implicitly agreed to its terms and conditions (organization, end-user).

time-stamp token: data object that binds a representation of a datum to a particular time, thus establishing evidence that the datum existed before that time.

time-stamping authority: authority which issues time-stamp tokens.

TSA Disclosure statement: set of statements about the policies and practices of a TSA that particularly require emphasis or disclosure to subscribers and relying parties, for example to meet regulatory requirements.

TSA practice statement: statement of the practices that a TSA employs in issuing time-stamp tokens.

TSA system: composition of IT products and components organized to support the provision of time-stamping services.

time-stamp policy: named set of rules that indicates the applicability of a time-stamp token to a particular community and/or class of application with common security requirements.

time-stamping unit: set of hardware and software which is managed as a unit and has a single time-stamp token signing key active at a time.

Coordinated Universal Time (UTC): Time scale based on the second as defined in ITU-R Recommendation TF.460-5. A list of UTC(k) laboratories is given in section 1 of Circular T disseminated by BIPM and available from the BIPM website (http://www.bipm.org/).

The examples for use of time stamps:

Electronic signatures: People acknowledge transactions and make contracts by signing documents — in both the paper and digital worlds. Signatures require a time stamp in order to establish when transactions or contracts occurred. A secure time stamp ensures that the time stamp is accurate, has not been altered, and is bound to one specific signature. It also ensures that the electronic signature was applied while the certificate that authorizes the signature was in effect — even if the certificate has long since expired.

Computer logging: Proving when events take place and in what sequence is vital for evaluating performance and security issues in systems and networks. That is equally true when collecting legal evidence against hackers and when upgrading system performance overall. Secure time stamps allow events to be audited long after they took place with assurance that times have not been altered (by a hacker, for example).

Online subscriptions: The granting and revocation of subscriptions to online services are governed by time. Secure time means that subscriptions are in effect during the period when they are supposed to be and only during that period.

Digital notarization services: As in the paper world, digital notarization services provide evidence from an unbiased third-party that records were created as claimed. Digital notarization services go a step further — they provide direct evidence those electronic files, inclusive of their respective pages and other digital components, were not altered after they were notarized. It also proves that the notarized file is the only file to which the notarization applies.

Security policy/logins: A secure time stamp provides an additional level of protection for ensuring that policies with respect to firewalls, logins, and other security procedures are observed and can be audited at any time.

Sales orders/receipts: Secure time stamps can prove that any important electronic events — from stock purchases, to funds transfers, to document filings, to invoice payments — are done (or not done) at the time claimed. Compliance: More and more industries – financial securities, manufacturing – have legal requirements that documents and transactions must have certified and auditable time stamps.

http://www.bipm.org/


Content sealing: Any document with a secure time stamp cannot be altered without there being evidence of alteration. A secure certificate’s time stamp proves that the document has not been altered after it has been stamped at a specific time.

3 Some theoretical aspects In practice time stamps from the same round are not automatically ordered. It is useful (in some obstacles) to have an relative ordering for these time stamps.

A cryptographic way to achieve a relative order for the documents is to create dependencies between the time certificates attached to the documents, where later certificates are obtained by applying a collision-resistant hash function to earlier ones (then we say that later certificates are dependent on the earlier ones). In general, the dependence is not direct: for two time stamps T1 and Tn there may exist a long list of time stamps (T1,T2,..., Tn), such that every time stamp in this list is dependent on the previous one. The smallest number n for which such list exists, is called the distance between L1 and Ln.

Concrete procedure that specifies which time stamps are directly dependent on which time stamps is called a linking scheme. For any i, ni<ni+1, then Tn=H(Tn1,Tn2,..., Tnm). It is always assumed that linking scheme is acyclic, i.e., that if n1 is dependent on n2 then n2 does not depend on n1. The second assumption is that the scheme is rooted, i.e., that the last element is one-way dependent on all the previous elements.

To be fully useable, linking schemes should additionally satisfy the next two conditions [7]:

It should be simply connected, that is, for any two given time certificates, one of them should dependent on the other. Otherwise the TSA could later reorder the time stamps without being detected.

It should be dense, that is, the maximum distance between any two certificates should be small, compared to the number of certificates issued.

For linear linking scheme is time stamp Ti for document (hash of document) Di computed as Ti = H(Di,Ti-1).

In [4], [11] are described so called binary linking schemes. The idea is to link the time stamps not only to the element directly preceding it but also to some other element (further in the past). The other link can be used to traverse the chain (by verifiers) more efficiently by taking longer jump. In [4] was proven (as expected) that there exist linking schemes that provide logarithmic length paths in the chain, enable the use of rounds and guarantee possibility of verification the temporal order between any two stamps issued in one round and the verifier does not need any additional information to perform the comparison.

4 Legislative and standards (EU) Final report of the EESSI Expert Team ([19], July 1999) identified strategic objectives in Electronic Signature Standardization. In the document are given general requirements for electronic signatures, described different types of electronic signatures (general, enhanced, qualified).

In December 1999 The European Commission issued a Directive on a Community framework for Electronic Signatures ([20]). This Directive identified minimal requirements for trusted service providers supporting electronic signatures as well as requirements for signers and verifiers. Following the Directive are prepared detailed standards.

Only in the first of these two documents are mentioned Time Stamping Authorities (TSA) as important component of electronic signature infrastructure (on the other hand – TSA is an example of a certification-service-provider defined in Directive). For this reason there are some differences in the legislative in various Member States in this area. The Czech Law on electronic signatures has no mention on time stamping problematic at this time.

4.1 Time-Stamp Protocol (RFC 3161)

This protocol (lit. [14]) defined TSA as Trusted Third party that creates time-stamp tokens in order to indicate that a datum existed at a particular point in time. TSA is required:

• to use a trustworthy source of time;

• to include a trustworthy time value for each time-stamp token;


• to include a unique integer for each newly generated time-stamp token;

• to produce a time-stamp token upon receiving a valid request from the requester, when it is possible;

• to include within each time-stamp token an identifier to uniquely indicate the security policy under which the token was created;

• to only time-stamp a hash representation of the datum, i.e., a data imprint associated with a one-way collision resistant hash-function uniquely identified by an OID;

• to examine the OID of the one-way collision resistant hash-function and to verify that the hash value length is consistent with the hash algorithm;

• not to examine the imprint being time-stamped in any way (other than to check its length, as specified in the previous bullet);

• not to include any identification of the requesting entity in the time-stamp tokens;

• to sign each time-stamp token using a key generated exclusively for this purpose and have this property of the key indicated on the corresponding certificate;

• to include additional information in the time-stamp token, if asked by the requester using the extensions field, only for the extensions that are supported by the TSA. If this is not possible, the TSA SHALL respond with an error message.

In protocol messages at first the requesting entity requests a time-stamp token by sending a request to the TSA and then TSA responds by sending a response to the requesting entity. This respond is then verified with requesting entity. The TSA must sign each time-stamp message with a key reserved specifically for that purposes.

The protocol specified formats for requests and responses. There is no mandatory mechanism for TSA messages. Possible is use of following mechanisms: E-mail, file based protocol, socket based protocol and protocol via http.

The ETSI document TS 101 861 is following definition of Time Stamp Protocol from above IETF document. His requirements are here more specified (parameters, algorithms, key lengths to be supported). One on-line protocol and one store and forward protocol must be supported for every Time Stamping Authority. Among the four protocols in RFC.3161 should be supported the Time Stamp Protocol via http.

4.2 Electronic Signature Formats for long term electronic signatures

In RFC.3126 [15] and in technically equivalent ETSI Standard TS 101 733 [16] are defined formats of an electronic signatures that can remain valid over long periods.

This includes evidence as to its validity even if the signer or verifying party later attempts to deny (repudiates) the validity of the signature. This document specifies the use of trusted service providers (e.g., Time-Stamping Authorities (TSA)), and the data that needs to be archived (e.g., cross certificates and revocation lists) to meet the requirements of long term electronic signatures. An electronic signature defined by this document can be used for arbitration in case of a dispute between the signer and verifier, which may occur at some later time, even years later. This document uses a signature policy, referenced by the signer, as the basis for establishing the validity of an electronic signature.

An electronic signature may exist in many forms including:

• the Electronic Signature (ES), which includes the digital signature and other basic information provided by the signer;

• the ES with Time-Stamp (ES-T), which adds a time-stamp to the Electronic Signature, to take initial steps towards providing long term validity

• the ES with Complete validation data (ES-C), which adds to the ES-T references to the complete set of data supporting the validity of the electronic signature (i.e., revocation status information).


+------------------------------------------------------------ES-C-----+ |+--------------------------------------------ES-T-----+ | ||+------Elect.Signature (ES)----------+ +------------+| +-----------+| |||+---------+ +----------+ +---------+| |Time-Stamp || |Complete || ||||Signature| | Other | | Digital || |over digital|| |certificate|| ||||Policy ID| | Signed | |Signature|| |signature || |and || |||| | |Attributes| | || +------------+| |revocation || |||+---------+ +----------+ +---------+| | |references || ||+------------------------------------+ | +-----------+| |+-----------------------------------------------------+ | +---------------------------------------------------------------------+

Figure 1. (lit. [15]].

There exist also an ES format with extended validation data (ES-X) with additional requirements (Type 1 and Type 2). The needs for this formats are derived from situations when the verifier does not has access to full certificate and revocation references or when there is a risk that any CA keys used in the certificate chain may be compromised.

Before the algorithms, keys and other cryptographic data used at the time the ES-C was built become weak and the cryptographic functions become vulnerable, or the certificates supporting previous time-stamps expires, the signed data, the ES-C and any additional information (ES-X) should be time-stamped. If possible this should use stronger algorithms (or longer key lengths) than in the original time-stamp. This additional data and time-stamp is called Archive Validation Data (ES-A). The Time-Stamping process may be repeated every time the protection used to time-stamp a previous ES-A become weak. An ES-A may thus bear multiple embedded time stamps. The format ES-A is considered for archival depositary of electronic signatures (with long term security of time stamps).

The overall structure of Electronic Signature is as defined in [CMS, RFC2630]. The Electronic Signature (ES) uses attributes defined in [CMS], [ESS, RFC.2634] and in given document. Next are in this standard specified the validation data structures.

The security of the electronic signature mechanism defined in this document depends on the privacy of the signer's private key. Implementations must take steps to ensure that private keys cannot be compromised. Document only defines conformance requirements up to a ES with Complete validation data (ES-C).

4.3 Policy requirements for time stamping authorities

For the practical construction of working TSA is necessary to solve range of the further problems following legislative conditions, operational and functional needs.

Document [21] (and his equivalent [18]) defines requirements for a baseline time-stamp policy for TSAs issuing time-stamp tokens, supported by public key certificates, with an accuracy of one second or better. A TSA may define its own policy which enhances the policy defined in the current document. Such a policy shall incorporate or further constrain the requirements identified in the given document.

Given policy requirements are primarily aimed at time-stamping services used in support of qualified electronic signatures (i.e. in line with article 5.1 of the European Directive on a community framework for electronic signatures) but may be applied to any application requiring to prove that a datum existed before a particular time. Document addresses requirements for TSAs issuing time-stamp tokens which are synchronized with Coordinated universal time (UTC) and digitally signed by TSUs.

The TSA may make use of other parties to provide parts of the Time-Stamping Services. However, the TSA always maintains overall responsibility and ensures that the policy requirements identified in the present document are met. For example, a TSA may sub-contract all the component services, including the services which generate time-stamp tokens using the TSU's keys. However, the private key or keys used to generate the time-stamp tokens are identified as belonging to the TSA which maintains overall responsibility for meeting the requirements defined in the current document.

A TSA may operate several identifiable time-stamping units. Each unit has a different key.


Time-stamp policy and TSA practice statement The time-stamp policy states "what is to be adhered to," while a TSA practice statement states "how it is adhered to", i.e., the processes it will use in creating time-stamps and maintaining the accuracy of its clock. The relationship between the time-stamp policy and TSA practice statement is similar in nature to the relationship of other business policies which state the requirements of the business, while operational units define the practices and procedures of how these policies are to be carried out. A time-stamp policy is a less specific document than a TSA practice statement. A TSA practice statement is a more detailed description of the terms and conditions as well as business and operational practices of a TSA in issuing and otherwise managing time-stamping services. The TSA practice statement of a TSA enforces the rules established by a time-stamp policy. A TSA practice statement defines how a specific TSA meets the technical, organizational and procedural requirements identified in a time-stamp policy. A time-stamp policy is defined independently of the specific details of the specific operating environment of a TSA, whereas a TSA practice statement is tailored to the organizational structure, operating procedures, facilities, and computing environment of a TSA. A time-stamp policy may be defined by the user of times-stamp services, whereas the TSA practice statement is always defined by the provider.

Document defines requirements for a baseline time-stamp policy for TSAs issuing time-stamp tokens, supported by public key certificates, with an accuracy of 1 second or better. If an accuracy of better than 1 second is provided by a TSA then, if all the TSUs have that same characteristics, the accuracy shall be indicated in the TSA's disclosure statement (see section 7.1.2) otherwise in each time-stamp token issued with an accuracy of better than 1 second.

Conformance: The TSA shall use the identifier for the time-stamp policy in time-stamp tokens as given in section 5.2, or define its own time-stamp policy that incorporates or further constrains the requirements identified in the present document:

a) if the TSA claims conformance to the identified time-stamp policy and makes available to subscribers and relying parties on request the evidence to support the claim of conformance; or

b) if the TSA has been assessed to be conformant to the identified time-stamp policy by an independent party.

A conformant TSA must demonstrate that:

a) it meets its obligations as defined in section 6.1;

b) it has implemented controls which meet the requirements specified in section 7.

Relying part shall

a) verify that the time-stamp token has been correctly signed and that the private key used to sign the time-stamp has not been compromised until the time of the verification;

b) take into account any limitations on the usage of the time-stamp indicated by the time-stamp policy;

c) take into account any other precautions prescribed in agreements or elsewhere.

The TSA shall implement the controls that meet the following requirements.

The TSA shall (in TSA Practice Statement) ensure that it demonstrates the reliability necessary for providing time-stamping services.

a) The TSA shall have a risk assessment carried out in order to evaluate business assets and threats to those assets in order to determine the necessary security controls and operational procedures.

b) The TSA shall have a statement of the practices and procedures used to address all the requirements identified in this time-stamp policy. (This policy makes no requirement as to the structure of the TSA practice statement).

c) The TSA's practice statement shall identify the obligations of all external organizations supporting the TSA services including the applicable policies and practices.

d) The TSA shall make available to subscribers and relying parties its practice statement, and other relevant documentation, as necessary to assess conformance to the time-stamp policy ( The TSA is not generally required to make all the details of its practices public).


e) The TSA shall disclose to all subscribers and potential relying parties the terms and conditions regarding use of its time-stamping services as specified in section 7.1.2.

f) The TSA shall have a high level management body with final authority for approving the TSA practice statement.

g) The senior management of the TSA shall ensure that the practices are properly implemented.

h) The TSA shall define a review process for the practices including responsibilities for maintaining the TSA practice statement.

i) The TSA shall give due notice of changes it intends to make in its practice statement and shall, following approval as in (f) above, make the revised TSA practice statement immediately available as required under (d) above.

The TSA shall (in TSA Disclosure Statement) disclose to all subscribers and potential relying parties the terms and conditions regarding use of its time-stamping services. This statement shall at least specify for each time-stamp policy supported by the TSA:

a) The TSA contact information.

b) The time-stamp policy being applied.

c) c) At least one hashing algorithm which may be used to represent the datum being time-stamped.

d) The expected life-time of the signature used to sign the time-stamp token (depends on the hashing algorithm being used, the signature algorithm being used and the private key length).

e) The accuracy of the time in the time-stamp tokens with respect to UTC.

f) Any limitations on the use of the time-stamping service.

g) The subscriber's obligations as defined in section 6.2, if any.

h) The relying party's obligations as defined in section 6.3.

i) Information on how to verify the time-stamp token such that the relying party is considered to "reasonably rely" on the time-stamp token (see section 6.3) and any possible limitations on the validity period.

j) The period of time during which TSA event logs (see section 7.4.10) are retained.

k) The applicable legal system, including any claim to meet the requirements on time-stamping services under national law.

l) Limitations of liability.

m) Procedures for complaints and dispute settlement.

n) If the TSA has been assessed to be conformant with the identified time-stamp policy, and if so by which independent body.

Next are in document defined requirements on key management life cycle. TSA shall ensure that cryptographic keys are generated in under controlled (and secure) circumstances. TSU (Time Stamping Unit) private keys remain confidential and maintain their integrity. TSU signature verification (public) keys shall be made available to relying parties in a public key certificate. The TSU's signature verification (public) key certificate shall be issued by a certification authority operating under a certificate policy which provides a level of security equivalent to, or higher than, this time-stamping policy. The TSA shall ensure that TSU private signing keys are not used beyond the end of their life cycle.

The TSA shall ensure that time-stamp tokens are issued securely and include the correct time. In particular:

a) The time-stamp token shall include an identifier for the time-stamp policy;

b) Each time-stamp token shall have a unique identifier;

c) The time values the TSU uses in the time-stamp token shall be traceable to at least one of the real time values distributed by a UTC(k) laboratory.


d) The time included in the time-stamp token shall be synchronized with UTC within the accuracy defined in this policy and, if present, within the accuracy defined in the time-stamp token itself;

e) If the time-stamp provider's clock is detected (see section 7.3.2c)) as being out of the stated accuracy (see section 7.1.2e)) then time-stamp tokens shall not be issued.

f) The time-stamp token shall include a representation (e.g. hash value) of the datum being time-stamped as provided by the requestor;

g) The time-stamp token shall be signed using a key generated exclusively for this purpose.

h) The time-stamp token shall include:

• where applicable, an identifier for the country in which the TSA is established;

• an identifier for the TSA;

• an identifier for the unit which issues the time-stamps.

The TSA shall ensure:

• that administrative and management procedures are applied which are adequate and correspond to recognized best practice;

• that its information and other assets receive an appropriate level of protection.;

• that personnel and hiring practices enhance and support the trustworthiness of the TSA's operations;

• that physical access to critical services is controlled and physical risks to its assets minimized;

• that the TSA system components are secure and correctly operated, with minimal risk of failure;

• that TSA system access is limited to properly authorized individuals;

• use trustworthy systems and products that are protected against modification;

• in the case of events which affect the security of the TSA's services, including compromise of TSU's private signing keys or detected loss of calibration, that relevant information is made available to subscribers and relying parties

• that potential disruptions to subscribers and relying parties are minimized as a result of the cessation of the TSA's time-stamping services, and in particular ensure continued maintenance of information required to verify the correctness of time-stamp tokens

• compliance with legal requirements

• that all relevant information concerning the operation of time-stamping services is recorded for a defined period of time, in particular for the purpose of providing evidence for the purposes of legal proceedings

• that its organization is reliable.

5 Conclusions In article was given some overview on problematic connected with the notion Time Stamping Authority. At this day there are TSA used rather rarely. But as the necessary (in many important applications – for example electronic commerce, government sector, health services and others) component of electronic signatures is time-stamping forthcoming technique and important tool.


References [1] Benaloh, Josh; de Mare, Michael: Efficient Broadcast Time-stamping. Technical Report 1, Clarkson

University Department of Mathematics and Computer Science, August 1991.

[2] Bayer, Dave; Haber, Stuart A.; Stornetta, Wakefield Scott: Improving the Efficiency And Reliability of Digital Time-stamping. In Sequences’91: Methods in Communication, Security, and Computer Science, pages 329–334. Springer-Verlag, 1992.

[3] Buldas, Ahto; Laud, Peeter: New Linking Schemes for Digital Time-stamping. In The 1st International Conference on Information Security and Cryptology, pages 3–14, Seoul, Korea, 18–19 December 1998. Korea Institute of Information Security and Cryptology.

[4] Buldas, Ahto; Laud, Peeter; Lipmaa, Helger; Villemson, Jan: "Time-Stamping with Binary Linking Schemes." In Hugo Krawczyk, editor, Advances in Cryptology --- CRYPTO '98, volume 1462 of Lecture Notes in Computer Science, pages 486-501. Springer-Verlag, 1998.

[5] Buldas, Ahto; Lipmaa, Helger; Schoenmakers, Berry: "Optimally Efficient Accountable Time-Stamping". In Yuliang Zheng and Hideki Imai, editors, Public Key Cryptography '2000, volume 1751 of Lecture Notes in Computer Science, pages 293-305, Melbourne, Australia, 18--20 January 2000. Springer Verlag

[6] Lipmaa, Helger: On Optimal Hash Tree Traversyl for Interval Time stamping, In Yuliang Zheng and Hideki Imai, editors, Public Key Cryptography '2000, volume 1751 of Lecture Notes in Computer Science, pages 293-305, Melbourne, Australia, 18--20 January 2000. Springer Verlag.

[7] Lipmaa, Helger:. Secure and Efficient Time-stamping Systems. PhD thesis, University of Tartu, June 1999.

[8] Lipmaa, Helger:. Cryptology Pointers. Time Stamping, http://www.tcs.hut.fi/~helger/crypto/link/ timestamping/

[9] Haber, Stuart A.; Stornetta, Wakefield Scott: Stuart: How to Time-stamp a Digital Document, Journal of Cryptology, 3(2):99–111, 1991.

[10] Willemson, Jan: Size-Efficient Interval Time Stamps. PhD thesis, University of Tartu, June 2002. Available from http://home.cyber.ee/jan/publ.html, May 2002.

[11] Roos, Melis: "Integrating Time-Stamping and Notarization". Master thesis, University of Tartu, 1999.

Projects and Standards [12] PKITS: Public key Infrastructure with Time Stamping Authority (a.k.a. PITA), ETS PROJECT: 23.192,

PKITS Overview Final Report, Produced by: FNMT

[13] RFC3029. Data Validation and Certification Server Protocols.

[14] RFC3161. Time-Stamp Protocol (TSP).

[15] RFC3126. Electronic Signature Formats for long term electronic signatures.

[16] ETSI Standard TS 101 733 V.1.4.0 (2002-09) Electronic Signature Formats.

[17] ETSI Standard TS 101 861 Time Stamping Profile

[18] ETSI Standard TS 102 023 Policy requirements for time-stamping authorities

[19] Final Report of the EESSI Expert Team

[20] Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for Electronic Signatures, in EN Official Journal of the European Communities 19.1.2000 L 13/12.

[21] Policy Requirements for Time-Stamping Authorities, http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-pkix-pr-tsa-02.txt

http://www.tcs.hut.fi/~helger/crypto/link/timestamping/

http://www.tcs.hut.fi/~helger/crypto/link/timestamping/

http://home.cyber.ee/mroos/thesis/

http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-pkix-pr-tsa-02.txt

http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-pkix-pr-tsa-02.txt


A New Approach of Signing Documents with Symmetric Cryptosystems and an Arbitrator

Nol Premasathian

[email protected]

Faculty of Science King Mongkut’s University of Technology Thonburi

Bangkok, Thailand

Abstract Signing documents can be done by using some public-key algorithms. Alternatively, there is a protocol to sign documents with symmetric cryptosystems and an arbitrator. The protocol requires each the sender and the receiver to maintain a secret key with the arbitrator. Messages and acknowledgments are sent through the arbitrator, who will decrypt it using the private key of the sender and encrypt it using the private key of the receiver. The arbitrator has to keep records of every signed message and acknowledgment transmitted. Since the arbitrator may work for several pairs of people, it can be a bottleneck in the transmission. This paper presents a new approach of signing documents with symmetric cryptosystems and an arbitrator. The new approach uses three private keys instead of two and has three improvements. First, it reduces the number of transmissions from four to three. It also reduces the number of cryptographic operations performed by the arbitrator. Second, the arbitrator needs not keep a record of each transmission. The proof of sending is kept by the message receiver while the proof of the message acknowledgment is kept by the message sender. The sender and the receiver naturally feel more secure to have the proof with them. Third, although the arbitrator is trusted by both parties, it doesn’t mean that they want to reveal the content of the message to the arbitrator. In the new approach, the arbitrator will not perceive the content of the message. This paper explains how the new approach can be used to send a signed message, to acknowledge the message and how to prove the sending or receiving when a dispute occurs.

Keywords: digital signatures, symmetric cryptosystems, private key, secret key.

1 Introduction With the expansion and the use of Internet, the electronic means of communication (exchange of information) are becoming progressively more important [2]. It is often useful to prove that a message was generated by a particular individual, if the individual is not necessarily around to be asked about authorship of the message [3]. The sender can sign a message using digital signature, which depends on the contents of the message. Most previously proposed signature schemes were based on well-known public key systems such as RSA system [4] and ElGamal system [1][7]. A disadvantage of public key systems is the speed [5]. It is possible to sign a document using private key systems and an arbitrator or a third person who is trusted by both the sender and the receiver.

2 The Existing Scheme The protocol that provides digital signatures using symmetric cryptosystems has been invented for some time [6]. It requires the help of an arbitrator. The sender shares a secret key Ks with the arbitrator while the receiver shares a secret key Kr with the arbitrator. A signed message can be sent as follows.

1. The sender encrypts the message with Ks and sends it to the arbitrator.

2. The arbitrator decrypts the message with Ks.

3. The arbitrator takes the decrypted message and a statement that he has received this message from the sender, and encrypts them with Kr.

4. The arbitrator sends the encrypted message and the statement to the receiver.

5. The receiver decrypts the message and the statement with Kr.


A message can be acknowledged in a similar way. The receiver composes an acknowledgment statement, encrypts it with Kr and sends it to the arbitrator, who will decrypt it with Kr, encrypt it with Ks and send it to the sender. Four transmissions are required to send a signed message and receive a signed acknowledgment. The arbitrator has to keep a record for every message and acknowledgment transmitted. If the sender refuses to recognise the sending of a message or the receiver refuses to recognise the acknowledgment of a message, disputes can be dissolved according to the records kept by the arbitrator. If the record is lost, the dispute cannot be dissolved. The protocol also requires the arbitrator to encrypt and decrypt all messages and acknowledgements. If messages are large and the arbitrator works for several pairs, this can be a bottleneck in communication. In addition, the content of the message is revealed to the arbitrator.

3 The Proposed Scheme In this section, we propose a new protocol to sign and acknowledge a message. In this protocol, the sender shares a secret key Ks with the arbitrator, the receiver shares a secret key Kr with the arbitrator, and the sender shares a secret key Km with the receiver. A signed message M can be sent and acknowledged as follows.

1. The sender computes the hash of the message H(M), encrypts the hash with Ks, encrypts the message with Km and sends Ks(H(M)) and Km(M) to the arbitrator.

2. The arbitrator decrypts the hash with Ks to get H(M), computes Kr(Kr(H(M))), hashes it to get H(Kr(Kr(H(M)))), combines H(Kr(Kr(H(M)))) with H(M) to get H(Kr(Kr(H(M))))+H(M) and encrypts it with Ks to get Ks(H(Kr(Kr(H(M))))+H(M)).

3. The arbitrator sends Km(M), Ks(H(M)), Kr (Kr(H(M))), and Ks(H(Kr(Kr(H(M))))+H(M)) to the receiver.

4. The receiver decrypts Km(M) to get the message, computes Kr(Kr(H(M))) from the message and compare it with the Kr(Kr(H(M))) that he received from the arbitrator. If they are the same, it means that the signature Ks(H(M)) is valid. The receiver then sends Kr(Kr(H(M))) and Ks(H(Kr(Kr(H(M))))+H(M)) to the sender.

5. The sender decrypts Ks(H(Kr(Kr(H(M))))+H(M)) to get H(Kr(Kr(H(M)))) and H(M). He can verify H(M) with the original one to check the validity of the acknowledgement. If they are the same and the hash of the received Kr(Kr(H(M))) is the same as the H(Kr(Kr(H(M)))) decrypted from Ks(H(Kr(Kr(H(M))))+H(M)), the acknowledgment Kr(Kr(H(M))) is valid.

In the proposed scheme, the content of the message M is not revealed to the arbitrator since it is encrypted with Km, which is shared only between the sender and the receiver. The encrypted message is forwarded to the receiver without a modification along with other information including the signature Ks(H(M)). Ks(H(M)) can be used as a signature because of two reasons. First, it is computed from the message. Second, the sender possesses the key Ks that can compute the signature from the message whereas the receiver does not. Although the arbitrator also possesses this key but we must assume that the arbitrator is trusted by both the sender and the receiver and therefore we assume that he will not cheat. The receiver knows that the signature Ks(H(M)) is a valid signature for the message M, though he does not have Ks to decrypt the signature and verify it. That is because he also receives Kr(Kr(H(M))), that was computed from the same H(M) the signature Ks(H(M)) by the arbitrator. He can verify the validity of Kr(Kr(H(M))) by hashing the message M, encrypting it with Kr twice and compare it with the received Kr(Kr(H(M))). In this way, the validity of the signature is verified. Similarly, Kr(Kr(H(M))) received by the sender can be used as the acknowledgment of the message M. It is computed from the message M using the key Kr that is possessed by the receiver but not the sender. The sender can verify the validity of the acknowledgment by decrypting Ks(H(Kr(Kr(H(M))))+H(M)), that was computed by the arbitrator and forwarded to the sender from the receiver, to get H(Kr(Kr(H(M))))+H(M). He can verify H(M) with the original one. The arbitrator used the same H(M) to compute H(Kr(Kr(H(M)))) and therefore it can be used to verify the validity of the acknowledgment by hashing the acknowledgment and compare it with the received H(Kr(Kr(H(M)))). H(M) is encrypted by Kr twice to make it differ from the signature. Note that the receiver cannot modify Ks(H(Kr(Kr(H(M))))+H(M)) since it is encrypted with Ks.

In the proposed scheme, there are three transmissions, each in step 1, 3 and 4. The cryptographic operations that the arbitrator has to perform are encrypting hash values and hashing encrypted hash values. These operations perform on fixed-length data regardless of the size of the message. He does not hash or encrypt the whole message, which can be long and may take a lot of time. This thus increases the efficiency of the arbitrator.


4 Dissolving Disputes There are two kinds of disputes here. The sender does not recognise the signature and the receiver does not recognise the acknowledgment. Both disputes can be dissolved by the arbitrator without revealing the key Km to the arbitrator. However, the content of the disputed message must be revealed.

If the sender refuses the sending of a message, the receiver can present the message M, and the signature Ks(H(M)) to the arbitrator. The arbitrator hashes M to get H(M), encrypts it using Ks and compares it with the signature Ks(H(M)) presented by the receiver. If they are the same, the arbitrator will declare the signature valid. The sender cannot claim that the signature Ks(H(M)) was produced by the receiver since the receiver does not possess the key Ks.

If the receiver refuses the receiving of a message, the sender can present the message M, and the acknowledgment Kr(Kr(H(M))) to the arbitrator. The arbitrator hashes M to get H(M), encrypts it using Kr twice and compares it with the acknowledgment Kr(Kr(H(M))). If they are the same, the arbitrator will declare acknowledgment valid. The receiver cannot claim that the acknowledgment Kr(Kr(H(M))) was produced by the sender since the sender does not possess the key Kr.

When a key is updated, the old key must be properly archived so that any dispute about a signature or an acknowledgment using the old key can be dissolved in the future.

5 Conclusion This paper presents a new approach of signing and acknowledging documents using symmetric key cryptosystems and an arbitrator. In the new approach, the number of transmissions is reduced from four to three, the arbitrator is not required to keep a record of each sending, the number of cryptographic operations performed by the arbitrator is reduced and the content of the message is not revealed to the arbitrator. The paper does not specify a particular encryption algorithm or a hash function to be used. Any person who is interested in implementing this protocol should choose an encryption algorithm carefully as some of them may be vulnerable to a certain attack when used in this protocol.

References [1] ElGamal, T.: A public key cryptosystem and a signature scheme based on discrete logarithms, IEEE Trans.

Inform. Theory 31 (4) , pp.469-472, 1985.

[2] Janka, J.: Use of public key infrastructure, in Proc. Security and Protection of Information, Brno, Czech Republic, 2001.

[3] Kaufman, C., Perlman, R., and Speciner, M.: Network security, Prentice Hall, 1995.

[4] Rivest, R.L., Shamir, A., Andelman, L.: A method for obtaining digital signature and public key cryptosystem, Comm. ACM 21(2), pp. 120-126, 1978.

[5] RSA Security Inc.: RSA Laboratories frequently asked questions about today’s cryptography, Version 4.1, http://www.rsasecurity.com/rsalabs/faq/2-1-3.html, 2003.

[6] Schneier, B.: Applied cryptography, Wiley, 1996.

[7] Tseng, Y., Jan, J., Chien, H.: Digital signature with message recovery using self-certified public keys and its variants, Journal of Applied Mathematics and Computation 136, pp. 203-214, 2003.

http://www.rsasecurity.com/rsalabs/faq/2-1-3.html


Ways of Doubling Block Size of Feistel Ciphers Used in Some Candidates for the AES

Bohuslav Rudolf

[email protected]

National Security Authority P. O. Box 49, 150 06, Prague 56

Abstract We describe and discuss rounds of 4 (former) candidates into the AES process (DEAL, CAST-256, Twofish and RC6). Each of them represents its own way from a Feistel network to a cipher with double block size. We try to sketch these ways and to compare them.

Keywords: Feistel network, AES, block size, DEAL, CAST, Twofish, RC6.

1 Introduction Most block ciphers in use today have a block size of 64 bits. For these ciphers some variants of the birthday attack require storage / collection of 2 32 ciphertexts blocks for a succes about one half [4]. With the rapid increase in computing power and available storage media it can be expected that in a few years this attack is very realistic. Hence in a near future we shall use for higher security levels block ciphers with 128-bit block size. This has been taken also into considerations in the projects AES and NESSIE.

A lot of block algorithms are Feistel networks. They are iterated block ciphers. This means taking a simple round function and iterating it multiple times. A basic building block of the round (function) is a non-linear function usually called “F function” or “round function”.

When we try to design Feistel cipher with 128-bit block size, we can choose one of two following possibilities. First one is to develop our own design. The second one is try to double 64-bit block size of some common Feistel cipher. In this contribution we describe and discuss rounds of 4 candidates into the AES process. Each of them represents its own way from (perhaps slightly modified) Feistel network to a cipher with double block size.

The simplest (and straightforward) approach to solve this problem is to use encryption function of a chosen 64-bit block cipher as F function of a new cipher. In the end we obtain pure Feistel network with 128-bit block size. This is an instance of the cipher DEAL (with DES encryption as the building block). Little bit less straightforward, but still very simple way is to take F function of the original cipher and use it in generalized (unbalanced) Feistel network. This way led for instance from the cipher CAST-128 to CAST-256. Both of these examples are very simple. But none of them (DEAL and CAST-256) became one of the AES finalists.

Both of two remaining discussed candidates Twofish and RC6 were among 5 finalists of the AES process. Twofish F function design is based on nontrivial modification and doubling of Blowfish F function. In this contribution we try to sketch a probable way from Blowfish to Twofish design. The last one example is design of RC6. It is the result of a careful modification of two parallel copies of RC5. Both of them are connected with Feistel structure but both of them differ essentially from traditional Feistel network. It is interesting for us that authors of RC6 described their way from RC5 to RC6 [7].

A way of mixing of all computation lines during encryption is important for a new cipher quality. If this mixing is too slow we should not expect high performance and high security of the cipher simultaneously. In the former paper [1] we studied and used DEM (diffusion evaluation matrix). It is a simple tool for elementary estimation of cipher diffusion. It is based on old ideas to use matrices for diffusion evaluation (see for instance [2]) completed by the theorem about DEM of composed mapping and exploitation of matrix calculus. Usually we use it for estimation of the smallest number of encryption rounds potentially providing full diffusion. We speak about potentiality only because we are not sure that different ways of dependency transfer do not mutually cancel.

In the paper [1] we illustrated DEM estimation with the following examples: Twofish F-function, a traditional Feistel network and an unbalanced Feistel network used in CAST-256. DEM estimation of RC6 is done in Appendix of this contribution.


Of course, block cipher security estimation is sophisticated problem. It has many important aspects. Usually cipher resistance against known attacks is examined (differential, linear and other kinds of cryptanalysis, detectable key classes and so on) and attacks against simplified variants of the algorithm are designed. For the AES finalists we know corresponding security levels assigned them by NIST.

2 DEAL - cipher design using DES encryption as F function Introductory remarks: In [5] Knudsen proposed the r-round Feistel cipher DEAL with a block size 128 bits. DEAL is a simple way of constructing a new block cipher based on another block cipher E, doubling the block size. It uses DES in the round function. One could as well view DEAL as a “mode of operation” of the underlying block cipher E (here DES), instead of a block cipher of its own right. The word DEAL means Data Encryption Algorithm with Larger blocks.

DEAL round: A 128 bit plaintext is split up into two halves. A round take the 128-bit block (L, R) and the round key K as the input to compute the output block (Lnew, Rnew) by:

Lnew = R, Rnew = L ⊕ E(R, K) ⊕ denotes XOR and E is the DES encryption function, K is the DES key,

L, R, Lnew and Rnew are 64-bit words

The Knudsen attack: In Knudsen paper [5] is the following proposition: There is an attack on six-round DEAL with independent round keys, which requires about 2121 DES-encryptions using about 270 chosen plaintexts.

Diffusion: DEAL F function is DES encryption function. Hence it has potentially full diffusion and in accordance with our results in [1] three DEAL rounds have potentially full diffusion.

Number of rounds and speed of encryption: Accordingly to the attack on 6 rounds Knudsen recommended to use DEAL at least with 6 rounds. DEAL accepts three different key sizes, namely 128 bits (DEAL-128), 192 bits (DEAL-192) and 256 bits (DEAL-256). For the first two sizes author recommends that number of rounds is equal to 6, for 256 bit keys it should be 8. DEAL with 6 rounds is as fast as triple DES. Hence it provides a worst-case performance benchmark for AES. [10]. Let us notice that Knudsen participated also on proposal of Serpent (one of AES finalists).

3 The CAST-256 - a cipher with a generalized Feistel network The CAST-256 encryption algorithm is an extension of the CAST-128 cipher and has been submitted as a candidate for NIST’s AES effort [3].

The main idea of the block size doubling: The mechanism for the expansion of a 64-bit block size to a larger block size in the CAST-256 design case is based on the following idea. In a traditional Feistel network (64-bit block size) it is possible the exchange of left and right halves in each round to interpret as a circular right shift of 32 bits. Let us consider a generalization of this structure to a cipher with a block size of 4 x 32 bits. In this case we consider round as a structure consisting in 2 steps. In the first of them F function is used for nontrivial change of one 32-bit word value. Then a 128-bit data block is circularly shifted of 32 bits (one word) to right.

Round equations: Accordingly, the round of this cipher contains a circular right shift of 32 bits and the round has the form:

C* = C ⊕ f(D, k), (Anew, Bnew, Cnew, Dnew) = (D, A, B, C*)

f denotes F function, k is a round subkey and (A, B, C, D) is a 128-bit block where words A, B, C, D are each 32 bits in length.

A cycle and a quad-round of the cipher: In accordance with [11], a cycle is the number of rounds necessary for (non-trivial) modification of each bit in the block. The cycle of a traditional Feistel network contains 2 rounds. For instance the DES cipher has 8 cycles. The CAST-256 algorithm with the block size 128 = 4 x 32 requires 4 rounds (instead of 2) to input all bits in the block to the round function. Thus, its cycle contains 4 rounds called a quad-round.

Two representations of a cycle: (see for instance [12], twisted ladder and untwisted ladder) The first one representation of a cycle is straightforward. We write four times one round equation. We obtain the second representation of a cycle by the following modification: Instead of the rotations in cycle rounds we change only notation of words in these rounds.


Encryption and decryption: The consequence of the CAST-256 cipher structure design is that it requires a separate structure for decryption. If in the encryption the right circular shift is used, the decryption needs a left circular shift. Accordingly, in this case we have to consider 2 types of quad-rounds: The forward one for the encryption and the reverse one for the decryption. If there are r rounds in the full cipher, the first r/2 rounds use right shifting and the last r/2 rounds use left-shifting. In this way decryption is identical to encryption, requiring only a reversal of the round key.

Form of the quad rounds: Here we shall use the second type representation of the Feistel cycle. The „forward quad-round“ has the form:

Cnew = C ⊕ f1(D, k0(j))

Bnew = B ⊕ f2(Cnew, k1

(j))

Anew = A ⊕ f3(Bnew, k2(j))

Dnew = D ⊕ f1(Anew, k3

(j)) The „reverse quad-round“ has the form:

Dnew = D ⊕ f1(A, k3(j))

Anew = A ⊕ f3(B, k2

(j))

Bnew = B ⊕ f2(C, k1(j))

Cnew = C ⊕ f1(Dnew, k0

(j)) where

f1, f2, f3 are functions defined as for CAST-128.

(A, B, C, D) denotes a 128-bit block where A, B, C, D are each 32 bits in length.

(k0(j), k1

(j), k2(j), k3

(j)) the set of keys for the j-th quad round

Choice of the Feistel function: The CAST-256 uses the same Feistel functions as the CAST-128.

Cipher diffusion: In [1] we have seen that this kind of unbalanced Feistel network needs at least 7 rounds to reach full diffusion.

Number of rounds and speed of encryption: Security analysis in [3] suggests to use CAST-256 with 12 quad rounds having 48 rounds. Accordingly to a lot of required rounds, it is considerably slower than the fastest AES candidates [10].

4 A possible way from Blowfish to Twofish Introductory remarks: Twofish is a block cipher designed by Counterpane Systems Group [9] as a candidate for the Advanced Encryption Standard selection process, and was accepted as one of the five finalists. It is a 128-bit block cipher that accepts a variable -length key up to 256 bits. It uses a 16-round (8-cycles) Feistel-like strukture with additional whitening of input and output. (The only non-Feistel elements are the 1-bit rotates.)

It originated from an attempt to take the original Blowfish design and modify it for a 128-bit block [8]. We do not know the way of the Twofish team from Blowfish to Twofish design exactly. But we can try to reconstruct its main probable line.

The Blowfish F function: Blowfish is traditional Feistel network with 64-bit block size. Let us describe its F function now.

1. First the 32-bit input data X are XORed with corresponding subkey K: X* = X ⊕ K.

2. The result X* is split into 4 bytes: (x*3, x*2, x*1, x*0) creating four 8-bit inputs to the four key-dependent S-boxes. Their outputs are four 32-bit words: [Y 3, Y 2, Y 1, Y 0]. Hence: Y j = sj(x*j).

3. The results are combined (mix) in the folowing way: Y = [(Y 0 + Y 1) ⊕ Y 2] + Y 3.


Figure 1: Blowfish F function B.

First probable step of the way to Twofish - replacement of the function B: The Twofish function G is a successor of Blowfish F function B.

• It uses 4 bijective 8 x 8 key-dependent s-boxes instead of Blowfish large 8 x 32 boxes. Dependence of the G function on a key is provided only by s-boxes.

• As mixing (diffusion) layer the MDS matrix (connected with sophisticated theoretical background) is used.

Figure 2: Twofish function G.

Second probable step of the way - predecessor of Twofish F function: Let us take two parallel versions of the function G. In the next steps we need above all to add some diffusion layer to mix outputs (or inputs) of these two versions of G. It also seems be reasonable to break in some way the symmetry connected with two identical functions use.

Third probable step of the way - adding mixing layer: To mix computation of both G function instances they use so called Pseudo Hadamard transform (PHT in short) with 32-bit long variables pairs:

(X*, Y*) = TPH(X, Y), where: X* = X + Y, Y* = X + 2 Y = X* + Y. It is applied on the both functions G outputs.

Fourth probable step of the way - first asymmetry installation: The second instance of G input is firstly rotated by one byte. It is an easy way to make from G a different function G*: G*(X) = G(X <<< 8).

It is different but closely related function to G. It contains the same boxes (but in different order) and

in some sense different MDS transformation, but simply related to the original one. Cryptographic properties of both of these functions are the same.

Fifth probable step - standard key-dependence insertion: Of course, outputs of the functions G and G* are key-dependent. But we need some standard key-dependence, too. Thus we take a different part of the Twofish key and add it modulo 232 to both parts of the PHT output.

Relationship between the F function F and the function G (resumption)

B k X X* Y

(8 x 32) S-box 3

⊕ (8 x 32) S-box 2

(8 x 32) S-box 1

(8 x 32) S-box 0+

⊕

+

G x0 X x1 Y Z x2 x3

S-box 0

S-box 1

S-box 2

S-box 3

MDS


• The F function F contains the function G twice.

• The inputs into the second instance of G are firstly rotated by one byte (to obtain function G*).

• The outputs from functions G and G* are combined by the Pseudo-Hadamard transform.

• The standard key-dependence is by subkey adding to the both parts of the output provided.

The mixing layer of Twofish F function: The mixing layer of the Twofish F function is composed of two parts:

• The first one contains the MDS transformations of the both instances function G

• And the second one is the Pseudo-Hadamard transformation realised by two additions.

The Twofish F function: Let us represent result of the former five steps. The F function is defined by the function G in the following form:

A* = G(A) + G(B<<< 8) + KA, B* = G(A) + 2 G(B<<< 8) + KB, where + denotes addition modulo 232, A, B (A*, B*) are 32-bit halves of the input (output), KA, KB are 32-bit subkeys.

Figure 3: Twofish F function.

Sixth step - second asymmetry installation (one-bit rotations in the Feistel structure): Majority of Twofish Feistel function building blocks are byte-oriented (namely S-boxes and MDS-transformation).

The one-bit rotations were included to help break this structure. Let us denote the round input as (A, B, C, D), its output as (Anew, Bnew, Cnew, Dnew) and two halves of the F function output as (A*, B*).

Then: Anew = (A* ⊕ C) >>> 1, Bnew = B* ⊕ (D <<< 1),

where X>>>1 (or X<<<1) denotes right (or left) one-bit rotation of the word X.

Of course: (Cnew, Dnew) = (A, B).

Remark about decryption: Different order of the XOR and rotation in C line and D line helps to provide symmetry for decryption.The Twofish encryption and decryption functions are slightly different, but are built from the same blocks.

F KA A A* B B*

KB

G

G +

+ +

+

PHT

<<< 8

G*


Figure 4: The round structure of Twofish.

Diffusion: In paper [1] we have seen that Twofish F function has potentially full diffusion.

Number of rounds, security and speed of encryption: Twofish with 16 rounds (8-cycles) appears to have a high security level in the sense of NIST comparison of AES finalists security. (Of course, this is probably mainly connected with the use of key-dependent boxes). Twofish was ranked among the fastest AES candidates.

5 Way from RC5 to RC6 Introductory remarks: The iterated block cipher RC5 was introduced by Rivest in [6]. It has a variable number of rounds denoted with r and key size of b bytes. The design is word-oriented for word sizes w = 32, 64 and the block size is 2w. The choice of parameters is usually denoted as RC5-w / r / b. In the next we shall take w = 32 only. A novel feature of the RC5 algorithm is the use of data-dependent rotations. RC5 is not exactly a Feistel cipher but it has a very similar structure.

The RC6 block cipher is an evolutionary improvement of RC5, designed to meet the requirements of the AES. The authors of the RC6 (Rivest,. Robshaw, Sidney and Yin) described the way from RC5 to RC6 in their AES proposal [7].

A round of RC5 encryption: Formulas for one (half) round of RC5 encryption have the form:

A* = [(A ⊕ B)<<< B] + K, (Anew, Bnew) = (B, A*) A, B, Kj, A*, Anew, Bnew are w-bit words, (here we suppose w = 32)

Anew, Bnew denote new values (after round) of words A, B and K is a round subkey.

A <<<B rotate the w-bit word A to the left by the amount given by the least significant lg w bits of B (here lg w = 5)

We see that the data entering round is split into two halves - a left word A and a right word B. Value of the word B does not change and it is transferred into a new value of the word A.

The unkeyed part of F function analogy: The function f(X, Y) = X <<< Y appears as unkeyed part of F function analogy. It has two input words X and Y. The inputs are playing very different roles. We can interpret it in the way that input word Y controls computation of a new value of the input word X. This function is highly non-linear accordingly to (in reality 5 least significant bits only) the input word Y. (RC5 security is based on data dependent rotations.)

A way from RC5 round to RC6 round: The authors of RC6 described their way from RC5 to RC6 roughly in the following form:

A B C D KA A* B*

KB Anew Bnew Cnew Dnew

F ⊕

⊕

<<<1

>>>1


A First step - an improvement of the RC5 round: The rotation provided by the function f depends on 5 least significant bits of word B only. Accordingly RC5 has been strengthened to have rotation amounts depending on all the bits of B. Instead of using B in straightforward manner as above, they use transformed version of this register, for suitable transformation. The particular choice of this transformation for RC6 is:

g(X) = [X ∗ (2X + 1)]<<< 5, Note that g(X) is one-to-one modulo 232, and that the bits of g(X), which determine the rotation amount used, depend heavily on all the bits of x.

Then the strengthened form of RC5 round has the form:

T = g(B), A* = [(A ⊕ T)<<< T] + K, (Anew, Bnew) = (B, A*)

Figure 5: The strengthened version of RC5 round.

A second step - doubling a block size: Run two copies of strengthened RC5 in parallel:

T = g(B), U = g(D),

A* = [(A ⊕ T)<<< T] + KL, C* = [(C ⊕ U)<<< U] + KR,

(Anew, Bnew) = (B, A*), (Cnew, Dnew) = (D, C*) A third step of the way : Mix the A, B computation with the C, D computation.

Instead of swapping A with B and C with D, permute the registers A, B, C, D.

Switch where the rotation amounts come from between two computations:

T = g(B), U = g(D),

A* = [(A ⊕ T)<<< U] + KL, C* = [(C ⊕ U)<<< T] + KR,

(Anew, Bnew, Cnew, Dnew) = (B, C*, D, A*)

⊕

f

+

A B T K Anew Bnew

g


Figure 6: One round of RC6.

Remark about change of order of words (A, B, C, D) on the figure 6: Both copies of RC5 are used in symmetric way. To preserve this symmetry in our figure we changed order of words C and D here. Hence instead of rotation of the outgoing 4 words we can see two kinds of mixing computation lines: The first one provides mixing inside (strengthened) RC5 instance only and it is represented by transpositions: Anew = B, Cnew = D. The second one mix both instances lines also: Bnew = C, Dnew = A.

Diffusion: In the Appendix, DEM estimation of RC6 is computed with the following result: “Full diffusion is potentially provided by 3 rounds of RC6.”

Number of rounds, security and speed of encryption: RC6 with 20 rounds appears to have an adequate security margin and reasonable speed of encryption. But both these characteristics are closely connected with a data dependent rotation use.

6 Conclusion We described 4 ways of doubling block length of Feistel network connected with 4 former candidates for the AES.

The simplest one of them is connected with the cipher DEAL. In this case the whole encryption function of the original cipher (here DES) is used as the F function of the new cipher. However, the resulting cipher is very slow in comparison with other AES candidates.

The second approach is based on inserting the F function of the original cipher into an unbalanced Feistel network. Cycle of this cipher consists of 4 rounds (quad round). Full mixing is potentially reached after 7 rounds. For reasonable security a huge amount of rounds is need. CAST-256 proposal require 12 quad rounds e. g. 48 rounds. Thus speed of encryption is also considerably low.

The third approach is based on doubling of F function. The original (Blowfish) F function has been essentially modified for function g and doubled. Mixing of lines of computing connected with these two instances of function g is provided by the PHT transform. In this way the Twofish F function is obtained. Number of resulting cipher rounds needed for full mixing is the same as for standard Feistel network - in the case of the optimal mixing of F function three rounds are needed. Twofish is secure and simultaneously fast cipher.

The last approach is based on doubling and mixing of a modified Feistel network. Two parallel running copies of original cipher (RC5) round are strengthened and their computation is mixed. RC6 reach full diffusion potentially after 3 rounds. Security of RC5 and RC6 is influenced heavily by the data dependent rotations use.

A B D C T U

KL KR Anew Bnew Dnew Cnew

⊕

+

g

f

⊕

+

g

f


References [1] Rudolf B.: “Diffusion Evaluation Matrix Applied to (Generalized) Feistel Networks”, (corrected version),

Mikulášská kryptobesídka 2002, sborník přednášek, ECOM-MONITOR.COM.

[2] Meyer C.: Cryptography A New Dimension in Computer data Security, 1982, John Wiley & sons pp. 165-189.

[3] Adams C.: „The CAST-256 Encryption Algorithm“, AES proposal 1998.

[4] Knudsen L.: „Contemporary Block Ciphers”, Lectures on Data Security, LNCS 1561.

[5] Knudsen L.: „DEAL - a 128-bit Block Cipher“, http://www.ii.uib.no/~lars/aes/.html.

[6] Rivest R. L.: “The RC5 Encryption Algorithm”, Fast Software Encryption 95, LNCS 1008, pp. 86 – 96.

[7] Rivest R. L., Robshaw M. J. B., Yin Y. L.: “The RC6 Block Cipher. v.1.1”, AES proposal 1998.

[8] Schneier Br.: “The Twofish Encryption Algorithm: A 128-bit block cipher“, Dr. Dobb’s Journal, December 1998.

[9] Schneier, Kelsey, Whiting, Wagner, Ferguson: “Twofish: A 128-bit block cipher“, AES proposal 1998.

[10] Schneier, Kelsey, Whiting, Wagner, Hall: “Performance Comparison of the AES Submissions”.

[11] Schneier, Kelsey: “Unbalanced Feistel Network and Block Cipher Design”, Fast Software Encryption 96, LNCS 1039, pp. 121-144.

[12] Oorschot, Vanstone, Menezes: Handbook of Applied Cryptography, CRC Press 1996, p. 254.

Information about the author RNDr. Bohuslav RUDOLF

Studies 1978 - 1983 Faculty of Mathematics and Physics of the Charles University (Mathematical Physics) 1986 Doctor degree - RNDr. - in the subject: Interdisciplinary Physics

Research 1984 -1994 Faculty of Mechanical Engineering of the Czech Technical University

• 1984 - 1989 Research project: “Stochastic Models in Statistical and Quantum Physics” • 1990-1993 Grant CTU: “Nonlinear Models in Quantum Physics”

9. 1993 - 2. 1994 Shanghai University of Science and Technology (quasi-classical approximation in quantum chaos)

1995 – 2000 Military Technical Institute of Electronics (risk analysis, public-key cryptography) 2000 - National Security Authority (block ciphers analysis)

http://www.ii.uib/


Appendix - DEM estimation of RC6 rounds

Preliminary information Definitions of DEM (D1), output-input-component dependence (D2) and σ-reduction (D3) D1: Let us consider function ϕ: Y = ϕ(X) working with n-bit variables X and Y. Now we regard

the n-bit variables X and Y as m-dimensional vectors. Usually we consider the case: m = n / 8 (vector components are bytes). The j-th component of vector X (or Y) we denote xj (or yj). We assign to this function the corresponding diffusion evaluation matrix (DEM), which we denote as M(ϕ). Its matrix element mjk(ϕ) (in the j-the row and k-th column) is by definition equal to 1 if and only if the j-th component yj of the variable Y depends on the k-th component xk of the variable X. Otherwise we put: mjk(ϕ) = 0.

D2: For function ϕ: Y = ϕ(X) and the variables X, Y as above, the formulation that the j-th component yj of Y depends on the k-th component xk of X means the following: There is at least one pair of values (X,X*) of the variable X such that: x*k ≠ xk, x*r = xr for r ≠ k, y*j ≠ yj, where: Y = ϕ(X), Y* = ϕ(X*).

D3. Let us consider a real matrix M. Then the σ-reduced matrix σ(M) corresponding to M has elements σ(mjk), whereas: mjk ≠ 0 ⇒ σ(mjk) = 1, mjk = 0 ⇒ σ(mjk) = 0, (mjk is the corresponding element of M).

Theorem about DEM estimation of a composed mapping: Let functions ϕ, χ and ψ are working with n-bit variables so that: ψ = ϕ ° χ. Let us regard the n-bit inputs and n-bit outputs of these functions as m-dimensional vectors. Then for DEMs of these functions the following inequality holds:

M(ψ) = M(ϕ ° χ) ≤ σ[M(ϕ) • M(χ)], where the symbol • denotes the standard matrix multiplication and the inequality: M ≤ N of matrices M, N means, that mjk ≤ njk for every pair of indices (j, k). Full diffusion and matrix E: We say that a function ϕ has full diffusion iff every component of its output Y depends on all components of its input X. The corresponding diffusion evaluation matrix contains only 1 as its matrix elements. This kind of matrix we call as full diffusion matrix and we denote it as E. Potentially full diffusion: Usually we are interested in lowest number of rounds needed for full diffusion. But we compute DEM estimation only (and not DEM value). It follows from our use of inequality for DEM of composed function. Accordingly we obtain results of estimation in the form: An n-round DEM of some considered function is less or equal to E. However in many cases it simply means that this DEM is equal to E. For this reason we speak about potentially full diffusion in these cases. Identity matrix I: We use matrix of identity also and we denote it as I. It has non-zero elements on its diagonal only. They all are equal to 1. Work with matrices E and I: To make σ-reduced multiplications of matrices M and N (containing E and I as submatrices) we can use the following equations: σ(I • E) = σ(E • I) = σ(E) = E, σ(E • E) = E, σ(I • I) = σ(I) = I, σ(E + E) = σ(E + I) = σ(I + E) = E, σ(I + I) = I. Rotational matrices: The left circular shift of a bit string by α bits we express by a (rotational) matrix ρα. Let us notice that DEM of this mapping is simply equal to this matrix: M(ρα) = ρα. In the following computation we do not need an explicit form of this matrix.


Work with rotational matrices: It is evident that the following equations hold:

σ(I • ρα) = σ(ρα • I) = σ(ρα) = ρα, σ(ρα • ρβ) = σ(ρα + β) = ρα + β,

σ(E • ρα) = σ(ρα • E) = σ(E) = E, σ(E + ρα) = σ(ρα + E) = E, If we need to express σ(I + ρα), σ(ρα + ρβ) we have to use an explicit form of a rotational matrix. It is not so complicated, but in the following computation we do not need it.

Calculations To be more close to the figure we change notation of words in the following way:

(A, B, C, D) → (α, β, γ, δ) = (A, B, D, C) Then the round equations become into:

α* = {[α ⊕ g(β)]<<< g(γ)} + KL, δ* = {[δ ⊕ g(γ)]<<< g(β)} + KR,

(αnew, βnew, γnew, δnew) = (β, δ*, α*, γ) The round mapping R we regard as composed mapping: R = q4 ° q3 ° q2 ° q1, whereas: (α*, β*, γ*, δ*) = q1(α, β, γ, δ), α* = α ⊕ g(β), β* = β, γ* = γ, δ* = δ ⊕ g(γ) (α*, β*, γ*, δ*) = q2(α, β, γ, δ), α* = α<<< g(γ), β* = β, γ* = γ, δ* = δ<<< g(β). (α*, β*, γ*, δ*) = q3(α, β, γ, δ), α* = α + KL, β* = β, γ* = γ, δ* = δ + KR. (α*, β*, γ*, δ*) = q4(α, β, γ, δ) = (β, δ, α, γ) DEM of the function g: It is equal to E: M(g) = E. Every bit of a modular product depends on all bits of its factors. DEM of subkey adding: It depends on a value of the subkey. Hence we consider the worst diffusion case only. It is connected with the particular subkey value: KL = KR = 0. Then M(q3, worst) = I. Accordingly we obtain the following formulas for DEM of mappings qj:

( )

=

IEI

IEI

qM

0000000000

1 , ( )

=

α

γ

ρ

ρ

00000000

00

2

EI

IE

qM

Here the symbols ργ and ρα denote rotational matrices for the left circular shifts by 5 least significant bits of the words g(γ) and g(α), respectively.


( )

=

II

II

worstqM

000000000000

,3 , ( )

=

000000

000000

4

II

II

qM

And DEM estimation of a round has the form:

( ) ( ) ( ) ( ) ( )[ ]

=•••≤

0000

0000

, 1234

IEEEE

I

qMqMworstqMqMRMγ

α

ρ

ρσ

Now we need to distinguish rotational matrices connected with different rounds. The matrices ρα, ρβ connected with the j-th round we denote as ρα(j), ρβ(j). DEM estimation of two rounds (for instance rounds 1. and 2.) we obtain in the following way:

( ) ( ) ( )[ ]( )

( )

( )

( )

•

≤•≤

0000

0000

0000

0000

21

1

2

2

IEEEE

I

IEEEE

I

RMRMRMγ

α

γ

α

ρ

ρ

ρ

ρσσ

And it has the form:

( )

( )

( )

≤

0

0

2

1

1

EEEEEEEEEE

EE

RM

γ

α

ρ

ρ

It is evident that DEM estimation of 3 rounds gives M(3R) ≤ E. Hence 3 rounds of RC6 provide potentially full diffusion.

New Nominative Proxy Signature Schemefor Mobile Communication

Seung-Hyun Seo and Sang-Ho Lee

{happyday, shlee}@mm.ewha.ac.kr

Dept. of Computer Science and Engineering,Ewha Womans University

11-1 Daehyun-dong, Seodaemun-gu, Seoul 120-750, Korea

Abstract

Recently, Park and Lee [6] proposed the nominative proxy signature scheme for mobile communication.In [6], they argued that their scheme satisfies the following security requirements: user anonymity, au-thentication and non-repudiation. However, in this paper, we show that their scheme does not satisfythe non-repudiation among their security requirements. And then we propose a new nominative proxysignature scheme that solves the weakness of their scheme. Unlike their scheme, our scheme provides anon-repudiation property and moreover, it does not need a secure channel between the original signerand the proxy signer.

Keywords: nominative signature, proxy signature, mobile communication.

1 Introduction

Recent years have seen an explosive growth of interest in wireless networks that support the mobility ofusers. These networks serve as mobile and ubiquitous personal communication system. Wireless networkshave many features such as the mobility of users, the transmission of signals through open-air and therequirement of low power consumption by a mobile user, distinctively different from the wired networks.Especially, because the wireless networks transmit signals through open-air, the mobile communicationis more vulnerable to security attacks such as interception and unauthorized access than the wirednetwork communications. Hence services for securing mobile communication are vital in guaranteeingauthentication, non-repudiation and privacy of legitimate users [1, 5, 8].

Recently, Park and Lee [6] proposed a nominative proxy signature scheme for mobile communication.The nominative proxy signature scheme is a method in which the designated proxy signer generates anominative signature and transmits it to a verifier, instead of the original signer. It is a useful methodin the mobile communication environment, because it provides mobile users’ anonymity through thenominative signature [3] and decreases the mobile users’ computational cost through the proxy signature[6]. But, their scheme does not provide non-repudiation, even though they claimed that their schemeprovides it. So, the original signer or proxy signer can falsely deny later the fact that he generatedthe signature. Therefore a dispute between the original signer and the proxy signer may be happened,frequently.

In this paper, we first point out the problem of Park-Lee’s scheme; i.e., unlike their claim, the scheme doesnot satisfy non-repudiation. Next we propose a new nominative proxy signature scheme that providesthe non-repudiation, and does not require a secure channel between the original signer and the proxysigner.

The rest of the paper is organized as follows. In section 2, we briefly review some properties of thenominative proxy signature scheme, and give brief descriptions of Park-Lee’s scheme. Next, we explainwhy their scheme does not satisfy the non-repudiation. We present the new nominative proxy signaturescheme in section 4, and analyze the security of our scheme in section 5. Finally, we draw our conclusionsin section 6.


2 Brief Description of Park-Lee’s Nominative Proxy SignatureSchemeIn this section, we review some properties of the nominative proxy signature scheme, and describe Park-Lee’s scheme.

2.1 Definition of Nominative Proxy Signatures

The nominative proxy signature scheme is the method that the designated proxy signer generates thenominative signature and transmits it to a verifier, instead of an original signer. To construct a nominativeproxy signature scheme, the following four conditions must be satisfied [3, 4];

1. The original signer can delegate his signing operation to the proxy signer.2. Only the delegated proxy signer can nominate the verifier, and create the nominative proxy signature.3. Only the nominee(verifier) can verify the nominator(proxy signer)’s signature.4. If necessary, only the nominee can prove to the third party that the signature was issued to him by

the nominator and it is valid.

By these properties, because only the nominated verifier can verify the signature, the third party cannotknow who is the actual signer given a nominative proxy signature without the verifier’s help. Therefore,this nominative proxy signature scheme can provide the signer’s anonymity.

If we use the nominative proxy signature scheme in mobile communication, we can obtain two benefits.First, the anonymity of mobile user and proxy agent can be guaranteed. Second, since a mobile usercan designate a proxy agent as the proxy signer, the mobile user’s computational cost for signing canbe decreased by the proxy agent. Hence, this nominative proxy signature scheme is a useful method inmobile communication environment.

2.2 Park-Lee’s Scheme

The system parameters consist of a large prime p, a prime factor q of p−1, and an element q ∈ Z∗p of order

q. The original signer A’s private key is a random element xA ∈R Zq, and corresponding public key isyA = gxA (mod p). The proxy agent G’s private key is a random element xG ∈R Zq, and correspondingpublic key is yG = g−xG (mod p). The verifier B’s private key is a random element xB ∈R Zq, andcorresponding public key is yB = gxB (mod p). H(·) is a secure one-way hash function, Ti is an i-thtime-stamp and M is a message. Park-Lee’s scheme is constructed as follows:

1. (Proxy generation) An original signer generates the following proxy information : ai ∈R Zp (i ∈R

Z), l = gai (mod p), di = H(M‖Ti), si = xA · di + ai · l (mod p).2. (Proxy delivery) A gives (si, l, M, Ti) to a proxy agent G in a secure manner.

3. (Proxy verification) G checks gsi?= Y

H(M‖Ti)A · ll (mod p). If the computed value is correct, G

accepts it as a valid proxy.4. (Nominative proxy signing by the proxy signer) The proxy signer G chooses r, R ∈R Zp at

random and computes K = gR−r·xG (mod p) to prevent an original signer’s illegal acts. And then,the proxy agent G computes (D,Z, e), and creates a nominative proxy signature Sa(Z) as follows :D = Y R

B (mod p), Z = YB‖K‖D‖M, e = H(Z), Sa(Z) = xG · r − R · si · e (mod q).5. (Nominative proxy signature delivery) The proxy agent G sends (M,Ti, l, K, D, R, Sa(Z)) to

a verifier B.6. (Verification of the proxy signature) A verifier B computes e and b to check the received

signature : e = H(YB‖K‖D‖M), b = YH(M‖Ti)A · ll (mod p). And then, B verifies the nominative

proxy signature by checking a congruence such that

(gSa(Z) · bR·e · K)xB?= D (mod p).

The above congruence is computed as follows :

(gSa(Z) · bR·e · K)xB

= (gxG·r−R·si·e · (Y H(M‖Ti)A · ll)R·e · gR−r·xG)xB


= (gxG·r−R·si·e · (gxA·H(M‖Ti) · gai·l)R·e · gR−r·xG)xB

= (gxG·r−R·si·e · (gai·l+xA·H(M‖Ti))R·e · gR−r·xG)xB

= (gxG·r−R·si·e · gsi·R·e · gR−r·xG)xB

= (gR)xB = Y RB = D (mod p).

3 Cryptanalysis of Park-Lee’s Scheme

In this section, we analyze Park-Lee’s scheme and point out the weakness of their scheme. In [6], Parkand Lee argued that their scheme satisfied the following security requirements: user confidentiality,authentication and non-repudiation. The non-repudiation means signers, both the original signer andthe proxy signer, cannot falsely deny later that he generated a signature [7]. They explained why theirscheme satisfied the non-repudiation as follows: since the proxy agent’s private key, xG was included inthe nominative proxy signature, the original signer could not deny the fact that he designated G as hisproxy agent, and the proxy agent could not deny the fact that he generated the signature instead of theoriginal signer. However, we show that their scheme doesn’t meet the property of non-repudiation in thefollowing.

Park-Lee’s scheme is a proxy-unprotected proxy signature method [2]. So, both the original signer andthe proxy agent who know the proxy signature key can create a valid proxy signature. In Park-Lee’sscheme, when B verifies the nominative proxy signature, he does not need the proxy agent’s public key.So, the verifier B cannot know whether the proxy agent’s private key is included or not. Actually, eventhough a dishonest original signer uses a random number instead of xG to create a nominative proxysignature, the verifier cannot know the fact. Therefore, after the dishonest original signer creates theproxy signature, he can deny the fact and shift the responsibility for signing to the proxy agent. Andalso, a dishonest proxy agent who has the proxy information si can create a nominative proxy signaturewithout using his private key, because the verifier B cannot know the fact. So, the dishonest proxy agentcan also deny the fact that he creates the nominative proxy signature. The following attack scenarioshows this situation in more detail.

[The Attack Scenario (in case of dishonest original signer)]

Let’s assume that the dishonest original signer A′ wants to deceive the verifier. So, A′ generates anominative proxy signature as follows.

1. The dishonest original signer, A′ generates ai ∈R Zp (i ∈R Z), and computes l = gai (mod p),di = H(M‖Ti), si = xA · di + ai · l (mod p).

2. A′ chooses k′, r′, R′ ∈R Zp at random and computes K = gR′−r′·k′(mod p). And then, A′ com-

putes D, Z and e, and creates a nominative proxy signature Sa(Z) as follows : D = Y R′

B (mod p),Z = YB‖K‖D‖M, e = H(Z), Sa(Z) = k′ · r′ − R′ · si · e (mod q).

3. A′ pretending a proxy agent sends (M‖Ti‖l‖K‖D‖R′‖Sa(Z)) to a verifier B.4. (Verification of the proxy signature) A verifier B computes e and b to check the received

signature : e = H(YB‖K‖D‖M), b = YH(M‖Ti)A · ll (mod p). And then, B verifies the nominative

proxy signature by checking a congruence such that

(gSa(Z) · bR′·e · K)xB?= D (mod p).

The above congruence is computed as follows :

(gSa(Z) · bR′·e · K)xB

= (gk′·r′−R′·si·e · (Y H(M‖Ti)A · ll)R′·e · gR′−r′·k′

)xB

= (gk′·r′−R′·si·e · (gxA·H(M‖Ti) · gai·l)R′·e · gR′−r′·k′)xB

= (gk′·r′−R′·si·e · (gai·l+xA·H(M‖Ti))R′·e · gR′−r′·k′)xB

= (gk′·r′−R′·si·e · gsi·R′·e · gR′−r′·k′)xB


= (gR′)xB = Y R′

B = D (mod p).

In step 4, the verifier B verifies the nominative proxy signature without the proxy agent’s public key.Therefore, though the dishonest original signer A′ generates the nominative proxy signature with arandom number instead of the proxy agent’s private key, the verifier B accepts it as a valid one. And Bbelieves that the proxy agent created the nominative proxy signature. So, A′ can deny the fact that hegenerated nominative proxy signature, and shifted the responsibility for signing to the proxy agent. Theattack scenario in case of dishonest proxy agent is similar to the above scenario. After the dishonest proxyagent G′ receives the proxy information si from the original signer A, he creates the nominative proxysignature like A′ in the above scenario. Hence, Park-Lee’s scheme does not satisfy the non-repudiation.

4 Proposed Nominative Proxy Signature SchemeIn this section, we propose a new nominative proxy signature scheme that solves the weakness of Park-Lee’s scheme.

4.1 Notations

The following notations are used in the description of the scheme.

• A : an original signer, mobile user• G : a proxy agent(a nominator)• B : a verifier(a nominee)• xA : a private key of original signer, xA ∈ Zq

• xG : a private key of proxy agent, xG ∈ Zq

• xB : a private key of verifier, xB ∈ Zq

• yA : a public key of original signer, yA = gxA (mod p)• yG : a public key of proxy agent, yG = gxG (mod p)• yB : a public key of verifier, yB = gxB (mod p)• p : a large prime• q : a prime factor of p − 1• g : a generator for Z∗

p

• H(·) : a strong one-way hash function• M : a message• MW : a warrant which contains the original signer’s ID, the proxy agent’s ID and the delegation

period

4.2 Proposed Scheme

Our scheme provides the non-repudiation, and does not need a secure channel between the original signerand the proxy agent. The scheme is constructed as follows:

[Proxy signature key generation phase]

This phase is executed between the original signer and the proxy agent.

1. (Proxy generation) The original signer A chooses a random number k ∈R Zq \ {0}, and thencomputes K = gk (mod p), e = H(MW ‖K‖T ) and σ = xA · e + k · K (mod q) where MW is awarrant message and T is a timestamp.

2. (Proxy delivery) The original signer A sends (σ,MW , T, K) to the proxy agent G. Because MW

contains the information on the proxy agent, no one obtaining σ can falsely pretend to be the proxyagent. Therefore, this step does not need a secure channel.

3. (Verification and alteration of the proxy) The proxy agent G confirms the validity of(σ,MW , T, K) by checking if the following congruence holds :

gσ = YH(MW ‖K‖T )A · KK (mod p).

If it holds, then the proxy agent G calculates an alternative proxy signature key σP :

σP = σ + xG · K (mod q).


[Nominative proxy signature generation phase]

This phase is executed between the proxy agent and the verifier.

1. (Nominative proxy signing by the proxy signer) The proxy agent G chooses random numbersr, R ∈R Zp and computes α = gR−r (mod p). And then, the proxy agent G computes D and E,and creates a nominative proxy signature SP .

D = Y RB (mod p)

E = H(YB‖α‖D‖M‖MW )SP = r − σP · E (mod q)

The nominative proxy signature on a message M is a (YB , D, α, SP ,K, T,MW ).2. (Nominative proxy signature delivery) The proxy agent G sends (M,YB , D, α, SP ,K, T,MW )

to a verifier B.

[Nominative proxy signature verification phase]

1. (Confirmation of the proxy agent and the original signer) From MW , the verifier B can findthe identities of the original signer and the proxy agent. Then the verifier B gets the public key ofthe original signer and the proxy signer from the CA.

2. (Verification of the nominative proxy signature) The verifier B computes E and b to checkthe received signature.

E = H(YB‖α‖D‖M‖MW )

b = YH(MW ‖K‖T )A · (YG · K)K (mod p)

And then, the verifier B verifies the nominative proxy signature by checking a congruence such that

(gSP · bE · α)xB?= D (mod p).

In this step, only nominee B with xB can check if the signature is valid.

5 The security of the proposed schemeIn this section, we analyze the proposed scheme. Our scheme satisfies the four conditions for the nomi-native proxy signature scheme. First, since the original signer generates the proxy σ with his private keyxA in the proxy generation step and transmits σ to the proxy agent, he can delegate his signing powerto the proxy agent. Second, since the proxy signature key σP includes the proxy agent’s private key xG,only the delegated proxy agent who knows xG can nominate the verifier and create the nominative proxysignature. Third, since the verifier’s private key is required to verify the nominative proxy signature,only the verifier who knows his private key xB can verify the nominative proxy signature. Fourth, byconfirmation protocol [3], only nominee (verifier B) can prove to the third party that the signature isvalid; i.e., (gSP · bE · α)xB = D (mod p) without revealing xB .Furthermore, unlike Park-Lee’s scheme, our scheme has two additional properties: (i) it provides thenon-repudiation and (ii) it does not need the secure channel between the original signer and the proxyagent.Our scheme is a proxy protected proxy signature method [2], because only the proxy agent G who knowsthe private key xG can compute a proxy signature key σP . So, only the proxy agent G can create thenominative proxy signature, and the original signer cannot create it. Moreover, because the nominativeproxy signature contains the warrant information MW , the verifier B can know whether G is a validproxy agent or not. And, since public keys of both the original signer and the proxy agent are usedin the nominative proxy signature verification phase, unlike Park-Lee’s scheme, in our scheme, B cancheck whether the proxy agent’s private key was included or not. Therefore, if once the proxy agentgenerates the nominative proxy signature, he cannot falsely deny later the fact that he generated it. Andthe original signer cannot deny the fact that he designated G as the proxy agent. Therefore our schemesatisfies the non-repudiation.Besides, because the warrant information MW has indicated the identity of the proxy agent and theidentity of the original signer, anyone who obtains the signature parameters in the proxy delivery stepcannot pretend to be the proxy agent. Therefore, our scheme does not need a secure channel betweenthe original signer and the proxy agent.


6 Conclusions

In this paper, we show that Park-Lee’s scheme does not provide the non-repudiation. In Park-Lee’sscheme, since the proxy agent’s public key is not used for verifying the nominative proxy signature, theverifier cannot know who is the actual proxy agent. So, after the dishonest original signer creates the proxysignature, he can deny the fact and shift the responsibility for signing to the proxy agent. Also, we proposea new nominative proxy signature scheme that solves the weakness of Park-Lee’s scheme. Our schemesatisfies four conditions for the nominative proxy signature scheme and decreases the user’s computationalcost by using the proxy agent. Moreover, our scheme provides the non-repudiation property and it doesnot need the secure channel.

References[1] Mavridis, I., and Pangalos, G.: Security Issues in a Mobile Computing Paradigm, in Proc. of CMS’97,

Communications and Multimedia Security, Vol.3, pp.60-76, 1997.

[2] Kim, S., Park, S., and Won, D.: Proxy Signatures, Revisited, in Proc. of ICICS 1997, LNCS 1334,pp.223-232,1997.

[3] Kim, S., Park, S., and Won, D.: Zero-Knowledge Nominative Signatures, in Proc. of Pragocrypt’96,International Conference on the Theory and Applications of Cryptology, pp.380-392, 1996.

[4] Mambo, M., Usuda, K., and Okamoto, E.: Proxy signatures: Delegation of the Power to SignMessages, in IEICE Trans. Fundamentals, vol.E79-A, no.9, pp.1338-1354, 1996.

[5] Mu, Y., and Varadharajan, V.: On the Design of Security Protocols for Mobile Communications,in Proc. of ACISP’96, Australasian Conference on Information Security and Privacy, pp.134-145,1996.

[6] Park, H.-U., and Lee, I.-Y.: A Digital Nominative Proxy Signature Scheme for Mobile Commu-nication, in Proc. of ICICS 2001, International Conference on Information and CommunicationsSecurity, Springer-Verlag, LNCS 2229, pp.451-455, 2001.

[7] Zhang, K.: Threshold Proxy Signature Schemes, in Proc. of ISW’97, Information Security Workshop,pp.191-197, 1997.

[8] Zheng, Y.: An Authentication and Security Protocol for Mobile Computing, in Proc. of IFIP WorldConference on Mobile Communications, pp.249-257, 1996.



True Random Number Generation Using Quantum Mechanical Effects

Luděk Smolík

[email protected]

Physic Department University Siegen, seculab s.r.o.

Siegen, Germany

Abstract We are using the radioactive decay as a source of randomness for the generation of statistically genuine bit streams which can be employed for cryptographic purposes. This method is based on the quantum mechanical unpredictability of the decay moment.

Keywords: True random number generator (TRNG), statistical tests, Monte Carlo simulation, chaotic and quantum mechanic uncertainty.

1 Introduction Making a decision about a perfect randomness is a more philosophical debate than a mathematical task. In order to prove the well known statistical distribution of genuine random numbers in principle an infinite sequence of random information is needed. This is in practice an evidently impossible exercise.

A similar philosophical disputation arises between an ideal and practical experimental environment which should serve perfect random events. In nature we know only a handful of elementary and at the same time applicable phenomena where we can definitely say, no physical law is able to describe and to predict them in the moment. Here, we have to be very careful with the usage of the words “unpredictable natural process”. We find in our world many phenomena which look like a perfect randomness but indeed they aren’t. Well known examples are: stochastic movement of gas atoms inside a volume, fan generated noise which is collected by a microphone, an accidental track of falling leaf, the trajectories of small planetoids or asteroids and many other chaotically generated events. From such events one can create chaotically generated numbers by repeating many experimental trials with quantized output. But the event prediction is here dominantly limited by the huge macroscopic number of parameters (e.g. number of gas atoms) and not by in principle possible calculation. The outcomes from a chaotic system vary considerably and nonlinearly due to small variations of initial experimental conditions which is the inherent essence of chaotic behaviour. Hence it seems to be impossible to find a correlation between the system outputs and the information from initial conditions of chaotic systems. This is of course not an easy provable statement and bases just on our experiences. But on the other hand this implies the following. We have no guarantee that in a chaotic system generated random events will not repeat or will not have another unexpected biases with the experimental apparatus. As long as we are not able to proof the mentioned infinite long output series we can not make a decision about the measured randomness especially in a case of an experimental environment with a spurious random source like a chaotic one. The consequence is the need of a continual monitoring of statistical behaviour of the outcomes and other necessary security steps.

In other words, not every physical effect is useful as an observable in generators for true random numbers. An entirely other class of physical measurements use the quantum mechanical uncertainty. From the theoretical point of view only those observations of single quantum mechanical effects fulfil the requirements as a source of unpredictable randomness. Here we are interested in the transition between the initial and final state of individual elementary particles. Examples for such easily observable interaction processes are the elementary spin of a particle, the radioactive decay, the photon emission or fluorescence and others. Nevertheless, the preparation of those experimental set ups today is the most difficult task in the development of simple, robust, cheap and statistically secure random generators.

An easily accessible random source used in this work are the natural radioactive decaying atomic nuclei. The decay moment of one particular nucleus is not predictable. More than this, there is indeed no fundamental reason for a prediction! Quantum mechanics is a non-causal and non-local theory. For the decay of the nucleus only the future probability can be given, but there is no observable parameter which would signalize the oncoming decay. The quantum mechanical calculation describes the mixture between the initial state (nucleus)


and the final state (decayed products) as a wave–function. Sometimes the nucleus changes causelessly from the initial to the final state, it decays. As long as no detection (interaction) of the decay products happens nothing happens with the wave-function, too. First, when one of the decayed products interacts with other particles (it will be observed) the wave-function breaks down and the final state is irreversibly fixed. This fundamental principle of the quantum mechanics was extensively tested in experiments with other elementary particles and the quantum mechanic theory today describes the experimental results with an incredible high precision.

The majority of commercial and certified TRNG´s use as a source of randomness less fundamental and more rough phenomena like thermal and shot noise (e.g. [1],[2]) of electronic devices (resistors or diodes). In these cases not just one charged particle but a huge macroscopic number of charged particles is responsible for the occurrence of a significant signal. Here the fundamental question arises, where is the boundary between the quantum and the classical domain [3]? Such large systems could appear as unguessable only due to the many unknown parameters and their behaviour could be taken for “true” randomness. Unfortunately, the outwardly stochastic signal evolution in time has still deterministic nature which derives mostly from autocorrelation effects in the amplified noise signal [4].

2 Radioactive Decay as a Source of Random Events

2.1 Experimental Set Up

An appropriate detector technique is necessary for the detection of penetrating decay particles essentially electrons, photons or α-particles. The detector used here is a small proportional wire chamber PWC (Fig.1) filled with the counting gas mixture Argon/CO2. The radioactive source is formed by the incandescent mantle containing radioactive Thorium (Th-232) and its daughter isotopes. This mantle together with the fibre material and the resin build the fibre-glass plate serving as cover of the wire chamber. The primordial Th-232 undergoes an α-decays with 4.083 MeV energy followed by a few β-decays and γ-transitions of the daughters. These decay products enter the selective chamber volume and can ionise the Argon atoms. The rationale behind the use of the incandescent mantle is that the exemption limit for natural radioactive sources like Th-232 is relatively generous, the exemption limit for Th-232 is 10 kBq1 and the dose limit is 6 mSv/yr for the handling of natural sources. Such a low activity source does not require special measures and precaution from the point of view of radiation protection and recycling problems. Although the charged decay products and the photons from the γ-transitions ionise the counter gas in a bit different way, the recorded signals after the gas gain due to the high electric field in the proximity of the sense wire are very similar. The detection of the decay products results in a sudden small decline in the applied high voltage. This electrical pulse is coupled out from the high voltage through a capacitor C, is fed into an operational amplifier A and finally into a discriminator D and the logic and communication module L&C (Fig.1).

Figure 1: Experimental set up of the generator.

1 1 Bq means 1 decay in a second.

A D L&C

CR

HV

PWC

Cathode (radioactive source)

Anode (wires) HV

A D L&C

CR

HV

PWC

Cathode (radioactive source)

Anode (wires) HV


According to the setting of the threshold the discriminator distinguishes between noise and signals and generates a norm TTL output signal for detectable signals (Fig.2). Whenever such a low-high transition occurs, the immediate logical status of the toggle flip-flop is read out. The logical states “0” and “1” of the flip-flop periodically change with a frequency of 15 MHz. The decay rate in the Th-232 radioactive source behaves of course constantly but the rate of registered events depends on the detector efficiency and on the threshold in the discriminator. The registered rate was varied with the applied high voltage between approximately 200 Bq and 2 kBq. Since the time difference between decays or between two registered pulses is not predictable, the output from the toggle flip-flop should be random. Using the described technique one should be able to resolve and to measure really single quantum mechanical effects which behave as perfect random source. Unfortunately, the toggle flip-flop and the consecutive electronics can not be perfect. This part of the apparatus is responsible for the occurrence of systematic effects.

Figure 2: Data acquisition.

2.2 Monte Carlo Simulation

In order to prove the liability to systematic effects an extensive Monte Carlo simulation was done [5]. It simulated a perfect random source with Poisson distributed events in a certain time interval and exponential distributed time distances between the decays. The simulation also included the dead time of the detector and the electronics, the duty cycle of the toggle flip-flop, its frequency stability and small systematic shifts in the operational settings of other essential electronic devices. Several statistical and cryptographic tests were applied to prove whether the output bits can be considered random. The simulated results showed that except for the duty cycle all investigated systematic effects did not change the input randomness by a statistical significant amount. An asymmetric duty cycle of the toggle flip-flop influenced the outputs in an expected manner. Figure 3 shows a schematic drawing of one clock cycle and the corresponding logical status of the toggle flip-flop. The manufacturer specification of the applied fast flip-flop guaranteed stable operation above the threshold of 2 V and below 0,8 V. Due to the typical 1 ns rise and fall time of the clock signal there is an “undefined status” of the flip-flop of around 1% operational time. The second systematic uncertainty derives from the duration and shape of “positive” and “negative” clock periods which don’t need to be a priori perfectly symmetric. Both effects contribute to a small nevertheless always present distortion in efficiency for logical state “1” and “0” from a ideal fifty/fifty case. This distortion disturbs and finally also disables an easy processing from recorded perfect randomness to perfect random output data.

Time

Detector signal after amplification

“0”

“1”

Discriminator signal

Toggle flip-flop

01100111001010010011010010111001Output register

Electronic threshold

Time

Detector signal after amplification

“0”

“1”

Discriminator signal

Toggle flip-flop

01100111001010010011010010111001Output register

Electronic threshold


Figure 3: The cycle of the clock and the corresponding logical levels of the flip-flop, the duration of the cycles are shorted in order to magnify the rise and fall time in the picture.

2.3 Experimental Data and Tests of the Randomness

How can be recognized that a long but finite series of bits is random to a certain confidential level? The reader can test it himself and try to write down perhaps 100, seemingly random digits 0 and 1. The result probably does not survive the elementary statistical tests. The reason is, we are indeed not able to act without control and completely memoryless. We can even manage the equilibrium in the occurrence between “1” and “0” but we will not be able to predict correctly the probability of runs, series with consecutive equal digits. This probability PNi follows a simple relation:

i

i

NiN pP = ,

where Ni is the run length and pi is the probability for occurrence of the logical state either “1” or “0”. As mentioned above, it turned out pi is not perfect ½ but slightly distorted and has major impact on the statistical results.

For test of the randomness there are available a lot of sophisticated and complementary procedures which are often gathered together to so called test-batteries [6]. In this work the Golomb criterions (1st , 2nd and 3rd) and the Poker test for 2, 3 and 4 bits are used and many Gigabits data analysed. The 1st Golomb criterion measures the ratio of frequency of states “0” and “1”. The 2nd Golomb criterion tests the occurrences of already mentioned runs with N identical digits. Series up to N=12 were analysed. In the 3rd Golomb criterion the autocorrelation functions were calculated for different shifts of the series. In this analysis shifts from 1 up to 16 bits were investigated. The Poker tests measure the relative frequency of occurrence for bit pattern. For example the 2 bit poker has the bit pattern: “00”, “01”, “10” and “11”. The expected value for occurrence of perfect random dealt pairs is ¼. For the perfect dealt triplets we expect 1/8 and 1/16 for the quadruples.

The significance of the difference between the observation and the theoretical prediction was calculated by the χ2-test. In the first step the bulk of data were divided in smaller subsets of 4 kB length. For each subset the χ2-value of a particular test was computed. For illustration, the χ2 for 4 bit Poker is calculated by the following formula:

( )∑=

−=

16

1

22

64/64/

i

ij n

nnχ

Here is n the length of the bit sequence, in this case 4 kB (4096 bits). The index i runs over the 16 possible bit pattern, ni is the total number of events with a bit pattern i which were found in the investigated subset j. The expected value of ni is equal 4/116/64/ ⋅= nn . Collecting these χ2-values of each test in a particular histogram we obtain six distributions which are each again χ2 distributed and can be fitted by an one-parameter function. The parameter is the mean value of the distribution. When the measurements are statistically distributed the mean value is in the same time equal to the number of degree of freedom. In Table 1 the results from the six tests are collected. The quality of the test is given by χ2-values in the last column.

Time

V

133 ns

2V

0.8V

„0“

„1“Undefined area

Time

V

133 ns

2V

0.8V

„0“

„1“Undefined area


Test Criterion Mean Value (Experiment) Degree of Freedom (Theory) χ2

1st Golomb 2,0 1 59

2nd Golomb 11,3 11 2,4

3rd Golomb 16,1 16 0,95

2-Bit Poker 4,2 3 59

3-Bit Poker 8,1 7 30

4-Bit Poker 16,2 15 18

Table 1: The results of the tests.

The results seem to be far away from perfection but they are fully understood. The discrepancy causes the already mentioned duty cycle of the toggle flip-flop which is not perfectly equal to 1. The cycle was adjusted by hand and eye on a digital oscilloscope in the best achievable way. The 1st Golomb criterion does it better, the result shows an about 0,28% (± 0,000001) higher chance for one of the logical levels. This corresponds to an overall difference of 0,4 ns between the duration of both clock half-waves. A later planned active monitoring of the duty cycle will allow an accuracy of up to 1 ps (0.001% shift in duty cycle) and an appropriate improvement in the statistic. Nevertheless, the measured numbers agree well with the prediction of Monte Carlo studies. For example the n-bit Poker tests can be easily simulated and explained with the probabilities for p1 = 0.5028 and p0 = 0.4972 obtained in the 1st Golomb test. For a better readable summary only the χ2 results with the theoretical prediction for the probabilities p1 = p0 = ½ were given in Table 1. Because of the low sensitivity of the 3rd and 2nd Golomb test to the moderate shifts of probabilities p1 and p0 the fitted χ2 are near by the expected 1. Of course, the input unbalance of measured numbers of “1” and “0” can be easily corrected for example by the “van Neumann corrector”2, but this was not the aim of the presented work.

3 Conclusion The general problems around the truly randomness are well known to the involved experts. With the growing understanding of the physical theory the concept of “coloured” bits has been established in order to distinguish the ideal random bits. Due to the always present systematic effects in the apparatus such perfect randomness is in practice indeed a hardly achievable task. For this reason the certification criteria prescribe the usage of cryptographic (deterministic) treatment on the original random numbers in order to cancel eventual systematic biases. This additional pragmatic step is called cryptographic post-processing and is used in all today’s TRNG’s. Especially, whenever huge rates of random numbers are generated by the TRNG (a few hundreds kbits/s up to the range of Mbit/s), there is always implemented a deterministic post-processing operation in the generator. At the first look this seems to be a little cheating but indeed the post-processing may not influence the outputting entropy significantly.

In this work a relatively “slow” source of randomness was used in order to study the systematic during the detection of perfect natural randomness and during the acquisition to the usable signals. The measuring apparatus was simulated by the Monte Carlo technique. The results agree well with the simulation. It turns out that by far the biggest systematic effect derives from the asymmetric duty cycle which of course can be improved but scarcely eliminated completely.

2 The input bit-pairs (0,1) and (1,0) are converted into the output bits 1 and into 0 respectively. The input bit-pairs (0,0) and (1,1) give no output. The length of the input bit sequence is reduced by a factor 4 approximately.


References [1] Jun, B.; Kocher, P.: The Intel Random Number Generator, Cryptography Research, Inc., April 22, 1999.

[2] Richter, M.: Ein Zufallszahlengenerator zur Erzeugung von quasi-idealen Zufallszahlen aus elektronischem Rauschen, www.puran2.de, January 8, 2000.

[3] Bell, J.S.: Speakable and Unspeakable in Quantum Mechanics, Cambridge University Press, New York, 1987, p. 29.

[4] Gude, M.: Concept for a High Performance Random Number Generator Based on Physical Random Phenomena, FREQUENZ Volume 39, Germany, 1985.

[5] Grupen, C.; Maurer, I.; Schmidt, D.; Smolik, L.: Generating Cryptographic Keys by radioactive Decays, Proceedings of the 3rd International Symposium on Nuclear and Related Techniques, Havana, Cuba, 2001.

[6] Rukhin, A. et al.: A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Application, NIST Special Publication 800-22, National Institute of Standard and Technology, Gaithersburg, May 15, 2001.

http://www.puran2.de/


A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Application

Jiří Sobotík and Václav Plátěnka

[email protected]

Department of Special Communication Systems Military Academy in Brno

Brno, Czech Republic and

The Military Technical Institute of Electronic Prague, Czech Republic

Abstract This paper discusses some aspects of testing random and pseudorandom number generators. A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications (NIST Special Publication) is presented. This paper also demonstrates the software implementation of the test suite with output protocols and presents experiences from testing some random and pseudorandom generators.

Keywords: statistical tests, cryptology.

1 Introduction Random and pseudorandom generators play an important role in many cryptographic applications. For example, cryptographic keys must be generated in a randomly and cryptographic protocols require random or pseudorandom input.

Cryptographic applications lay great emphasis on the statistical properties of random and pseudorandom number generators. The sequences generated by these generators must be indistinguishable from the sequences generated by “true random generators”. Any non-randomness in the generated sequences rapidly degrades the security of cryptographic systems as a whole. When a deviation from randomness occurs, a cryptanalytic attack can usually be succeeded. The National Institute of Standards and Technology has developed a statistical test suite that is suitable for testing the generators to be used in cryptographic applications. This paper briefly describes the test suite. The software implementation of this test suite in environment MATHCAD 2001 is also presented with some examples of testing pseudorandom generators.

2 Statistical Test Suite The NIST Test Suite consists of 16 statistical tests that were developed to test the randomness of binary sequences. These tests focus on a variety of different types of non-randomness that could exist in sequences. This test suite consists of the following:

1. The Frequency (Monobit) Test

2. Frequency Test within a Block

3. The Runs Tests

4. Test for the Longest-Run-of-Ones in a Block

5. The Binary Matrix Rank Test

6. The Discrete Fourier Transform (Spectral) Test

7. The Non-overlapping Template Matching Test

8. The Overlapping Template Matching Test

9. Maurer’s “Universal Statistical” Test

10. The Lempel-Ziv Compression Test


11. The linear Complexity Test

12. The Serial Test

13. The approximate Entropy Test

14. The Cumulative Sums (Cusums) Test

15. The Random Excursion Test

16. The Random Excursion Variant Test

Some tests consist of the sets of subtests.

2.1 The General Structure of the Statistical Test

Each test is based on a calculated test statistic value, which is a function of the testing sequence. The test statistic value is use to calculate a Pvalue that summarizes the strength of the evidence against the hypothesis about perfect randomness of the number generator. For each test from test suite, the

Pvalue is the probability that the perfect random number generator would have produced a sequence less random than the sequence that was tested, given the kind of non-randomness assessed by the test.

If a Pvalue for a test is determined to be equal to one, then the sequence appears to have perfect randomness. A Pvalue of zero indicates that the sequence appears to be completely non-random. A significant level α can be chosen for the tests. The parameter α denotes the probability of test rejecting a testing generator that is in fact perfectly random. If Pvalue ≥ α then the sequence appears to be random to significant level α. If Pvalue < α the sequence appears to be non-random. The typical values for α are chosen in the range [0.001 – 0.01].

Example: The Frequency (Monobit) Test. Let (x0, x1, …, xn-1) be a binary sequence of length n. The statistic

is ( ) ( )∑−

=− −⋅⋅=

1

0110 121,...,,

n

iinn x

nxxxS (summational statistic). By means of asymptotical analysis

it can be shown that if n goes to infinity then

=

2n

valueSerfcP , where ∫

∞ −=x

y dyexerfc22)(

π is

so called error function. The decision rule of Frequency Test is: If 01.02

≥

nSerfc then the sequence

(x0, x1, …, xn-1) is accepted as random at a significant level 0.01. Otherwise it is concluded that the sequence is non-random. It is recommended that each sequence to be tested consists of a minimum of 100 bits (n ≥ 100).

The statistic in the test suite is different from case to case and depends on which non-randomness was aimed to be detected. In cryptographic application it is better to consider the term statistic in a broader sense. Generally, the statistic is mapping from the set of all sequences of length n to the real number. From this point of view, the statistic of each test in the test suite is mapping {0,1}n →[0,1] that assigns to every binary sequence of length n the real number – Pvalue. Consequently, the image of statistics is uniform for each test regardless of which type of non-randomness is searched.

2.2 Outline of tests

The following brief description of the tests of the test suite is taken from [1].

Frequency (Monobit) Test is focused to evaluate the proportion of zeros and ones for the entire sequences. The purpose of this test is to determine whether the number of ones and zeros in a sequence are approximately the same as would be expected for a truly random sequence. The test assesses the closeness of the fraction of ones to 0.5, that is, the number of ones and zeroes in the sequence should be about the same.

Frequency Test within a Block is focused to evaluate the proportion of ones within M–bit blocks. The purpose of this test is to determine whether the frequency of ones in an M-bit block is approximately M/2 as would be expected under an assumption of randomness. For bock size M=1, this test degenerates to the Frequency (Monobit) Test.


Runs Test measures the total number of runs in the sequence, where a run is an uninterrupted sequence of identical bits. A run of length k consists of exactly k identical bits and is bounded before and after with a bit of opposite value. The purpose of the runs test is to determine whether the number of runs of ones and zeros of various lengths is as expected for a random sequence. In particular, this test determines whether the oscillation between such zeros and ones is too fast or too slow.

Test for the Longest Run of Ones in a Block assesses the longest run of ones within M-bit blocks. The purpose of this test is to determine whether the length of the longest run of ones within the tested sequence is consistent with the length of the longest run of ones that would be expected in a random sequence. Note that an irregularity in the expected length of the longest run of ones implies that there is also an irregularity in the expected length of the longest run of zeroes. Therefore, only a test for ones is necessary.

Binary Matrix Rank Test is focussed on evaluates the rank of disjoint sub-matrices of the entire sequence. The purpose of this test is to check for linear dependence among fixed length substrings of the original sequence.

Discrete Fourier Transform (Spectral) Test detects periodic features in the tested sequence that would indicate a deviation from the assumption of randomness. The intention is to detect whether the number of peaks exceeding the 95% threshold is significantly different 5%.

Non-overlapping Template Matching Test detects generators that produce too many occurrences of a given non-periodic (aperiodic) pattern. For this test and for The Overlapping Template Matching Test an m-bit window is used to search for a specific m-bit pattern. If the pattern is not found, the window slides one bit position. If the pattern is found, the window is reset to the bit after the found pattern, and the search resumes.

Overlapping Template Matching Test counts the number of occurrences of pre-specified target strings. Both this test and the Non-overlapping Template Matching Test use the m-bit window to search for a specific m-bit pattern. If the pattern is not found, the window slides one bit position. The difference between this test and Non-overlapping Template Matching Test is that when the pattern is found the window slides only one bit before resuming the search.

Maurer’s „Universal Statistical“ Test counts the number of bits between matching pattern. This number is close related to the entropy of a number generator.

Lempel-Ziv Compression Test determines how far the tested sequence can be compressed. The sequence is considered to be non-random if it can be significantly compressed.

Linear Complexity Test evaluates the length of a linear feedback register (LFSR). The purpose of this test is to determine whether or not the sequence is complex enough to be considered random. Random sequences can be characterized by longer LFSRs. An LFSR that is to short implies non-randomness.

Serial Test determines whether the number of occurrences of the 2m m-bit overlapping patterns is approximately the same as would be expected for a random sequence. Random sequences have uniformity; that is every m-bit pattern has the same chance of appearing as other m-bit pattern. For m = 1, the Serial test is equivalent to the Frequency Test.

Approximate Entropy Test as with the Serial test focused to the frequency of all possible overlapping m-bit patterns across entire sequence. The purpose of the test is to compare the frequency of overlapping blocks of two consecutive / adjacent lengths (m and m+1) against the expected result for a random sequence.

Cumulative Sums (Cusum) Test counts the maximal excursion (from zero) of the random walk defined by the cumulative sum of adjusted (-1,+1) digits in the sequence. The purpose of the test is to determine whether the cumulative sum of the partial sequences occurring in the tested sequence is to large or too small relative to the expected behaviour of the cumulative sum for random sequences, the excursion of the random walk should be near zero. For certain types of non-random sequences, the excursion of this random walk from zero will be large.

Random Excursion Test counts the number of cycles having exactly K visit in a cumulative sum random walk. The cumulative sum random walk is derived from partial sums after the (0, 1) sequence is transferred to the appropriate (-1,+1) sequence. A cycle of random walk consists of a sequence of steps of unit length taken at random that begin at and return to the origin. The purpose of this test is to determine if the number of visits to a particular state within a cycle deviates from what one would expect for a random sequence. This test is actually a series of eight tests (and conclusion), one test and conclusion for each of the states : -4, -3, -2, -1 and +1, +2, +3, +4.


Random Excursion Variant Test counts the total number of times that a particular state is visited (i.e., occurs) in a cumulative sum random walk. The purpose of this test is to detect deviations from the expected number of visits to various states in the random walk. This test is actually a series of eighteen tests (and conclusions), one test and conclusion for each of the states -9, -8, …, -1, and +1, +2, …, +9.

3 Software Implementation of Test Suite In publication [1], each test from the test suite is described in detail and an elementary example is done. The verification examples of tests of known sequences (binary expansion of e number, π number, 3,2 ) are included so that it is not difficult to program the all tests in mathematically-oriented programming languages; e.g. MATLAB, MATHCAD or MATEMATICA.

The Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications is written in MATHAD programming language. Code in MATHCAD language is very analogous to mathematical notation. There are many built-in functions with faster computation features and vector-oriented operators and functions. Figure 1 shows the three statistical tests in MATHCAD code. The others tests are not much more complex. Note that X is a binary input sequence and the output of each test is a Pvalue (last row in code).

Figure 1: Example of code for the first three statistical tests in MATHCAD language.

There is one disadvantage of implementation of test suite in higher mathematically-oriented languages. These languages usually operate with 32-bit words so that one bit of tested sequence uses 32 bits and mathematical operations cannot be performed quickly, especially in the Binary Matrix Rank Test and Linear Complexity Test. In these cases the computing time is unacceptable. For faster computation, critical routines of these two tests were programmed in C++ language and built-in as special function to MATHCAD library. The latest version of the test suite in MATHCAD takes approximately 40 seconds to perform the all sixteen test on one megabits sequence. It is approximately three or four times longer than the time taken by pure C++ version of test suite. It is obvious that for routine testing it is effective to use test suite in C++ programming language. On the other hand, for the purpose of analysing of test results in detail, operative manipulation of the sequences and visualizing the results, it is better to use higher programming languages. The Figure 2 shows the Test protocol that is made by using MATHAD in conjunction with Exel.

FreqTest X( ) erfclength X( ) 2 mean X( )⋅ 1−⋅

2

:= FreqBlockTest X M,( ) N floorlength X( )

M

←

πi1M

0

M 1−

j

X i M⋅ j+∑=

⋅←

i 0 N 1−..∈for

chi

0

N 1−

i

πi12

−

2

∑=

←

1 pgamma 2 M⋅ chi⋅N2

,

−

:=

RunsTest X( ) n length X( )← p mean X( )←( )

0.0return( ) p 0.5−2

n≥if

a submatrix X 0, n 2−, 0, 0,( )←

b submatrix X 1, n 1−, 0, 0,( )←

Vobs 1 a b≠( )→( )∑+←

erfcVobs 2 n⋅ p⋅ 1 p−( )⋅−

2 2 n⋅⋅ p⋅ 1 p−( )⋅

:=


10000000,01

Test No. parametr/ P value Acceptationvariant/state

1 0,953749 YES2 100 0,619340 YES3 0,561917 YES4 0,769568 YES5 32 0,306156 YES6 0,443864 YES7 000000001 0,078790 YES8 0,110434 YES9 0,282568 YES10 0,000584 NO11 500 0,826335 YES12 5 0,225783 YES

0,057499 YES13 5 0,361688 YES14 forward 0,669886 YES

backward 0,724265 YES15 -4 0,573306 YES

-3 0,197996 YES-2 0,164011 YES-1 0,007779 NO1 0,786868 YES2 0,440912 YES3 0,797854 YES4 0,778186 YES

16 -9 0,858946 YES-8 0,794755 YES-7 0,576249 YES-6 0,493417 YES-5 0,633873 YES-4 0,917283 YES-3 0,934708 YES-2 0,816012 YES-1 0,826009 YES1 0,137861 YES2 0,200642 YES3 0,441254 YES4 0,939291 YES5 0,505683 YES6 0,445935 YES7 0,512207 YES8 0,538635 YES

Frequency Test within a BlockRun Test

The Culmulative Sum Test

Test for the Longest-Run-of-Ones in a BlockThe Binary Matrix Rank Test

The Approximate Entropy Test

The Discrete Fourier Transform Test

The Serial Test

Random Excursion Test

Random Excursion Variant Test

Test name:

The Non-Overlapping Template Matching TestThe Overlapping Template Matching Test

The Linear Complexity Test

The Frequency Test

The Lempel - Ziv Compression TestMauerer' "Universal Statistical" Test

The Statistical Test Suite Protocol

File length:

Description of generator (sequence): The binary expansion of Euler number. e = 10.1011011111100001010100010110001010001010111…

Significance level:

C:\Documents and Settings\platenka\Dokumenty\Testování Sobotík\Testování pomocí NIST\e.bitFile name:

Figure 2: The tests protocol.


4 Some Experiences The tests of the random number generator from the NIST statistical test suite are written for files of about 106 bits in length. The output of each test is a Pvalue that is a measure of the randomness of generator. If the Pvalue is less than significant level α then the hypothesis about randomness of the generator is rejected. In these cases it is necessary to consider the significant level α because a perfect random number generator has probability α to generate a bad sequence. Further tests must be conduced to verify that the rejection of hypothesis was only due to randomness or if there is some significant non-randomness in the generator.

The process of further testing follows. First we generate one file of length 109 bits with the tested generator. We split this file up into 1,000 separate files of length 106 bits and then we apply the test to each sequence separately. We obtain the list of 1,000 outputs of Pvalue. Now we consider the Pvalue as a random variable on unit interval with uniform distribution. This can be visually illustrated using a histogram, see Table 1 and Figure 3.

sub-interval number

0.0-0.1 1

0.1-0.2 2

0.2-0.33

0.3-0.44

0.4-0.55

0.5-0.66

0.6-0.77

0.7-0.8 8

0.8-0.9 9

0.9-1.010

frequency 103 107 89 97 95 97 93 95 113 111

Table 1: Histogram of Pvalues.

0

20

40

60

80

100

120

1 2 3 4 5 6 7 8 9 10

Figure 3: Histogram of Pvalues.

Uniformity of Pvaluess is tested by the Goodness-of-Fit Distributional Test. This is accomplished by computing

the chi-square value( )

∑=

−=

10

1

2

2

10

10i

i

s

sFχ , where Fi is the frequency of Pvalue in sub-interval i, and s is the

sample size (s = 1,000 in our case). A new PvalueT is obtained by formula PvalueT = igamc(9/2,χ2/2), where igamc is an incomplete gamma function. The decision rule is: If PvalueT ≥ 0.0001, then the generator can be considered to be random relative to the given test. Otherwise, the generator is non-random.

The statistical test suite was applied to examine the next four pseudorandom number generators:

• a built-in generator in MATHCAD 2001

• a built-in generator in MATLAB 6

• the block cipher VINO in stream mode

• the data obtained from Georgia Marsaglia’s Random Number CDROM on http://stst.fsu.edu/pub/diehard/cdrom/

Each generated sequence with a length of 109 was split into 1,000 sequences of 106 bits in length and the test suite was applied. Sixteen PvalueT were obtained with following results:

http://stst.fsu.edu/pub/diehard/cdrom/


No file from the list above passes the Lempel-Ziv Compression Test, the Random Excursion Test and the Random Excursion Variant Test. The files passed all remaining tests with PvalueT ≥ 0.0001.

5 Conclusion The Statistical Tests Suite for Random and Pseudorandom Number Generators for Cryptographic Applications is a powerful instrument for practical verification of generators and algorithms in cryptography. It should be applied in the first steps of an evaluation process of cryptographic primitives. It cannot fully substitute a detailed cryptanalysis, but if the generator or other primitives do not pass the test suite then they are not suitable for cryptographic application. It is possible and not so difficult to implement the test suite in higher mathematically-oriented language. This gives rise to the additional benefits of detailed analysis of sequences with other tests, operative manipulation of sequences, visualization of results and interconnection with other applications.

References [1] Andrew R., at al: The Statistical Tests Suite for Random and Pseudorandom Number Generators for

Cryptographic application. NIST Special Publication 800-22. May 2001.


Military Information Operations

Ryszard Szpyra

[email protected]

Air Force Faculty National Defence University

Warsaw, Poland

Abstract This paper contains results of a few years’ study and research done by author. Many models of information warfare and information operations are too much stick to doctrine regulations. This factor is a cause of some weaknesses of these models. Study of a nature of information operations and composition of existing information operations models clearly shows that information operations phenomenon has many dimensions, for example: personal, corporational, national. These considerations focus on national information operations, and more precisely on information operations waged by states. This subject links with two areas: external relations among nations and country interior. Information operations are form of relations among nations located in information sphere. These relations may have positive and negative form of cooperation. As a result information collaboration and information warfare are important parts of information operations. From this perspective country interior is internal processes supply. This supply may be located in matter, energy and information sphere. My point of interest is information sphere. Therefore focus is placed on information supply, which is a basis for decision processes. This supply requires collection of information what is function of reconnaissance and information distribution. This way, another component of information operations such as: reconnaissance and information distribution have been identified.

Applying decomposition (atomization) of doctrinal information operations components and making a new design, more rational model of information operations has been done. Having on mind the nature of information operations I put more attention on military area of these operations. There are two basic components of information warfare: information attack and information defence. Information attack includes: digital attack; electronic attack; physical attack; PSYOPS, deception. Information defence is composed of: reconnaissance with surveillance prevention and information attack prevention. This paper describes also some of techniques of information warfare and makes some predictions for further development of information warfare.

1 Introduction The role of information in emerging new civilisation – information society is well known. It became the main value and factor of progress. This phenomenon is effect of new information technologies development. It brings fast civilisation changes not only in developed countries but also in less developed world. Along with it, dependency from information creates significant vulnerability or even danger. Since reliance from information communication systems is so general, destructive action on it can have widespread effects for any state or its elements. It is also valid for military therefore, warfare in cyberspace became subject of many researches and writings. Practical dimension of it are American military doctrines – doctrines of information operations and information warfare. Despite fact that doctrines are accumulation of experience and knowledge their contents contain many weaknesses. Doctrinal concepts of information operations or information warfare evolve like human brain. Other new ones covered the first layers. In military thinking existing concepts of e.g. electronic countermeasures and later electronic warfare were covered by information warfare and information operations conceptions. Electronic warfare however still exists as a part of offensive information warfare whereas electronic warfare contains offensive as well as defensive measures. It means that e.g. only part of electronic warfare should belong to offensive information warfare. These types of weaknesses were inspiration to search for more rational model of information operations. It was natural then that military officer focuses on military information operations however basic considerations were related to state level operations.

2 Information Operations Activity on the international arena is very important for existence of any state. All this activity undertaken by state components constitutes state operations. Military operations are one of the subcategories of those state

mailto:[email protected]


operations. Any of the state operations are focused on the support of the state interests. This is a basic factor, which shapes any form of state operations. State activity like any activity may have form of positive cooperation (collaboration) or negative cooperation (warfare). In reality state activity contains positive and negative forms of cooperation at the same time.

With a basic category of existence – matter, energy and information correspond adequately to their spheres: matter, energy and information areas of activity. From the social point of view any of these activities may be positive or negative cooperation (collaboration or warfare). Considering that, state operations are placed in material energy and information spheres in addition to each of them may contain a spectrum of positive or negative form of activity (fig. 1). Apart from exterior also interior activity is very important. Internal state activity requires material, energy and information supply. Information nature of emerging new civilization makes information supply more important than in the past.

Exterior and internal state activity in the information sphere is a basic point of interest for these considerations (fig. 1).

Figure 1: Positive and negative forms as well as exterior and internal areas of state activity.

The essence of activity in the information sphere is information communication. This communication is commonly present in social processes. Information science plays very important role for information communication exploration. Mathematics-physics approach of information theory is well known. It focuses only on channel of information transfer. More convenient for this consideration is social approach to the information. It places attention not only on channel of information transfer but also on the whole unit of act of communication: source, channel and recipient (fig. 2).


Figure 2: Social approach to information communication (Source: B. i A.Vickery, Information Science in theory and practice, London 1987, pp. 13).

Dynamic development in computer technology and progress made in communication area, which took place in the second half of the 20th century caused changes in information communication process. Each element of this process extended. In reality this model is more complex. Source, information transfer channel and recipient (user) include sub elements. Each of them is influence sensitive (fig. 3).

Figure 3: Places of possible influence on information or information communication systems.

State operations contain any form of its activity. Any state activity in the information sphere is called information operations. Consequently, state information operations will be understood as organized state activity supporting national interests that focuses on the external and the internal information communication systems and information flowing by these systems (fig. 4).


Figure 4: State operations and state information operations.

Consequently: military information operations will be understood as organized military state activity supporting national interests focused on the external and the internal information communication systems and information flowing by these systems (fig. 5).

Information operations are composed with three main components that are: information collaboration, information warfare and information support. First two components are placed in the external area of state activity whereas information support is located in the internal area of this activity.

Figure 5: Information operations and military information operations.


Information collaboration encompasses activity followed by the “civil” rules of cooperation. It is not too much complicated but still very important part of information operations. Presently, one of the main purposes of military activity is war prevention. Therefore information collaboration should be a significant part of this effort.

Information warfare is negative form of information cooperation. Since the essence of warfare is violence and a target of this warfare are information communications systems one may assume that: Information warfare is organized forcible state activity supporting national interests, conducted for destruction or modification of adversary information or information communication systems and activity defending own information and information systems.

Third component of information operations is information support. Activity in this area focuses on improving decision maker’s capability of observation, orientation, decision and action (OODA Loop) faster and more effective than adversary’s. Main purpose of this activity is situational awareness. Information support relays on surveillance, reconnaissance and information distribution.

3 Military Information Warfare Part of state information warfare is military information warfare therefore: military information warfare is organized by military, forcible state activity supporting national interests conducted for destruction or modification of adversary information or information communication systems and activity defending own information and information systems.

Military information warfare comprise information attack and information defence.

3.1 Military Information Attack

Military information attack is organized military, forcible state activity supporting national interests conducted for destruction or modification of adversary information or information communication systems.

Military information defence is organized military activity lead up to protection of own information and information communication systems from adversary reconnaissance, surveillance and information attack actions.

Information attack that can directly affect adversary information or information communication systems include:

• Digital Attack

• Electronic Attack

• Physical Attack

• Psychological Attack (PSYOPS)

• Military Deception

3.1.1 Digital Attack

Digital attack is malicious computer code covertly introduced into one or more specific computer systems or networks, by an attacker to meet desirable objectives. Unlike other types of malicious codes, digital attack code is a tool, one of many weapons an information warrior may use. Digital attack may take form of a virus, worm, logic bomb, time bomb, trojan horse, or some combination, depending on its function, but it differs from the “hacker” variety of these insofar as it targets a specific system (or network of systems), for a specific objective, in a manner that is predictable to the attacker. Within this definition, the attacker could be a military or national organization, a terrorist organization, a multi-national or private corporation, or even an individual with the knowledge and means to produce and install such code.

An attacker using digital attack seeks to affect the targeted system in one or more of the following ways:

• Denial – deny the intended target the use of the system, its data, or the information it provides. This can be done using malicious code that causes hardware failures or the destruction of programs and data.

• Degradation – degrade the targeted system to the point where it cannot effectively perform its mission.


• Deception – deceive the target system into generating false information or into believing that erroneous data is actually accurate.

• Exploitation – provide a means by which information on the target system can be transmitted back to the attacker.

3.1.2 Electronic Attack

Electronic attack is any military action involving the use of electro-magnetic energy to attack personnel, facilities, or equipment with the intent of degrading, neutralizing, or destroying enemy combat capability. Modern electronic attack consists of laser attack, electromagnetic attack and particle energy attack. With regard to effect of electronic attack one may find two areas: time limited disturbance and permanent or near permanent destruction of attacked targets. The first is tide with disruption. The purpose of electronic disruption is paralysis of adversary electronic equipment what leads to significant disturbance of information communication processes. This effect disappears when electronic disruption ends. Electronic destruction is aimed on permanent damage. This result lasts after the end of that form of electronic attack. Modern combat capability in the area of electronic attack allows for achieving disruption as well as destruction. These desired effects may be achieved by exploitation of energy of optical waves and other electromagnetic waves. Particle energy (electron, proton, neutron, etc.) is still new in non-nuclear warfare but possible in military application.

3.1.3 Physical Attack

Physical attack refers to the use of physical weapons against elements of information communication systems. The objective is to affect information or information systems by using destructive power of a physical weapon.

Coupling precision-guided munitions and advanced delivery platforms, employing cruise-type missiles or infiltrating a small strike team to neutralize a communications node are key examples that require precision to accurately attack an adversary information system.

3.1.4 Psychological Attack

Psychological attack known, as Psychological Operations are planned actions seeking to induce, influence, or reinforce the perceptions, attitudes, reasoning, and behaviour of foreign leaders, groups, and organizations in a manner favourable to military objectives. Psychological attack supports these objectives through the calculated use of air, space, and information power with emphasis on psychological effects-based targeting. Examples of this activity include promises, threats of force or retaliation, conditions of surrender, safe passage for deserters, or support resistance groups.

At the strategic level, psychological attack may take form of political or diplomatic positions, announcements, or communiqués. At the operational and tactical levels this attack planning may include the distribution of leaflets, the use of loudspeakers, and other means of transmitting information that encourage adversary forces to defect, desert, flee, or surrender and to promote fear or dissension in adversary ranks. Persistent psychological attacks can accelerate the degradation of morale and further encouraging desertion.

3.1.5 Military Deception

Military deception misleads adversaries, causing them to act in accordance with the originator’s objectives. Deception operations span all levels of war and can include, at the same time, both offensive and defensive components. Deception can distract our adversaries’ attention from legitimate friendly military operations and can confuse and dissipate adversary forces. However, effective deception efforts require a deep appreciation of an adversary’s cultural, political, and doctrinal perceptions and decision-making processes. Planners exploit these factors for successful deception operations. Deception is another force multiplier and can enhance the effects of other information warfare activities.

3.2 Military Information Defence

Military information defence focuses on reconnaissance, surveillance and information attack prevention. This led us to two areas of interest: reconnaissance with surveillance prevention and information attack prevention.


As far as the first one is concerned, the purpose of reconnaissance and surveillance activity is intelligence. It is easy to find two areas of reconnaissance and surveillance prevention (fig. 6). One is focused on information and information communication systems and another on adversary’s reconnaissance and surveillance activity. As a result defensive activity is concentrated on information and information communication systems protection and counteraction to adversary’s reconnaissance and surveillance.

This protection comprises wide variety of ventures. Theirs protective nature relates to adversary’s activity as well as other factors like environment influence or personnel misbehaviour. But more dangerous is adversary’s activity – reconnaissance and surveillance actions. Protection against it may have form of technological and electronic protection. Operations security and deception are also means of this protection.

Counteraction to adversary’s reconnaissance and surveillance depend on deterrence and neutralization. Deterrence is aimed on discourage an adversary from intelligence activity whereas essence of neutralization is similar to air defence one. Neutralization takes place when deterrence fails. All measures of neutralization are directed to nullify or reduce the effectiveness of adversary’s reconnaissance and surveillance actions.

Figure 6: Reconnaissance with surveillance prevention.

Information attack is aimed on destruction or modification of adversary information or information communication systems. Similar to reconnaissance with surveillance prevention, information attack prevention is concentrated on information and information communication systems protection and counteraction to adversary’s information attack (fig. 7).

Protection of information and information communication systems base on wide spectrum of ventures. Technological and electronic protection as well as operations security and deception belong to the most important of them.

Counteraction to adversary’s information attack, in the same way like counteraction to reconnaissance and surveillance, contains deterrence and neutralization. Essence of deterrence is to discourage adversary form information attacks. When deterrence fails neutralization takes place. All measures of neutralization are directed to nullify or reduce the effectiveness of adversary’s information attack.


Figure 7: Information attack prevention.

4 Information Support Information support plays very important role in the modern world. Its main function is to supply decision makers with information. Adequate for military considerations is military information support. Military dimension of information support is intelligence, reconnaissance and surveillance (ISR). Information about own system status is also very important, however information about an adversary plays vital role in military decision process therefore focus is placed on ISR.

There are many forms of ISR. Their classification may be done in many ways. Taking type of sensor (human or machine) as main criterion we will have human and technical intelligence.

Human intelligence is the oldest type of intelligence. Information in this case is gained by conspiracy action like espionage, patrolling or special operations.

Technical intelligence is carried out by systems using technical sensors. They can detect any phenomena useful for intelligence purposes. These may be natural emissions of watched objects or environment reaction on that objects presence. Those kinds of sensors can emit emission by itself and register reflected by objects reemissions (active radiolocation, active night vision). Very important role in technical intelligence plays sensing on electromagnetic spectrum therefore it is useful to recognize two separate areas: electromagnetic and extra electromagnetic. Inside electromagnetic area one can find radio, radiolocation and optoelectronic intelligence. Extra electromagnetic area of technical intelligence is filled up with sensing on no electromagnetic type phenomena. It can be detection of magnetic or gravity fields, particles emission, acoustic waves, chemicals etc. This type of intelligence has big potential for the future development.

5 Further Development Of Information Warfare Theory Warfare in information sphere, which is sometimes named – cyberspace, is similar to air warfare therefore air war theory is good inspiration for cyber warfare study. One of the most important requirements in air warfare is air superiority. Also main goal of many actions undertaken in cyberspace are directed on information superiority. All efforts undertaken to gain information superiority consists of offensive and defensive information warfare. Offensive information warfare contains actions leading to destruction or neutralization of the offensive potential of adversary information warfare system whereas defensive are focused on protection of own information and information communications systems.


When information superiority is achieved it may be possible to obtain political goals by strategic information attack. This type of attack is not just military but whole country endeavour. Military information attack usually is a part of state strategic information attack. The subject for this kind of attack is basically adversary state information infrastructure. Strategic information warfare may lead up to accomplishment of political or strategic military goals. Since the target of that attack is whole adversary state, John Warden`s analysis model is useful inspiration (fig. 8). Expected direct effect of this action is paralysis or rising for an adversary cost.

Figure 8: Strategic information attack model.

6 Conclusions Military information operations are one of the tools of state international policy. They are the part of state information operations. First component of information operations – information collaboration is applicable when conflict of state interests does not exist. Information warfare – second component of information operations – is negative form of states cooperation in the information sphere. Information warfare consists of information attack and information defence. Military information warfare is that part of information warfare which is executed by military organization. Next component of information operations is information support. Main function of it is information supply of own decision processes. Recent dependency from information and information communication systems creates strategic vulnerability. It could be explored by strategic information attack. This kind of attack can be conducted by state power and may lead to political goals achievement. Military can be one from many executors of that kind of warfare.


References [1] Bosh J. M. J., Luiijf H. A. M., Mollema A. R.: Information Operations, NL Arms. Netherlands Annual

Review of Mlitary Studies 1999, Breda, 1999.

[2] Campen A. D. Dearth D. H. Goodden R. T., Cyberwar: Security, Strategy, and Conflct in the Information Age, Fairfax, 1996.

[3] Cyber-attacks, www.infowar.com/mil_c4i/00/mil_c4i_120100a_j.shtml

[4] Downs L. G. Jr., Digital Data Warfare: Using Malicious Computer Code as a Weapon. A Research Report Submitted to the Faculty in Fulfillment of the Curriculum Requirement, Maxwell AFB, 1995.

[5] Electronic Warfare. AFDD 2-5.1, Maxwell AFB, 1999.

[6] FM 100-6 Information Operations. Headquarters Department of the Army, Washington, 1996.

[7] Information Operations. AFDD 2-5, Maxwell AFB, 1998.

[8] Joint Pub 3-13 Joint Doctrine for Information Operations, Washington D.C., 1998.

[9] Molander R. C., Wilson P. A., Mussington D. A., Mesic R. F.: Strategic Information Warfare Rising, Santa Monica, 1998.

[10] Schwartau W.: Information Warfare. Cyberterrorism: Protecting Your Personal Security in the Electronic Age, New York, 1996.

[11] Strategic Assessment 1996. Instrument of U.S. Power. National Defense University INSS, Washington D.C., 1996.

[12] Szpyra R.: Operacje informacyjne państwa w działaniach sił powietrznych. Rozprawa habilitacyjna. In: Zeszyty Naukowe Akademii Obrony Narodowej. Dodatek, Warszawa, 2002.

[13] Vickery B. i A. Information Science in theory and practice, London, 1987.

[14] Warden III J. A. (1995): „Air Theory for the Twenty-first Century” Battlefield of the Future. In: 21st Century Warfare Issues, Maxwell AFB, 1995.

http://www.infowar.com/mil_c4i/00/mil_c4i_120100a_j.shtml


Uniform approach to mandatory security of event management systems

Pavel Štros

[email protected]

Department of system and network management Datasys s.r.o.

Prague, Czech Republic

Abstract The article reveals the specifics of a typical event management system (EMS) with respect to mandatory protection, defines necessary information granularity, provides semantics for associations between sensitivity levels and model constructs and analyzes effects of the classification of a particular construct on the classifications of other constructs.

A typical EMS uses rules to correlate and analyze events. It supplies an engine for event processing that will handle all the filtering and correlation of events. Data are typically stored in a database. Mandatory access policy model presented in this article not only states definitions and rules that control access to event data stored in the database, but supplies mandatory access policy to rules and supplies constraints to the execution of rules.

Keywords: event, class, access policy, security model, and mandatory.

1 Introduction Event management is one of the central questions in network management. Event management pertains to detection, isolation, classification, filtration, correlation and presentation of events occurring in a network. All of the functional elements of EMS have to deal with large volumes of events [1]. Event management aids in the:

• Reduction in alarm events reported to a management station.

• Quick isolation and possible correction of fault.

• Detection of various composite events or event patterns that are a set of interrelated events.

In a multilevel security policy, every user is associated with a clearance level and every piece of information is associated with a sensitivity level. A subject is a user or a process running on behalf of a user. Process running on behalf of a user is associated with a security level dominated by the clearance level of this user. Classifications, clearances and security levels are both taken out of a partially ordered set of sensitivity levels. In the example presented in this paper I consider sensitivity levels Secret (S), Confidential (C) and Unclassified (U)

There are two key requirements of the Bell & LaPadula mandatory security policy model [2] that is used in [3] to analyze multilevel security policy in the context of object-oriented databases.

• ”No Read Up” - Subjects are only permitted to read data whose classification is dominated by their clearance.

• ”No Write Down” - Subjects are only permitted to write data whose classification dominates their clearance.

My research is derived from [3].

1.1 Research outline

The process of designing multilevel security policy in the context of EMS involves three issues. First, information granularity has to be defined. The question here is what constructs of the event are subjects to mandatory protection and have to be associated with sensitivity levels. Second, semantics for the association between a sensitivity level and a construct must be provided. In particular, does this association protect the


construct content or the existence of the construct? And third, effects of a classification of a construct on classifications of other constructs require analysis. The knowledge of a low classified data may disclose the knowledge of another higher classified data; in order to control these unauthorized inferences, assignment of sensitivity levels must be carefully analysed.

The objective of this paper is to define a set of principles addressing these three issues in the context of a generic EMS.

2 Multilevel security in the context of EMS

2.1 Terminology and assumptions

Event is a particular fault or incident within the computing environment that occurs on an object. An event usually represents either a change in status or a threshold violation. Every time the status of a managed object changes in any way, an event occurs. If this event is important enough to drive attention, or if it needs to be correlated with events from other sources and therefore cannot be fully processed at its local site, then the event should be forwarded to a central event server. The description of an event is referred to as an event message. Event messages are the central unit of information within the EMS. Event messages are structured chains and are typically provided in the form of attributes, which are ”name=value” pairs. The term ”event” or “event instance” is often used in place of the more appropriate term ”event message” within this article.

My research assumes event class hierarchy. Event classes determine the attributes and information that may constitute the event message. Each event is identified by a class name as a result of classification. Multiple inheritances are not allowed within class definitions.

A typical EMS uses rules to correlate and analyze events. An engine that runs a set of rules to determine if an action needs to be taken in case of an event performs this. The rule engine is responsible for:

• Finding applicable rules for a given event.

• Managing the execution of applicable rules.

• Storage of the processed event data in a database.

A rule describes what should be performed when the event server receives a particular event. Rules are used to assess the received event and to determine appropriate actions to perform and to proactively address situations before they become problems. A rule definition is a construct that lets you specify what action to take when a certain event is received. A rule base contains all rules and event class definitions that are to be performed against events. A rule is only triggered when the event under analysis has satisfied all of the conditions specified in the rule’s event filter. Rules are run one at a time and are usually applied based on their order within the rule base.

2.2 The information granularity

I have to identify what constructs of an event are subjects to mandatory protection and will be associated with sensitivity levels. There are two possible approaches to that: the Single-level Event and the Multi-level Event approaches. In the Single-level Event approach, every event class and event instance is assigned a sensitivity level. The sensitivity level applies to all the information encapsulated in the construct. In the Multi-level Event approach, every attribute of every event class and event instance is assigned with a sensitivity level. This sensitivity level protects the existence and the value of the attribute.

Security models based on the Single-level Event approach are easy to implement. However, the expressive power of the multilevel policy is poor. In my opinion, the Single-level Event approach is too restrictive. Thus, the Multi-level Event approach is adopted in my research. As a result, the following construct may by subject to mandatory protection in my model: Event class, Event class attribute, Inheritance link, Event instance, Event instance attribute, Event instance attribute value, Event instance link and Rule definition. However, I will unveil in the next section that not all of these constructs need to be assigned a sensitivity level.


2.3 Semantics of sensitivity level association and inference effects

In this section the principles of semantics are stated as rules that should be applied when designing multilevel EMS. The rules are stated using easy-to-read sentences, without using any formal language. They are derived from the research related to mandatory security in object-oriented databases [3]. A more formal proof presented in [4] provides evidence that these rules are sound and complete. The purpose of this section is to derive the semantics of every association between a sensitivity level and each of the constructs identified in previous section. I also state the inference control rules that must be enforced when assigning security levels to these constructs.

2.3.1 Event classes

Event classes are used for the operational classification of events and determine the attributes and information that may constitute the event message. In other words, they are used for event message formatting. The correctness and availability of class definitions determine successful processing of a newly arrived event. In the proposed system, classes are used as the means of assigning sensitivity level to a newly arrived event. The following rules are relevant to mandatory protection of event classes; detailed reasoning can be found in [3]:

1. Each event class is associated with a sensitivity level. Assigning a sensitivity level to event class c_ec protects the existence of class c_ec i.e. the fact that c is an event class.

2. Each event class attribute is associated with a sensitivity level. Assigning a sensitivity level to an attribute c_eca of a class c_ec protects its existence, i.e. the fact that c_eca is an attribute of c_ec.

3. The sensitivity level assigned to an attribute c_eca of a class c_ec must dominate the security level assigned to c_ec.

Event class hierarchy is used for event type definitions. Only single inheritance is allowed. With the exception of the ”root event class” each event class is assigned just one ”parent class”. ”Child event class” contains all the attributes of its parent class but may have additional attributes defined. The definition of the ”root event class” is classified at the lowest sensitivity level and contains all ”basic description of an event” attributes, such as ”date_occured”, ”date_received”, ”received_from”, etc. The following rules are relevant to mandatory protection of inheritance links between event classes; detailed reasoning can be found in [3]:

4. Each inheritance link is associated with a sensitivity level. Assigning a sensitivity level to an inheritance link between a class c_ec and a class c_ec’ protects the fact that c_ec’ inherits from c_ec.

5. The sensitivity level assigned to an inheritance link between two classes c_ec and c_ec’ must dominate the least upper bound of the sensitivity level assigned to c_ec and the sensitivity level assigned to c_ec’.

6. The least upper bound of the sensitivity level assigned to an attribute c_eca of a class c_ec and the sensitivity level assigned to an inheritance link between a class c_ec’ and c_ec must dominate the sensitivity level assigned to c_eca in class c_ec’.

The following constraints are imposed by the assumption that each event class with the exception of the ”root event class” is assigned just one parent class and that a child event class contains all the attributes of its parent class. In particular the constraints have to be enforced when deleting or modifying parent classes.

7. If c_ec’ is a event class classified at level l, there must be at least one parent event class c_ec such that the inheritance link between c_ec and c_ec’ is classified at level l.1

8. If an inherited attribute c_eca of an event class c_ec’ is classified at level l, there must be at least one parent event class c_ec such that c_eca is an attribute of c_ec and l is equal2 to the least upper bound of the sensitivity level assigned to c_eca in class c_ec and the sensitivity level assigned to the inheritance link between c_ec and c_ec’.

2.3.2 Event messages

In the proposed system, classes are used as the means of assigning sensitivity level to a newly arrived event. Because the event instance is assigned the same sensitivity level as the corresponding event class, there is no 1 Notice that it is not explicitly stated, that a parent event class classified at least at level l must exist. 2 Due to paragraph 6, it cannot be greater.


need to assign sensitivity level to the construct ”Event instance link”. Event instance attributes do not suffer from the integrity constraint that is present in the object paradigm. Unlike object attributes, event instance attributes are not required to have a value. Therefore, users cannot guess the existence of a high-classified value if the attribute does not have value. Therefore, in the context of EMS, there is no need to introduce polyinstantiation to attributes. The following rules are relevant to mandatory protection of event instances:

9. Each event instance is assigned with a sensitivity level of the corresponding event class. Assigning a sensitivity level to an event instance c_ei protects the fact that c_ei exists.

10. Each event instance attribute is associated with a sensitivity level of the corresponding event class attribute. Assigning a sensitivity level to an attribute c_eia of an event instance c_ei protects the fact that c_eia is an attribute of c_ei.

11. Each event instance attribute value is associated with a sensitivity level of the corresponding event instance attribute. Assigning a sensitivity level to a event instance attribute value c_eiav of an event instance attribute c_eia of an event instance c_ei protects the fact that the value of c_eia in object c_ei is equal to c_eiav.

2.3.2.1 Remarks to the event data storage Most existing EMS’s use traditional (relational) database systems that are not tightly integrated with the EMS and are only used as storage for event data. Using an Active Database Management System (ADBMS) to build an EMS system would allow one to specify re-actions to both simple and composite events in the form of declarative ECA (Event-Condition-Action) rules. An advantage of this proposed architecture is that advanced research has been done in the security of ADBMS’ and subset of the ADBMS security research results can be directly applied to the proposed mandatory security model for event management systems.

2.3.3 Rules

A rule is a construct that lets you specify what action to take when a certain event is received. Rules are usually written in a high-level structured language called the rule language that supports the well-known ”event-condition-action” schema. There seems to be no need to apply mandatory protection to parts of the rule structure. Protection on the rule level is only considered in this article. The following rule is relevant to mandatory protection of rule definitions:

12. Each rule definition is assigned with a sensitivity level equal to the security level of the creators’ session. Assigning a sensitivity level to a rule definition c_rd protects the fact that c_rd exists.

3 Event processing

3.1 Classification of events

Events received by the EMS are first evaluated against all available event classes by the rule engine. Event classes with higher sensitivity levels are considered first. The most specific matching class is found and event message is assigned with a sensitivity level of the class. The event message is then formatted according to attributes defined for that event class. Each event message attribute and event message attribute value is associated with a sensitivity level of the corresponding event class attribute.

3.2 Evaluation against the rule base

In the proposed system, rules are evaluated based on their order within the rule base, but rules with higher sensitivity levels have higher priority and are considered first. A rule is only triggered when its sensitivity level dominates the sensitivity level of the event and the event under analysis has satisfied all of the conditions specified in the rule. Only event attributes ”visible” at the rule’s sensitivity level may be evaluated in conditions. Rules are run one at a time.


3.2.1 Event processing example

Consider event class hierarchy that is depicted in the following diagram.

The event class hierarchy may be built from the definition of classes that is listed below. The syntax used for the class definition language is not really important and I will not explain it in detail. However, you can dip that the definition of a class contains a name and sensitivity classification statement, and a link to a parent class in the header part. Further, there are message format constraints and attribute assignment formulas in the body part of the class definition The event class hierarchy created in accordance with this example permits access to information about dropped connection requests to unclassified (U) users, whereas permits access to information about accepted connection requests to confidential (C) and secret (S) users only. Clearance level secret is required to get knowledge about the ”firewall_rule” attribute and to gain access to the firewall rule number (the value of the attribute).

CLASS (”root event”; U ) {

(%d %s*; date_occured; message);

date_occured = (date; U);

message = (string; U);

}

CLASS (”firewall event”; U ) ISA ”root event”{

(%d firewall at host %s %s*; date_occured; hostname; message)

hostname = (string; U);

}

CLASS (”firewall config”; S ) ISA ”firewall event” {

(%d firewall at host %s configuration changed: %s*; date_occured; hostname; message);

}

CLASS (”connection request”; C ) ISA ”firewall event” {

(%d firewall at host %s connection request: %s*; date_occured; hostname; message);

root event (U) date_occured (U) message (U)

firewall event (U)date_occured (U) hostname (U) message (U)

connection request (C)date_occured (C) hostname (C) message (C)

connection request accepted (C)date_occured (C) hostname (C) firewall_rule (S) message (C)

connection request dropped (U)date_occured (U) hostname (U) firewall_rule (S) message (U)

(C)

(C)(C)

(U)

(U)

firewall config (S) date_occured (S) hostname (S) message (S)

(S)


}

CLASS (”connection request accepted”; C) ISA ”connection request” {

%d firewall at host %s connection request accepted: %s*, rule: %n; date_occured; hostname; message; firewall_rule);

firewall_rule = (integer; S);

}

CLASS (”connection request dropped”; U) ISA ”connection request” {

%d firewall at host %s connection request dropped: %s*, rule: %n; date_occured; hostname; message; firewall_rule);

date_occured : U;

hostname : U;

message : U;

firewall_rule = (integer; S);

}

The class hierarchy is built in accordance to rules 1-8. In particular, rules 7-8 are satisfied for the class ”connection request dropped” due to existence of the parent class ”firewall event”. Rules 9-12 do not apply to event classes.

When the event message

”2003/02/28 16:03:11 firewall at host guardian connection request: src 192.168.1.15 dst 192.168.2.7 svc ssh”

is received by the rule engine, event classes at secret sensitivity level are evaluated first but no matching class is found. Thus event classes at confidential sensitivity level are evaluated. The matching class ”connection request” is the most specific matching class at the evaluated sensitivity level. The event message is formatted according to the ”connection request” class definition.

EVENT (”connection request”; C) {

date_occured = (” 2003/02/28 16:03:11”; C);

hostname = (”guardian”; C);

message = (”src 192.168.1.15 dst 192.168.2.7 svc ssh”; C);

}

Should there be a rule within the rule base at sensibility level secret or confidential, whose condition part is satisfied by the attribute values of this event, the rule is triggered.

4 Conclusions In the context of EMS the following constructs should be subject to mandatory protection: Event class, Event class attribute, Inheritance link, Event instance, Event instance attribute, Event instance attribute value, Rule definition. With respect to semantics presented in this article and the subsequent inference analysis there is no need to introduce polyinstantiation.

There are some key processing principles that must be introduced to the rule engine in order to ensure that the mandatory protection can’t be mitigated. Rules are processed not only with respect to their position within the rule base, but higher sensitivity level rules are evaluated first.

Constraints applicable to deletion and modification of parent event classes should be subject to further research and the corresponding conflict between unauthorised inference and usability of such event management system should be solved.


References [1] Hasan, M. Z.: The management of data, events, and information presentation for network management,

Thesis of the University of Waterloo, Ontario, Canada, 1996.

[2] Bell, D., and LaPadula, L. Secure Computer Systems: Unified Exposition and Multics Interpretation, Technical Report ESD-TR-75-306, MTR 2997, MITRE, Bedford, Mass. 1975.

[3] Cuppens, F., and Gabillon, A.: Rules for Designing Multilevel Object-Oriented Databases, Fifth European Symposium on Research In Computer Security (ESORICS), Louvain la Neuve, Belgium, Springer-Verlag, September 1998.

[4] Gabillon, A.: Sécurite multi-niveaux dans les bases de données à objets, Ph.D. dissertation, ENSAE, 1995.


Evaluating trusted electronic documents

Petr Švéda

[email protected]

Department of Program Systems and Communications Faculty of Informatics MU Brno

Botanická 68a, 602 00 Brno, Czech Republic

Abstract An attack does not have to be the biggest threat to a digital signature system or application. The real threat is failing, which implements the security required by law to establish trust. Today security and reliability have become the key for digital signature and electronic documents. In essence, a technical problem has become also a legal issue.

Proprietary solutions are not compatible and their security depends on a closed design. Real solutions based on XML standards are solving only the problem of a content verification partially. It is one of the clue points, but other unsolved or partially solved problems are left there – e.g. content presentation, trust issues in signature creation, long-term signature verification, time stamps, compatibility and legal issues. A lot of drafts and partially pre-published standards exist there, which solve only several isolated problems. Any complete evaluation concept has not been published yet. This paper presents the evaluation approach based on requirements on a content, context and structure of a signed electronic document.

Keywords: content, context, digital signature, electronic document, evaluation, structure, trust.

1 Introduction People trust data in the context of a document. It is possible to secure an electronic document by digital signature techniques – this document would be trusted and unalterable. The key points of an electronic document are flexibility and editability. So it is infeasible to trust an editable file format, which has a lot of optional settings that can change a visual representation of an electronic document dramatically.

Existing file and data formats can be divided (according to the data structure) into three groups:

• Mark-up based – Formats that capture logical structure and may include some necessary metadata for viewable transformation (for instance XML or TeX file formats).

• Page describing oriented – Formats that capture layout, e.g. Portable Document Format (PDF) or PostScript (PS).

• Combined – Formats that contain mixture of document's layout and structure. An example is Rich Text Format (RTF) or Microsoft Word Document (DOC).

A fundamental conflict exists between trust and usability in current combined file and data formats. Mark-up based formats can be trusted if the problem of an unambiguous presentation is solved correctly. Detailed discussion about trust issues related to XML documents can be found in [7].

It seems to be suitable to separate content data and its presentation for a trustworthy document structure. It has to contain a signed instance of an electronic document, which was visible on a signer's screen at the moment of signing. A processing viewer or editor uses the trusted signed instance, called view, later. Design principles for a trustworthy document structure, which is based on views, are proposed in [11].

2 Trustworthy documents It is necessary to preserve the content, context and structure of a document to remain reliable and authentic. A trustworthy document preserves the actual content. There is also is required information about the document that relates to the context in which it was created and used. Specific contextual information will vary according to


the requirements of the activity. It is also necessary to preserve the structure or arrangement of the document. The failure in the structure of the document will impair its structural integrity. That, in turn, may undermine the reliability and authenticity of the document.

There are special considerations when dealing with the preservation of the content, context, and structure of documents that are augmented by digital signatures:

• Content – The digital signature or signatures in a document are part of the content. They indicate who signed a document. Sometimes they also can show that person approved the content of the document. Multiple signatures can indicate initial approval and subsequent concurrences. Signatures are often accompanied by some other information (e.g., creation date). All these things are part of the content of the document and needs to be preserved. The lack of this information seriously affects a reliability and authenticity of the document.

• Context – Digital signature technologies rely on individual identifiers that are not embedded in the content of the document. Trust paths, time stamps, and other means are included there to create and verify the validity of a signature (see Section 3). This information is outside of the content of the document, nevertheless it is important to the context. It provides additional evidence to support the reliability and authenticity of the document. The lack of these contextual elements affects seriously one's ability to verify the validity of the signed content.

• Structure – Preserving the structure of a document means its physical and logical format. This is also the question of the relationships between the data elements comprising the document which remains intact physically and logically. It is essential that all states of the document structure are fully and unforgeably described. It is necessary to assure the integrity of all information about structure of the document.

3 Revalidation issues The information necessary for revalidation (i.e., the public key used to validate the signature, the certificate related to that key, and the certificate revocation list from the certificate authority that corresponds to the time of signing) must be retained for as long as the digitally-signed document is retained. Both contextual and structural information of the document must be retained.

Important contextual information are:

• Certificate (or public key certificate) – A digitally signed data structure that binds the identity of a certificate holder to a public key. It is defined in the X.509 standard [6].

• Certificate policy – A named set of rules that indicates the applicability of a certificate to a particular community and/or class of an application with common security requirements. For example, a particular certificate policy might indicate applicability of a type of certificate to the authentication of electronic data interchange transactions for the trading of goods within a given price range.

• Certificate practice statements – A statement of the practices which a certification authority employs in issuing certificates. It provides a detailed explanation how the certificate authority manages the certificates, its issues and associate services, such as key management. The CPS acts as a contact between the certification authority and users, describing the obligations and legal limitations and setting the foundation for future audits.

• Certificate revocation list – A list of revoked but unexpired certificates issued by a certification authority. A list of subscribers paired with their digital signature status and the reason for the revocation.

• Trust paths – A chain of certificates of trusted third parties among parties to a transaction which ends with the issuance of a certificate that the relying party trusts.

• Trust verification records – Records that prove when and how the authenticity of the signature was verified. An example of this would be an Online Certificate Status Protocol (OCSP) [9] or another response from a certification authority.

Structural information are all the cryptographic primitives, file and signature format properties (e.g., necessary metadata tags) [2, 4, 5]. A digital signature remains valid as long as all the cryptographic primitives (e.g., hash functions, encryption algorithm and digital signature schemes) and parameters (e.g., key material and


certificates) remain valid. If one of these components becomes invalid, then the signature would lose its property as evidence. As a consequence, the signature verification process cannot succeed.

3.1 Procedures of signature validation

Consider the basic digital signature scheme with an appendix (e.g., DSA, ElGamal, Schnorr). There also exist digital signature schemes with message recovery (e.g., RSA, Rabin, Nyberg-Rueppel). The later type can be exchanged for the former one [8, 10]. The recipient uses an appropriate sender’s public key to decrypt the attached signature, computes the hash value of a received message and compares both characteristics. If they are equal, the signature (and document) is verified. Aside from the basic scheme, there are distinguished other validation schemes in [1]:

• Initial signature verification – It is the action of capturing the information that makes the digital signature verifiable against a signature policy. This should be done “soon after” a digital signature is generated.

• Usual signature verification – It is the action of checking a digital signature against a signature policy. This may be done at any time after the initial signature verification (e.g. years after the digital signature was produced).

• Archival signature verification – It is the action of checking a digital signature against the information that were secure and valid at the time of the signature, but which are likely to be no longer secure at the time of a later verification.

4 Evaluation concept This proposal of the evaluation divides signed documents into four categories according to the level of the trustworthiness they can offer. The higher category the higher assurance of reliability and authenticity of signed documents they offer. The choice of level depends on the type of an application, potential threats and on the security functional requirements.

• Level 0 – Documents falling into this category are more or less simple. They only offer very restricted level of reliability and authenticity. And they can be “easily” cheated or impeached. Trustworthiness of an electronic document is based only on a reliable public key issuing. A typical example of such document can be a plaintext file or email signed by popular PGP package or with a certificate issued only on e-mail address.

• Level 1 – Electronic documents at level two require signature created with certificate. The requirement on an enforced proof of the origin can be supplied by a qualified certificate [3]. The verification is sufficient initial signature verification. A structure has to contain also a document snapshot, which was visible on the screen at the moment of signing. An example of such document can be an MS Word or Excel document signed by a commercial solution that stores virtual printed copy. Tenths of possible product solutions are available.

• Level 2 – Level two documents require structure that allows verification of content data. Exposed components of the system which are working with a document (typically editor, viewer and signature creation or verification application) have to do integrity checking. The verification is sufficient usual signature verification. A document has ability to contain audit data (e.g., revisions). An example of such document can be a XML document signed by XAdES format [4].

• Level 3 – Archival signature verification is required for the documents on level three. The document structure allows content verification by two or more techniques. A supplemental public interface to the document structure must be available. It is necessary to monitor all data integrity. All previous states of the document are described fully and unforgeably. The electronic document falling into the level three should be able to resist even well-funded attacks. But it is rather difficult to design a document resistant to conspiracy among other parties inclusive TTP against the last one.


Content requirements

Context requirements

Structure requirements

Other requirements

Level 0 no requirements basic verification no requirements public key issuing

Level 1 basic user identity generation

initial signature verification

contains document snapshot created during signature creation process

enforced proof of origin and its identity

Level 2 audit data generation

usual signature verification

allows content verification

all data integrity checking

Level 3 full audit data availability

archival signature verification

allows content verification by two or more techniques with public interface

all data integrity monitoring

Table 1: Brief overview of evaluation requirements.

5 Conclusions The law, regulations and standards do not clearly identify which technology has to be used to implement digital signatures nowadays. Digital signatures techniques, known from the field of cryptography, assure legal signature requirements on the binary data level. Human beings cannot read binary data and do not understand them. People depend on widely spread file and data formats.

Widely spread combined file and data formats cannot be trusted. So the trustworthiness criteria have to be set. This paper presents the evaluation approach based on requirements on a content, context and structure of a signed electronic document. The proposed evaluation approach can be extended via + notation. For an example, level one+ document can correspond to some but not all requirements for level two documents.

References [1] CEN: Procedures for Electronic Signature Verification, CWA 14171, 2001.

[2] ETSI: Electronic Signature Formats, TS 101 733, 2000.

[3] ETSI: Qualified certificate profile, TS 101 862, 2001.

[4] ETSI: XML Advanced Electronic Signatures (XAdES), TS 101 903, 2002.

[5] ETSI: XML Format for Signature Policies, TR 102 038, 2002.

[6] ITU: X.509, The Directory: Public-key and attribute certificate frameworks, 2000.

[7] N. Lundblad: Trusted Documents, in XML Europe 2001, pp. 27-34, 2001.

[8] A. J. Menezes, P. C. Oorschot, and S. A. Vanstone: Handbook of Applied Cryptography, CRC Press, ISBN 0-8493-8523-7, 1996.

[9] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol, RFC 2560, 1999.

[10] B. Schneier: Applied Cryptography, John Wiley & Sons, Inc., ISBN 0-471-11709-9, 1996.

[11] P. Švéda: Trustworthiness of Signed Data, Technical report, Faculty of Informatics, Masaryk University, 2002.


Advantages of modular PKI for implementation in information systems

Petr Vaněk, Jiří Mrnuštík

AEC spol. s r.o. Bayerova 799/30


Abstract PKI implementation in practice is not limited only to technical and organizational construction of a trustworthy authority that issues certificates.

The Certification Authority establishment includes many partial systems such as signing units, certificates and requests storage and CRL management. Certification and CRL publications require constructed FrontEnds such as WWW, LDAP, OCSP and others. No less important part of Certification Authority are Registration Authorities. The establishment of CA and RA itself is only one of the targets that are awaiting for the person responsible for the implementation. There are many applications that use PKI infrastructure.

This contribution is first of all focused on electronic signature matter and on data security used not only during communication via electronic mail. Together with electronically signed documents we are also speaking about Time Stamp Authority and services related to TSA.

The supplied solutions have often the disadvantage of its finality and the impossibility to use the constructed PKI in other information systems. Many information systems implemented in practice need to resolve the incorporation of PKI by the easiest way possible. This is way the author points at advantages of PKI with modular structure and open interfaces constructed on AEC PKI SDK. The suitable combination and connection of “boxed” products and the existing information systems by SDK helps not only to save finances but also to shorten the development circle.

1 We start from the end The encryption and electronic signature is becoming inevitable part of each information system that handles in any way some sensitive data. For apprehension let’s start with the need to secure message sending between two participants. For various purposes the symmetric cipher with the key generated from password will be sufficient but the necessity to share this secret and distribute it to the individual participants leads us to the use of the asymmetric cipher. Broadly spread and used communication system is electronic mail (e-mail). The most frequently used security protocols of today are PGP and S/MIME. In recent times the S/MIME protocol is supported more and more. It is implemented very often to the client programs working with their electronic mail.

To enable an understandable between participants, it is necessary to state a communication protocol (data formatting). The base is standard PKCS#7 (RFC 2315) that is today replaced by CMS (Cryptographic Message Standard, RFC 2630). The types of the most important data contents according CMS are summarized in table 1.


Data type OID (object identifier) Significance Data Content Type id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)

us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } The data itself, e.g. signed,..

SignedData Type id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }

Electronically signed data

EnvelopedData Type id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }

Encrypted data (data in envelope)

Digested-data Content Type id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 }

Data with imprint (HASH)

Encrypted-data Content Type id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }

Data encryption, does not include information about cipher-key

AuthenticatedData Type id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 2 }

Authentication, if electronic signature can not be used

Tab. 1

1.1 Electronically signed data – what to do with it?

As indicated above, the data type used for electronic signature is id-signedData. We will not enter into details of CMS but let’s have a look briefly at the electronic signature structure. SignedData ::= SEQUENCE { version CMSVersion, digestAlgorithms DigestAlgorithmIdentifiers, encapContentInfo EncapsulatedContentInfo, certificates [0] IMPLICIT CertificateSet OPTIONAL, crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, signerInfos SignerInfos }

where SignerInfos ::= SET OF SignerInfo and next then SignerInfo ::= SEQUENCE { version CMSVersion, sid SignerIdentifier, digestAlgorithm DigestAlgorithmIdentifier, signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, signatureAlgorithm SignatureAlgorithmIdentifier, signature SignatureValue, unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } The message id-signedData is composed of several items such as version, sets of algorithm identifiers for calculation of message imprint, encapContentInfo, certificate, CRL and information about the subscribers. The item EncapsulatedContentInfo defines the sequence of data type and of the signed data itself. These are not, however, the obligatory content, see for example extra signature. The set CertificateSet may contain certificates related to subscribers, eventually with a full scope path to CA. In the same way even the currently enclosed CRL can be included in CertificateRevocationLists.

From the description of id-signedData is visible that we can add arbitrary number of signature sequences (SignerInfo) related to signed data (EncapsulatedContentInfo). The data are not always included - in that case we speak about so called extra signature.

For distribution of certificates with complete path to the root authority is used wrapping into this sequence in a way that the data part EncapsulatedContentInfo is again empty and SignerInfos is also an empty set. This data type has usually file extension p7c or p7b.

Sequence SignerInfo contains apart from the signature itself and algorithm identifiers also signed/not-signed attributes. Among the most important signed attributes are message imprint, type of signed data and time of signature. As we will see later, the finally mentioned attribute is not very trustful.

In summary we can say that data type id-signedData has the following purposes:


• compact format for signature (signatures) and data itself

• separated signature (extra signature), where the data are stored separately

• certificate and/or CRL wrapping either separately or with signatures

1.2 Data encryption, data in electronic envelope

Why do we say electronic envelope? Electronic enveloped id-envelopedData of the message is created by the following way: EnvelopedData ::= SEQUENCE { version CMSVersion, originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, recipientInfos RecipientInfos, encryptedContentInfo EncryptedContentInfo, unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } where RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo

RecipientInfo ::= SEQUENCE { version Version, issuerAndSerialNumber IssuerAndSerialNumber, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, encryptedKey EncryptedKey }

The message is encrypted by a symmetric cipher where the key is generated randomly and this key is then encrypted by a public key (certificate) of the recipient. Each recipient has his own structure RecipientInfo. The above stated structure RecipientInfo is valid only for case PKCS#7 where the version is equal 0. The recipient identification (of certificate) is done from the serial number of certificate and from the unique name of CA (issuerAndSerialNumber). CMS brings a possibility of another identification with help of SubjectKeyIdentifier (version 2). Other versions 3 and 4 are not very widespread.

1.3 From CMS to S/MIME

CMS messages are in binary form and are suitable for “native” signature and/or data encryption. Format S/MIME was introduced because of the electronic mail requirements. The format supports from CMS only: id-data, id-signedData and id-envelopedData. S/MIME defines the way of CMS messages packing to the MIME form; it means it performs BASE64 coding and the relevant MIME headers are added. From: "Petr Vanek" <[email protected]> To: "JK" <[email protected]> Subject: Report Date: Fri, 7 Feb 2003 09:57:39 +0100 MIME-Version: 1.0 Content-Type: application/x-pkcs7-mime; smime-type=enveloped-data; boundary="----=_NextPart_000_0005_01C2CE8F.59EACB00"; name="smime.p7m" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7m" MIAGCSqGSIb3DQEHA6CAMIACAQAxggI1MIHYAgEAMEEwNTEWMBQGA1UEAxMNTXlDQSBmb3IgbWFp …. …

1.4 Do we really need S/MIME ?

Here we thing about necessity of “wrapping“ of CMS messages into S/MIME format. We carry out only BASE64 encoding, it means a transfer into 7. bit representation and we add description information so as the mail clients are able to process the information. For storage and work in information systems it is not absolutely necessary to convert CMS into S/MIME format. This transformation only extends the data volume and slows down the manipulation.

A frequently discussed question is data signing in database. To sign all data stored in database is ineffective from the point of overloading of equipment power during creation and verification of signature and also from the point


of the way of signature creation by the private key owner. The transparent signature procedure means that DB engine or signing front-end data proxy signs anything that is on the entrance. The private key participated in signature must be permanently “unlocked“, so we have used the signature only to ensure the integrity of data in the database. To sign records has the sense only in case where there is a concrete person behind these records, eventually service that signs by its private key. Whereas the key is unlocked only for the shortest time possible, only for creation of the signature. In case of signing of large amount of data (columns etc.) it is possible to sign the final data processing (summary report); this report can be placed in an archive. In case where it is not possible to process the summary report, there can be defined rules by application logic for definition of an extract from individual records and a extra signature is created. The extra signature may be stored separately into the database column.

There are several solutions how to simply apply signing, and eventually encryption functions. Usually there are separated libraries of crypto core and ASN processors where the programmer himself must compile the individual parts of the message. This is too complicated way for IS (Information System) implementers and this technology has many way of solutions. From the programmer point of view it is ideal to carry out as few steps as possible (function calls) to achieve the success. That is way various SDK (Software Development Kit) are developed. They provide sufficient set of functions for full-scale work with electronic signature and/or encryption.

We are often implementing only a narrow set of functions e.g. creation and verification of electronic signature but we would be losing precious time during the construction of the whole functional infrastructure with help of random SDK. The necessary supplementary applications (such as key pairs and CRL management, key generators, LDAP storage etc.) are repeated every time. It seems that the ideal answer is the “boxed” solution where it is possible to complete functionality by necessary IS modules so as we get a compact entity. There are few suppliers that are willing to provide SDK and to enable connection to the existing applications of product portfolio.

2 Key pairs We can use the above-mentioned signing providing that we own a key pair; it means a private key and a public key certification. The key pair is generated by a generator that calculates the pair with help of some of asymmetric algorithms. Let me remind that for key generating we do not need only the algorithm but also the length of the generated key. Not all SDK or applications are capable to accept arbitrary algorithm. We consider RSA as the implemented standard. A serious competitor regarding the rapidity and the key size are algorithms based on elliptic curves. Table 2. shows the outline of asymmetric algorithms and key sizes that should be supported by all up-to-date PKI solutions.

Name Key length in bits RSA 512 - 4096 Diffie-Hellman modulus 1024, private key 160 DSA 1024 Elliptic Curves 112, 160, 180, 192, 256

Tab 2.

Before the key pair generating it is advisable to have the possibility to initialize explicitly the generator of random numbers to ensure the greatest security possible (non-deductibility of the key from the ascendant). SDK must shield another no less important task and it is the protection of the private against eventual exploitation. The generating of private keys in “save memory” and its following encrypted storage on disk will be sufficient for various purposes. By the safe memory we mean here a memory space that is with help of kernel driver guarded against memory swapping to disc. Before unblocking of this place the key is overwritten by defined formula in a way that the key itself does not appear in any other place. Because there exist techniques how to acquire this key, e.g. during system hibernation when the whole operation memory is stored on disc (done by OS) or by another kernel driver searching in operational memory for keys, there must exist safer storage. The storage can be smart card, tokens that apart from memory chip carry in them microprocessor that includes its own OS with crypto core. Thanks to this OS we are able to generate the key pair inside of the token so as the private key never leaves the token. The definition “never leaves“ is meant it the sense that the firmware producer for token binds itself to it. But the possibility of back door always exists. The impossibility for the private key to leave the token may be a disadvantage; it is the case when we need to backup our private key from some reason.


The common tokens do not have this option. CA requires this option inevitably. There exist equipment such as Chrysalis ITS Luna CA3 that contains the required utility. This equipment is certified to the standard FIPS-141 level 3 so we can trust that copying can not be used as a backdoor. In case of CA where the investment would exceed tolerable boundary because of this equipment, it is possible to generate the key pairs in safe memory, then import them into tokens and delete these keys from the memory.

In case of token use the keys are protected by application logic of given firmware and the access is ensured by one or more PINs. With keys stored on common memory media the most passable way is PKCS#12 format. These keys are then protected by access password from which is extracted the encryption key for private key protection. P12, as this format is called for short, is suitable even for storage of private keys including their certificates. Efficiently designed SDK should wipe away the differences among the use of individual storages.

3 Certificates The public keys obviously belong together with private keys. The public keys by themselves do not carry any owner identification. We verify the public key to be secured against forgery. The certificate is a data structure that contains, apart from public key, other description information about the owner, issuer, the purpose and so on. Leaving aside the special case where the subscriber is the owner (selfsigned), the issuer should provide sufficient guarantee for the data stated in the certificate. The issuer is called Certification Authority.

To issue a certificate by CA it is necessary to have a request that must be put together by the applicant during key pair generating, it means private and public keys. There are several standards related to the request format. The most expanded is PKCS#10 format that is described in RFC 2314. The request itself is similar to a simplified certificate signed by applicant’s private key. CertificationRequest ::= SEQUENCE { certificationRequestInfo CertificationRequestInfo, signatureAlgorithm SignatureAlgorithmIdentifier, signature Signature }

CertificationRequestInfo ::= SEQUENCE { version Version, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, attributes [0] IMPLICIT Attributes } The content is signed (Signature), CA then verifies this signature and by this also the fact that the applicant owns his own private key.

SubjectPublicKeyInfo carrying the information about the applicant public key and its algorithm are the most important information contained in the request for certificate creation. Information in item subject that should carry a unique name is rather a recommendation of the content for the issuer, for CA. There will be many people that will not agree with this statement but let’s have a look at this problem in practice.

The user or if you like his client’s software may not be always able to produce a request with the appropriate extensions and can not know his unique name in the CA frame. That is way the RA officers complete the information in accordance with the executive rules of CA and place them on the unique name in the CA frame. Certificate ::= SEQUENCE { tbsCertificate TBSCertificate, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING } TBSCertificate ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, -- If present, version shall be v2 or v3 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, -- If present, version shall be v2 or v3 extensions [3] EXPLICIT Extensions OPTIONAL -- If present, version shall be v3 }


The certificate itself is a structure (see above) that may, due to possible extensions in version X509 v.3 cause numerous problems with handling and data representation. The certificate is constantly developing. PKI SDK should be at least able of partition and presentation of unknown extensions. We should not also forget the work with qualified certificates according RFC 3039.

As we can see, the objects (keys, certificates, ...) in PKI have a very complicated structure. Many PKI SDK uses complicated structures, eventually leaves up to the user himself to set up the structures. With this approach the implementation is burdened by a high error rate and it places great requirements on programmers knowledge. The whole problem can be also seen from a different angle. PKI SDK should be also seen from the user point of view, not only from the point of view of rules and recommendations although these must be accepted internally. If we complete such a system by the option of universal data representation as XML is, we have good suppositions of open system base.

4 Certification Authority Certification Authority (CA) stands on the top of the whole PKI trustworthiness. It is not obligatory to implement in the frame of PKI to IS own CA. In case of small IS it is possible to use commercially accessible CA of third parts. For closed and independent solution is nevertheless convenient own CA construction. CA is not only signing equipment that signs the certificate requests but complex program and organizational background. The CA construction can be approach by different ways. One of them is the CA construction on base of PKI SDK; but this way we acquire only signing equipment. Another alternative is getting of application components such as signing equipment, RA, storage management, LDAP and others. Apart from Ca components itself it is necessary to create documentation base, executive rules, and other documents needed for smooth course of CA.

CA should publish its certificates. Most of CAs limits to the option to provide the certificates through web interface. This approach may have disadvantages during implementations IS where it is necessary to procure certification according various criteria. As alternative distribution channels are used directory servers, usually LDAP.

The certifications can be revoked during the validity from various reasons. CA creates lists of revoked certificates and places them into signed lists called CRL (Certificate Revocation List). The way of revoke request is solved in CA certification policy.

These CRL CA generates in prescribed time intervals and issues them on so called distribution places, usually defined with help of URL. These distribution places are also stated in issued certificates so as the user have always the possibility to verify the certificate. Here we encounter the biggest problems with implementations. It is not always the best solution to copy CRL from CA and check with the certificate. The whole process is greatly slowed down and it leads almost to system malfunction. Let’s have a look at the following example of IIS where it always copies CRL during the use of SSL and check of client’s certificate. To ensure IIS function it is necessary to switch off this. An alternative method may be the application of individual crl on certificates in storage and their deposit in local PKI. Here it is necessary to carry out copying and application CRL in storage (check of certificate in storage already included) in intervals defined by CA. OCSP protocol for detection of given certification state tries to solve this problem. But this one has also its drawbacks. During the check of signed document signature, we will monitor several certificates CA, TSA and client’s. In the course of common work with certificates the frequency of network connections to OCSP will be rather high.

5 Time Stamp One of the signed attributes in electronic signature is time. As was already mentioned this attribute is not very trustful because the time stated in this attribute is not guaranteed by anybody. The data in this attribute can not be disproved nor verified without use of additional utility. When we check the electronic signature, we need to be sure that the signature was created in time when the certificate of signing party was valid. The certification is valid if its time validity has not passed and if it was not revoked by the CA that issued it. The time of signature belong among the signed attributes and therefore it can not be modified or completed by any signed attributes. The possibility how to add trustful time to the existing signature is the use of non-signed attributes of signature as it is stated in RFC 3126, it means addition of time mark token. OID of non-signed attribute of own signature is defined as id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 14}


The content itself is then SignatureTimeStampToken, which is signed message id-signedData according to CMS. The signed data have then the following structure

TSTInfo ::= SEQUENCE { version INTEGER { v1(1) }, policy TSAPolicyId, messageImprint MessageImprint, -- MUST have the same value as the similar field in -- TimeStampReq serialNumber INTEGER, -- Time-Stamping users MUST be ready to accommodate integers -- up to 160 bits. genTime GeneralizedTime, accuracy Accuracy OPTIONAL, ordering BOOLEAN DEFAULT FALSE, nonce INTEGER OPTIONAL, -- MUST be present if the similar field was present -- in TimeStampReq. In that case it MUST have the same value. tsa [0] GeneralName OPTIONAL, extensions [1] IMPLICIT Extensions OPTIONAL }

The item messageImprint contains signature imprint and we add time stamp token to it. The item genTime defines the time when the time stamp was created. The issue of time stamps is controlled by certain policy similarly to certificates. The definition of policy is done by the item Policy.

The institution that issues the time stamps is called Time Stamp Authority (TSA). The communication with TSA can be done by several methods. Transport protocol http appears to be universal either because of its widespread usage by various clients’ libraries or because of its passage through firewall.

The electronic signature is not the only application of time stamp but it can practically be created for arbitrary imprint. The imprint can be done from a document, a log or other files where we wish to prove their existence in time.

6 Summary of requirements for modular PKI and SDK This article presented a very simplified cross-section by surrounding of electronic signature and encryption in IS. As we can see, there are many requirements for PKI system functionality. Because the PKI is being constantly developed, the individual modules, libraries and SDK must be designed so as the system does not disintegrate by eventual changes. The openness and modularity from the point of applications as well as PKI itself are necessary conditions for successful implementation into IS.


The enforcement of NATO INFOSEC requirements into the policy and architecture of CISs

Frantisek Vosejpka

[email protected]

S.ICZ a.s. V Olsinach 75

Prague 10, post zip 100 97

Abstract A series of national problem-oriented communication and information systems (CISs) have been developed within certain Czech government organizations and focused mainly on the Czech Restricted security level. A few of these CISs have received approval to operate at target-classification level, but only within the local networks. The other CISs are operated without completion of required security measures and therefore handle only unclassified information. The certification and accreditation processes of these CISs have failed to succeed due to a current lack of financial resources and skilled personnel. In both cases these CISs do not meet predetermined network functionality. This situation, in conjunction with a reduction in IT specialists in the government sector necessitates a series of fundamental decisions to enforce revised NATO INFOSEC policy requirements into CISs of the Czech Ministry of Defence (MoD) and partially the Ministry of Foreign Affairs (MFA). Numerous problem-oriented CISs have to be reduced to a small number of overarching CISs with all required Functional Area Services. There is a necessity to realize the current state and resource limitations, to set out new operational requirements for the functionality of CISs, to set out a new target system and service architecture, life cycle phases and steps with priorities and terms capable of guaranteeing a smooth transition from the current to the target state. The security within this process must be seen as added value and must be reflected from the very beginning, otherwise serious barriers will arise, which will cause failure to meet security and operational requirements. Simultaneously the project risks that have caused failure to certify current CISs (lack of communication security and excessive system building before system certification) have to be eliminated.

Keywords: NATO, INFOSEC, CIS, security, policy, directive.

1 Introduction The communication and information systems (CISs) within the Czech Republic that handle the classified information are subject to certification by the Czech National Security Authority (NSA) before handling the classified information. The objective of this article is to sum up the breaches that have caused a situation whereby the CISs of some Czech government organizations (typically the Ministry of Defence (MoD)) have not reached the required functionality and have failed their certification process. A further objective is to illustrate the legislative requirements stated by Czech Act No 148/1998 of the Collection of Laws (Coll.) on “Security of Classified Information” [1] and revised NATO Security Policy [2] that concentrates its requirements into the INFOSEC area. And finally to introduce possible features of target CIS INFOSEC architecture and migration steps to such a target state.

The content of this article is unclassified and limited by quite weak access of a civil firm (with security clearance) to the whole suite of NATO Security Policy documents.

2 Applicability of NATO INFOSEC policy within the national conditions The Enclosure F “INFOSEC” of NATO Security Policy [2] sets out the policy and minimum standards for the protection of NATO classified information, and supporting system services and resources in communication, information and other electronic systems handling NATO classified information. The document defines INFOSEC as “the application of security measures to protect information processed, stored or transmitted in communication, information and other electronic systems against loss of confidentiality, integrity or availability,


whether accidental or intentional, and to prevent loss of integrity or availability of the systems themselves. In order to achieve the security objectives of confidentiality, integrity and availability for classified information stored, processed or transmitted in communication, information and other electronic systems, a balanced set of security measures (physical, personnel, security of information and INFOSEC) shall be implemented to create a secure environment in which to operate communication, information or other electronic systems.”

The “Primary Directive on INFOSEC” [4], which is published in support of [2], addresses the INFOSEC activities in the system life cycle, security principles, and the INFOSEC responsibilities. The Primary Directive on INFOSEC is supported by directives addressing INFOSEC management (including security risk management, security approval, security-related documentation, and security review/inspection) and INFOSEC technical and implementation aspects (including computer and local area network (LAN) security, interconnection of CIS security, cryptographic security, transmission security, and emission security). The Primary Directive on INFOSEC itself is classified NATO Restricted and can not be discussed in this article.

The interconnection of communications and information systems is also an important part of INFOSEC [5]. “The increased number of users of interconnected CISs leads to a higher risk of unauthorised disclosure, modification or deletion of information either deliberate or accidental and of denial of service by threatening the availability of some or all CISs and/or the interconnection.” The interconnection of classified CISs should be strictly based on operational requirements and apply a restrictive policy. The security boundary as a mutually agreed physical interconnection point where the first CIS’s responsibility for the interconnection ends and where the responsibility of the other CIS starts shall be defined in the System Interconnection Security Requirement Statement (SISRS) [6].

Utilization of NATO INFOSEC policy is mandatory whenever the NATO CIS or its node is deployed within national conditions. Utilization of NATO INFOSEC policy is recommended and very useful in many other cases in the Czech Republic because of a quite poor set of CZ INFOSEC documents. In addition the usage of NATO INFOSEC policy and the documents on INFOSEC Architecture contributes to compatibility and interoperability.

NATO INFOSEC policy is applicable not only to the Ministry of Defence (MoD) but even to the Ministry of Foreign Affairs (MFA) and other organizations, whose CISs should be connected to a CIS of the European Union (EU). The Security Arrangements for the Release of NATO Classified Information to the Western European Union (WEU) (see [3]) sets out the policy, procedures and regulations required for the release of NATO classified information to WEU, and regulations for the handling of NATO classified information released to WEU. “All NATO classified information that is released to WEU is for official use only. It will, therefore, only be disseminated to individuals in WEU on a Need-To-Know basis and in accordance with stipulated release caveats. Within WEU, NATO classified information will be handled in accordance with WEU security regulations, which are based on NATO regulations.” Besides, the NATO Information Management Policy states that NATO Unclassified information is only for official use and should be appropriately protected.

3 Current state of CISs within some Czech government organizations Some government organizations currently have a large deployed base of problem-oriented CISs. Typically, each of these has been developed by a separate service (e.g. logistic, personnel, financial) for its own use and then entered into a competition to meet the specific organization requirements. As a result, the organizations have an array of CISs that, with few exceptions, do not interoperate. There are several underlying technical reasons for this:

• CISs have been designed to different communication and IT standards and are not interoperable with other organizations’ CISs;

• In general terms, CISs have been designed to meet one specific CIS requirement and not to be sufficiently flexible to be used in other scenarios;

• The main focus of CIS security developers has been on information protection at its specific classification level, which has entailed the very rigid implementation of algorithms and other security enforcing functions (which have been heavily reliant on hardware), exacerbating still further the inflexibility problem;

• Discrete CISs have often made use of different confidentiality algorithms. This is one of the biggest problems that an organization needs to overcome if it is to develop an integrated CIS of the entire organization.


Disintegrated and non-interconnected CISs within the organization lead to serious problems, such as:

• Difficulty in systems integration in connection with overly broad diversity of technology;

• Multiplicity of databases, mail and other common services;

• High project investment needs and their low efficiency;

• High operation and maintenance requirements, lack of IT specialists;

• High requirements on communication infrastructure (too many LANs and security boundaries);

• Failure to meet user requirements on the operability and information availability from a single workstation;

• Failure to meet security requirements necessary for issue of “Approval to Operate” classified information (within the Czech condition this means the issuing of a certificate by NSA, and accreditation by the Security Authority of the given organization);

• Inability to fulfill security requirements simultaneously in all sites (nodes) of particular CISs causes the failure of certification of entire CISs and leads to operation limited to unclassified information;

• The serious problems arise when only certain sites of a particular CIS have met security requirements and should be approved to handle classified information. The main problem lies in the constitution of secure interconnection of both system parts (approved and non-approved to handle classified information), because of a lack of certified boundary protection technology. As a result the users of one part cannot reach data and services in another part (e.g. mail between the two parts).

LANVLAN

Workstation

Workstation

Workstation

Policy A:Classification: RestrictedMode of operation: DedicatedStandards: X, local net

LANVLAN

Policy B:Classification: RestrictedMode of operation: System HighStandards: Y, local net

LANVLAN

Policy C:Classification: UnclassifiedMode of operation: NoneStandards: Z, distributed

Policy DStandalone WS

User

Higher classification level ???Internet ???

Multiple managements, policies and standardsComplicated communication infrastructure and security

Private WANAccessRouter

Figure 1: The user access fails from one computer in a disintegrated infrastructure.

These CISs have not yet met all of the security requirements. As a result the CIS certifications have been done either for local handling of classified information limited to a few sites, or have even failed completely and the systems handle only unclassified information. In both cases the CISs have not met the proposed network functionality and top-management, together with certain other users, have to have more than one computer to satisfy their operational requirements to access different applications of CISs. In addition there is usually no


authority that would have enough courage to decide on prompt controlled simplifying of such complicated architecture.

The complex of NATO INFOSEC measures and CIS INFOSEC Architecture compliance should be implemented into CISs. But in addition to disadvantages mentioned above, the detailed NATO INFOSEC documents are mostly classified and only in English, which is often a problem due to their quantity.

4 Possible way leading to integration of CISs The analysis of the current state of non-interoperating CISs with ensuing design of the “INFOSEC Architecture of the Target CIS” should be the first step. The design should accept the layered “NATO INFOSEC Architecture” that consists of “Core Services” as an overarching computing base covering the entire organization, and “Functional Applications” as a higher level.

The second step should be projection of a “Migration Plan” from the current state to the architecture of the “Target CIS”. The migration plan should take into account the following requirements:

1. Definition of the Community Security Requirement Statement (CSRS) [6], which states the classification level, security mode of operation, management, security environment, interconnection with other CISs, and other requirements of common security policy. The common technical and architectural standards should be developed and maintained. In the case of military CISs the NATO INFOSEC architectural requirements will have been met.

2. All CISs that migrate into the common network of the future “Target CIS” should accept and implement CSRS requirements and subordinate to common management.

3. As a first phase the migration of CIS into the common network usually does not imply serious changes of technology and the CIS will more or less be operated nearly as before, but within a secure environment.

LAN / VLANs / Domains

Standards: X Standards: Y Standards: Z

User

Policy:Classification: Restricted

Mode of operation: System High

IP-Crypto WANAccessRouter

Centralized management, CSRS based policies, multiple standardsCommon communication infrastructure and environment

Figure 2: The CISs integrated within the frame of CSRS.

4. As the second phase, the evolution-based development of CIS technology should be implemented, in which services and application would be gradually subordinated to the common standards of the integrated “Target CIS”. The core capabilities are developed as a process relatively independent of development of “Functional Applications”. The common standards should be defined and invoked.


5. The “Functional Applications” are developed independently as problem-oriented services to supersede the functionality of old CISs, and/or satisfy newly identified operational requirements of the given organization.

Policy:Classification: RestrictedMode of operation: System High

User

Core Services

SERVICES

Appl1

Appl2

Appl3

IP-CryptoWAN

AccessRouter

Centralized management, unified policy or CSRS based policiesCommon standards, core services, communication infrastructure and environment

Figure 3: The integrated IT and services within the Target INFOSEC Architecture.

The process described above is a massive intervention into CISs architecture, but should be done promptly, supported and controlled by top-level operational and security authorities.

5 Policy, classification level, and security mode of operation The operational requirements of government organizations (especially those that have to be connected to NATO or EU classified CISs) encompass handling classified information of different levels. But the higher classified information should be protected by higher (more expensive) security measures, and the user access should be minimized.

The good Commercial Off-The-Shelf (COTS) IT products generally provide for such a level of protection that is appropriate for a non-hostile and well-managed user community requiring protection against threats of inadvertent or casual attempts to breach the system security. The CISs based on such COTS IT cannot be operated in an environment in which protection is required against determined attempts by hostile and well-funded attackers to breach the system security.

The limitations mentioned above imply CISs’ separation based on the security mode of operation at the given classification level. The security principle “Need-To-Know” in this case requires using a “System-High” security mode of operation. Whenever the organization uses more than one classification level and the users do not have clearance for all classification levels, the CISs’ separation should be taken into consideration. The general concept is to operate one relatively broad CIS for Restricted information, and, where applicable, to develop a CIS for a Confidential and/or Secret level for those users who have personnel clearance and “Need-To-Know” to handle such a level of classified information.

Where the organization develops CISs for different classification levels, the architecture, standards, services, and applications may be the same for all CISs in order to save on investment. The appropriate security measures corresponding to the CIS security level should be satisfied by a secured environment and communication security measures. All components and services on the boundary between two CISs should be developed in


compliance with accepted standards and coordinated with the appropriate authority of the interconnected CISs to reach interoperability and consistency of security measures. Both operational and security requirements should be defined in advance for boundaries between such CISs.

CONFIDENTIALCIS

DMZ

SECRETCIS

Mission Remote WSs

SECRETCIS

SECRETCIS

Government Organization Other Government OrganizationNATO / EU organization

RestrictedCIS

RestrictedCIS

One way Flow?

RestrictedCIS

PublicINTERNET

Private Intranetwith domain for

Unclassified

One way Flow?

One way Flow?Public Domain

DMZDMZ

DMZDMZ

DMZ

PrivateUnclassified

SecurityAgreement

SecurityAgreement

SecurityAgreement

Figure 4: The model situation of interconnection of government organization CISs.

The Directive for the Interconnection of Communications and Information Systems [5] should be invoked when the boundary protection services are designed, implemented and documented. The directive sets out security principles and minimum-security requirements for different scenarios of interconnected CISs based on mission, classification level, and level of trust between the two sides.

All security aspects of interconnection of two CISs should be described in the document “System Interconnection Security Requirement Statement” (SISRS) [6] and boundary protection devices should be operated under conditions stated in the “Security Operational Procedures for Interconnection of CISs”. The security authorities of both CISs should approve their respective interconnection measures before the start of operation.

Figure 4 above shows various scenarios of CIS interconnection. The establishment of a boundary should be based on the “Security Agreement” between the government organizations to be interconnected, and in compliance with the directive [5]. The level of trust between those organizations, classification level of CISs, permitted data flows and other aspects should be taken into account for definition of boundary functionality and EAL (Evaluation Assurance Level, see [8] and [5]). Where the level of risk is too high or where there is a lack of sufficient technology, the air gap or one-way data flow technology should be implemented to fulfil operational requirements.

6 Conclusions The Czech national CISs that handle classified information should invoke Czech Act No 148/1998 Coll. on “Security of Classified Information” [1] and supporting directives of CZ NSA. The detailed security principles, minimum standards, life cycle requirements, risk evaluation and vulnerability reports, risk management


procedures etc., that are stated in Directives of NATO Security Policy, should be used and implemented, where applicable.

The layered “NATO INFOSEC Architecture” with “Core Services” and “Functional Applications” should be accepted in order to reach high efficiency. The system core should be designed as an overarching computing base covering the entire organization, relatively stable, with evolution-based development. The “Functional Applications” should be flexible to changing organization needs.

The acceptance and implementation of “NATO INFOSEC Architecture” is necessary in order to reach interoperability of Czech national CISs with NATO CISs.

The interconnection of two CISs must be strictly based on operational requirements and invoke the appropriate NATO INFOSEC Directive. Where the risk arising from interconnection is too high, the boundary protection devices should be alternatively based on one-way security mechanisms excluding network services connectivity.

The operational and security authorities should undertake responsibility and actively govern the migration of current separated and non-interoperating CISs toward integration.

References [1] Czech Act No 148/1998 Coll. on Security of classified information, CZ NSA 1998.

[2] NATO Security Policy, C-M(2002)49, 17 June 2002, Enclosure “F”, INFOSEC (NU).

[3] Directive on the Security of Information, AC/35-D/2002, 17 June 2002 (NU).

[4] Primary Directive on INFOSEC, AC/35-D/2004, AC/322-D/0052, 17 June 2002, (NR).

[5] INFOSEC Technical and Implementation Directive for the Interconnection of Communications and Information Systems, AC/322-D/0030-REV2, 25 October 2002 (NU).

[6] Guidelines for the Development of Security Requirement Statements, chapters System Interconnection Security Requirement Statement (SISRS) and Community Security Requirement Statement (CSRS), AC/35-D/1015 (Revised), 15 November 1996, (now under revision) (NR).

[7] Controlled Access Protection Profile version 1.d, National Security Agency, NSA Oct 1999.

[8] Common Criteria for Information Technology Security Evaluation, CCIB-99-031 Version 2.1, August 1999, Incorporated with interpretations as of 28 February 2002 (published as ISO/IEC 15408, 1999, Evaluation Criteria for IT Security).

An Effective Active Attack on Fiat-Shamir Systems

Artemios G. Voyiatzis and Dimitrios N. Serpanos

{bogart,serpanos}@ee.upatras.gr

Department of Electrical and Computer EngineeringUniversity of Patras

GR-26500 Rion PatrasGreece

Abstract

Hardware or side-channel cryptanalysis, in contrast to mathematical cryptanalysis, targets on implemen-tations of cryptographic algorithms and exploits side-channels, which transmit information of the secretcomponents of the cryptosystem. In passive hardware cryptanalysis, attacks measure parameters of theimplementation, such as execution delay of a cryptographic algorithm, power consumption and EM ra-diation, while in active hardware cryptanalysis, attacks are implemented through injections of hardwarefaults that cause faulty computations and result to leakage of secret key information. Active attacks, alsoknown as the Bellcore active attacks, target implementations of RSA using Chinese Remainder Theoremor Montgommery arithmetic, Schnorr’s scheme and the Fiat-Shamir identification scheme.

In this paper, we focus on the Fiat-Shamir identification scheme, which is widely used in environmentswith resource-limited clients, such as smart-cards. We provide a proof that the Bellcore attack on Fiat-Shamir systems is incomplete and we demonstrate that, there exist configurations of Fiat-Shamir systemsthat can defend against the Bellcore attack. Finally, we introduce a new active (hardware) attack andwe prove that it is effective against all possible Fiat-Shamir configurations. This new attack is not onlysuccessful, but efficient and realistic for typical resource-limited environments like smart cards.

Keywords: Side-channel attacks, active attacks, Bellcore attack, hardware faults, Fiat-Shamir iden-tification scheme.

1 Introduction

Side-channel cryptanalysis [13][14] has introduced a new class of (hardware) attacks, which are appliedto implementations of cryptographic algorithms and exploit a side-channel that transmits information ofthe secret components of an algorithm. These attacks are classified as active and passive, depending onthe implementation of the side-channel. Passive hardware attacks target some measurable parameter ofthe implementation, such as power consumption [16] [17], time delay of the execution of a cryptographicalgorithm [15] [10] and lately electromagnetic radiation [1] [12] [18]. In contrast, active hardware attacksinsert faults in data of cryptographic calculations [6] [7] [8]; such attacks can be realized, for example, byoperating a cryptosystem in extreme conditions or by destroying gates [2] [3].

Active hardware attacks were introduced with the development of the well-known Bellcore attack [8] [9],which targets the implementations of RSA using Chinese Remainder Theorem, RSA using Montgommeryarithmetic, Schnorr’s scheme and the Fiat-Shamir identification scheme. These theoretical attacks wereverified through simulation as well [4]; furthermore, practical experiments have been carried for the caseof RSA/CRT [5]. Simulations have shown that all theoretical active attacks are complete, with theexception of the Fiat-Shamir identification scheme, where there is indication that, in general, there maybe system configurations, where the Bellcore attack is not successful.

In this paper, we focus on the Fiat-Shamir identification scheme. The scheme is widely used in environ-ments with resource-limited clients, such as smart-cards, whose population is increasing at a dramaticrate. We have proven that the Bellcore attack is not successful, in general, on systems implementing theFiat-Shamir scheme, because it is based on an assumption which is not always true: one can construct afull-rank �× � matrix over Z2. Taking advantage of the conditions under which this assumption does not


hold, we describe Precautious Fiat-Shamir, a version of the original Fiat-Shamir scheme, which success-fully defends against the Bellcore attack; however, the scheme is weak against alternative active attackswhich are extensions of the original one, as we describe with an attack that requires the same resources(as the Bellcore attack) in order to obtain secret information [4]. This extended attack leads to a need forincreased computational and memory resources to impersonate a legitimate user. Thus, it is ineffectiveand unrealistic when targeted to resource-limited environments, such as smart-cards. Considering thatactive attacks target systems with limited resources, we introduce a new active attack model, which isnot only successful but efficient and realistic for these environments as well.

The paper is organized as follows. Section 2 describes the Fiat-Shamir identification scheme, the faultinsertion model and the Bellcore attack. Section 3 introduces a configuration of the Fiat-Shamir protocol,called Precautious Fiat-Shamir scheme, which defends against the attack, and proves its correctness.Section 4 introduces an extension of the Bellcore attack, which is successful against Precautious Fiat-Shamir. Finally, we introduce our new active attack model, which is successful and efficient in limitedresource environments.

2 Background

The Fiat-Shamir identification scheme [11] is a zero-knowledge authentication scheme, where one party,say Alice, authenticates her identity to another, say Bob, using an asymmetric method based on a publickey. The scheme works as follows. Alice has an n-bit modulus N , where N is the product of two largeprime numbers, and a set of invertible elements s1, s2, . . . , s� (mod N). Alice’s public key is the setPK� = {ui | ui = s2

i (mod N) and 1 ≤ i ≤ �}. Alice proves her identity to Bob using the followingcommunication protocol:

1. Alice and Bob agree on the security parameter, �;2. Alice chooses a random number r ∈ Z

∗N , calculates r2 mod N and sends this number to Bob;

3. Bob chooses a random subset S ⊆ {1, . . . , �} and sends S to Alice;4. Alice computes y = r · ∏i∈S si mod N and sends y to Bob;5. Bob verifies Alice’s identity by checking that the following holds:

y2 = r2 ·∏i∈S

ui (mod N)

The security of the scheme is based on the hypothesis that computation of square roots is a hard problemover ZN (this is believed to be equivalent to factoring N).

2.1 Bellcore attack on Fiat-Shamir Identification Scheme

Bellcore attack [8], introduced by Boneh, De Millo and Lipton and revised in [9], is a theoretical activeattack model that exploits erroneous cryptographic computations. The attack models derive secret keysfor various cryptographic protocols. In the case of Fiat-Shamir identification scheme, Bob can deriveAlice’s secret elements, s1, . . . , s� (mod N). The attack assumes that it is possible to introduce transientbit flips during Alice’s computations. Specifically, Bob introduces bit flips in r, during Step 3 of thecommunication protocol described above, while Alice waits for Bob to send the subset S. Then, Alice’scomputation in Step 4 is made with an incorrect value of r. This leads to Bob’s ability to calculate Alice’ssecret elements. Bellcore attack on Fiat-Shamir identification scheme is summarized in the followingtheorem:

Theorem 1. Let N be an n-bit modulus and � the predetermined security parameter of the Fiat-Shamirprotocol. Given � erroneous executions of the protocol one can recover the secret s1, . . . , s� in the time ittakes to perform O(n� + �2) modular multiplications.

Proof 1. (summarized) A bit-flip at bit position i, i ∈ {0, 1, . . . , n− 1}, in r changes its original valueby adding the value E, where E = ±2i; the sign of the change depends on whether the bit-flip caused a0-to-1 or a 1-to-0 change.


When the bit-flip occurs, Alice calculates (and sends Bob) an incorrect value of y, denoted as y, duringStep 4 of the protocol:

y = (r + E) ·∏i∈S

si

From this, Bob can compute

T (S) =∏i∈S

si =2E · y

y2Q

i∈S ui− r2 + E2

mod N

Bob validates the correctness of his bit-flip guess by checking that

T 2(S) =∏i∈S

ui

Since we have a method to compute T (S) for various sets S, we need an algorithm to derive eachs1, s2, . . . s�. If Alice accepts singleton sets, then the algorithm is trivial: Bob can choose S = {k} andthen, T (S) = sk. Thus, Bob needs only � iterations to collect all � possible si’s.

However, if Alice does not accept singleton sets, Bob can follow the following algorithm. Bob can mapeach set S to its characteristic binary vector U ∈ {0, 1}�, i.e. U(i) = 1 if i ∈ S. Now, if Bob can constructan � × � full rank matrix over Z2, then Bob can derive each si. For example, in order to determine s1,Bob constructs elements a1, a2, . . . , a� ∈ {0, 1}, so that

a1U1 + . . . + a�U� = (1, 0, 0, . . . , 0) (mod 2)

This is efficient, because vectors U1, . . . , U� are linearly independent over Z2. When computations aremade over the integers, we have:

a1U1 + . . . + a�U� = (2b1 + 1, 2b2, 2b3, . . . , 2b�)

for some known b1, . . . , b�. Then, Bob calculates s1 as:

s1 =T a1

1 · · ·T a�

l

ub11 · · ·ub�

�

(mod N)

The overall complexity of the algorithm is O(n� + �2) modular multiplications [9].

3 Defense against Bellcore attackBellcore attack identifies that the Fiat-Shamir identification scheme breaks very easily when |S| = 1, i.e.,when Alice accepts singleton index sets, and assumes that it is reasonable for Alice to deny to accept suchsingleton S sets. However, it presents the attack described above, which derives Alice’s secret elementseven when Alice accepts index sets S with |S| ≥ 2.

The ability to have Alice deny singleton S sets motivated our work: we introduce the concept that Alicemay be able to judge and/or decide what sets S to accept. So, in the following, we evaluate Bellcore attackunder the assumption that Alice accepts specific sizes for the index sets S. Our evaluation originatesfrom the claim in the proof of Theorem 1. that a full rank matrix can be always constructed over Z2.

Assuming that Alice accepts only specific sizes for S, in the following, we denote the set of acceptable(by Alice) sizes for the index set as G = {n1, n2, . . . , nk}.Using this notation, one can easily verify that, for even � and {2, � − 1} ⊆ G, the following matrix Be ofcharacteristic vectors constitutes a full rank matrix over Z2:

Be =

b1

b2

...b�−1

ble

=

1 0 . . . 0 10 1 . . . 0 1

. . .0 0 . . . 1 11 1 . . . 1 0


Accordingly, for odd � and {2, �} ⊆ G the matrix Bo of characteristic vectors constitutes a full rankmatrix over Z2:

Bo =

b1

b2

...b�−1

blo

=

1 0 . . . 0 10 1 . . . 0 1

. . .0 0 . . . 1 11 1 . . . 1 1

Thus, in conclusion, Bellcore attack is effective under these assumptions, because one can always constructa full rank matrix.

However, it is possible to choose G in such a way, so that it is impossible to construct a full-rank matrix;this renders Bellcore attack ineffective. As an example, consider the case where l = 3 and G = {2}; inthis case {2, �} �⊆ G. For this example, there are only three possible vectors: (1, 0, 1), (0, 1, 1) and (1, 1, 0).Furthermore, over Z2, (1, 0, 1) + (0, 1, 1) = (1, 1, 0). Hence, the “only” possible � × � matrix

1 0 10 1 11 1 0

has rank 2 and not 3 as required for Bellcore attack to be effective. Thus, Bellcore attack is not effectivein the case of the example.

The analysis above indicates that there exists a relationship between the Hamming weight of the charac-teristic vectors, w(u) =

∑ui and the rank of the matrix they can formulate. In the following, we establish

this relationship. For our analyses we denote as V2(�) the set of vectors of Z�2 with even Hamming weight.

In [19], we prove the next two propositions that we will use in our analysis:

Proposition 1. For every a, b ∈ Zn2 the Hamming weight of their sum is:

• even, if w(a), w(b) are both even or both odd;• odd, otherwise.

Proposition 2. V2(�) is a subspace of Z�2. Its dimension is dim(V2(�)) = � − 1.

3.1 The “Precautious Fiat-Shamir Identification Scheme”

We define a variation of the original Fiat-Shamir identification scheme, which changes slightly the thirdstep (Step 3) of the communication protocol used in the Fiat-Shamir scheme. The new scheme is definedas follows:

Definition 1. A Fiat-Shamir Identification Scheme augmented with a set G of even numbers is calledprecautious, if Alice accepts on the third step only S, such that |S| ∈ G.

By definition, if it could be G = {1, 2, . . . , �}, then the scheme is the original Fiat-Shamir identificationscheme. If G ⊂ {1, 2, . . . , �}, we argue that the scheme offers equivalent security as the original one. Thesecurity of the scheme is solely based on the difficulty of factoring a product over ZN and on the diffusioneffect of the random number r. The original scheme’s security is not based on the exact number of factorsof a given product. The defined Precautious Fiat-Shamir scheme does not disclose any selection of anindividual si, but rather limits the total number of factors of a protocol reply y. Furthermore, there is noknown work, where the total number of factors of a number over ZN provides any evidence of the factorsthemselves.

The Precautious Fiat-Shamir identification scheme provides good defense characteristics against Bellcoreattack, as proven in the following theorem:

Theorem 2. If Alice implements Precautious Fiat-Shamir Identification Scheme, then Bellcore attackis not effective.


Proof 2. Bellcore attack is effective when one can construct an � × � full rank matrix which has ascolumns (or rows) elements of V2(�).

According to Proposition 2., V2(�) has dimension � − 1. Thus, any � vectors from V2(�) are linearlydependent, and use of any such � vectors as rows (or columns) in an � × � matrix, results to a matrixrank at most � − 1.

4 A New Attack on the Precautious Fiat-Shamir Scheme

4.1 Strength of the Precautious Fiat-Shamir Scheme

We proved that the Bellcore attack is unsuccessful, since a device that judges the nature of challengescan defend against it. The new set of acceptable challenges, V2(�), is approximately half of Z

�2. Thus,

the probability of impersonation is reduced by a factor of two and becomes 2−�+1. However, with thisslight modification, the Bellcore attack can not derive Alice’s secret elements, s1, . . . , s�.

Since the set G contains even numbers, the set of acceptable challenges will be a subset of V2(�). Followingthe methodology of the Bellcore attack, one could give challenges such as their characteristics vectors tobe linear independent. By Proposition 2., such a set of vectors exists and � − 1 erroneous executions ofthe protocol will suffice to impersonate Alice. Thus, a simple adaptation of the Bellcore attack to thenew space, V2(�), is enough to impersonate Alice.

In Section 3, we provided a configuration for the implementation of the Fiat-Shamir scheme, with � = 3and G = {2}, which defended against the Bellcore attack. Here, we apply the extended attack to thisexample and demonstrate its success.

In this case, � = 3 and G = {2}, thus GS = 3. Alice can produce three products in total: s1s2, s1s3, s2s3.Without loss of generality, we assume that, after two erroneous protocol invocations, the first step ofthe extended Bellcore attack has derived s1s2 and s1s3. Then, in the second step, we compute theremaining product as follows. As the characteristic vectors (1, 1, 0) and (1, 0, 1) are linearly independent,we can express: (0, 1, 1) = a1(1, 1, 0) + a2(1, 0, 1); so, a1 = a2 = 1. Respectively, we can computeb1 = 1, b2 = 0, b3 = 0. So, we derive s2s3:

(s1s2)a1(s1s3)a2

ub11 ub2

2 ub33

(mod N) ==s21s2s3

u1(mod N) = s2s3 (mod N)

So, after two erroneous protocol invocations, we have all possible replies that Alice can produce (recall thatit is Alice who controls the random number r in the first step of the protocol). Thus, we can impersonateAlice successfully, although she implements the Precautious Fiat-Shamir identification scheme.

The impersonation information collected using this attack is not always useful for practical implemen-tations. In the case a smart card is the object of the attack, the new, fraudelent smart card, will needto either compute in real-time the correct responses using the collected information, or precompute allpossible replies. The former approach introduces a detectable timing overhead for performing the extramodular multiplications. Such time increases can be a strong indication of a fraudelent smart card. Thelatter approach is not feasible, since the size of all possible replies is exponential with respect to �; asmart card has very limited memory resources and thus a careful selection of � can protect against thisattack.

4.2 A new attack on the Fiat-Shamir identification scheme

In the previous section, we showed that the Fiat-Shamir Identification Scheme can defend against knownactive attacks, if properly implemented. In this section, we propose a new theoretical active attack modelwhich is successful against both the classical and precautious Fiat-Shamir schemes. This model allowsBob to derive Alice’s secret elements in polynomial time, in all cases.


4.2.1 Fault model

We assume that single transient bit flips can occur during the computation of the reply, in Step 4 of theFiat-Shamir identification scheme. Furthermore, we assume that an error can be introduced in any si,before Alice starts the computation of the reply r

∏i∈S si, in Step 4 of the protocol. Thus, Bob (the

attacker) needs to solve both time and space isolation problems, because he cannot control in time thisstep of the protocol. In this context, our assumption of the fault model is stronger than the correspondingassumption of Bellcore’s attack, because we need exact synchronization with the device that acts as Alice(i.e., the probability of introducing an error is smaller). In contrast, Bellcore attack needs to solve onlythe space isolation problem.

Similarly to Bellcore attack, our model is effective for multiple bit flips, with increased complexity.

4.2.2 Revised Theoretical Active Attack

Using the predefined fault model, our attack is percepted in the following theorem.

Theorem 3. Let N be an n-bit modulus and � the predetermined security parameter of the Fiat-Shamirprotocol. Given � erroneous executions of the protocol one can recover the secret s1, . . . , s� in the timeit takes to perform O(n�2) modular multiplications.

Proof 3. Assume that a single bit flip occurs during a protocol invocation, in Step 4. Bob can detectthat an error indeed occurred in Step 5 of the protocol. Without loss of generality, let us assume thatthe error occurred in sj . Then, we derive sj as follows.

Since a single bit flip occurred, sj was changed in Step 4 to sj ± 2i, for some 0 ≤ i ≤ n− 1. After such aprotocol invocation, Bob has collected the following numbers (during the corresponding protocol steps):

Step 2:r21 (mod N)

Step 4:y = r1(sj ± 2i)

∏k∈S−sj

sk (mod N)

The following simple operations allow Bob to derive sj , if Bob knows that the error indeed occurred insj .

C1 =y2

r21

(mod N) = (1)

= (sj ± 2i)2∏

k∈S−sk

s2k (mod N) (2)

C =C1∏i∈S ui

(mod N) = (3)

=uj + 22i ± 2i+1sj

uj(mod N) (4)

sj = ±uj(C − 1) − 22i

2i+1(mod N) (5)

During this calculation, we perform three multiplications in equations 2 and 4. In equation 5, we mustperform O(n) tries (modular multiplications) to find the correct sj , by determining the correct errorposition i. Thus, the complexity to compute sj is O(n).

Considering that Bob does not know a priori in which sj the error occurred, he must try all |S| possiblesj ’s to derive the correct one. Thus, the total complexity for deriving one sj is O(n�).

Given � erroneous protocol invocations, so that errors occur in every s1, . . . , s�, we can derive all secretelements of Alice in the time it takes to perform O(n�2) modular exponentations.


5 Conclusions

The Bellcore attack against systems implementing the Fiat-Shamir scheme is based on the assumptionthat the construction of a full rank �×� matrix over Z2 is always possible, where � is the number of Alice’ssecret elements. The construction of such a full rank matrix is not always possible, leading to alternativesystem configurations, as the described Precautious Fiat-Shamir Identification Scheme, which render theoriginal attack unsuccessful. As we have shown, the original fault model of the Bellcore attack can lead tosuccessful attacks on Precautious Fiat-Shamir, which, theoretically, derive enough information to imper-sonate Alice. However, these attacks are very demanding in terms of computational power and memoryresources, rendering these attacks impractical in resource-limited environments, such as smart-cards.Considering these limitations of the extended attack, we have introduced a novel active attack model,which enables successful attacks in all environments and known Fiat-Shamir system configurations.

References[1] Dakshi Agrawal, Bruce Archambeault, Josyula R. Rao, and Pankaj Rohatgi. The EM Side-

Channel(s). In Cryptographic Hardware and Embedded Systems - CHES 2002, LNCS 2523, pages29–45. Springer-Verlag, 2002.

[2] R. Anderson and M. Kuhn. Tamper Resistance – a Cautionary Note. In Proceedings of the SecondUSENIX Workshop on Electronic Commerce, November 1996.

[3] R. Anderson and M. Kuhn. Low Cost Attacks on Tamper Resistance Devices. In Security ProtocolWorkshop ’97, LNCS 1361, pages 125–136. Springer-Verlag, 1997.

[4] E.P. Antoniadis, D.N. Serpanos, A. Traganitis, and A.G. Voyiatzis. Software Simulation of ActiveAttacks on Cryptographic Systems. Technical Report TR-CSD-2001-01, Department of ComputerScience, University of Crete, 2001.

[5] Christian Aumuller, Peter Bier, Wieland Fischer, Peter Hofreiter, and Jean-Pierre Seifert. FaultAttacks on RSA with CRT: Concrete Results and Practical Countermeasures. In CryptographicHardware and Embedded Systems, CHES 2002, pages 260–275. Springer-Verlag, 2002.

[6] F. Bao, R. Deng, Y. Han, A.D. Narasimhalu, and T. Ngair. Breaking Public Key Cryptosystems onTamper Resistant Devices in the Presence of Transient Faults. In Security Protocol Workshop ’97,LNCS 1361. Springer-Verlag, 1997.

[7] E. Biham and A. Shamir. Differential Fault Analysis of Secret Key Cryptosystems. In Advances inCryptology-Crypto ’97, LNCS 1294, pages 513–525. Springer-Verlag, 1997.

[8] Dan Boneh, Richard A. DeMillo, and Richard J. Lipton. On the Importance of Checking Crypto-graphic Protocols for Faults. In Advances in Cryptology - EUROCRYPT ’97, LNCS 1233, pages37–51. Springer-Verlag, 1997.

[9] Dan Boneh, Richard A. DeMillo, and Richard J. Lipton. On the importance of eliminating errors incryptographic computations. Journal of Cryptology, 14(2):101–119, 2001.

[10] J.-F. Dhem, F. Koeune, P.-A. Leroux, Mestre, J.-J. Quisquater, and J.-L. Willems. A PracticalImplementation of the Timing Attack. Technical Report CG-1998/1, UCL Crypto Group, DICE,Universite Catholique de Louvain, Belgium, 1998.

[11] A. Fiat and A. Shamir. How to prove yourself: practical solutions to identification and signatureproblems. In Advances in Cryptology - CRYPTO ’86, LNCS 263, pages 186–194. Springer-Verlag,1987.

[12] Karine Gandolfi, Christophe Mourtel, and Francis Olivier. Electromagnetic Analysis: ConcreteResults. In Cryptographic Hardware and Embedded Systems - CHES 2001, LNCS 2162, pages 251–261. Springer-Verlag, 2001.

[13] John Kelsey, Bruce Schneier, David Wagner, and Chris Hall. Side Channel Cryptanalysis of ProductCiphers. In Computer Security - ESORICS 98, LNCS 1485, pages 97–110. Springer-Verlag, 1998.

[14] John Kelsey, Bruce Schneier, David Wagner, and Chris Hall. Side channel cryptanalysis of productciphers. Journal of Computer Security, 8(2–3):141–158, 2000.


[15] P. Kocher. Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS and Other Systems.In Advances in Cryptology - Crypto ’96, LNCS 1109, pages 104–113. Springer-Verlag, 1996.

[16] P. Kocher, J. Jaffe, and J. Benjamin. Differential Power Analysis. In Advances in Cryptology -Crypto ’99, LNCS 1666, pages 388–397. Springer-Verlag, 1999.

[17] T.S. Messerges, E.A. Dabbish, and R.H. Sloan. Investigations of Power Analysis Attacks on Smart-cards. In Proceedings of the First USENIX Workshop on Smartcard Technology, May 1999.

[18] Jean-Jacques Quisquater and David Samyde. ElectroMagnetic Analysis (EMA): Measures and Coun-termeasures for Smart Cards. In Smart Card Programming and Security, E-smart 2001, LNCS 2140,pages 200–210. Springer-Verlag, 2001.

[19] A.G. Voyiatzis and D.N. Serpanos. Active Hardware Attacks and Proactive Countermeasures. InProceedings of the 7th IEEE Symposium on Computers and Communications (ISCC’02), pages 361–366, July 2002.



Steganalysis of Images based on Randomness Metrics

Tao Zhang Xijian Ping

[email protected]

Department of Information Science University of Information Engineering

Zhengzhou, P.R.China, 450002

Abstract

This paper introduces a steganalytic technique that can detect the existence of secret messages embedded by randomly scattered LSB replacement in raw lossless compressed images. This technique is based on the analysis of the difference between randomness metrics of two binary sequences formed by concatenating the least significant bits of carrier image and stego-image. A logistic regression model is constructed to determine the existence of secret messages. Experimental results show that for gray-level images even if secret message capacity is as less as 0.4 bit per pixel, it is possible to achieve a high degree of detection reliability.

1 Introduction

Information hiding techniques are gaining worldwide attention due to the increasing popularity of information technology [1]. There are two main branches: steganography and digital watermarking. As a new way of covert communication, the main purpose of steganography is to convey messages secretly by concealing the very existence of messages [2]. In steganography the carrier image and the stego-image is visually indiscernible. The basic requirement for steganography is undetectability; in addition, embedding capacity should also be considered. However, security often conflicts with embedding capacity. Studies on steganalysis of images can evaluate the security of a given steganographic tool and promote the presentations of more secure steganographic algorithms.

Detection of secret messages in images is usually broken down into two areas: signature detection and blind detection. N. Johnson [2] made a careful analysis of signatures introduced by current steganographic software. J. Fridrich [3] introduced a steganalytic technique that can be successfully used for raw high-color-depth images with randomly scattered messages. N. D. Memon [4] constructed a steganalyzer that can classify the embedded and non-embedded using multivariate regression on the selected image quality metrics.

This paper focuses on stego-only attack of steganography algorithm of LSB randomly scattered insertion, i.e., determining the existence of secret messages only by computer analysis of stego-images.

2 Randomness Metrics

The randomness of binary sequences is an abstract concept and usually described using probability model. Kolmogorov [5] defined the amount of randomness (Kolmogorov-complexity) of a binary sequence as the length of the shortest program for a universal Turing-machine that generates the sequence. A sequence can be considered “random” if one of the shortest descriptions is the sequence itself.


In the application of random bit generators as the secret-key source in cryptography, it is often necessary to decide whether the output of the given generator is “random” enough. When no theoretical proof based on the device’s physical structure can be given, such a decision must be based on an observed sample output sequence of a given length N. Therefore, several kinds of statistical tests are introduced [6]. A statistical test is typically implemented by specifying an efficiently computable test function that maps the binary sequences to the real number set. Usually, the test function is chosen such that the test statistics is distributed according to a well-known probability distribution, most often the normal distribution or the chi-square distribution with d degrees of freedom. Given a significance level of test, we can decide the range of the test statistics when the sequence is a random sequence. On the other hand, the more the statistics deviate from this range, the worse the randomness of the sequence is. Therefore, we will construct randomness metrics based on those statistical test statistics. By experimental comparison we select Maurer’s universal statistical test and runs test to construct randomness metrics. See [6-7] for the definitions of those statistical tests.

We select Maurer’s approximation information entropy ex and runs test statistic rx as the randomness metrics of

binary sequences. The more “random” the binary sequence, the bigger ex and the smaller rx ; and vice versa.

Note that there are an upper limit for ex and a lower limit for rx respectively.

By concatenating the least significant bits of each row of an image, we can get a binary sequence Nl , called

LSB sequence. Experimental results show that for raw lossless compressed images more than 95 percent of them can not pass the statistical tests with significance level of 0.05. This fact indicates that their randomness are much weaker than that of a true random binary sequence. Therefore, we can utilize the randomness metrics to describe those differences on the randomness of LSB sequences between carrier image and stego-image quantitatively.

3 Detection of Secret Messages

Though it is the simplest way of steganography, LSB embedding is still one of the most practical algorithms due to its large embedding capacity, easy implementation and hard detection. We embed messages in images using the same methods as used in [3]: select a portion of points randomly in the LSB plane of the image, and replace all the bits on those points with the secret message to be embedded.

Define the embedding ratio β ( 10 ≤≤ β ) as the proportion of the size of secret messages embedded to the

maximum embedding capacity. It should be noted that secret messages are compressed and encrypted prior to embedding.

3.1 The Basis of Our Steganalytic Technique

The main idea of LSB embedding algorithm is that the LSB sequence Nl can be considered as random binary

sequence and replacing Nl with encrypted secret messages will not bring any visual difference between carrier

image and stego-image. However, statistical tests on LSB binary sequences of a large amount of images show


that most of them can not pass those tests with a significance level of 0.05, that is, they can not be viewed as true random binary sequences.

Experimental results also show that owing to the randomness of test messages and embedding positions the

LSB sequence of stego-image Nl1 exhibits much stronger randomness than that of carrier image Nl . Describing

quantitatively using randomness metrics introduced in section 2, generally, we have:

)()( 1N

eN

e lxlx < , )()( 1N

rN

r lxlx > (1)

Further analysis reveals that changes on the randomness metrics brought by embedding secret messages are

closely related with the embedding ratio. Besides, those changes are also related to )( Ne lx and )( N

r lx .

Without carrier image (stego-only attack) we can not find out those changes on randomness metrics of LSB sequences. However, we have noticed that if an image already contains a certain amount of secret message, embedding another test message in it will not modify the randomness metrics of the LSB sequence significantly; On the other hand, if the image does not contain a secret message, the randomness metrics of the LSB sequence will change significantly after embedding a test message. Thus, we can compute the Maurer

entropy ex and runs test statistic rx of the LSB sequence of the image to be tested at first, and after embedding

a curtain proportion of test messages using the same embedding method, compute Maurer entropy 1ex and runs

test statistic 1rx again. A logistic regression model is used to describe the close relationship between the

embedding ratio and 11rree xxxx ，，， . Because of the predictability of regression model, we can predict the

embedding ratio of secret messages in any image and consequently determine the existence of secret messages.

3.2 Logistic Regression Model Based on Randomness Metrics

The steganalytic technique proposed in this paper is based on changes on randomness metrics of LSB sequences. In this section, decision-making rules based on randomness metrics will be constructed and used to determine the existence of secret messages in the image. Logistic regression model [8] is selected in this paper to construct decision-making rules.

Let Y be the embedding ratio, ex and rx denote the Maurer’s approximation information entropy and runs test

statistic of LSB sequence of the image to be tested, respectively, 1ex and 1

rx denote those of LSB sequence of

the image after embedding test messages, respectively. The logistic regression model we used can be expressed as follows:

T

T

bX

bX

eeY rr

rr

+=

1 (2)


in which

，，，，，， 111 )lg()lg(1( eerree xxxxxxX =r

))lg()lg( 1rr xx , ),...,,( 610 bbbb =

r.

4 Experimental Results

We test our steganalytic technique on an image database that contains 350 raw lossless compressed gray-scale images of 512*512 pixels. Those images in the database are collected from USC-SIPI image database，RPI image database and the website of KODAK company , in which 250 images are used as training data for fitting the logistic regression model, and the rest 100 images are used to test the predictive ability of regression model. Secret messages and test messages are all cut randomly from a piece of cipher-text. Experimental procedures are listed below:

4.1 Compute The Parameters of The Model

First, we embed variant size of secret messages in 250 training images. Ten embedding ratios are

=β 10%,20%,...,100%, respectively. Then, compute the Maurer entropy and runs test statistic of LSB

sequences of those images (L=8, Q=2560, K=30208 for computing Maurer entropy). Second, embed test messages in carrier images and stego-images, and compute Maurer entropy and runs test statistic again. Consider the embedding ratio as the probability of the existence of secret messages in the image, and fit the logistic regression model defined in equation (2). We use SPSS statistical software package to compute the parameters of the model.

The logistic regression model constructed can be used to predict the embedding ratio of secret messages in any images and consequently be used to determine the existence of secret messages. The embedding ratio also indicates the possibility of existence of secret messages.

4.2 Parameter Optimization

Change the test ratio(the ratio of test message size to the maximum LSB embedding capacity) to the following value: 0.01, 0.02, 0.03, 0.04, 0.08, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9. Using the area under the ROC curve and the false positive /negative rate (short for FPR/FNR, respectively) as criterion for evaluating the performance of the regression model, experimental results show that when the testing ratio is equal to 0.5 the performance of classifier is the best. Especially when the embedding ratio is between 0.4 and 0.8, the performance of the classifier is improved significantly; when the embedding ratio is above 0.9 or under 0.3, the size of test messages has no significant effect on the performance of the classifier.

When the testing ratio is equal to 0.5 the parameters of the model are: b0=2917.68, b1=472.38, b2=-444.59, b3=7.25, b4=-7.29, b5=-3101.30, b6=-15.12. The model can predict the embedding ratio of secret messages in any images and consequently be used to classify the embedded and the non-embedded by selecting a simple threshold of the predicted embedding ratio. Figure 1 shows the ROC curves of the regression model, in which from left upper to right lower it in turn depicts the ROC curve when the embedding ratio is 100%, 90%,…,10%.

The FPR/FNR listed in Table I is the value of false positive /negative rate while the false positive rate is equal to the false negative rate.


4.3 The Predictive Ability of Regression Model

The following two experiments are designed to test the predictive ability of the logistic regression model:

1. Embed different embedding ratios of secret messages from those of section 4.1 in 250 training images first, and then utilize the model constructed in section 4.1 to predict the embedding ratio of secret messages and consequently classify the embedded from unembeded images. The embedding ratios are: 5%,15%,…,95%;

2. Embed the same embedding ratios of secret messages as those of section 4.1 in 100 test images, and then utilize the model constructed in section 4.1. to predict the embedding ratio of secret messages and consequently classify the embedded from unembeded images.

(a): results for variant embedding ratios: see Figure 2 and Table II; (b): results for test image database (100 images): see Figure 3 and Table III.

Figure 1. Figure 2. Figure 3.

Table I

Embedding Ratio 1.0 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 Area Under ROC 0.990 0.948 0.935 0.898 0.874 0.866 0.757 0.677 0.610 0.550 FPR/FNR(%) 2.4 13.2 12.8 14.8 16.4 18.4 28.8 37.6 41.6 46.8

Table II Embedding Ratio 0.95 0.85 0.75 0.65 0.55 0.45 0.35 0.25 0.15 0.05 Area Under ROC 0.963 0.941 0.911 0.883 0.851 0.789 0.716 0.645 0.579 0.523 FPR/FNR(%) 10 12.8 14.4 15.6 18 27.2 34 39.2 44.8 49.2

Table III Embedding Ratio 1.0 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 Area Under ROC 0.983 0.960 0.941 0.900 0.857 0.862 0.738 0.665 0.584 0.537 FPR/FNR(%) 3 9 12 14 19 17 28 34 46 49


4.4 Analysis of Experimental Results

From Figure 1, 2, 3 and Table I, II, III we can see that even if the embedding ratio β is as less as 0.4, it is

possible to achieve a high degree of detection reliability. Moreover, The FPR/FNR listed in Table I,II,III is the values of FPR/FNR while the FPR is equal to the FNR. In many cases, people would pay more attention to FNR. From the ROC curves depicted in Figure 1, 2, 3 we can see most of them are close to the upper part of the rectangle; therefore, we can get a lower FNR while maintaining a certain FPR.

From the comparison of ROC curve and FPR/FNR between section 4.1 and section 4.2 (a), (b), we can conclude that the logistic regression model has an unusual ability to predict for unknown images and variant embedding ratios.

5 Conclusion

Starting from randomness metrics of binary sequences, we proposed a steganalytic technique that can detect the existence of secret messages embedded by randomly scattered LSB replacement in raw lossless compressed images. Experimental results show that for gray-level images even if secret message capacity is as less as 0.4 bit per pixel, it is possible to achieve a high degree of detection reliability.

References

[1] F. A. Petitcolas, R. J. Anderson, and M. G. Kuhn: “Information Hiding – A Survey”, Proceeding of IEEE, vol. 87, no. 7, pp. 1062-1078, June 1999.

[2] N. F. Johnson, S. Jajodia: “Steganalysis of Images Created Using Current Steganography Software”, LNCS Vol.1525, pp. 273-289, Springer-Verlag, 1998.

[3] Jiri Fridrich, M. Long: “Steganalysis of LSB Encoding in Color Images”, pp. 1279-1282, ICME 2000.

[4] N. D. Memon, et al.: “Steganalysis Based on Image Quality Metrics”, SPIE Vol. 4314, Jan. 2001.

[5] A. N. Kolmogorov: ”Three Approaches to the Quantitative Definition of Information”, Problemy Peredachi Informatsii, Vol. 1, No. 1, pp. 3-11, 1965.

[6] A. Menezes, P. van Oorschot, and S. Vanstone: Handbook of Applied Cryptography, CRC Press, 1996.

[7] U. M. Maurer: “A Universal Statistical Test for Random Bit Generations”, Journal of Cryptology, Vol. 5, No. 2, 1992, pp. 89-105.

[8] David W. Hosner, S.Lemeshow: Applied Logistic Regression, John Wiley & Sons, New York, 1989.