13

Click here to load reader

Building advanced applications with the Belgian eID

Embed Size (px)

Citation preview

Page 1: Building advanced applications with the Belgian eID

SECURITY AND COMMUNICATION NETWORKSSecurity Comm. Networks 2010; 3:439–451Published online 1 February 2010 in Wiley Online Library(wileyonlinelibrary.com). DOI: 10.1002/sec.192

Building advanced applications with the Belgian eID

Jorn Lapon1*, Vincent Naessens1, Bram Verdegem1, Pieter Verhaeghe2 and Bart De Decker2

1Department of Industrial Engineering, Katholieke Hogeschool Sint-Lieven, Gebroeders Desmetstraat 1, 9000Gent, Belgium2Department of Computer Science, Katholieke Universiteit Leuven, Celestijnenlaan 200A, 3001 Heverlee, Belgium

Summary

The Belgian Electronic Identity Card (eID) was introduced in 2002. The card enables Belgian citizens to digitallyprove their identity and to sign electronic documents. Today, only a limited number of citizens really use the cardin electronic applications. An important reason is the lack of killer functionality and killer applications.

This paper presents two reusable extensions to the Belgian eID technology that opens up new opportunities forapplication developers. First, a secure and ubiquitously accessible remote storage service is presented. Second, itis shown how the eID card can be used to issue new certificates. The feasibility and reusability of both extensionsare validated through the development of several applications in different domains. Copyright © 2010 John Wiley& Sons, Ltd.

KEY WORDS: identity technology; security; privacy; mobile access

1. Introduction

In 2002, Belgium has introduced an electronic identitycard (eID) [1] as one of the first countries in Europe.The card enables individuals to digitally prove theiridentity and to sign electronic documents. The BelgianeID card opens up new opportunities for the govern-ment, their citizens, service providers and applicationdevelopers. Although many eID applications havebeen developed, the success of the Belgian eIDtechnology is still limited. An important reason is the

∗Correspondence to: Jorn Lapon, Department of Industrial Engineering, Katholieke Hogeschool Sint-Lieven, GebroedersDesmetstraat 1, 9000 Gent, Belgium.

†E-mail: [email protected]‡SAP Survey: Belgen verdeeld over gebruik van eID op het werk (sept. 2009 by Indigov).

lack of essential functionality and, more importantly,real killer applications. Moreover, the use of thecurrent eID card involves a few security and privacyhazards [2,3].

A recent survey on the use of the Belgian eID cardin corporate environments‡ suggests one of the mainobstacles for using the eID card is the mistrust in thetechnology. While about 99% of the Belgian citizenspossess a Belgian eID card, 56% of the respondentsnever used it. The most important applications forwhich the eID was used, were personal eGovernment

Copyright © 2010 John Wiley & Sons, Ltd.

Page 2: Building advanced applications with the Belgian eID

440 J. LAPON ET AL.

applications, such as tax-on-web or requests forofficial documents. Only 3.2% of the users digitallysigned documents with the eID. The eID card hasless penetrated the corporate environment. The mostimportant applications, access to workstations and spe-cific business applications only involved 9.4% of therespondents who used the eID. The results of anothersurvey§ show that Belgian citizens are rather unhappyabout the availability and the number of eID applica-tions.

This paper presents two enhancements to the currentBelgian eID technology while addressing relevant pri-vacy shortcomings. A first extension defines a servicethat allows users to securely store and update confi-dential data (such as passwords, cryptographic keys,tickets, . . . ) at a remote location. The service is ubiqui-tously accessible with the Belgian eID card. Moreover,the data kept at the server cannot be abused by internaland external attackers. A second extension defines thecreation and use of proxy certificates that are certifiedby means of the Belgian eID card. Hence, an individualcan create proxy certificates that can be used to sendconfidential messages, to setup a mutually authenti-cated secure channel between two individuals, etc. Anexternal certificate authority is no longer required toissue these certificates.

Both extensions are bootstrapped by means ofthe Belgian eID Card and can be integrated inmany applications. To demonstrate their reusability,both extensions are integrated in several applica-tions. Some of them only incorporate one extension.An application to securely access confidential datafrom various locations is based on the secure storageextension. Delegation schemes use proxy certificates.Both extensions have been combined in a securee-mail service that is ubiquitously available; Individ-uals can send and receive encrypted and/or signedmessages.

The paper is structured as follows. Section 2 gives anoverview of the Belgian eID card technology. Section 3describes the notation used in the rest of the paper. Twoextensions to the Belgian eID technology are proposedin Section 4 and Section 5.

Both extensions are validated through the develop-ment of applications (see Section 6) and related workis discussed in Section 7. Finally, the paper drawssome conclusions and outlines directions for futureresearch.

§De tevredenheidsenquête van de algemene directie instellin-gen en bevolking, 2008.

2. Belgian Electronic Identity CardTechnology

The Belgian eID card is a smart card that allows Bel-gian citizens to both visually and digitally prove theiridentity and to sign electronic documents [4]. The eIDcard contains three files: (1) a digital picture of the citi-zen, (2) an identity file which contains the basic identityinformation and a hash value of the picture file; thisfile is signed by the National Registry, (3) an addressfile which contains the citizen’s current residence; itis signed by the National Registry together with theidentity file to guarantee the link between both files.

Two private keys SKAuth and SKSig are stored in the eIDcard. These keys are used for digital authentication andsigning respectively. They are stored in a tamper-proofpart of the chip and can be activated with a PIN code.Each corresponding public key (PKAuth and PKSig) iscertified in a certificate. Each certificate also containsthe name of the card holder and his nation-wide uniqueidentification number (i.e., the National RegistrationNumber or NRN).

The Belgian government offers a middleware pack-age [5,6] to facilitate interaction with the eID card. Themiddleware contains a GUI to enable end-users to readthe files and the certificates that are stored in the eIDcard and to change the PIN code. Moreover, the mid-dleware acts as an intermediary for all accesses to theeID card by other applications. If a document has to besigned, the middleware passes a hash of the documentto the card. Similarly, a hash of the challenge is passedto the card for authentication purposes. When an appli-cation wants to authenticate or sign a document withthe eID card, the middleware asks the user for a PINcode and forwards it to the eID card. The middlewarecan also check the validity of certificates (using CRLor OCSP). Note that the middleware is not essential: anapplication can also implement the functionality of themiddleware itself and directly interact with the card.

The certificates on the eID card are part of alarger hierarchical infrastructure, the Belgian PublicKey Infrastructure [7]. The signature and authentica-tion certificates are issued by a Citizen CA and thecertificates of each Citizen CA are issued by the Bel-gium Root CA, which is found at the top of the eIDPKI hierarchy. In addition, the PKI maintains Certifi-cate Revocation Lists [8] that contain the serial numberof revoked certificates.

The government aims at encouraging the use of theeID card in both e-government and commercial appli-cations. Currently, most applications use the BelgianeID card for setting up an SSL connection with mutual

Copyright © 2010 John Wiley & Sons, Ltd. Security Comm. Networks 2010; 3:439–451

DOI: 10.1002/sec

Page 3: Building advanced applications with the Belgian eID

BUILDING ADVANCED APPLICATIONS WITH THE BELGIAN EID 441

authentication between a client and a remote serverapplication. Many other applications (such as physicalaccess control) only retrieve the identity informationstored on the card.

3. Notations

The following notations are used throughout this paper;U represents a user, E an entity (a user or a serviceprovider):

� U ↔ E : NRN← authenticateeID() represents aninteractive protocol, in which user U authenticateswith his eID card (which involves the use of SKAuth)to entity E. As a result, E obtains U’s NRN.

� U : Sig ← signeID(hashM(M)) denotes that user Usigns a message M with his eID card (which involvesthe use of SKSig); the message is first hashed to afixed-length bit string by the middleware (hashM).

� E : K ← createSymKey(PRG, seed) denotes thatthe entity E generates a secret symmetric key, basedon a pseudorandom number generator PRG and aseed. Use of the same PRG and seed will alwaysgenerate the same key.

� E : storeindex (data) means that data is stored byentity E in a database at location index.

4. Storing Confidential Data

A major challenge in today’s society is to enable accessto confidential data (e.g., personal information, secretkeys, . . . ) from various locations. Data must be securelystored on an easily accessible remote server. Data istypically encrypted by the owner before it is sent toand stored on the server. Hence, the encrypted data isuseless to the server or any adversary that may haveaccess to it. In this section a scheme is presented –based on the Belgian eID card– for securely storingconfidential data.

4.1. Construction

A trivial solution consists of encrypting the data withthe public key of the authentication certificate. When-ever needed, the ciphertext is fetched from the serverand decrypted using the corresponding private key.However, encryption/decryption with the Belgian eIDcard is not possible. Moreover, when the card is lost orrenewed, decryption of previously encrypted informa-tion is no longer possible. Therefore, a new mechanism

Table I. Storing confidential data remotely.

storeConfidentialData(data, tag):(1) U : keyGenMsg ← ’KEYGEN’ ‖

NRN ‖ CardNb ‖ otherUserInfo

(2) U↔ C : Sig ← signeID(hashM(keyGenMsg))

(3) U : KT ← createSymKey(PRG,

hashT(Sig))

(4) U : Etag ← encrypt(tag, KT )

(5) U : R ← generateRandom()

(6) U : KD ← createSymKey(PRG,

hashD(Sig ‖ R))

(7) U : Edata ← encrypt(data, KD )

(8) U↔ S : NRN ← authenticateeID()

(9) U→ S : (Edata, R, Etag)

(10) S : index ← hashL(NRN ‖ Etag)

(11) S : storeindex ([Edata, R])

(12) S : delete Etag

(13) U← S : (Timestamp, signS(hashR(

[Timestamp, Etag,

Edata,R])))

is proposed that uses the Belgian eID card as a boot-strap.

A secret (symmetric) key is derived from a signaturegenerated by the eID card. This secret key is used forencrypting data before it is stored. When a user wantsto retrieve his confidential information, the encryptedinformation is fetched from the server and decryptedwith the secret key, which is regenerated using the sameeID card. In the following paragraphs, the protocols forstoring and retrieving confidential data are discussed inmore detail.

Storing confidential data. Table I and Figure 1 showthe steps for storing confidential data. The user providesthe data to be stored and a secret tag that serves as aname or alias of the data.

First, the Belgian eID card is used to generate a secretkey as follows. A message keyGenMsg with a fixed for-mat is constructed (1). The message consists of a header‘KEYGEN’, the NRN, the serial number of the eIDcard and possibly some other user information, makingthe message card specific. The hash of the message,hashM(keyGenMsg) is then signed with the signaturekey on the eID card resulting in a 1024 bit signature Sig(2). The fixed format prevents that an adversary obtainsSig by requesting a signature on a forged message; anymessage to be signed by the eID card should not matchthis format, except in this protocol. Subsequently, Sigis used as the seed for generating two new symmetrickeys, namely KT and KD . To ensure that the samekeys are generated, independent of the platform, a

Copyright © 2010 John Wiley & Sons, Ltd. Security Comm. Networks 2010; 3:439–451

DOI: 10.1002/sec

Page 4: Building advanced applications with the Belgian eID

442 J. LAPON ET AL.

Figure 1. Storing confidential data.

specific pseudo-random generator PRG is passed asa parameter of the createSymKey function; also, thehash-functions used should be fixed. KT is used forencrypting the secret tag associated with the data. Thekey is derived from the hash of Sig (3-4). The encryptedtag Etag is used in step 10 of the protocol to derive anindex to a record in the server database. KD is used forencrypting the data. Each time information is stored(i.e., each time the protocol is invoked), a new randomnumber R is associated with it (5). From the hash of Rand Sig the encryption keyKD is derived (6) with whichthe data is encrypted into the ciphertext Edata (7). Ineach execution of storeConfidentialData the data willbe encrypted with another key; this prevents linking ofthe same encrypted data that is stored under multipletags.

Next, the encrypted data Edata is stored on a remoteserver S. First, the user authenticates with his eID, toensure that later only the owner U can retrieve hisuploaded data (8). Then, U sends the encrypted tag,Etag, and the encrypted data, Edata, to S (9). The NRN,disclosed during the authentication, is hashed togetherwith Etag and will be used as an index in the serverdatabase (10). The use of the encrypted secret tag, Etag,ensures the user’s privacy (index obfuscation), whilemaking the index tag specific. A different tag* willresult in a different index. Finally, the database storesa record with the encrypted data and the random num-ber R at location index (11). Although useless to theserver or any other adversary, the random number Ris necessary for the owner of the data to regeneratethe correct symmetric key for decrypting Edata. Etag isdeleted permanently (12). If the server S is trustwor-thy (i.e., it permanently deletes the Etag immediatelyafter storing Edata), dictionary attacks on the indexare no longer feasible. An adversary with full accessto the server data cannot link any data to a particularcitizen.

Table II. Retrieving confidential data remotely.

retrieveConfidentialData(tag):(1) U : keyGenMsg ← ’KEYGEN’ ‖

NRN ‖ CardNb ‖ otherUserInfo

(2) U↔ C : Sig ← signeID(hashM(keyGenMsg))

(3) U : KT ← createSymKey(PRG,

hashT(Sig))

(4) U : Etag ← encrypt(tag, KT )

(5) U↔ S : NRN ← authenticateeID()

(6) U→ S : requestRecord(Etag)

(7) U← S : record ← getRecord(

hashL(NRN ‖ Etag))

(8) S : delete Etag

(9) U : KD ← createSymKey(PRG,

hashD(Sig ‖ record.R))

(10) U : data ← decrypt(record.Edata, KD )

A receipt is sent to the user, certifying the properstorage of the encrypted data (13).

Retrieving confidential data. When the data has beenstored on the remote server, it can be retrieved by theowner from everywhere (see Table II). First, the mes-sage keyGenMsg is reconstructed (1) and signed withthe eID card (2). With the signature Sig, the secret keyKT (3) is regenerated for encrypting the secret tag (4).Next, the user authenticates to the server S with hiseID card (5). The encrypted secret tag, Etag, is sent andthe corresponding record is requested (6). The serverS fetches the record with index = hashL(NRN ‖ Etag)from his database; the record, comprising of encrypteddata and the random number, is sent to U (7). To ensureprivacy, Etag is permanently deleted (8). U can nowregenerate the data specific secret key KD from thehash of Sig and R (9). Finally, U decrypts Edata withthe secret key KD (10).

Recovery of lost keys. This scheme exploits theproperty that a deterministic signature algorithm is

Copyright © 2010 John Wiley & Sons, Ltd. Security Comm. Networks 2010; 3:439–451

DOI: 10.1002/sec

Page 5: Building advanced applications with the Belgian eID

BUILDING ADVANCED APPLICATIONS WITH THE BELGIAN EID 443

implemented in the eID card. When creating a signa-ture with the eID card, the same input (keyGenMsg),always results in the same signature Sig. As such, usingthe same PRG and the same hash-functions (hashT,hashD, hashL), the same secret keys KT and KD (fora certain R) are always regenerated. However, in caseof loss or renewal of the eID card, PKSig, SKSig andCardNb will have changed and the generated signatureSig* no longer matches the signature Sig (generatedby the previous eID card), impeding the localizationand decryption of the stored information. Therefore, toprotect important data, a secure backup of the signatureSig is created the first time this signature is generated.In case of loss or renewal, Sig is recovered from thebackup and the keys can be recomputed. This securebackup could be provided by a key escrow service.The secret Sig is then split into n parts using a secretsharing algorithm and each part is stored on a differentescrow server. To reconstruct the secret, all n parts areretrieved from the escrow servers and the interpolationof the parts results in the secret. To ensure that usersonly obtain their own keys, eID authentication can beused with the escrow servers [9,10]. Additionally, ahash of the NRN and the serial number of the eID cardcan be used as an index to store a part of the secret.Every citizen can –online– lookup his current and pre-vious card numbers at the National Registry. With thisscheme, the capabilities of the eID card (authentica-tion and signing) are extended with a mechanism tostore and retrieve confidential data without the need tohave a secure key management mechanism. The useronly needs his card to access the encrypted data thatis stored on the remote server. However, adversariesmight try to get hold of the secret keys by continu-ously sending challenges to the eID card. Our solutiontackles the threat by using the signature key in theeID card. Signing requires a PIN for every signa-ture while authentication requires only a PIN the firsttime (Single Sign-On feature of the eID card). More-over, the fixed format of the message allows to detecttrojan horses or malicious applications that requestusers to sign a message resembling the proposedformat.

5. Proxying the Belgian eID

In the previous section, a scheme was designed to per-form symmetric encryption based on the Belgian eIDcard. However, when other parties are involved, asym-metric encryption may be required. Therefore, a secondencryption scheme based on the eID card is proposed.

5.1. BeID proxy certificates

Although the eID card itself cannot encrypt nor decryptdata, the right to do this can be delegated to thesystem to which the card reader is connected. Thisrestricted delegation and proxying to another entity canbe achieved through proxy certificates [11].

In the sequel we will abbreviate the phrase ‘signedwith the private key that corresponds to the publickey certified in a certificate’ into ‘signed with thecertificate’.

Proxy certificates. A proxy certificate is an extendedversion of a normal X.509 certificate. Proxy certifi-cates are derived from and, hence, signed by a normalX.509 certificate or by another proxy certificate. Forevery proxy certificate, a new key pair is generated;the new public key is included in the proxy certificate.The proxy certificate and its corresponding privatekey can be used for asymmetric encryption resp.decryption.

Modified standard. The standards for proxy certifi-cates, as defined in the RFC 3820 [11], present someproblems when used in the context of the BelgianeID. Therefore, some modifications have to be made(see Figure 2). First, according to the RFC, proxycertificates should be signed with the authenticationcertificate, since only this certificate of the Belgian eIDcontains the required value for the key-usage attribute.‖The key-usage attribute defines the purpose of thecorresponding private key. However, using the authen-tication key SKAuth is less secure than using the signaturekey SKSig since the PIN is only required for the firstauthentication, while it is required for every signature.Therefore, we propose to use SKSig for signing proxycertificates. Second, Belgian legislation prohibitsnon-authorized companies to store the NRN. However,the subject field contains both the owner’s name andhis NRN. This implies that the eID certificates may notbe stored. Nevertheless, the proxy certificate standardspecifies that the subject of the issuing certificate isto be copied into the issuer and subject fields of newproxy certificates. To solve this problem, we proposeto copy the name of the owner into the subject field andto copy the hash of the NRN into the issuer field insteadof the subject of the eID certificate. For validationpurposes, the serial number of the issuer certificate isalso included in the certificate (i.e., issuerSN). Addi-tionally, another extra attribute indicates the certificate

‖In the Belgian eID card, the authentication certificate has askey usage Digital Signature, while the signature certificatecontains Non-repudiation!

Copyright © 2010 John Wiley & Sons, Ltd. Security Comm. Networks 2010; 3:439–451

DOI: 10.1002/sec

Page 6: Building advanced applications with the Belgian eID

444 J. LAPON ET AL.

Figure 2. Content of the modified proxy certificate.

Table III. Create a new proxy certificate.

createBeIDProxy([attributes]):(1) U : (SKU, PKU ) ← generateKeyPair()

(2) U : issueDate ← getDate()

(3) U : serialNb ← hash(NRN ‖ issueDate)

(4) U : proxyCert ← generateProxy(

BEID-PROXY, certSig, serialNb,

PKU , issueDate, crlLocation,

[attributes])

(5) U↔ C : Sig ← signeID(hashM(proxyCert))

(6) U : proxyCert.Sig ← Sig

type: BEID-PROXY. In this scheme, we assume thatwhen the eID certificate is revoked (e.g., in case ofloss or theft), all issued proxy certificates are also nolonger valid. Moreover, every proxy certificate mustexpire before the expiration date of the issuing eIDcertificate.

The protocol in Table III demonstrates the creationof a BeID proxy certificate. The user U generates anasymmetric key-pair (1). A serial number is generatedfrom the hash of the NRN and the issueDate of the newproxy certificate (2-3). The NRN in the hash avoids col-lisions, while the issueDate enables users to have morethan one proxy certificate. A proxy certificate proxyC-ert is then generated and signed with the eID card (4-5).Finally, the signature is inserted in the certificate.

Revocation of proxy certificates. A special purposeserver RP can keep track of revoked proxy certificatesand publish the appropriate CRLs. To revoke a proxycertificate (cf. Table IV), the user authenticates withhis eID card (1) and sends the proxy certificate he

Table IV. Revoke a proxy certificate account.

revokeBeIDProxy(proxyCert):(1) U ↔ RP : NRN ← authenticateeID()

(2) U → RP : revokeCertificate(

proxyCert.serialNb)

(3) S : if (hash(certSig.SubjectName.NRN)

�= proxyCert.Issuer) abort

(4) U ← S : true ← addToCRL(proxyCert.serialNb)

wants to revoke (2). If the issuer corresponds to the eIDsigning certificate (i.e., hash(certSig.NRN) = proxyC-ert.Issuer), the proxy certificate is revoked by addingits serial number to the latest CRL.

Validation. A receiver validates a new proxy certifi-cate by checking its signature, the validity period, itsrevocation status and by verifying the rest of the cer-tificate chain. Since the hash of NRN is kept in theissuer field, name chaining (cf. RFC 3280 [12]) for cer-tification path validation will fail. However, the extraattribute issuerSN included in the certificate binds theeID certificate to the proxy certificate. The first step increating the certification path needs thus to be mod-ified: the serial number of its issuing eID certificatemust match the issuerSN in the proxy certificate.

To comply with Belgian legislation, the eID certifi-cate is deleted after validation. Hence, future validationis not possible. However, verifying the validity periodand the revocation status suffices as the proxy certifi-cate was stored on a trusted location after its validation.Additionally, the revocation status of the eID certificatecan be verified by checking the issuerSN of the proxycertificate in the CRLs of the Belgian eID.

Copyright © 2010 John Wiley & Sons, Ltd. Security Comm. Networks 2010; 3:439–451

DOI: 10.1002/sec

Page 7: Building advanced applications with the Belgian eID

BUILDING ADVANCED APPLICATIONS WITH THE BELGIAN EID 445

The scheme described in this section allows for cre-ating legitimate proxy certificates (created with the eIDcard), that can be used in many applications. Moreover,once a proxy certificate has been created, the BelgianeID is no longer required.

5.2. Evaluation

The proxy certificate mechanism allows owners of aneID card to setup mutually authenticated secure chan-nels without the need for a trusted third party. Securecommunication is even no longer restricted to SSL.The proposed system with proxy certificates makes itmore flexible and extensible. Although not completelycomplying with the standards, the proposed schemesupports asymmetric encryption with the eID card.Moreover, the proxy certificates can be used for asyn-chronous communication (i.e., recipients can decryptconfidential messages after the communication channelhas been closed).

Once the receiver of a proxy certificate has deletedthe eID certificate that signed the proxy certificate(as is imposed by Belgian legislation), he can stillcheck the validity of the proxy certificate and the revo-cation status of the eID certificate. Although othercertificates in the validation path (i.e., Citizen CA, Bel-gium Root CA, . . . ) may have been revoked, the proxycertificate can include the serial numbers and the CRL-locations of these certificates as extra attributes as well,to make the verification of the rest of the certificatechain possible. Note that optional attributes in the proxycertificate may further restrict its use.

The storage of the private key corresponding to thepublic key in the proxy certificate requires more trustin the device storing it. A developer must pay specialattention on how to use this technology. For instance,when using proxy certificates on mobile phones, thedeveloper should store the private key inside the SIMcard. Moreover, revocation and a limited validity periodmay reduce the implications of a stolen private key.Anyhow, revoking a proxy certificate causes less bur-den than revoking eID certificates.

6. Applications

The extensions discussed above promise new opportu-nities for the Belgian eID technology. The proposedextensions can be used in a variety of applications.The following applications demonstrate their reusabil-ity. However, depending on the application, some finetuning may be required.

6.1. Secure storage applications

6.1.1. A local secure vault

Workstations are often used by multiple users. In ahome environment, a laptop is used by different mem-bers of the family. In a work environment, a computermay be shared by multiple colleagues. It is often notvery difficult to access other users’ confidential data(such as passwords, secret keys, . . . ) unless appropriatecountermeasures are taken.

This application uses the secure storage scheme forthe implementation of a local credential vault. As such,users do not have to remember their passwords any-more (except for the PIN code of their eID card), whichallows them to select more secure passwords. Everyuser has the exclusive right to access his own credentialvault to store, access and update confidential data. In ahome environment, index obfuscation may be omitted;hence, the scheme can be simplified.

6.1.2. Shared confidential files

With some small modifications to the secure stor-age extension, it is possible to have shared access tosecurely stored information. Hence, it is easy to buildclosed user groups in a corporate environment (e.g.,managers can share top secret documents, developmentteams and focus groups can share confidential projectinformation, . . . ). The data are ubiquitously accessibleand no secrets are stored.

We assume a common file server S (with access con-trol mechanisms). For every shared encrypted file, ‘F’,a companion file, ‘.F.keys’, is generated which containsfor every user Ui with access to F a tuple [Ui, Ri, �i]which is used to recreate the symmetric key with whichF has been encrypted. The companion file will be main-tained (i.e., can only be modified) by the owner ofthe shared encrypted file. However, the companion filedoes not contain secrets and, hence, does not need tobe kept confidential except maybe for privacy reasons(to hide who has access to a file).

Decryption. The scheme works as follows (cf.Table V): Ui retrieves his tuple from the companionfile (1) and generates a signature on a fixed messagewith his eID card (2-3). Then, the signature, the file’sname ‘F’ and Ri are hashed into a fixed-length bit stringwhich is xor-ed with �i to serve as a seed for the keygeneration function (4). The generated key K can beused to decrypt the file F or to re-encrypt the modifiedcontent.

Setup. The owner of the shared file (Uo) generates arandomly chosen seed, which will be used for gener-

Copyright © 2010 John Wiley & Sons, Ltd. Security Comm. Networks 2010; 3:439–451

DOI: 10.1002/sec

Page 8: Building advanced applications with the Belgian eID

446 J. LAPON ET AL.

Table V. Decrypting a shared encrypted file.

keyGenSharedFile(‘F’):(1) Ui ← S : (Ui, Ri, �i) ← readTuple(‘.F.keys’, Ui)

(2) Ui : keyGenMsgi ← ’SHARED-KEYGEN’ ‖NRNi ‖ CardNbi ‖ otherUserInfo

(3) Ui : Sigi ← signeID(hashM(keyGenMsgi))

(4) Ui : K ← createSymKey(PRG,

hashS(Sigi ‖ ‘F’ ‖ Ri) ⊕ �i)

Table VI. Setting up the companion file with key material.

sharedKeySetup(‘F’):(1) Uo : Ro ← generateRandom();

(2) Uo : seed ← generateRandomSeed();

(3) Uo : keyGenMsgo ← ’SHARED-KEYGEN’ ‖NRNo ‖ CardNbo ‖ otherUserInfo

(4) Uo : Sigo ← signeID(hashM(keyGenMsgo))

(5) Uo : �o ← seed ⊕ hashS(Sigo ‖ ‘F’ ‖ Ro)

(6) Uo → S : createKeyFile(‘.F.keys’, [Uo, Ro, �o])

ating a secret symmetric key K with which the file Fcan be encrypted and decrypted. The scheme works asfollows (cf. Table VI):

Uo first selects a random value Ro and a random seed(1-2), generates a signature on a fixed message (whichis eID card specific) (3-4). Then, the bitwise differencebetween the seed and the hash of the signature, thefile’s name ‘F’ and the random value Ro is computed(5). Finally, the companion file is created with contentthe tuple [Uo, Ro, �o] (6).

Extending the set of sharing users. A new user Uj

(j > i) can be added to the companion file by Uo viaa similar scheme (cf. Table VII). The owner Uo invitesuser Uj to send the necessary information to updatethe companion key-file (1). Uj will generate a randomvalue Rj and sign a fixed message with his eID card (2-4). The signature is hashed with the file name ‘F’ and

Table VII. Extending the set of users.

sharedKeyExtension(‘F’):(1) Uj ← Uo : prepare for sharing ‘F’

(2) Uj : Rj ← generateRandom();

(3) Uj : keyGenMsgj ← ’SHARED-KEYGEN’

‖NRNj ‖ CardNbj ‖ otherUserInfo

(4) Uj : Sigj ← signeID(hashM(keyGenMsgj))

(5) Uj : Hj ← hashS(Sigj ‖ ‘F’ ‖ Rj)

(6) Uj → Uo : Rj , Hj

(7) Uo : �j ← seed⊕ Hj

(8) Uo → S : appendKeyFile(‘.F.keys’, [Uj , Rj , �j])

the random value Rj (5). Then, Rj and Hj are sent to theowner over a secure channel (6) who will xor Hj withthe secret seed (8) and update the companion file (9).

Note that in this scheme, the only secret that needsto be sent over the network is Hj: if an eavesdrop-per gets hold of that value, and later fetches �j fromthe companion file, he could easily construct seed and,hence, generate the secret key. A solution using proxy-certificates is presented in Section 6.3.2. Of course, anyother means to securely transfer that value from Uj toUo could also be used (e.g., transfer via memory stick).

The use of random values Ri is necessary to allowfor the removal of users from the set or to allow forrenewing the encryption key of the confidential file.Otherwise, the users who have been removed from theset, could easily recompute the file’s encryption key.

Evaluation. Sigi is secret and never leaves the user’sworkstation. If an adversary does get hold of the Sigi ofa group member, the user must change otherUserInfo.For instance, it may include an updated version num-ber. However, all files shared by the user must bere-encrypted with new keys and all corresponding keyfiles must be updated (new keys must be chosen). Addi-tionally, a GroupID can be included into otherUserInfo.This ensures a different Sig per group. However, thePIN-code will have to be entered multiple times whenfiles belonging to different groups are consulted. Thehash hashS(Sigi ‖ ‘F’ ‖ Ri) is file and version specific.Hence, all group members can compute it, but it cannever be used to access another file. This prevents auser with knowledge of the seed and encryption key ofone file, to calculate the encryption key of another file.

The scheme is efficient and user-friendly. As Sigi isgroup specific, the PIN is required only once for everygroup involved. The same Sigi is used to generate keysfor every file that is shared by the same group.

Note that the access control mechanism of the filesystem can limit the consequences of a breach of Sigi.

6.2. Proxy

The Belgian proxy certificates scheme bootstraps lotsof practical applications. The use of an existing nation-wide Belgian PKI infrastructure, maintained by thegovernment considerably decreases the implementa-tion costs of applications requiring strong security.Moreover, rights can be delegated to other devicesand/or individuals. Constraints (e.g., purpose, location,time intervals, . . . ) and liabilities can be included inproxy certificates.

Proxy certificates may ease interoperability of eIDinfrastructures of different countries. However, legis-

Copyright © 2010 John Wiley & Sons, Ltd. Security Comm. Networks 2010; 3:439–451

DOI: 10.1002/sec

Page 9: Building advanced applications with the Belgian eID

BUILDING ADVANCED APPLICATIONS WITH THE BELGIAN EID 447

lation may impose restrictions. The use of the BelgianeID certificate, required to verify the validity of aproxy certificate, is restricted by Belgian legislation.Moreover, the certificate contains personal informa-tion which brings the privacy of the owner at stake.For instance, a proxy certificate that serves as a servercertificate should not be used for securing a publicwebsite.

Additionally, it is important to carefully handlethe private keys associated with the proxy certifi-cates. Below, three different application domains arepresented in which the proxy certificates can beused, namely delegation of rights to another device,delegation of rights to another person and secure com-munication channels.

6.2.1. Delegation to another device

The GSM trade association has announced that thenumber of mobile devices has passed the 4 billion markin December 2008. This number represents more than60 per cent of the world’s total population. The numberof portable Internet-enabled devices are set to grow to1.5 billion by 2012. Experts anticipate that by 2020,mobile phones will be the primary Internet devices formost people in the world. It is to be expected that mobiledevices will become the main guardians and man-agers of our multiple electronic identities for a broadrange of applications and services which include pay-ments, e-health, e-government, etc. The Belgian eIDcard may be used to delegate electronic identities tomobile devices. Hence, Belgian proxy certificates canbe stored and used on mobile devices to secure accessto corporate email and resources, personal health dataor e-government applications based on a nation wideinfrastructure.

A major reason to implement single-sign-on forauthentication is that a private key operation on thecard is required to renew the session key during anSSL session. The server typically fixes the time intervalbetween two session renewals. However, single-sign-on results in severe security and privacy threats usingthe Belgian eID card as discussed in [2]. Proxy cer-tificates may solve this problem as the user maytemporarily delegate the right to access that specificservice to the browser.

Further, it supports a physical access control mecha-nism. A building automation system may allow accessto a building or secure area based on the identity ofindividuals. Using proxy certificates, their identity canbe proved easily.

6.2.2. Delegation to other individuals

A second application domain is where one person del-egates his rights to another individual by means of aproxy certificate to allow that individual to sign orauthenticate in the name of the delegator. The followingare two examples:

A first example concerns online-tax-declaration.Currently, online-VAT-declaration requires a digitalsignature based on the Belgian eID of the employeesubmitting the declaration, instead of the director ofthe company. However, using a proxy certificate, theemployee can declare the taxesin the name of thedirector. Moreover, the proxy certificate can includerestrictions. For instance, it may include that it is onlyvalid forvat-declarations, during office hours, by a spe-cific employee.

A second example in which this kind of delegationmay be useful is for delegating certain privileges (suchas physical access rights) to another person.

6.2.3. Secure communication

In contrast with the Belgian eID card, proxy certificatesfacilitate encryption and decryption. As such, based onan existing nation-wide PKI infrastructure, it is pos-sible to implement peer to peer SSL communication.For instance, in a secure chat application, trust can beestablished between two persons based on these proxycertificates, as both are signed with the eID card.

6.3. Combined

A combination of both schemes is shown below.

6.3.1. Secure email

Combining both extensions enables the developmentof a secure email application based on the Belgian eIDtechnology. It supports exchanging confidential e-mailmessages using the BeID proxy mechanism describedin Section 5. Moreover, individuals can use the e-mailservice at any location as the necessary key materialand contact information are stored securely on an easilyaccessible remote server.

Setup. Every user generates a BeID proxy certificate,sends it to his contacts and retrieves a proxy certifi-cate from every contact. This procedure contains thevalidation of the eID certificate as well as the proxycertificate itself. Next, The user contacts his remotesecure storage and stores the proxy certificates of hiscontacts, together with his own proxy certificate andcorresponding private key.

Copyright © 2010 John Wiley & Sons, Ltd. Security Comm. Networks 2010; 3:439–451

DOI: 10.1002/sec

Page 10: Building advanced applications with the Belgian eID

448 J. LAPON ET AL.

Sending and receiving messages. When a user wantsto send an email message, he generates a symmetric keySK and encrypts the message M. Next, for every recip-ient, he fetches the corresponding proxy certificate,which he received during the setup, from his remotesecure storage. The key SK is encrypted with the publickey of each of these proxy certificates. As a result, thereare as much encrypted secret keys as there are recipi-ents (i.e., ESK−contact1, ESK−contact2, . . .). Finally, theencrypted message, together with the encrypted keysis sent to the recipients.

When a user receives an encrypted message, heselects his personal proxy certificate used to encryptthe symmetric key and fetches the corresponding pri-vate key from the secure store. Finally, the symmetrickey is decrypted and used for decrypting the message.

6.3.2. Extended shared secure storage

To enhance the security of the shared secure stor-age scheme discussed above, proxy certificates areintroduced. The secret Hj needs to be sent over thenetwork. An adversary may use this information tobreak the security of the scheme. Therefore, beforesending the hash Hj , it is encrypted with the publickey of the owner’s (Uo) proxy certificate. The mod-

Table VIII. Extending the set of users with secure communica-tion.

sharedKeyExtension(‘F’):(1) Uj ← Uo : prepare for sharing ‘F’, proxyCerto(2) Uj : Rj ← generateRandom();

(3) Uj : keyGenMsgj ← ’SHARED-KEYGEN’ ‖NRNj ‖ CardNbj ‖ otherUserInfo

(4) Uj : Sigj ← signeID(hashM(keyGenMsgj))

(5) Uj : EHj← encrypt(hashS(Sigj ‖ ‘F’ ‖ Rj),

proxyCerto.pk)

(6) Uj → Uo : Rj , EHj

(7) Uo : Hj ← decrypt(EHj, PRo)

(8) Uo : �j ← seed⊕ Hj

(9) Uo → S : appendKeyFile(‘.F.keys’, [Uj , Rj , �j])

ified sharedKeyExtension protocol from Table VIIbecomes.

6.4. Evaluation

Figure 3 gives an overview of the number ofPIN requests and cryptographic operations for eachapplication. The former is relevant to evaluate theuser-friendliness. The latter has an impact on the

Figure 3. Application overview.

Copyright © 2010 John Wiley & Sons, Ltd. Security Comm. Networks 2010; 3:439–451

DOI: 10.1002/sec

Page 11: Building advanced applications with the Belgian eID

BUILDING ADVANCED APPLICATIONS WITH THE BELGIAN EID 449

performance. In many applications, a reasonable trade-off must be made between multiple non-functionalqualities (e.g., performance, security/privacy, user-friendliness, degree of mobility, . . . ). Slight modifica-tions of the protocols may increase/decrease the qualityof some parameters. This is argued with some exam-ples.

Proxy certificates can be used to access files inthe shared secure storage application (instead of cer-tificates on the eID card). This may increase themobility and user-friendliness as individuals can nowretrieve/update files on platforms without a smart cardreader. Moreover, the user does not need to enter hisPIN code when accessing a file. However, the usermust run the sharedKeyExtension again to generatea Sig’ in step (4) using his proxy certificate and thekeyfile must include an extra entity. This allows him toaccess the shared storage with a mobile device. How-ever, the private key of the proxy certificate must bestored securely on the mobile device. Otherwise, thesecurity properties decrease.

Index obfuscation can be omitted to increase the per-formance of the local secure storage application. If so,less cryptographic operations are required. However,this may have a negative impact on the privacy prop-erties (i.e., an attacker can derive which individualskeep data at the local store). However, this is accept-able in certain settings (such as workstations in a homeenvironment).

The extended shared secure store has better secu-rity properties compared to the shared secure store.The extension allows users to send the hash Hj overa secure channel. However, the proxy certificate (andcorresponding private key) must be available.

The secure storage extension is more user-friendlyif the authentication certificate on the eID card is usedto generate the Sig (i.e., the pin code must only beentered once). Nevertheless, the signature certificate ismore secure.

7. Related Work

The first eID extension may solve current passwordproblems. First, a password vault can be protected bystrong security techniques (i.e., by means of a symmet-ric key that is (re-)generated based on the private keyon the eID card). Second, less intuitive passwords canbe selected. A strong password generator can be used.The user does not have to remember any password.They can be loaded automatically from the vault tothe application. There is no reason to reuse passwords.

Hence, our password vault meets many concerns thatare raised in Reference [13].

Secure storage mechanisms often require high trustin the server. Other solutions like CRUST [14] decreasethe level of trust in the server, since secret information isstored locally. The latter, however, are not ubiquitouslyaccessible. Our solution combines the advantages ofboth, requiring less trust in the server, while beingeasily accessible.

Theft of the device is a major security concern asis raised in a European study by Enisa on authentica-tion using mobile devices, particularly in the case of aMobile Device as National ID card [15]. Our solutiondoes not propose to store the full electronic identity onthe mobile device. Instead, proxy certificates are lim-ited in terms of lifetime, purpose, etc. For instance,an upper-bound to the lifetime of proxy certificatescan be imposed. Restricting the purpose of proxycertificates in combination with appropriate accesscontrol mechanisms may further reduce risks in case ofloss.

Reference [16] presents proxy certificates issued bycertificates on smart cards for bank transactions. Thepurpose of this technique is to increase the mobilityof the SET/A protocol while preserving an acceptablelevel of security. The mechanism is based on a mobileagent traveling form the card holder’s computer,carrying all relevant information about the transactionto a remote server. On arrival, the agent performsthe card holder’s role and carries on a complete SETpurchase request transaction with the merchant. Fromthe merchant’s point of view, there will be no distinc-tion between an agent and a real buyer. Our approachgeneralizes the concept (i.e., the eID card is used toissue proxy certificates that can be used in differentdomains). Moreover, we presented proxy certificatesto extend eID functionality (i.e., proxy certificates canbe used to encrypt/decrypt data), whereas Reference[16] just introduces proxy certificates to clone thefunctionality of the bank card. Our proxy certificatescan be used in different domains as no specificpurpose is included in the eID certificates. However,privacy concerns have to be tackled in our system.Some modifications to the proxy certificate standardswere required. Reference [16] suggests to includeconstraints in proxy certificates for money transfer.Similarly, constraints can be kept in BeID proxy certifi-cates (e.g., limited lifetime, purpose, . . . ). Moreover,liabilities can be kept in proxy certificates. Reference[17] formalizes liability-aware certificates: the issuercan specify to which extent he is willing to take liabil-ities for certain types of abuse. Enclosing liabilities in

Copyright © 2010 John Wiley & Sons, Ltd. Security Comm. Networks 2010; 3:439–451

DOI: 10.1002/sec

Page 12: Building advanced applications with the Belgian eID

450 J. LAPON ET AL.

proxy certificates might be useful if they are delegatedto other individuals (e.g., the online-vat-declarationapplication).

Both eID extensions might be useful in certain P2Papplications. A lot of research has been performed todecentralize security functionality in order to avoidbottlenecks and deployment problems using CAs (i.e.,to ease key management). Therefore, many reputa-tion based P2P approaches were proposed [18--20].Our eID extensions solve many key managementproblems. The eID can be used to bootstrap proxycertificates, to set up and manage secure (shared)stores, to set up secure communication channels, toshare confidential information, . . . However, uniqueidentifiable information (i.e., NRN) is kept in the eIDcertificate. Therefore, using some of the mechanismsin public P2P systems (such as bittorrent, napster, etc.)might lead to privacy problems.

Similarly, the secure email application has manyadvantages with respect to other existing secure emailsystems such as PGP [21,22] and S/MIME [23]. Theuser can manage his emails from any workstationwhere a card reader is available. Note that the Belgiangovernment distributes card readers for free to encour-age the use of the eID card. In contrast with PGP inwhich trust is based on chains of trust, our solution isbased on valid certificate chains. S/MIME also offers asolution to send confidential messages based on certifi-cate chains. However, our eID based solution providesstronger security while maximizing the availability.

Moreover, the creation of a BeID proxy certificatedoes not require a complex registration procedure. Theindividual can even create a proxy certificate off-line.

8. Conclusion

This paper presents two reusable extensions to the Bel-gian eID technology, namely a ubiquitously accessibleremote secure storage service and a mechanism to issueproxy certificates. The former allows Belgian citizensto manage confidential personal data such as contactinformation, passwords, keys, tickets, etc. The lattercan be used to self-certify asymmetric encryption keys.The validation of the proxy certificates slightly deviatesfrom the standard, because of the current design of theeID certificates and restrictions imposed by the Belgianlegislation. However, this problem can easily be solvedby redesigning the eID certificates. Hence, this paperalso offers some guidelines for countries that considerintroducing an eID card in the future. The value of theextensions has been demonstrated for each extension

individually and for the combination of both by severalinteresting applications.

Although the two extensions open up new opportu-nities for applications in different domains, the papershows that fine-tuning is often required to optimizethe extensions in a particular setting. Moreover, thedesigner should carefully analyze the feasibility ofextensions for a particular application. For instance,many applications can benefit from this extension in acorporate or private environment. However, using theeID extensions in public domains is not trivial due tomodified trust assumptions and privacy concerns.

Acknowledgements

This research is partially funded by the InteruniversityAttraction Poles Program Belgian State, Belgian Sci-ence Policy and the Research Fund K.U.Leuven, theIWT-SBO project ADAPID and the IWT-Tetra projecte-IDea.

References

1. De Cock D, Wolf C, Preneel B. The Belgian Electronic Iden-tity Card (Overview). Sicherheit 2005: Sicherheit—Schutz undZuverlassigkeit, Beitrage der 3rd Jahrestagung des Fachbere-ichs Sicherheit der Gesellschaft fur Informatik e.v. (GI), LectureNotes in Informatics (LNI), Vol. LNI P-77, Dittmann J (ed.).Bonner Kollen Verlag: Magdeburg, DE, 2006; 298–301.

2. Verhaeghe P, Lapon J, De Decker B, Naessens V, VerslypeK. Security and privacy improvements for the belgian eidtechnology. 24th IFIP International Information Security Con-ference (SEC), Springer, Boston, 2009. https://lirias.kuleuven.be/handle/123456789/215296

3. Dumortier J. eid en de paradoks van het rijksregisternummer2005.

4. Stern M. Belgian Electronic Identity Card content. Zetes, CSC,(2.2 edn) 2003.

5. Andries P. eID Middleware Architecture Document. Zetes, (1.0edn) 2003.

6. Rommelaere J. Belgian Electronic Identity Card MiddlewareProgrammers Guide. Zetes, (1.40 edn) 2003.

7. Ramlot G. eID Hierarchy and Certificate Profiles. Zetes, Certi-post, (3.1 edn) 2006.

8. Belgian certificate revocation list. http://status.eid.belgium.be/.9. Shamir A. How to share a secret. Communications of

the ACM 1979; 22(11): 612–613, http://doi.acm.org/10.1145/359168.359176

10. Bellare M, Goldwasser S. Verifiable partial key escrow. CCS’97: Proceedings of the 4th ACM Conference on Computer andCommunications Security, ACM: New York, NY, USA, 1997;78–91, http://doi.acm.org/ 10.1145/266420.266439

11. Tuecke S, Welch V, Engert D, Pearlman L, Thompson M. Rfc3820—internet x.509 public key infrastructure (pki) proxy cer-tificate profile. 2004. http://www.ietf.org/rfc/ rfc3820.txt

12. Housley R, Polk W, Ford W, Solo D. Internet x.509 public keyinfrastructure certificate and certificate revocation list (crl) pro-file 2002.

Copyright © 2010 John Wiley & Sons, Ltd. Security Comm. Networks 2010; 3:439–451

DOI: 10.1002/sec

Page 13: Building advanced applications with the Belgian eID

BUILDING ADVANCED APPLICATIONS WITH THE BELGIAN EID 451

13. Geron E, Wool A. CRUST: cryptographic remote untrustedstorage without public keys. International Journal of Informa-tion Security 2009; 8(5): 357–377, 10.1007/s10207-009-0081-6.http://dx.doi.org/10.1007/ s10207-009-0081-6

14. ENISA. Security issues in the context of authentication usingmobile devices (mobile eid). http://www.enisa.europa.eu/act/it/eid/mobile-eid 2008

15. Gaw S, Felten EW. Password management strategies for onlineaccounts. SOUPS ’06: Proceedings of the Second Symposiumon Usable Privacy and Security, ACM: New York, NY, USA,2006; 44–55, http://doi.acm.org/ 10.1145/1143120.1143127

16. Rom A ao, Silva MMd. Secure mobile agent digital signatureswith proxy certificates. E-Commerce Agents, Marketplace Solu-tions, Security Issues, and Supply and Demand, Springer-Verlag:London, UK, 2001; 206–220.

17. Herreweghen EV. Secure anonymous signature-based trans-actions. ESORICS ’00: Proceedings of the 6th EuropeanSymposium on Research in Computer Security, Springer-Verlag:London, UK, 2000; 55–71.

18. Xiong L, Liu L. Peertrust: supporting reputation-based trustfor peer-to-peer electronic communities. IEEE Transactionson Knowledge and Data Engineering 2004; 16(7): 843–

857, http://doi.ieeecomputersociety.org/10.1109/TKDE.2004.1318566

19. Selcuk AA, Uzun E, Pariente MR. A reputation-based trust man-agement system for p2p networks. CCGRID ’04: Proceedings ofthe 2004 IEEE International Symposium on Cluster Computingand the Grid, IEEE Computer Society: Washington, DC, USA,2004; 251–258.

20. Damiani E, di Vimercati DC, Paraboschi S, Samarati P,Violante F. A reputation-based approach for choosing reli-able resources in peer-to-peer networks. CCS ’02: Proceedingsof the 9th ACM conference on Computer and communi-cations security, ACM Press: New York, NY, USA, 2002;207–216, 10.1145/586110.586138. http://dx.doi.org/10.1145/586110.586138

21. Garfinkel S. PGP: Pretty Good Privacy. O’Reilly Media, 1994.http://www.amazon.ca/exec/obidos/redirect?tag=citeulike09-20% &path=ASIN/1565920988

22. Callas J, Donnerhacke L, Finney H, Shaw D, Thayer R.OpenPGP Message Format. RFC 4880 (Proposed Standard) Nov2007. http://www.ietf.org/rfc/rfc4880.txt

23. Ramsdell B. Rfc 2633—s/mime version 3 message specification1999. http://www.ietf.org/rfc/rfc2633.txt

Copyright © 2010 John Wiley & Sons, Ltd. Security Comm. Networks 2010; 3:439–451

DOI: 10.1002/sec