DOCUMENTOS Y REFERENCIAS RELACIONADOS EN EL ANEXO

Transcription

DOCUMENTOS Y REFERENCIAS RELACIONADOS EN EL ANEXO
DOCUMENTOS Y REFERENCIAS RELACIONADOS EN EL ANEXO EXPERIENCIA DE ESTONIA 1.
2.
3.
4.
5.
6.
7.
8.
Certificates.mht -­‐ http://www.id.ee/index.php?id=31013 Mobil ID.mht -­‐ http://id.ee/index.php?id=36877 Mobil ID Protocol.pdf eID Estonia.pdf eID Estonia Market vs Governance.pdf Electronic Signature.mht -­‐ http://eturundus.eu/digiallkirja-­‐kalkulaator/ egov Estonia.pdf Aplicaciones Sostenibilidad E-­‐Stonia.htm -­‐ https://www.foreignaffairs.com/articles/eastern-­‐europe-­‐caucasus/2015-­‐
01-­‐28/e-­‐stonia-­‐and-­‐future-­‐cyberstate#main-­‐menu 9. Modelo de Negocio.pdf 10. Estrategia Digital Estonia.pdf 11. Marco Regulatorio eID Estonia.pdf 12. Estrategia de uso eID Estonia.pdf 13. An†lisis TÇcnico Arquitectura.pdf 14. Modelo Interoperabilidad.pdf 15. Casos Exito.pdf 16. Explicacion Completa Modelo Estonia.pdf 17. Implementacion Tecnica.pdf 18. Componentes Socioculturales.htm -­‐ https://e-­‐estonia.com/ 19. Modelo Open Goverment.pdf 20. Mejores pr†cticas egov.pdf 21. eID Card and Digital Signature.pdf Formal Analysis of the Estonian Mobile-ID
Protocol
Peeter Laud1,2 and Meelis Roos1,2
1
2
Cybernetica AS
Tartu University, Institute of Computer Science
Abstract. In this paper, we report the results of the formal analysis
performed on the Estonian Mobile-ID protocol (deployed since 2008), allowing citizens and permanent residents of Estonia to authenticate themselves and issue digital signatures with the help of a signature-capable
SIM-card inside their mobile phone. We analyze the resiliency of the
protocol to network attacks under various threat models (compromised
infrastructure, client application, etc., confusing user interface) and give
suggestions for improvement.
1
Introduction
Since 2002, Estonia has issued chipped ID cards to its citizens and permanent
residents. The card has been integrated into a national public-key infrastructure.
Upon the initialization of a new ID card for the user U , two RSA keypairs are
loaded into it. The card is capable of performing modular exponentiations with
the secret exponents of those keypairs. During initialization, certificates binding
the public keys to the user U are also issued and stored on the card (as well
as in a public database). The certificates are issued by a certification authority
(CA) in the list of state-recognized CAs. The intended uses for the secret keys
(as recorded in certificates) are identification (for the first keypair) and signing
(for the second keypair).
The identification functionality of the card can be used when accessing public web-sites. When the user has directed his client application (usually a web
browser) to access a server over a secured connection, the two will perform a TLS
handshake [10] during which both the server and the client are authenticated.
During the protocol, the client has to sign a message, a hash of which is handed
over to the ID card in a smartcard reader connected to client’s computer. The
card will apply the RSA exponentiation to this hash, using the secret exponent in
the first RSA keypair. The result is handed back to the client application which
includes it in a protocol message. To activate the card’s signing functionality, a
PIN (consisting of four or more decimal digits) has to be given to it (different
PINs for different keypairs). The PIN is entered either from the computer keyboard or the PIN-pad integrated with the card reader. In the first case, the PIN
is handled by the client application and given to the card together with the hash
to be signed. The card locks up after a couple consequtive incorrect enterings of
the PIN.
Since 2007, Eesti Mobiiltelefon (the largest Estonian mobile operator) in
cooperation with Sertifitseerimiskeskus AS (the only state-recognized CA in Estonia) have issued mobile SIM cards with the same functionality [15]. Later that
year, they were joined by the Lithuanian mobile operator Omnitel [20]. Similarly,
RSA keypairs are loaded into those cards and the public keys are issued certificates binding them with users. The SIM card can compute signatures on users’
behalf after being given a PIN which is entered from the keypad of the mobile
phone. The mobile ID thus reduces the threats related to handing over one’s PIN
to a possibly trojaned computer. Trojan horse attacks on mobile phones are as
of now only a negligible part of the malware market [13], although should their
number and impact increase, the conclusions made in this paper must be reconsidered. Another claimed advantage of mobile ID is convenience — no smartcard
reader is necessary [16].
At the same time, client authentication in the Mobile-ID protocol uses a
much more complex protocol than the TLS handshake, and involves many more
parties. This raises a number of interesting security questions. The goal of the
research reported in this paper was to formalize the Mobile-ID protocol in the
protocol checker ProVerif [7] and use it to explore what happens if various parts
of the system are acting differently than expected. We also have tested the implementation of central parts of the protocol; this paper shows how to formally
model the possible weaknesses we found. After reporting the results of this exploration, we also suggest modifications for the protocol to make it more secure
under certain attacks.
A general security analysis of Mobile-ID has been performed previously [21].
This analysis was considerably broader in scope than the one reported in this
paper; it considered not just the network attacks, but also legal and human issues
and risks related to the failure of technical components. The conclusion of the
analysis was that generally, the risks associated with Mobile ID are the same
as the risks of using the ID card. There are some additional risks related to the
necessity to trust the extra infrastructure used in the Mobile ID protocols. No
formal analysis of the protocols was presented in [21].
In this paper we first describe the Mobile-ID authentication protocol and base
security assumptions (honesty of certain parties and security of certain channels)
for it. The base security assumptions describe the situation where only parties
that are normally considered to be dishonest can be dishonest. As next we describe how we have formalized the Mobile-ID protocol in ProVerif. In the next
section we describe the results of our analysis. We have analyzed the protocol under base security assumptions, as well as several different, stronger assumptions
where we have allowed certain parties or connections to be under adversarial
control. We finish the paper with suggestions for improving the protocol, as well
as general conclusions.
2
The Mobile-ID Protocol
The Mobile-ID protocol [4] involves the following parties:
2
– The user U that wants to access some service requiring authentication.
– The phone P of that user, as well as the SIM card inside it. Although technically two different units, we model them as a single one. The SIM card
knows the secret signing key skU , the corresponding public key pkU of which
is bound to the identity of U by the certificate certU .
– The client application C of that user, typically a computer running a web
browser. The client application is used to actually access the service.
– The server S that the user wants to connect to. It has a secret key skS which
public counterpart pkS is bound to the name S by the certificate certS . With
the help of skS , the server can participate in a TLS handshake as a server.
– The mobile operator O that has issued the SIM-card of the phone P .
– The DigiDocService D [4]. This is a central party of the protocol meditating
the authentication process and forwarding the messages to right parties.
The DigiDocService has a secret key skD allowing it to participate in a TLS
handshake as a server. The certificate certD binds the corresponding public
key pkD to the identity of D.
The parties above actively take part of a protocol session. Besides them, there is
also the certificate authority CA issuing the certificates. Also, there are means
(OCSP) to verify the status of a certificate [19].
The Mobile-ID protocol [4] is depicted in Fig. 1. A protocol session is initiated by the user U deciding to contact the server S and informing the client
application C about this choice. The client application locates the certificate
certS of the server and initiates a TLS handshake with it. During the handshake, the server is authenticated to the client, but not vice versa. The resulting
TLS tunnel is used to communicate the rest of the messages between C and S.
To authenticate the user, C sends to S the name U (which also determines the
phone number P ). The server S then initiates a TLS handshake with D, again
resulting in the secure identification of D, but not S. Again, the TLS tunnel is
used to encapsulate the messages between S and D. The server S sends to D
the names U and P , identifying the user. Additionally, S generates a 10-byte
challenge r1 (part of the challenge signed with skU ) and sends it to D, too. Optionally, r1 may be empty. Also, S sends to D something that identifies itself:
S̃ = (S, m) where m is an additional message that will be displayed to the user
on the screen of the mobile phone. Both S and D will then locate the certificate
certU of the user.
The DigiDocService will generate a random nonce r2 . The phone of the user
is supposed to sign the concatenation of r1 and r2 with the key skU , where pkU is
included in certU . DigiDocService forwards both S̃ and r1 kr2 to the phone P via
the mobile operator O. The communication between D and O is protected by a
VPN solution. The communication between O and P is through SMS-s, and is
protected by encrypting the messages between O and P with the symmetric key
K̃P known only to themselves. DigiDocService also computes CC1 as the control
code of r1 kr2 . The control code consists of four decimal digits. The control code
CC1 is forwarded to the client application C that displays it to the user U . The
phone P also computes the control code of r1 kr2 and displays it to the user,
3
C
S
S
know certD
get certS
skS
TLS HS
D
O
VPN
U, P
P
U
protected
using K̃P
U
skD
TLS HS
S̃, U, P, r1
get certU
CC1
get certU
S̃, P, r1 kr2
CC1 := cc(r1 kr2 )
CC1
CC1
S̃, r1 kr2
CC2 := cc(r1 kr2 )
S̃, CC2
Compare CC1 and CC2 . Check S̃.
PIN
sigskU (r1 kr2 )
sigskU (r1 kr2 )
OK
Fig. 1. Mobile-ID protocol
along with the name of the server S and the accompanying message m. The
user checks that the control codes displayed by the client application and the
phone are equal. The user also checks that the name of the server displayed by
the phone is equal to the server he wanted to access, and the message m makes
sense. If the checks succeed then the user instructs the phone that it is OK to
sign the challenge, and provides the PIN for identification. The phone, receiving
the PIN, signs the challenge r1 kr2 and forwards it to D via O. DigiDocService
D verifies that signature. If the signature verification is successful, and r1 is
not empty, then the signature is forwarded to S that also checks it, and upon
success deems U to be authenticated. If r1 is empty (i.e., S did not provide a
challenge) then D does not forward the successfully verified signature to S, but
only sends the confirmation that the verification succeeded. Again, S considers
U to be authenticated. The TLS tunnel between C and S is then used for the
regular communication.
2.1
Base security model
There are several entities, with several channels between them. Certain of those
may be controlled by the adversary. In our “base” model we make the following
assumptions about the security of various channels and entities:
4
1. There are several users and servers, some of them may be under adversarial
control.
2. There is a single DigiDocService and mobile operator. They are honest. The
channel between them is secure. In reality, these parties are relatively large
organizations under significant public scrutiny. Still, we will relax this assumption in certain models.
3. The phones and client applications are under the control of their respective
users.
4. The channel between a user and his client application is secure. So is the
channel between a user and his phone. This is a reasonable assumption (for
the base model, where we do not consider trojaned devices) as these channels
are realized by the keyboards and screens of computers and phones.
The basic security property that we are interested in is the secrecy of the TLS
keys agreed by honest clients and servers. We are also interested in correspondence properties: if a server S thinks that it talks to a client controlled by the
user U using the key K and U is honest, then U must also think that it talks to
the server S in a session where his client application C is using the key K (integrity for servers). Similar property must hold if we swap the user and the server
(integrity for clients). Note that integrity for clients is derived directly from the
properties of TLS because the server is authenticated during TLS handshake.
TLS is a thoroughly researched protocol [12] and we know that it provides integrity for clients. Therefore we will subsequently only be concerned with the
integrity for servers.
3
Formalization in ProVerif
ProVerif [7] is a protocol analyzer in the formal (or: Dolev-Yao) model [11].
To apply it to a protocol, it has to be formalized in a language reminiscent
to the applied π-calculus [3]. In this calculus, messages are represented by formal expressions made up of free names and expression constructors, the set of
constructors is fixed for a protocol. The process is expressed in a language containing primitives for sending and receiving messages (the channel has to be
specified, too; it is a name), generating new names (modeling the generation
of new keys, nonces, etc.), constructing and deconstructing messages, branching, sequential and parallel composition, and replication. The input language of
ProVerif also contains means to specify the security properties (both secrecy and
correspondence properties, as well as various process equivalences that we are
not using here). ProVerif is a mature tool, having been used to check the security
of various key-exchange [7, 2], authentication [8], fair exchange [1], secure storage
[9], electronic voting [17, 5], etc. protocols. The tool is capable of modeling different cryptographic primitives, including Diffie-Hellman key exchange [2] and
non-interactive zero-knowledge [6].
Our model of the Mobile-ID protocol, following the base security model consists of the following parts.
5
TLS handshake We follow the modeling by Tankink and Vullers [22]. They
have verified that the TLS handshake provides integrity for clients. The TLS
handshake is used as a subprotocol in two different places of the Mobile-ID
protocol. We use the trick described by Haack [14] to include TLS handshake as
a subprotocol, without duplicating its code.
Certification Instead of including a full-fledged CA process in our model, giving
signatures to certificate requests, we have included a private expression constructor cert, such that cert(X, pkX ) represents that pkX is the public key of X. The
privacy of the constructor means that the adversary cannot use it to construct
new expressions. On the other hand, we have included destructors that the adversary can use and read both components of a cert-message. The honest users,
servers and DigiDocService generate their keys and publish the corresponding
certificates at the beginning of their processes. To give certificates to dishonest
users and servers, we add a (replicated) process that takes a public key pk as
an input, generates a new name n and outputs cert(n, pk ) on a public channel.
It is important that the name is newly generated, otherwise the adversary could
issue new certificates to honest parties.
Phone registration The binding of the key K̃P to the phone P is handled similarly — there is a private binary constructor phonereg representing the binding
of a key to a user’s phone. There are also destructors to read both components
of a phonereg-message, but only the one giving the name of the user is public
(i.e., can be invoked by the adversary). Binding a key to the phone of a dishonest
user is handled similarly to certification. Actually, the process described in the
previous paragraph is extended to also output a phonereg-message.
User, client application and phone We model these parties as a single process (with several replicated subprocesses). The process first generates a new
name and keys for signing and mobile communication and publishes the certificates for them. The process will then split into several parallel subprocesses,
each of them replicated. These subprocesses are described below.
One of the subprocesses models the client application in one protocol session.
It receives the name of the server to connect to (from the user subprocess), runs
the TLS handshake with the server, verifying server’s identity in that process,
receives the control code from the server through the established TLS-tunnel and
sends it to the user subprocess. The channel between the user and client subprocesses is a secure one; its name is generated before the parallel subprocesses
start.
Another subprocess models both the user and the phone during one protocol
session. It tells the client application to start connecting to a server (the name of
the server is received from the adversary), gets back the control code from it, and
also gets the challenge to be signed and information identifying the server from
the network, encrypted with the key for mobile communication. The process
6
verifies whether the control code from the client application matches the control
code of the challenge (also checks the identity of the server). If the check succeeds,
it signs the challenge and sends it back, encrypted.
Third subprocess is used to indicate that this user is honest. It sends the
name of the user on a private channel (a free name that the adversary does not
have access to).
Other parties The processes modeling a server, the DigiDocService, and the
mobile operator are straightforward. The server process first generates the name
and the key of the server, publishes the certificate certS and then runs an unbounded number of processes implementing the server part of the Mobile-ID
protocol. The name of the DigiDocService is globally known, hence the DigiDocService process starts by generating only the key and publishing the certificate
for it. We use a private channel (a free name that the adversary cannot use) to
model the VPN used for communication between the DigiDocService and mobile
operator.
The whole system The analyzed process consists of the parallel composition
of the client process (replicated), server process (replicated), DigiDocService
process, mobile operator process, processes for TLS handshake (replicated) and
the process for issuing certificates for dishonest clients and servers.
Checking the control code The control code consists of four decimal digits,
hence collisions are easy to construct. It would be wrong to model the control
code just by a message constructor with no additional equations as that would
hide the very real possibility of control code collisions. In our model, we still
introduce the constructor cc, such that cc(r) is the control code corresponding
to r, but instead of using equality of terms to check the control code in the user
process, we have introduced a binary predicate TestCCEq (ProVerif supports
such introduction of predicates). The invocation of TestCCEq(r, c) is supposed
to return true if c is the control code corresponding to r (recall that the user
process receives the control code from the client process and the challenge from
the mobile operator). Our model contains the clause TestCCEq(x, cc(x)). Additionally, it contains the clauses for modeling that given c, the adversary can
construct messages of certain shapes whose control code is c. The shapes of these
clauses depend on the attacks that the adversary may want to perform. In the
weakest case (the adversary can find preimages of a given control code, but cannot control the shape of the preimage) the clause is TestCCEq(invcc(x), x), where
invcc is a new message constructor. We consider stronger cases when we study
different security models. Our model does not consider the possibility that two
control codes might be equal by chance. An honest DigiDocService can easily
ensure that challenges with equal control codes are not awaiting signatures of
the same user at the same time.
7
Security properties We are interested in two security properties — the secrecy of the keys of the TLS-tunnel between honest clients and servers, and the
authentication of users to servers. Our model in ProVerif contains queries for
verifying these two properties. For verifying the secrecy of keys, we have introduced a private free name M. The server process encrypts M with the keys of
the TLS tunnel at the end of each protocol round (at the bottom of Fig. 1) and
makes the resulting ciphertext public. The query asks ProVerif whether M is still
secret.
For the correspondence properties we use the events. An event E is a program
statement that is semantically equivalent to a no-operation, but records that the
program point containing event E has been passed (E has happened). ProVerif
can answer queries of the form “if event E2 has happened, then must the event
E1 also have happened?” In our model, we add an event ServerEnd(U, S, k),
where k is the key for the TLS-tunnel between S and C, to the end of the server
process, after it has accepted that user U has been authenticated. We also add
an event UserEnd(U, S, k) at the point where the user has completed all of his
steps to be accepted by the server — at the point where the user must enter his
PIN to the phone. The user process does not normally have the key k. Therefore
the client process will send k to the user process, too. The query asks whether
the event ServerEnd(U, S, k) implies UserEnd(U, S, k).
Both properties are easily invalidated if the user is dishonest. Hence the server
performs the actions for both properties (publishing the encryption of M , and
performing the event ServerEnd) only if the user is honest. The user is honest if
the server can receive his name over the private channel for honest user names
(see the description of user, client application and phone processes above).
4
Verification results
The Mobile-ID protocol, as we have modeled it in Sec. 3, following the security
model of Sec. 2.1 is deemed secure by ProVerif — the correspondence property
holds and the message M cannot be found by the attacker. Still, this only reflects
an in some sense “ideal” situation. Let us now consider the protocol where certain
things go wrong with respect to the base security model.
4.1
Attacker controls DigiDocService
DigiDocService is a mediator of messages, helping the protocol to proceed. It
would be unnatural if the security of the protocol depended on its actions. It is
straightforward to model DigiDocService being under adversarial control — we
make public its secret key skD , as well as the channel between it and the mobile
operator.
Being under adversarial control, the DigiDocService is expected to look for
collisions in control codes for challenges. As it can fix the second half of the
challenge, we expect that DigiDocService desires to solve the problems of the
following form: given c and r1 , find r2 so that cc(r1 kr2 ) = c. This is a reasonably
8
solvable problem, and we add a clause to the definition of TestCCEq stating its
solvability. Namely, we introduce a binary message constructor postc and state
that TestCCEq((r1 kpostc(c, r1 )), c) holds.
ProVerif finds an attack violating both security properties. This attack should
not even be so surprising, because the construction of the signature sigskU (r1 kr2 )
violates certain prudency criteria for the construction of cryptographic protocols
[18, Ch. 11]. If the adversary wants to masquerade as U to a server S then it
waits until U wants to contact some server S ′ , and proceeds as follows:
– A contacts S and performs the TLS handshake with it. At the same time,
U is performing the TLS handshake with S ′ .
– A identifies itself to S as U . S contacts DigiDocService D (under control of
A), performs the TLS handshake with it and forwards it the name U (and
P ) together with its own name S̃ (including the additional message m) and
its half of the challenge r1 . At the same time, U identifies itself to S ′ , which
also performs the TLS handshake with D and forwards to it the names U
and P , its own name S̃ ′ and the half of the challenge r1′ .
– The adversary (as D) constructs r2 and r2′ so, that cc(r1 kr2 ) = cc(r1′ kr2′ ).
Let c be this control code. The adversary (as D) sends c back to S and S ′ .
It also sends S̃ ′ , P , and r1 kr2 to the mobile operator, which forwards them
to P .
– The server S ′ sends c back to U . The phone P shows S̃ ′ to the user U . The
user agrees that it intended to contact S ′ . The phone also shows the control
code of r1 kr2 to the user. This happens to equal c.
– The user enters his PIN to the phone and the phone signs r1 kr2 . This signature is forwarded to S (via the mobile operator and the adversary posing as
DigiDocService), and S accepts the connection with A as coming from U .
Note that here the adversary only controls D, and not any other parties. Therefore this is a very powerful attack.
The attack succeeds even if the collisions for control codes were impossible
to construct. Impossibility of collisions means that the control codes must be
so much longer (at least 40-50 decimal places) that it would seriously degrade
the usability of the system. In this case, the attack is possible if S ′ is under
adversarial control. Compared to the described attack, we now just take r1′ = r1
and r2′ = r2 , and we do not have to look for collisions.
A prudent protocol design guideline says that when constructing a signature,
let the name of the intended verifier be a part of the signed message. This
guideline has not been followed in the design of the Mobile-ID protocol. We
could modify the protocol by letting P include the name S under the signature
it generates, and subsequently verifying that a correct name has been included.
This change still does not fix the protocol, but now the original attack succeeds only if S = S ′ . In other words, the user U initiates one session with the
server S and the attacker initiates a different session at the same time. The adversary (in the role of D) again finds r2 and r2′ so that there is a collision in the
control codes. The modified protocol might be secure if a server does not allow
9
the same alleged user to run two sessions in parallel. Unfortunately, we do not
know of a simple means to model such restriction in ProVerif.
ProVerif deems the protocol secure if both modifications (no control code collisions and server name under signature) are made. To ensure that adversarially
controlled DigiDocService does not generate control code collisions, the server
itself should generate the whole challenge. In terms of Fig. 1, r2 should be the
empty string and r1 should be long enough to be unpredictable. The server must
also make sure to not issue challenges with the same control code for parallel
sessions of allegedly the same user. It goes without saying that the control code
CC1 sent to the user via his client application must be computed by the server,
not the DigiDocService.
4.2
Attacker partially controls the client
One of the goals of the Mobile-ID protocol was to reduce the effect that a compromised client machine might have on the security of authentication. Clearly,
if the adversary has completely taken over the client computer, then it knows
the keys for the TLS-tunnel between the client and the server and can listen
and speak on behalf of the user. Still, even in this case the adversary cannot
contact a server S on behalf of a user U while the user U remains completely
passive: ProVerif claims that even in this case the event ServerEnd(U, S) implies
the event UserEnd(U, S) (note that we do not include the key for the TLS-tunnel
in the arguments of these events) and moreover, the correspondence is injective:
for each action of the user (instructing the phone to sign a challenge), the adversary can start at most one session with the server. To model in ProVerif that
the adversary controls the client machine, we make public the secret that this
process uses: the channel between the client application and the user.
A keylogger does not have to take over the whole machine in order to cause
harm (record the PIN of the ID card). A similarly interesting case for the MobileID protocol is, when the malware has not taken over the whole machine, but can
influence how the control code is shown to the user. This case models malware
that can redraw the screen. This change is simple to model — in Fig. 1, the
value CC1 is received by the user U not from C, but from public network.
ProVerif finds, that if the adversary controls the value of CC1 as presented
to U , then the protocol is insecure. If the adversary A wants to masquerade as
the user U to a server S, then it proceeds as follows.
– Wait until U himself contacts S. As we explained in the first paragraph, it
is impossible to initiate a session (as U ) with S, unless U himself also wants
to contact S.
– Start a session with S, claiming to be U . Let both sessions proceed to the
point where DigiDocService has constructed control codes c (for U ) and c′
(for A) and sent them to S and to P .
– The adversary makes sure that the challenge with the control code c′ reaches
P first. This can be achieved with right timing. The adversary also makes
sure that the second control code is not shown to the user before it has
10
accepted c′ . By our experimentations with DigiDocService3 , this condition
trivially holds — a mobile phone does not hint of the existence of a second
incoming control code before the user has taken action on the first one.
– The adversary receives c′ , the client application receives c. The dishonest
client application now contacts the adversary, learns c′ , and shows it to the
user instead of c. The user confirms that the client application and the phone
show the same control code c′ and instructs the phone to sign the challenge.
This challenge corresponds to the session between A and S.
The attack should be avoidable if the server does not start several sessions with
the same user in parallel. Indeed, if a session has ended and the user has generated the event UserEnd(U, S) then the server has also generated the event
ServerEnd(U, S) and because of injective correspondence, this event UserEnd(U, S)
cannot be used to match a different ServerEnd(U, S) taking place later (presumably because of adversarial activity).
4.3
User confused regarding the server names
An important class of attacks are semantic attacks where the adversary tries to
convince the user that a wrong statement holds. One example of such attacks
are the phishing web-sites masquerading as legitimate ones. They typically have
names similar to the one they are trying to masquerade. Authentication using an
ID card is relatively immune to such attacks — while an attacker can obviously
make the user connect to a fake server (if the user does not notice its fakeness),
this cannot be used to masquerade the user to a legitimate server.
We studied how well the Mobile-ID protocol fared against such attacks. We
assumed that there is an adversarially controlled server S ′ that is hard to distinguish from a legitimate server S. It turned out, that a classical man-in-the-middle
attack is possible, allowing the adversary to masquerade as U to S. In this attack, U connects to S ′ thinking it is S, while the adversary (masquerading as
U ) connects to S. The server S contacts D and the phone of the user receives
the challenge and the information S̃ identifying the server. The control code is
also sent from D back to S, which forwards it to A, which forwards it to U as
S ′ . The phone shows S as the name of the server, the user is connected to S ′ ,
but we assume that he does not notice the difference. The control codes shown
by the phone and the client application are the same. The user hence tells the
phone to sign the challenge and S will accept A as U . The attack works even if
the name of the server is included in the signed message.
4.4
Server chooses the control code
When server S contacts the DigiDocService D, it sends it not only the name S,
but also the up to 40 characters long message m; both S and m will be shown to
the user on his phone. A typical picture of the phone screen is shown in Fig. 2a.
3
http://www.sk.ee/DigiDocService/DigiDocService 2 3.wsdl
11
Here S equals “TheBank” and m equals “Enter?”. The next lines have been
produced by software running inside the phone (actually, inside the SIM-card).
They inform the user that the control code of the challenge is 1234.
TheBank
Enter?
Testing
TheBank
Enter?
Control code:
1234
Ok
Cancel
(a)
TheBank
Enter?
Control code:
2345
Ok
Cancel
Control code:
2345
Ok
(b)
Cancel
(c)
Fig. 2. Typical screen for comparing the control code
The possible values for S have been enumerated by the DigiDocService D and
D also weakly authenticates S by its IP-address. The server named “Testing”
may connect from any IP-address. We have experimented with DigiDocService
and various values of m, using this server identity. We have discovered that if m
contains embedded newlines, then these are shown as line breaks on the phone
screen. E.g., if m equals “TheBank\nEnter?\n\nControl code:\n2345\n” then
the phone screen (for certain models) will look as shown in Fig. 2b. Here the
entire message shown by the phone has not fit on the screen and a scroll bar
has appeared on the right-hand side. If we scroll down, we see the control code
that has been computed by the phone itself and may be different from 2345.
Depending on the model of the phone, this scroll bar may be rather hard to
notice.
We believe that with IP-spoofing, we can cause the picture in Fig. 2c to
appear on the phone screen. Also, if the adversary controls either TheBank or
the DigiDocService (as we have argued before, this case has to be analyzed, too)
then it is straightforward to make this picture appear, as the DigiDocService
can control which S and m are sent to the phone. Hence we conclude that a
malicious server or DigiDocService can (under certain circumstances) control
which four-digit number is shown to the user as the control code.
We have modeled this scenario with ProVerif. The necessary modifications
involve several parts of the model, as the fake control code is inserted at the
server, and then travels to DigiDocService, mobile operator, phone, and the
user. At the same time, the changes are rather straightforward.
We have considered the case where the DigiDocService is honest, but a malicious server is capable of entering a fake control code, eventually shown to the
user by the phone. Somewhat surprisingly, the protocol is still deemed secure.
One may conjecture that the user might not need to perform the equality check
of control codes at all. Of course, this is not so; there exists a straightforward
12
parallel attack: both U and A connect to S, both claim to be U , the challenge
for A’s session is the first to arrive at U ’s phone, U does not check the equality
of control codes and causes this challenge to be signed. Note that U still checks
that the phone shows the name of the server S (the opposite is considered in
Sec. 4.3). The reason why there is no attack if a malicious server can pick a fake
control code, is that to use this capability, the attacker has to set up a malicious
server S ′ whose name will be shown to and rejected by the user.
In Sec. 4.1 we gave some suggestions to handle a dishonest DigiDocService.
We have checked the security of our modifications (server name under signature,
challenge generated entirely by the server, no control code collisions) if a server
or the DigiDocService can also choose the control code that the phone shows.
ProVerif gives us an attack. The attack is similar to the attack presented in
Sec. 4.2. The only difference is that now the attacker changes the control code
shown by the phone, not the control code shown by the client application. Again,
the attack should not work if the server does not start several sessions with the
same user in parallel.
5
Proposed improvements
We suggest the following modifications to the Mobile-ID protocol to increase its
security:
– When the phone signs the challenge r1 kr2 for the server S, the signed message
should not be sigskU (r1 kr2 ), but sigskU (r1 kr2 , S). The presence of S under the
signature must be checked by parties receiving that signature.
– r2 should be a constant, most naturally the empty string. The control code
CC1 should be computed by S, not D. The server S should generate the
challenges r1 in such a way that the sessions of the same alleged user U have
challenges with different control codes.
We also suggest that the user interface of the phone should be modified in a
way that the control code is always in the same place at the phone screen, and
always visible when the message is first shown to the user. This can be achieved
by showing the control code before the message m, or by appropriately filtering
m. Users should also be educated to look for the control code in a certain place.
6
Summary
Above, we have considered attackers of various strength. They all had the ability
to initate protocol sessions; they controlled certain users and servers and had
no access to the phones of the users. Their strength varied along the following
dimensions:
– d1 — control over the DigiDocService or mobile operator (possible values: 0
— no control, 1 — full control);
13
– d2 — control over the client application (0 — no control, 1 — can change
displayed CC, 2 — full control);
– d3 — ability to confuse the user about server names (0 — no, 1 — yes);
– d4 — ability for a compromised server to pick the control code shown on
phone screen (0 — no, 1 — yes).
We see that the abilities of attackers may include the corruption of any party in
Fig. 1, except the phone P , taking the advantage of the user interface issues in
both C and P , and phishing attacks. We have not considered the attacker gaining
significant control over the phone. Indeed, any reasonable attack model would
allow the adversary to learn the PIN entered from the keypad of the phone; the
knowledge of the PIN gives the adversary full capabilities of masquerading as
the user U . We have also not considered the user’s failure to compare the control
codes shown by the client application and the phone, but this is subsumed by
the dimension d2 . To summarize, we believe that we have not left any significant
attack vectors without consideration.
We have proposed two mutually independent protocol modifications. These
propositions introduce dimensions on whether they have been taken into account.
– d5 — is the name of the server included under the signature of the challenge?
(0 — yes, 1 — no)
– d6 — is the half r2 of the challenge empty? (0 — yes, 1 — no)
Another dimension is introduced by an honest server’s behaviour when allegedly
the same user attempts to authenticate himself several times in parallel:
– d7 — does S allow parallel sessions with the same U ? (0 — no, 1 — yes,
but picks challenges with different control codes, 2 — yes) Note that d7 = 0
means that the server lets a session with a user U to time out before agreeing
to participate in a different session with U . This may make denial-of-service
attacks too simple.
Let Lij denote the predicate dj ≤ i. Our analysis shows that the security properties described in the end of Sec. 3 hold if
(L01 ∨ (L05 ∧ L06 ∧ L17 )) ∧ L12 ∧ (L02 ∨ L07 ) ∧ L03 ∧ (L04 ∨ L01 ∨ (L05 ∧ L06 ∧ L07 )) .
Indeed, the justification for each of the conjuncts is the following:
– We showed in Sec. 4.1 that an adversarially controlled DigiDocService is
capable of breaking the protocol unless the modifications stated in Sec. 5
were introduced.
– If the adversary has full control over the client application, then it can take
over the connection between C and S.
– In Sec. 4.2 we showed that if the adversary can change the control code
shown to the user by the client application, then there exist an attack that
requires parallel sessions with the same server.
– In Sec. 4.3 we argued that the mobile-ID protocol does not protect against
phishing attacks, even if we implement the modifications in Sec. 5.
14
– In Sec. 4.4 we showed that the capability for a malicious server to choose the
control code displayed by the phone is not enough for breaking the security
properties, but if the DigiDocService is also under adversarial control then
the modifications of Sec. 5 no longer suffice to preserve the security, but
parallel sessions between the same alleged user and server must be ruled
out. Hence we suggested in Sec. 5 to make sure that L04 holds.
7
Conclusions
We have analyzed the security of the Mobile-ID protocol introduced by an Estonian CA and Estonian and Lithuanian mobile operators. We have discovered
some weaknesses in the protocol which manifest under strong adversarial models.
Despite these weaknesses, we believe that the usage of the protocol can continue
in the immediate future. Indeed, we believe that the attack vectors included in
those adversarial models either will not materialize in the immediate future, or
their materialization would allow attacks of similar success against other authentication methods, sometimes including ID card based methods. Still, the
weaknesses should nevertheless be fixed with high priority.
Our analysis also shows that compared to other methods of authentication
(passwords, one-time passwords, PIN-calculators), Mobile-ID does not offer significant protection against user errors or weaknesses of the client application. We
conclude that it is too premature to state that modulo negligible risks, Mobile-ID
is at least as secure as authentication with ID card [21].
Acknowledgments
This research has been supported by Estonian Science Foundation, grant #6944,
by the European Regional Development Fund through the Estonian Center of
Excellence in Computer Science, EXCS, and by Sampo Pank. We are grateful
to Dan Bogdanov, Ilja Livenson, and Mari Seeba for fruitful discussions.
References
1. M. Abadi, B. Blanchet. Computer-Assisted Verification of a Protocol for Certified
Email. In Static Analysis, 10th International Symposium (SAS’03), LNCS 2694,
pages 316–335, San Diego, California, June 2003.
2. M. Abadi, B. Blanchet, C. Fournet. Just Fast Keying in the Pi Calculus. In Programming Languages and Systems: Proceedings of the 13th European Symposium
on Programming (ESOP’04), LNCS 2986, pages 340-354, Barcelona, Spain, March
2004.
3. M. Abadi, C. Fournet. Mobile values, new names, and secure communication. In
28th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL), pages 104–115, London, UK, January 2001.
4. AS Sertifitseerimiskeskus. DigiDocService specification, v. 2.122, April 24th, 2007.
http://www.sk.ee/files/DigiDocService spec eng.pdf
15
5. M. Backes, C. Hritcu, M. Maffei. Automated Verification of Remote Electronic Voting Protocols in the Applied Pi-Calculus. In 21st IEEE Computer Security Foundations Symposium, CSF 2008, Pittsburgh, Pennsylvania, pages 195–209, June
2008.
6. M. Backes, M. Maffei, D. Unruh. Zero-Knowledge in the Applied Pi-calculus and
Automated Verification of the Direct Anonymous Attestation Protocol. In 2008
IEEE Symposium on Security and Privacy, pages 202–215, May 2008.
7. B. Blanchet. An Efficient Cryptographic Protocol Verifier Based on Prolog Rules.
In 14th IEEE Computer Security Foundations Workshop (CSFW-14), pages 82–96,
Cape Breton, Nova Scotia, Canada, June 2001.
8. B. Blanchet. From Secrecy to Authenticity in Security Protocols. In 9th International Static Analysis Symposium (SAS’02), LNCS 2477, pages 342–359, Madrid,
Spain, September 2002.
9. B. Blanchet, A. Chaudhuri. Automated Formal Analysis of a Protocol for Secure
File Sharing on Untrusted Storage. In IEEE Symposium on Security and Privacy,
pages 417–431, Oakland, CA, May 2008.
10. T. Dierks, E. Rescorla. The Transport Layer Security (TLS) Protocol, Version 1.1.
IETF Network Working Group, RFC 4346, April 2006.
11. D. Dolev, A. C. Yao. On the security of public key protocols. IEEE Transactions
on Information Theory 29(2):198–207, 1983.
12. S. Gajek, M. Manulis, O. Pereira, A.-R. Sadeghi, J. Schwenk. Universally Composable Security Analysis of TLS. In 2nd International Conference on Provable
Security, ProvSec 2008, LNCS 5324, pages 313–327, Shanghai, China, October
2008.
13. S.
Golovanov,
A.
Gostev,
D.
Maslennikov.
Kaspersky
Security
Bulletin
2008:
Malware
Evolution
January
June
2008.
http://www.viruslist.com/en/analysis?pubid=204792034#9
14. C. Haack. Verification of Security Protocols, ProVerif’s Resolution Method, lecture
slides. March 2008. http://www.cs.ru.nl/˜chaack/teaching/2IF02-Spring08/
15. idBlog. EMT Launches the Mobiil-ID Service. http://www.id.ee/blog en/?p=20,
May 2nd, 2007.
16. ID.ee. Mobile-ID main page. http://www.id.ee/10995, November 20th, 2008.
17. S. Kremer, M. Ryan. Analysis of an Electronic Voting Protocol in the Applied Pi
Calculus. In Programming Languages and Systems, 14th European Symposium on
Programming, ESOP 2005, LNCS 3444, pages 186–200, April 2005.
18. W. Mao. Modern Cryptography: Theory and Practice. Prentice Hall, 2003.
19. M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams. X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. IETF Network
Working Group, RFC 2560, June 1999.
20. R. Šablinskas. Summary of Mobile-ID launch in Lithuania. Minutes of the Baltic
WPKI Forum Steering Committee, October 31, 2007. http://wpki.eu/Launch-ofmobile-ES-BalticWPKI.pdf
21. Security Analysis of Mobile ID (Summary, in Estonian). Ordered by Department of State Information Systems, fulfilled by Jaak Tepandi. July 11th, 2008.
http://www.riso.ee/et/files/MOBIIL-ID kokkuvote 11-07-2008.pdf
22. Carst Tankink, Pim Vullers. Verification of the TLS Handshake protocol. May
20th, 2008. http://www.cs.ru.nl/˜chaack/teaching/2IF02-Spring08/tv-report.pdf
16
Prepared for the eGovernment Unit
DG Information Society and Media
European Commission
Good Practice Case
eID in Estonia
Case Study
17 October 2006
Case study prepared by Ralf Cimander
(ifib, Germany) in co-operation with
Andres Aarma and Ain Järv from AS
Sertifitseerimiskeskus, Estonia.
eGovernment Unit
DG Information Society and Media
European Commission
Table of contents
1.
eID in Estonia
2
1.1
Case Summary
2
1.2
1.2.1
1.2.2
1.2.3
Problem addressed
Specific Problem
General Background
Policy context and strategy
3
3
4
6
1.3
1.3.1
1.3.2
1.3.3
Solution
Specific Objectives
Principles of eID card
Implementation
- Workflow description
- Security and Privacy
- Awareness and Marketing
8
8
8
13
14
16
17
1.4
1.4.1
1.4.2
18
18
1.4.3
Features making it a candidate for good practice exchange
Impact
Relevance of the case for other administrations that could learn
from the experience
Transferability
1.5
Results
21
1.6
Learning points and conclusions
23
1.7
References and links
26
19
20
Annex 1: Assessment Questionnaire for the MODINIS Case Descriptions
GP - Case: eID in Estonia
10-2006, vs 1.0
27
1
1.
eID in Estonia
1.1
Case Summary
Estonia has implemented the ID card as the primary document for identifying its citizens and alien
residents living within the country. Before introduction of this card, no national personal
identification document - neither physically nor electronically - did exist in Estonia. The card,
besides being a physical identification document, has advanced electronic functions that facilitate
secure authentication and legally binding digital signature, in connection with nationwide online
services.
There is only one version of the national ID card — no optional features or variations exist. All
cards are equipped with a chip containing electronic data and a pair of unique digital certificates
relating to each individual. In emergency cases (e.g. loss of the card) the certificates can be
suspended if required — disabling the ability to use the card for electronic authentication and
transactions.
The Estonian ID card scheme is the overall responsibility of the Estonian Government's Citizen and
Migration Board (CMB) and is regulated by the government's National Identity Act. The process
itself is managed through a tight public and private partnership with two key private organizations,
the AS Sertifitseerimiskeskus which is a joint venture between banks and telecommunications
organizations in Finland – acting as Certification Centre - and TRÜB Baltic AS which is the
company that personalizes the card itself — both physically and electronically.
The overall aim of the CMB was the introduction of a reliable and trustworthy identification
infrastructure in Estonia, receiving high acceptance by citizens and businesses and hence
becoming a success in terms of effectiveness and efficiency of its use in everyday life. As an (e-)ID
infrastructure is a very sensible area in public administration of a country, which need to be highly
reliable and requires full-time technical support in case of problems, a solution had to found that is
based on already proven technology and that is provided by inner country software and vendors.
Besides, this infrastructure had to be scalable, flexible and standards-based for expansion to other
services as well as forward-looking to enable also cross-border use.
Considering these overall goals, specific objectives and the organisation of service delivery, the
interoperability requirement is that of different public services which have to use the same
auxiliary services, i.e. digital signature, authentication, document encryption. Beside the use for
application of public services or signing of documents, the approach is universal and is also
applicable to private use and services. The interoperability requirement is met by employment of
standardised workflows in form of a common document format applicable to each service
independent of its provider (DigiDoc) and a central common public, service-rendering resource,
connecting national databases (X-Road). In addition, a centralised infrastructure of a national,
unique identification number for each Estonian resident has been employed serving their
authentication (not only) in electronic processes. Each workflow where digitally signed data or
documents are integrated in the legacy systems, IOP in the front-office to back-processes has
been achieved, in the other cases front-office to front-office flows are concerned. Almost 70 per
cent of Estonian residents own an ID card out of which 2.5 per cent use the electronic features of
the card. Several applications are already working with eID, like e.g. e-voting pioneered at the
local government elections in 2005 and with the e-ticketing of public transport tickets as one of
the most massively used application.
GP - Case: eID in Estonia
10-2006, vs 1.0
2
1.2
Problem addressed
1.2.1
Specific Problem
Prior to introduction of the present ID card there was no personal
identification document which could be applied both physically as
well as electronically. The same applied to residence permits.
Specific problems
addressed:
• No personal
identification
document existed;
neither physically nor
electronically
In terms of interoperability in the Estonian eIDentity Management
project, interoperability had to be employed where auxiliary services
(digital signature, authentication, document encryption) are to
support different primary services.
IOP requirement 1:
IOP between eID card
functions (auxiliary
services) and different
services
As the main objectives of the Estonian eID card is to digitally sign,
documents, encrypt documents and to authenticate users, the
natural focus of service delivery is on the front-office to front-office
processes and where documents are directly integrated in the
respective legacy system, front-office to back-office processes are
also concerned.
Service delivery
model:
IOP among front-offices
and where data are also
integrated in the legacy
systems, front-office to
back-office processes
are also concerned
To meet the interoperability requirement, a central database of
unique identification numbers, allocated to each Estonian resident
has been established providing authentication of the card holder (i.e.
the applicant or signing person). To enable identification and
authentication for different services via a corporate infrastructure, a
common public, service rendering resource – X-Road - has been
developed. Based on Internet, X-Road connects public databases
and information systems, tools centrally developed by the state (i.e.
the State Portal Centre) and the X-Road Center (management and
control of the gateway) with the Certification Centre for the (e-)ID
cards. The eID card of citizens is just a secure token for different
purposes where access to these purposes, i.e. public services is
provided by a single point of entry - the E-Citizen Portal. To digitally
sign documents, a communication model using standardised
workflows in form of a common document format (DigiDoc) has been
employed. DigiDoc format is based on the XML Advanced Electronic
Signatures standard (XAdES) and is a profile of that standard.
XAdES defines a format that enables structurally storing signed data,
GP - Case: eID in Estonia
10-2006, vs 1.0
Basic organisational
model employed:
• Centrally provided
unique identification
number for each
Estonian resident
• Common public,
service rendering
resource to connect
national databases (XRoad)
• Central single point of
access to public
services (E-Citizen
Portal)
• Standardised
workflows in form of a
uniform document
format (DigiDoc)
3
signature and security attributes associated with digital signature
and hence caters for a common understanding.
1.2.2
General Background
Issued by the Estonian Government’s Citizen and Migration Board
(CMB), national ID cards represent the primary source of personal
identification for people living within Estonia and are mandatory for
all citizens and resident aliens above the age of fifteen.
The Estonian identification card carries two discreet functions:
−
Physical Identity – can be used as a regular ID in conventional
real-world situations — anywhere one would typically need to
prove identity, age and so on.
−
Electronic Identity – enables citizens to use the same card to
electronically authenticate to Web sites and networks, and/or
digitally sign communications and transactions as required.
There was no national ID card scheme in place in Estonia before the
launch of the new ID card project. Conventional ID card schemes
(e.g., corporate cards) have been in operation for some time within
Estonia; however the dual-purpose physical/electronic ID cards were
not so familiar. To fulfil the scheme's requirements, the Estonian
Government’s Citizen and Migration Board required a single, holistic
system which could process and provision users with a dual-purpose
smart identification card. The process had to be straightforward for
citizens (to register and receive), easy to administer (for technology
controllers) and above all, be secure and reliable. In conjunction
with the ID Card initiative, the CMB were also eager to drive the
adoption of electronic signatures within the region, thus streamlining
key public service and commercial processes for residents and
businesses.
The Estonian ID card scheme is the overall responsibility of the
Estonian Government’s Citizen and Migration Board. It is responsible
for the issuance of identity documents to citizens and alien residents
as required by the government's National Identity Act. The CMB is
the institution that physically receives card application forms from
residents. However, the process itself is managed through a tight
public and private partnership. Two key private organizations work
with the government to support the ID card project:
−
AS Sertifitseerimiskeskus (hereinafter 'SK') – a joint venture
formed in 2001 between two of Estonia’s largest banks
(Hansapank,
Eesti
Ühispank)
and
telecommunications
organizations (Eesti Telefon and EMT). SK functions as the
certificate authority for the Estonian ID card project and
manages a complete range of associated electronic services —
GP - Case: eID in Estonia
10-2006, vs 1.0
Service:
Electronic Identity –
enables citizens to use
the same card to
electronically
authenticate to Web
sites and networks,
and/or digitally sign
communications and
transactions as required
Types and level of
agencies involved:
• Estonian
Government’s Citizen
and Migration Board
• AS
Sertifitseerimiskeskus
as Certification
Authority which is a
joint venture between
two of Estonia’s
largest banks and
telecommunications
organizations
• TRÜB Baltic AS – a
subsidiary of the TRÜB
financial services
organization
• Certification Service
Providers (CSPs)
• Time-stamping Service
Providers (TSPs)
• As Supervising
Authority the Ministry
of Economy and
Communications, in
particular the National
Registry of
Certification Service
Providers
4
including the LDAP (Lightweight Directory Access Protocol)
directory service, OCSP (Online Certificate Status Protocol)
validation service, and other certificate-related services. SK also
manages the end-user distribution channel (through its parents'
retail bank outlets).
−
TRÜB Baltic AS – a subsidiary of the TRÜB financial services
organization — headquartered in Switzerland. TRÜB is the
company that personalizes the card itself — both physically and
electronically. TRÜB receives the card application from CMB and
manufactures the card, printing and engraving the personal data
on the card, generating keys on the chip and embedding the
certificates on the card.
Besides, for the processing and controlling of digital signatures,
following authorities and agencies are relevant:
According to the Estonian Digital Signature Act (DSA), Certification
Service Providers (CSPs) certify real persons identifiable by name
and ID code and must be legal entities fulfilling specific legal
requirements.
DSA also regulates the work of Time-stamping Service Providers
(TSPs). The requirements to such service providers are generally the
same as those to CSPs. According to DSA, a time stamp is simply a
data unit that proves that certain data existed at a certain moment.
The National Registry of Certification Service Providers contains data
about all Estonian CSP-s and TSP-s. Although it confirms the public
keys of CSP-s, it is technically not a root CA in Estonia. Instead, it
functions as a supervisory authority, confirming the results of service
providers’ annual audits among other things. The Ministry of
Economy and Communications, in whose administration area the
registry works, has the right to verify audit results and inspect the
service providers' premises and relevant information.
GP - Case: eID in Estonia
10-2006, vs 1.0
5
1.2.3
Policy context and strategy
The Republic of Estonia is a small, independent Baltic state with a
population of just below 1.4 million people. Estonia is structured into
15 sovereign counties. While Estonia is a relatively small country (in
terms of other European population sizes, land area, GDP levels,
etc.), the nation is an innovator when it comes to introducing and
adopting new technology products and services. According to spring
2006 data (TNS Emor Gallup e-Ratings study), 58 per cent of the
population regularly use the Web — the figure shows that Estonia
has one of the highest Internet-usage rate in Eastern Europe.
Internet connectivity is also very high and well accessible at homes,
offices and schools.
Institutional context:
• Estonia is structured
into 15 sovereign
counties
• Highest Internetusage rate in Eastern
Europe
The legal framework associated with the issuance and government of
ID cards was established through the Identity Documents Act, which
was passed in 1999 and took effect on January 1, 2000. The specific
legislation associated with digital signatures - the national Digital
Signature Act (DSA) - was passed separately by the Estonian
parliament (Riigikogu) on March 8, 2000 and came into force on
December 15, 2000. This law regulates the framework and rules
required to effectively govern a national PKI and digital signature
infrastructure.
Legal framework:
• Identity Documents
Act of 1 January 2001
• National Digital
Signature Act (DSA) of
15 December 2000
• Rules and regulations
for Certificate Service
Providers (CSPs)
• Rules and regulations
for Time Stamp
Providers (TSP)
• Personal Data
Protection Act
The primary aim of the DSA was to give electronic signatures the
same level of trust and assurance as handwritten ones. As a rule,
digital and handwritten signatures should be equivalent in both the
public and private sector. The DSA also states that public service
departments must accept digitally signed documents. The DSA
requires that each digital signature can:
−
Uniquely identify the signatory.
−
Bind the individual to the signed data.
−
Ensure that signed data cannot be tampered with retrospectively
— without invalidating the signature itself.
While there is no direct sanction for not holding an ID card, it is
expected that as the first Estonian passports were issued in 1992
(following independence from the Soviet Union) with a 10-year
validity period, most people will apply for a card when renewing their
passport — if not already done so independently. By 2007, the
government expects over one million cards to be issued (almost the
entire registered and qualified population).
In terms of EU status, all certificates issued in association with the
ID card scheme are qualified certificates as per the European digital
signature directive 1999/93/EC. The Estonian DSA only regulates
advanced electronic signatures with regard to the EU directive.
Naturally, other types of electronic signatures can also be regulated,
but the DSA does not give them legal power or status.
One of the core components of the DSA was the establishment of
rules and regulations with regard to Certificate Service Providers
GP - Case: eID in Estonia
10-2006, vs 1.0
Interoperability
Framework:
All certificates issued in
association with the ID
card scheme are
qualified certificates as
per the European digital
signature directive
1999/93/EC
6
(CSPs) — who issue digital certificates to users and manage related
security services. The Estonian DSA mandated a number of stringent
requirements (financial and procedural) to ensure that CSPs are set
up and managed properly — to perform their function to the highest
possible standard.
The DSA also regulates time stamping services which are provided
by dedicated Time Stamp Providers (TSP). These TSP service
providers have to adhere to similar laws and regulations as CSPs.
The time stamp is simply a piece of data which attests to the
occurrence of an event at a specific time. The DSA does not define
time stamps in great detail, but ensures that time stamped data
cannot be tampered with or amended without invalidating the time
stamp itself.
A national registry of service providers contains all the relevant
information associated with registered CSPs and TSPs.
A broad Personal Data Protection Act regulates the use of personal
data and databases containing personal data by public authorities
and private entities.
GP - Case: eID in Estonia
10-2006, vs 1.0
7
1.3
Solution
1.3.1
Specific Objectives
In order to drive the adoption of digital signatures within the region,
software and technology had to be available for parties looking to
incorporate compatible applications.
When technical experts looked for a generic application or
implementation that would fulfil this requirement, no ideal solution
was found. It was also not optimal to rely on a foreign software or
technology vendor to provide and guarantee support for a critical
piece of national infrastructure. This reliance could have detrimental
impact on the country’s day-today functioning going forward.
Because of these considerations, a bespoke software model was
developed specifically to cater for Estonia and its digital signature
constituents.
In order to issue and manage the PKI-based digital credentials, the
following objectives were set by SK:
−
Selection of a PKI product which is already value proven in a
range of successful deployments in similar environments;
−
Scalability and Flexibility of the product;
−
To have a technology structure that is based on standards since
the PKI has to interoperate with a broad range of
complementary technologies;
−
Consideration of internationalization aspects since the Estonian
language is rich in non-ASCII characters that need to be
correctly processed and embedded in the certificates;
−
Auditable security and the possibility to construct reliable
processes. Technology is just one aspect of security, equally
important are the organizational and physical security measures.
Estonian legislation requires annual external info system audits
from the PKI providers.
1.3.2
Objectives to be
achieved in general:
• Raise the adoption of
digital signatures
• Good availability of
software and
technology for
interested parties
• Not to rely on foreign
software or vendors
for this sensible piece
of infrastructure
Specific objectives:
• Implementation of an
already value proven
technology
• Scalability and
Flexibility
• Standards-based
solution to enable
expansion to other
services
• Processing and
embedding of nonASCII characters that
are common in
Estonian language
• Auditable security and
possibility to construct
reliable processes
Principles of eID card
The front side of the card contains the card holder's signature and
photo, and also the following data:
−
name of card holder
−
personal code (national ID code) of card holder
−
card holder day of birth
−
card holder sex
−
card holder citizenship
−
card number
−
card validity end
GP - Case: eID in Estonia
10-2006, vs 1.0
8
The back side contains the following data:
−
card holder birth place
−
card issuing date
−
residence permit details and other information (if applicable)
−
card and holder data in machine-readable (ICAO) format
Electronic data on card
Each ID card contains all the above data except photo and
handwritten signature in electronic form, in a special publicly
readable data file. In addition, the card contains two certificates and
their associated private keys protected with PIN codes. The
certificate contains only the holder's name and personal code
(national ID code). In addition, the authentication certificate
contains the holder's unique e-mail address.
GP - Case: eID in Estonia
10-2006, vs 1.0
9
- Certificates
Each issued ID card contains two discreet PKI-based digital
certificates – one for authentication and one for digital signing. As
said, the certificates contain only the holder's name and personal
code (national ID code). These certificates are standard X509 v3
certificates and have two associated private keys on the card – each
protected by a unique user PIN code. The certificates contain no
restrictions of use: they are by nature universal and meant to be
used in any form of communications, whether between private
persons, organizations or the card holder and government. They
contain no roles or authorizations: those where required must be
managed using some out-of-band method (see below, "Roles,
authorizations and organizations' validations").
The certificates contain the card holder's name and national ID code.
It is agreed in Estonia that this data is public by nature. The
certificates identify the card holder uniquely because even though
there may be name overlaps, the national ID code is unique. In
addition, the authentication certificate contains the card holder's email address.
In terms of the European Council and Parliament digital signature
directive 1999/93/EC, all the certificates on Estonian ID card are
qualified certificates.
- E-mail address
The authentication certificate on each ID card contains the card
holder's government-assigned e-mail address in the format
firstname.lastname@eesti.ee. Random numbers can be used in
addition to provide unique e-mail addresses even to persons with the
same name. The address does not change with subsequent
certificate or card issuing – it is guaranteed to be a person's
"lifetime" address.
There is no real e-mail service associated with the address. It is
merely a relay address which forwards e-mails to users' "real"
addresses (e-mail accounts). Each user must configure the
forwarding addresses using an online service made available for this
purpose, and may reconfigure the addresses as often as he or she
pleases. Up to five forwarding addresses can be specified.
The address is supposed to be used in communications from
government to the person, but it can also be used in
communications between persons and companies and private
persons themselves. The addresses are available online to anyone
through CSP's certificate directory.
The address can be used as a simple e-mail address, but using the
address and the authentication certificate on the card, users can also
digitally sign and encrypt their e-mail. The digital e-mail signature is
not legally binding and not covered by DSA, but it provides receivers
additional confirmation of sender authenticity. E-mail encryption and
GP - Case: eID in Estonia
10-2006, vs 1.0
10
signing using certificates on smart card is a standard function of
various e-mail applications.
Anti-spam measures are implemented in the forwarding server. In
addition, spamming is illegal in Estonia and spammers will be
prosecuted accordingly.
Roles, authorizations and organizations' validations
In connection with implementing PKI and digital signatures, the
question of roles and authorizations has arisen in various projects. It
is assumed that certificates for digital signing may be issued for
specific purposes only, and that a person's roles can be embedded in
role certificates that are then used for authenticating the certificate
holder into different systems and giving digital signatures in different
roles. Thus, a person needs additional role and signature certificates
for each different role (s)he has, and the number of certificates
grows, creating substantial interoperability and scalability issues.
The Estonian approach states (as also said in the Estonian DSA) that
a digital signature given using a digital signing certificate is no
different than a handwritten one. A person's handwritten signature
does not contain his or her role – the role and authorization are
established using some out-of-band method (out-of-band in the
context of certificates). The same approach also goes for
authorization while authenticating – a person's certificate should not
contain his or her authorization credentials. Instead, everyone has a
similar universal key (authentication certificate), and the person's
role and authorization can be determined using some other method
(e.g. an online database) based on that key.
Case capitalises
mainly on following
layers of IOP:
• Technical and
syntactic IOP is
provided by the use of
the Internet-gateway
X-Road connecting the
national databases
and by DigiDoc which
is based on
OpenXAdES and hence
on ETSI standard.
DigiDoc provides a
common document
format and is a key
feature of the
semantic
standardisation. A key
feature enabling
semantic IOP is the
use of the national ID
number for
authentication
throughout any public
service
A practical example illustrating the above concept is signing
documents in organization using power of attorney. In traditional PKI
environments, this has been done using some form of attribute
certificates where issues described above arise. In Estonian and PKI
context, we could ask how power of attorney given in real life is, and
use the same principles in electronic document management.
Traditionally, power of attorney is granted in the form of a document
signed by the person giving the authorization. The document is then
given to the person who receives the authorization and who can then
present the document to relevant parties if necessary. The same can
be done electronically: the person giving the power of attorney can
sign the document using his/her own universal personal certificate,
and forward the document to the person who is given authorization.
The person can then enclose the digital power of attorney with any
further documents (s)he signs. The person receiving the document
can then verify both the original signed document and the enclosed
power of attorney that confirms that the person indeed had the right
to sign such a document.
Attribute certificates can of course be used in connection with the
universal certificates and documents outlined above, but the
Estonian concept is geared more towards universal certificates.
GP - Case: eID in Estonia
10-2006, vs 1.0
11
An exception to the above is organization's validation. Digital
documents sometimes need to be validated by organizations, so that
other organizations can be sure of the identity of the organization
where the document originated. This is useful for e.g. signing pieces
of databases (e.g. bank statements) online, to be presented to other
organizations. For this, SK issues certificates to organizations that
can be used to sign documents digitally. Technically, they are
equivalent to personal signing certificates on everyone's ID card, but
legally, they are not viewed as signatures and need not be covered
by law, because according to the Estonian law, only real persons can
give signatures. The "organizations' signatures" must therefore be
viewed simply as additional tools for proving information authenticity
(that it really originated from a specific organization) which may or
may not be accompanied by a digital signature of a real person
working in that organization. Still, the PKI complexity stops here,
and besides personal and organizational signature certificates, there
is no need for personal role certificates or anything else more
complex.
GP - Case: eID in Estonia
10-2006, vs 1.0
12
1.3.3
Implementation
In order to bring digital signatures into everyday life, common
understanding and signature handling practices are required. In
addition, software and technology must be available for anyone
interested, in order to create compatible applications. After all, the
key to unleashing potential digital signature benefits lies in
communication between organizations, not within one organization.
Therefore, it is vital that all organizations in a given community
interpret and understand digital signatures the same way. In case of
Estonia, the community is the whole country.
SK, together with its partners, delivered a comprehensive digital
signature architecture called DigiDoc. DigiDoc is a universal system
for giving, processing and verifying digital signatures created by AS
Sertifitseerimiskeskus. It can be connected to any new or existing
piece of software, but its components are a stand-alone client
program and a Web portal.
The core components of DigiDoc are:
− Client Program – DigiDoc Client is available to anybody to
download for free. Anyone can use it to verify digital signatures
or, if you have an Estonian ID card and smartcard reader,
generate digital signatures.
−
Web Portal – The portal is located at http://digidoc.sk.ee and is
available to all ID cardholders free of charge. Its functions are
similar to the client program — you can use it to generate and
verify digital signatures. In addition, you can use it to have a
document signed by a number of people. With a few clicks of the
mouse, you designate the people whose signatures you need on
the document, and they can all sign it in the same portal. Every
user has a directory of his or her documents which no one else
sees but where anyone can send documents to be signed by
you.
−
File Format – DigiDoc specifies the file format for storing a digital
signature and other technical data in a container file, together
with the original file that was signed. All DigiDoc-enabled
programs must support this format, and it must be possible to
export files from all the programs into stand-alone files, to be
verified with the stand-alone DigiDoc Client.
−
Software Library – The DigiDoc library is available to all
developers as a program library in C and as a Windows COM
component. It can be connected to any existing or new software.
For example, you could add DigiDoc support to accounting
software, document management system, Web and intranet
applications, and so on.
Supporting
infrastructure
employed:
• Web Portal to
generate and verify
digital signatures
• Software Library
(DigiDoc library
program in C
• DigiDoc document
format
• SK's OCSP validation
service
• X-Road, the Internetgateway connecting
the national databases
(public authorities),
Banks and the
Certification Authority
On the server side, DigiDoc provides an RFC2560-compliant OCSP
server, operating directly off the CA master certificate database and
providing validity confirmations to certificates and signatures. On the
GP - Case: eID in Estonia
10-2006, vs 1.0
13
client side, it provides a number of components — the most
important being the digital document format, which is key to
common digital signature implementation and practice.
SK based the DigiDoc document format on XML-DSIG standard. In
February 2002, ETSI published its extensions to XML-DSIG as ETSI
TS
101
903,
also
known
as
XAdES
(see
also
http://www.openxades.org). DigiDoc document format is a profile of
XAdES, containing a subset of its proposed extensions.
Based on the document format, a library was developed in C
language that binds together the following:
−
DigiDoc document format
−
SK's OCSP validation service
−
Interfacing with the user's ID card using Windows' native CSP
interface or cross platform PKCS#11.
Workflow description
The eID card is used for identification at the E-Citizen Portal. This
portal serves as a gateway to the services of approximately 20
different databases. Here, a person can check his or her data in
these various national databases and fill out application forms, sign
and send documents, and receive information about planned
electrical supply interruptions in the specific area. The DigiDoc
system described above is needed by citizens to start giving and
receiving digital signatures.
After identification at the E-Citizen Portal, services mainly of the
central public authorities like Benefits and Social Assistance,
Citizenship, Health Care or many others may be applied for (see
www.eesti.ee). The validity of the citizens' certificates will be
confirmed (OCSP) and a time-stamp given to the applications. Via a
common public, service rendering resource which connects the
national databases - the Internet X-Road - the application messages
are securely exchanged. More than 350 organisations already joined
this Internet-gateway.
GP - Case: eID in Estonia
10-2006, vs 1.0
14
Architecture of service delivery via eID in Finland
GP - Case: eID in Estonia
10-2006, vs 1.0
15
In 2004, The Parental Benefit Service was awarded for the best
government agencies cooperation solution.
Five information systems interact the data (real time).
−
Citizens' Portal
−
Register of Social Insurance Board
−
Population Register
−
Information system of Health Insurance Fund
−
Information system of Tax and Customs Office
Security and Privacy
The data protection question is not seen to be very relevant in the
context of Estonian ID card because there is very little private data
involved in the card issuing and further utilization process. There is a
broad Personal Data Protection Act in effect in Estonia which
regulates the use of personal data and databases containing
personal data by public authorities and private entities, and Estonian
Data Protection Inspection is the government body overseeing that
the requirements of the act are met and enforcing compliance if
necessary.
The certificates on the card are available publicly in a directory
service and contain only the card holder's name and personal ID
code, which are considered public data by law in Estonia. In addition,
e-mail addresses in authentication certificates are also available in
the directory. The directory contains only valid (active) certificates:
if a person suspends or revokes his/her certificate, it is also removed
from the directory and the data are no longer available.
GP - Case: eID in Estonia
10-2006, vs 1.0
Warranty of security
and privacy:
• Only little data is
saved on the ID card
• Estonian Data
Protection Inspection
controls that
requirements of the
Personal Data
Protection Act are met
• Personal ID code is
held publicly together
with card holder's
name and are
considered public data
by law in Estonia
16
The public data file is not published anywhere online. The personal
data on the card in visual and electronic format are accessible only
to those persons to whom the card holder physically presents the
card.
The general stance to ID card and data protection in Estonia is that
the card should contain as little private data as possible. Instead, the
data should be kept in databases at relevant authorities, and a
person can use the card as key (authorization method) to access his
or her data in the database.
Requests by third parties (e.g. representatives of authorities) for
private data are logged and logs are available online for the
individual upon request (via the citizen's portal). Thus such approach
presumes justified interest on behalf of authorities. An individual can
submit additional queries regarding the requests.
Warranty of security
and privacy:
• Card holder can
suspend or revoke
their electronic
certificate form the
card (for only "offline"
use of the card)
• Public data file is not
published anywhere
online
• Card is used as key to
access his/her data in
databases in public
authorities instead of
containing these data
Awareness and Marketing
Till now, the electronic usage of eID cards has been mostly the
realm of professionals and enthusiasts. This mainly due to:
-
the time required to change the mindset;
-
lack of inevitable applications (e.g. compared to free Internet
telephony);
-
initial technical glitches which discouraged some first-movers
and resulted in lack of hype for the ID card;
-
relative expensiveness of ID card readers (currently readers are
offered at more than three times cheaper price than some years
ago).
However, currently the card is used very actively as the token for
verification of a valid e-ticket in city public transport. One of the key
drivers behind a rapid and successful adoption of e-tickets is the
price difference between e-tickets and paper tickets.
The eID function of the bank card is currently much more often used
as that of the ID card. However, in order to strengthen the use of
the eID card instead of the bank card citizens as well as banks shall
be convinced by economic logic: As Internet use is affected by
viruses and other similar things updated security features and other
applications are permanently required in order to provide secure
services. This costs lots of money for the banks for services which
are not directly related to their own business. Also citizens need to
update their systems for these purposes which would not be the
case if they use the eID functionalities.
Currently, the Computer Security 2009 initiative has been launched
with the aim to ensure a more secure use of internet by application
of PKI products and services. E.g. internet banking transaction limits
which presume usage of higher security means (e.g. PKI tokens)
shall be decreased significantly. Also, new PKI products and services
are in production.
GP - Case: eID in Estonia
10-2006, vs 1.0
Awareness and
Marketing:
• Currently, the use of
the e-function for
identification is mostly
the realm of
enthusiasts
• However, card is
widely used as token
for verification of valid
e-tickets in public
transport
• e-tickets are cheaper
than paper ones and
force their use
• Increase of Internet
security envisaged by
development and use
of PKI products and
services
• As the use of the eID
card saves costs for
banks and also for
citizens in terms of
Internet security,
economic logic will
support the change
from using banking
cards to eID cards for
public service
applications
17
1.4
Features making it a candidate for good practice exchange
1.4.1
Impact
The Estonian eID roll-out is known to be one of the most successful
in Europe. It has been organised in a valuable public-private
partnership and there are already many applications working with it.
E.g. Estonian citizens can use it to buy e-tickets for public transport
and it allows drivers permit verification. Citizens can browse through
their information in the population register; they can digitally sign
documents or check their telephone bill. The card is also be used for
health insurance and banking purposes.
Outreach:
• > 950,000 residents
own an ID card, i.e.
almost full national
roll-out
• e-functions are active
by default and 2.5%
are using it
The first Estonian ID cards were issued in January 2002. In the first
year, more than 130,000 cards were issued, and the total figure up
to now (mid 2006) is more than 950,000; i.e. almost everybody has
one, considering that citizens under the age of 15 do not need one.
2.5% are users of the e-function of the ID-card in terms auf
identification and authorisation in public services.
Estonia has a PKI penetration of more than 67%. The reason for its
major success is that Estonia is a relative small country with almost
1.4 million residents.
The card is meant to be universal and its functions are to be used in
any form of business, governmental or private communications. It is
already helping people to make everyday communications more
convenient.
Although the ID card project is a success it took five years instead of
the originally expected 14 months to implement the infrastructure
and raise awareness and high uptake due to legislative and political
issues. Another challenge was to promote the use of the card and to
make people getting used to it.
Like in many cases the take-up of eGovernment service applications
based on the eID card was very slow due to the reasons mentioned
in the Awareness and Marketing chapter above.
With the DigiDoc library easy-to-use interfaces to the signature
relevant features are provided and there is no need for application
developers to know OCSP protocol specifics or DigiDoc (XAdES, XMLDSIG) format internals. It can be embedded in any application or on
top of it. A COM interface has been implemented, making it easy to
add DigiDoc support to any Windows based application supporting
COM technology. A Java implementation is also provided.
Despite these strengths, providing the libraries and formats was not
enough — because these do not add value to end users without real
applications. Although it is expected that DigiDoc support will
eventually be present in most Estonian document management
systems and Web sites dealing with documents, a number of sample
or reference applications were also provided. The parental benefit
service, the health care services or taxation services are good
GP - Case: eID in Estonia
10-2006, vs 1.0
Performance:
• DigiDoc support will
eventually be present
in most Estonian
document
management systems
and Web sites
• Easy to use function
as DigiDoc client is a
Windows application
• No need to install
stand-alone software
on user side as
functions are provided
via a web portal
• Libraries,
specifications, and
applications are
provided free of
charge to Estonian
public
18
examples in this regard. DigiDoc Client is a Windows® application
that lets users simply sign and verify documents, and DigiDoc portal
is an application that lets users do the same online — without the
need to install any stand-alone software. Both are based on the
same DigiDoc library and thus fully compatible e-signatures given in
Client can be verified in portal and vice versa. The libraries,
specifications and applications are provided to the Estonian public
free of charge, and it is expected that digital signature usage in
common life and everyday business and government practices will
grow significantly through 2003–2008. The first official digital
signatures in Estonia were given using DigiDoc Client on October 7,
2002.
1.4.2
Relevance of the case for other administrations that could learn from the experience
With the national eID card the Estonian government follows a
pragmatic and simplicity approach avoiding some of the contentious
aspects of ID cards in general:
−
ID cards do not contain any digital biometrics;
−
ID cards do not contain any roles or authorizations. Where such
is required these must be managed using some out-of-band
method;
−
The certificates are simple and only contain the holder's name
and personal code (national ID code);
−
There is not central aggregation of loads of user data as the card
is only the 'key' to user data stored in public authorities;
−
The certificates contain no restrictions of use: they are by nature
universal and meant to be used in any form of communications;
−
The use of the eID card is easy to understand for users as it only
contains two functions to be used with two different PIN codes,
one for digital signing and one for authentication;
−
Users may disable the electronic functions of the card in case
they have lost it or they have doubts or fears about using these
functions;
−
Users do only need card and card reader for using the system.
Innovativeness:
• Simplicity of the card
(no digital biometrics)
• Simplicity of the
certificates (only
contain name and ID
code)
• Simplicity of its use
(only two functions:
digital signature and
authentication)
• No restrictions in use
since certificates are
universal
• No central aggregation
of loads of user data
• Possibility to disable
the electronic
functions of the card
However, the use of a unique national ID code for identification still
bears some risks for abuse and privacy concerns are present. The
success of such applications is highly dependent on the trust users
have in the system including the legal regulations encompassing also
the control of its use. In addition, as an objective and a possible
killer application of the card is its multifunctional use, in particular in
the private sector, one has to consider whether it is appropriate that
these private sector organisations know the identity of their clients.
GP - Case: eID in Estonia
10-2006, vs 1.0
19
1.4.3
Transferability
Foreign Certificates
DSA regulates the recognition of foreign certificates, stating that in
order for them to be recognized equivalent to those issued by
Estonian CSP-s, they must be either confirmed by a registered CSP,
be explicitly compliant with DSA requirements or covered by an
international agreement.
DigiDoc and OpenXAdES
Estonia launced the OpenXAdES initiative which is, as the name
indicates, an open initiative where anyone is welcome to join.
OpenXAdES is a free software development project aiming at
profiling XAdES (XML Advanced Electronic Signatures), technical
standard
(TS
101
903)
published
by
ETSI
(European
Telecommunication Standards Institute). With digital signatures,
common understanding of the document format is critical as digital
signatures can't be converted. Open XAdES' mission is to
concentrate efforts on developing a common document format and
share implementations supporting this. With DigiDoc, a uniform
platform based on XAdES has been developed which has the
following important features:
−
Can be verified offline without any additional information;
−
Signature can be given to several original documents at the
same time;
−
Protection against format attacks – type of signed document is
also signed;
−
Original document can be in the container or stored separately;
−
Original document can be XML or any binary file (Word, Excel,
PDF, RTF etc);
−
Zero, one or more signatures per container;
−
One validity confirmation per signature.
Transferability:
• Foreign certificates
can be dealt with
when they are
confirmed by a CSP or
are compliant with
DSA requirements
covered by
international
agreement
• Launch of the Open
XAdES Initiative
aiming at commonly
(with other countries)
profiling XAdES which
is a standard
published by ETSI
• Agreement on IOP
between Estonia and
Finland
In
June
2003,
AS
Sertifitseerimiskeskus
and
Finnish
Väestörekisterikeskus (Population Register Centre, PRC) signed an
agreement for improving digital signature interoperability between
the countries, with the goal of making digital documents a reality
within and between Finland and Estonia. Estonia and Finland invite
other parties from other communities to join the project and thus
expand the network of "digital countries".
GP - Case: eID in Estonia
10-2006, vs 1.0
20
1.5
Results
The Government's objective is to reach one million ID cards issued
by 2007. Besides the use of the national ID card, Estonian residents
can also use their Internet banking identification data to access
online public services (more than 70% of Estonian residents use
Internet banking, the highest proportion in Europe).
The most important application for public services, - the e-Citizen
portal – can be used by both cards for authentication purposes. As
internet banking already started in 1995, citizens are more used to it
and tend to login to their bank and then go to the portal. E.g. many
people (65%) declared their tax online with bank codes but not
through the eID card. Hence authentication is currently not the killer
application for eIDs in Estonia though the main purpose of the eID
card is to authenticate its owner.
Benefits:
• Unique identification
throughout public and
private services
• Provision of secure email account and
unique e-mail address
• Possible encryption of
documents
• e-tickets for public
transportation is a big
success as it is used
110,000 times per day
Beside authentication, the card can also be used for secure e-mail.
The idea was to give a lifetime e-mail address to the citizens so the
authentication certificate contains an e-mail address. The e-mail
address provided by the government looks like the perfect
communication channel. Since it works voluntarily, and the citizen
has to login to the citizen portal and register the address, not
everyone does this.
The card can be also used for encryption of documents so that only
the person intended to view the document can decrypt it. This is a
very efficient means for secure transfer of documents using public
networks.
One of the most successful applications is the electronic ID-ticket
which can be used for travel in the public transport of Tallinn, Tartu
and Viimsi as well as in the county of Harjumaa. During year 2005,
passengers using this e-ticket service purchased a total of 975,263
electronic ID-tickets. Today, more than 110,000 persons use the ID
ticket system every day.
Another application is Internet voting piloted in 2005. As the
infrastructure was in place, it was desired to use it via the eID card.
I-voting was based on an envelope scheme. The citizen makes a
choice and the choice is then encrypted with the public key of the
whole system. Many international observers were present at its first
run. However, there were and still are some privacy concerns about
the I-voting and the buying of public transport ticket with the eID
card mentioned above. E.g. even if the personalisation of tickets
actually eliminates the risk of forgery (which is an issue with nonpersonalised paper tickets) the transport company knows the
identity of the person who bought the ticket. The success of these
applications is highly dependant on the trust users have in the
system. Of course one can always travel anonymously by buying a
paper ticket.
GP - Case: eID in Estonia
10-2006, vs 1.0
21
In May 2006, the largest banks and telecoms (SEB Eesti Ühispank,
Hansapank, Elion, EMT) as well as the Ministry of Economic Affairs
and Communications of Estonia signed a co-operation agreement to
launch a nationwide "Computer Protection 2009" initiative, pledging
to invest up to EEK 60 million to increase end-user PC protection and
awareness in Estonia.
The initiative aims at making Estonia a country with the most secure
information society in the world by year 2009. To this end, a number
of sub-projects have been launched, one of the priority fields being
the promotion of ID card-based authentication in the use of eservices. Thus PKI should become the main method of authentication
as well as transaction verification within the three years with a total
of ca 600,000 active users. Parallel to the existing ID card, mobile ID
will be launched by the beginning of 2007 enabling secure
authentication and digital signing using a mobile phone.
GP - Case: eID in Estonia
10-2006, vs 1.0
Future developments:
• Launch of the
nationwide "Computer
Protection 2009"
initiative in order to
making Estonia leader
in secure information
management
22
1.6
Learning points and conclusions
Critical success
factors for IOP:
Many lessons were learned while organising, developing,
implementing, and running eIDs in Estonia and are presented below.
As Estonia is a main driver in the OpenXAdES initiative and eID
adheres to this standard, many lessons can also be stated on a
rather general level which stem from the OpenXAdES group.
Digital signature is universal
Think of your handwritten signature. Whether you sign a paper as a
citizen, the CEO of your company, the head of some non-profit
hobby association or as a bank customer - the scribbling that you
draw on paper and that is called a signature always looks the same,
regardless of your role. Whether you were indeed authorized to sign
the document or did agree to its content or other such questions are
totally different matters, just as in the traditional world. Aim merely
at providing users a way of working with legally binding digital
signatures.
Document must be self-contained
No additional validation services should be needed for verification
after the signature has been created and saved. Documents should
contain the digital signature, original signed data and all other data
necessary for document verification. Using the data in the document
file, it is possible to firmly establish whether the digital signatures
are valid (whether the certificates were valid at the time of signing
etc).
Legislation is important
Since we are talking about legally binding signature, legal framework
for digital signatures is critical. Different countries have different
digital signature regulations and you should provide solutions which
are as flexible and universal as possible. OpenXAdES is such a
solution which fully complies with the Estonian digital signature
regulation, as well as the EU directive 1999/93/EC, regulating the
general use of digital signatures within the EU. There is also a
chance that OpenXAdES is already compliant also with the regulation
in your country.
• Aim merely at
providing users a way
of working with legally
binding digital
signatures
• Document must be
self-contained - no
additional validation
services should be
needed after the
signature has been
created
• The use of legally
binding signatures
requires a valuable
legal framework
• As different countries
have different legal
frameworks, provide
flexible and universal
solutions to be
connective with these
countries
Additionally, when talking about legislation, we cannot only
concentrate on strictly digital signature and PKI-related acts:
whether you can use digital signatures or not depends also on the
legislation of other generic areas of life, e.g. administrative
procedure, civil relations, court proceedings etc. A number of
European countries are at a disadvantage in this respect: although
digital signature law is in place, other laws foresee that documents
can only be used on paper. Estonia is in a good position because
many of the country's laws have recently been passed or updated to
GP - Case: eID in Estonia
10-2006, vs 1.0
23
reflect the vision described above: digital documents and paper
documents should be used interchangeably in everyday life in private
and business relations and should be considered equivalent in all
respects.
PKI hype is over, business value is important
It is no more the year 2000 where technology opened all the doors
(and buzzwords guaranteed immediate funding). Set the focus on
added business value to organizations and end users. This may
sound painful to some PKI enthusiasts: many PKI projects carried
out so far do not justify the costs made and do not add significant
value to anybody. Avoid this pitfall by trying to be as simple as barebones as possible, while adding considerable value to any business
process which uses legal documents. This ensures hat the business
requirements would take precedence and that the most appropriate
technology would be used to implement them.
Open standards and trust are critical for user confidence and
interoperability
Digital signatures and the whole PKI is based on trust and confidence
- implementers and end users need to be aware of what actions
cause what outcomes in the system, and that the system is really
doing what it claims to be doing. Open source and free software,
based on public standards enable that anyone can examine the
project and document internals if necessary. E.g. do not use any
heavyweight and cutting-edge time-stamping protocol for signature
timing and validation - instead, use lightweight and proven
standards such as OCSP.
Our main competitor is pen and paper
Remember that we are talking about giving signatures to
documents. This has been done the same way for many hundreds
and thousands of years. Telling people that it can also be done
differently is a very complex task and you are facing fierce
competition from traditional signing tools, pen and paper. If you
cannot explain the benefits of the new method to people and
organizations and do not credibly demonstrate that it is more cost
effective to them, you will fail and people will continue using paper
documents.
PKI business model must be based on certificates and
corporate services, not end-user services and transactions
This is a direct consequence of the above point: Understanding and
accepting the new system is already hard enough for people. If you
want to charge them lots for using the digital signature, they won't
ever use it. A place where persons can be charged is issuing a
certificate for them, but after that, it should be free, both the
services and the software.
GP - Case: eID in Estonia
10-2006, vs 1.0
Critical success
factors for IOP:
• Business requirements
should be the driver
not the most
sophisticated PKI
solution
• Base your project on
open standards to
enable trust in the
system
• Use open standards to
be prepared for
interoperability
• Demonstrate the
additional benefit by
using the new solution
in contrast to the
traditional way
• Base your business
model on certificates
and corporate services
in stead of end-user
services and
transactions
24
Critical success
factors for IOP:
Capitalize on already existing IT investment
Much of the infrastructure that is necessary for using digital
signatures is most often already in place. Most people and
businesses have access to PC-s and the Internet. Countries and
communities are starting to distribute universal national or regional
ID cards. Having an ID card and access to smartcard-reader
equipped PC should be the only thing a person needs for using the
digital signature.
The costs to businesses and end users should be limited
We do not need to construct complex expensive PKIs for each
different service: single PKIs, perhaps even on a national scale such
as in Estonia, are suitable for all purposes.
People should be able to understand digital signatures
Complexity has been the key inhibitor in successfully providing PKI
services to end users, and much of that complexity is due to the fact
that current services and products have been specific to one service
or organization only. People have to learn new approaches and new
interfaces for each communication pattern, and it is very frustrating.
Having a single certificate and PIN code for all digital signature
purposes is all that a person needs, and people can also understand
this, exactly as they can understand using ATM cards and mobile
phones.
Single tokens are more secure
When people have only a single token to look after, they know they
have to be very careful with it. If a single card carries the
authentication and digital signature functions such as in Estonia,
security-critical functions can be easily established and maintained,
such as a round-the-clock helpdesk for suspending card and
certificate validity in case of loss or theft. Problems associated with
outdated or insecure passwords are eliminated, as smartcard- and
certificate-based authentication gains momentum.
GP - Case: eID in Estonia
10-2006, vs 1.0
• Capitalize on already
existing IT
investments in to
protect investments
also on user side
• One unique PKI
system for all public
services would be
more beneficial than
having one for each
service
• Provide easy to
understand services in
order to drive their
dissemination
• Provide single tokens
as they are more
secure than having
different solutions
25
1.7
References and links
All URL's worked out on the last visit on 04.09.2006:
The Estonian ID card project information, including the newest version of their Whitepaper, is
available online at http://www.id.ee. Contact at info@id.ee.
Important papers which also build the basis of this case study are:
Cybertrust 2005: Managing Digital Identities and Signatures through Public/Private Partnership
(http://www.cybertrust.com/media/case_studies/cybertrust_cs_easton.pdf)
The Estonian ID Card and Digital Signature Concept. Principles and Solutions. Whitepaper.
Version: June 5, 2003 (http://www.id.ee/file.php?id=122)
Acts:
Digital Signature Act: http://www.esis.ee/ist2004/101.html or PDF:
(http://www.esis.ee/legislation/digital_signatures_act.pdf#search=%22digital%20signature%20ac
t%20estonia%22)
Personal Data Protection Act: http://www.esis.ee/ist2004/103.html
Further useful references and websites:
−
AS Sertifitseerimiskeskus: http://www.sk.ee
−
DigiDoc
Format
Specification.
Version
1.3.0,
12.05.2004
(http://www.id.ee/file.php?id=342#search=%22digiDoc%20format%20specification%22)
−
Modinis IDM 2006: National profile for eGovernment IDM initiatives in Estonia. In: D 3.5: IDM
Initiatives
Report.
(Estonian
example:
https://www.cosic.esat.kuleuven.be/modinisidm/twiki/bin/view.cgi/Main/EstonianProfile)
−
OpenXAdES group: http://www.openxades.org
−
Web Portal to generate and verify digital signatures: http://digidoc.sk.ee
−
E-Citizen Portal: http://www.eesti.ee
GP - Case: eID in Estonia
10-2006, vs 1.0
26
Annex 1: Assessment Questionnaire for the MODINIS Case
Descriptions
In order to ensure the case descriptions meet the information needs of stakeholders in
interoperability at the local and regional level, we ask you to complete this short assessment
questionnaire. Your feedback will be used to improve the next version of the present case and will
also be taken into consideration when writing up more cases to be described in the course of the
project.
Case being reviewed:……………………………………………………………………………………………………………………….…
1.) Information content
a) Completeness of description
1
5
|-----------|-----------|-----------|-----------|
only few
all
relevant
relevant
aspects
aspects
b) Detail of description
1
3
5
3
1
|-----------|-----------|-----------|-----------|
too
right
too many
general
level
details
2.) Length of description
1
3
5
3
1
|-----------|-----------|-----------|-----------|
too
right
too
short
length
long
3.) Structure / headings
1
5
|-----------|-----------|-----------|-----------|
unclear
clear
GP - Case: eID in Estonia
10-2006, vs 1.0
27
4.) Margins
1
3
5
|----------------------|-------------------- --|
misleading
not necessary
good
orientation
5.) Learning potential
1
5
|-----------|-----------|-----------|-----------|
none at all
many new insights
6.) Usefulness for your own work
1
5
|-----------|-----------|-----------|-----------|
not at all
very much
7.) Transferability of case to your country
1
5
|-----------|-----------|-----------|-----------|
not at all
very high
8.) Will you get into contact with the contact person?
1
5
|-----------|-----------|-----------|-----------|
certainly
for sure
not
Comments
______________________________________________________________________________
______________________________________________________________________________
Your affiliation
local/regional
government
GP - Case: eID in Estonia
national
government
IT
business
10-2006, vs 1.0
academia
28
Prepared by:
Ralf Cimander and Herbert Kubicek
Institut für Informationsmanagement Bremen GmbH (ifib)
Am Fallturm 1, D-28359 Bremen, Germany
www.ifib.de
Tel.: (+49 421) 218 26 74, Fax: (+49 421) 218 48 94, email: info@ifib.de
http://www.ifib.de/egov-interoperability
European Institute of Public Administration (EIPA)
Center for Research and Technology Hellas / Institute of Informatics and Telematics
(CERTH/ITI)
Prepared for:
European Commission
Information Society and Media Directorate-General
eGovernment Unit
Tel
Fax
(32-2) 299 02 45
(32-2) 299 41 14
E-mail
EC-egovernment-research@cec.eu.int
Website europa.eu.int/egovernment_research
IDIS (2010) 3:213–233
DOI 10.1007/s12394-010-0044-0
Electronic identity management in Estonia
between market and state governance
Tarvi Martens
Received: 22 October 2009 / Accepted: 4 February 2010 / Published online: 9 March 2010
# The Author(s) 2010. This article is published with open access at Springerlink.com
Abstract The present paper summarizes the development of the national electronic
Identity Management System (eIDMS) in Estonia according to a conceptual
framework developed in an European comparative research project outlined in the
first chapter of this special issue. Its main function is to amend the picture of the
European eIDMS landscape by presenting a case with high involvement of the private
sector and thereby checking the generalizations from the comparisons of Austria,
Belgium, Germany and Spain, presented by Kubicek and Noack in the previous
chapter of this special issue. Starting with a short introduction into the historical
background of identity documents in Estonia the national population register, the
passport as well as the bank ID are described as the main pillars of the Estonian
eIDMS, on which the national ID card builds on, which has been introduced in 2002.
The technical features of the eID and the ID card are described in Section two as well
as the areas of application and the processes for production and distribution. Section
three presents the actors constellation, Section four the time line of the development
process, starting from 1997. Section five deals with the diffusion and promotion of the
ID card and the eID authentication function. After a very low and slow take up during
the first 5 years due to a cooperation agreement between major banks, telecom
operators and the government usage has increased. But still the authentication by
Internet banks, which provides authentication services to third parties, including
government, is the biggest competitor for the eID function on the national eID card.
Only recently the major banks have announced to slowly fade out the password cards
and PIN calculators as alternative modes of bank authentication.
Keywords Estonia . Digital signature . Electronic identity
This report is based on official documents and the personal experience of the author. It has been compiled
under contract with the Institute for information management Bremen, funded by Volkswagen Foundation,
Germany
T. Martens (*)
Certification Centre, Pärnu Ave. 141, 11314 Tallinn, Estonia
e-mail: tarvi@sk.ee
214
T. Martens
Historical background of identity documents in Estonia
The present structure of the national identity management in Estonia has been
established in 1992 after the full independence from the Soviet Union. Under the
Soviet regime, Estonian SSR had the same identity document system as the rest of
USSR had i.e. paper passports and other paper identity documents.
In the new system the central agency is the Citizenship and Migration Board
(CMB1), a state authority under the Ministry of the Interior. It runs the national
population register, administers the national Personal Identification Code and issues
identity documents, since 1992 a passport and since 2002 an ID card, including an
eID-function. However, the most popular method for online authentication for ecommerce and e-government was and still is via the Bank ID, which has been
introduced in Estonia 1996 for Internet banking.
The national population register and the personal identification code
The national Population Register is a central database for the performance of
functions of the state and local governments established by the Population Register
Act regulating the registration of the population, the maintenance of the records and
the rights and obligations of citizens and public authorities.2 It contains the personal
data of the citizens, data of all identity documents and vital events certificates. The
registry includes the following personal data: names, sex, date of birth, place of
birth, citizenship, residence permit, place of residence and marital status and the
Personal Identification Code (PIC).
PIC is the core element of the identity system in Estonia. It is a unique number
assigned to every Estonian citizen and resident. The legal basis for assigning and
using the PIC was established in 1992. The 11-digit PIN consists of:
&
&
&
&
gender/century of the birth digit (one digit for two attributes)
date of birth digits (YY+MM+DD)
three random digits
one checksum digit
All certificates of widely accepted eID-s in Estonia (ID-card and Mobile-ID)
contain the PIC. It is used as a primary key in the majority of databases containing
personal information both in the public and private sector. Therefore service
providers can easily link eID-authenticated users with their personal data. Moreover,
digitally signed files contain a certificate of the signatory including the PIC and
thereby allowing for a definite identification of the signatory.
The data entered in the Population Register is the basis for other databases
of the state and local government authorities. The population registry is also
issuing the PIC to other state authorities who have to document a person for
1
2
As of 01.01.2010 CMB is a part of Police- and Border Guard Board, see http://www.politsei.ee/en/.
Population Register Act (2005), in English: http://www.legaltext.ee/et/andmebaas/ava.asp?m=022.
Electronic identity management in Estonia
215
the first time (usually by birth or issuance of the residence permit or the right
of the residence).3 The data is collected and entered by different state and local
government authorities, natural and legal persons. Persons and authorities can
submit data to the population register online or by forwarding data through a data
communication network.
The passport
First passports in Estonia were issued in 1992 by the Citizenship and Migration
Board (CMB). The CMB issues passports for Estonian citizens and aliens, temporary
travel documents, seafarers’ discharge books, certificates of record of service on
ships and refugees’ travel documents. For 10 years the passport was the only
national ID document.
Bank ID
In 1996 Estonian banks started Internet banking and introduced two methods for
online authentication, which are still offered today:
–
–
Password cards containing 24 one time passwords are issued personally to the
customer in his bank,
PIN calculators are off-line card readers with a keypad. At log in the customer
receives a code number on his screen, enters his bank card and this number and
the calculator generates a new one time PIN which the customer enters online.
PIN calculators were introduced in the beginning of 90’s.
Until 2002 the only and today still the most popular method for online authentication
is to use the Bank ID authentication modes. In contrast to many other European
countries Internet bank authentication is not only used for online banking but is a
service, which the five major banks are providing to third parties. It started back in 1996
and today covers almost 100% of the people between 16 and 74. It is simple to use, as
no special hardware or software is needed: the user logs into the Internet bank, using the
appropriate method, selects “external e-service”, user’s PIC is securely communicated
to the e-service and the user continues work with selected e-service.
Since 2002 the ID card based eID is offered as a third option. Considering the
number of cards issued the password cards and ID cards are almost equal:
&
&
&
around one million password cards (with 24 codes) have been issued,
estimated 50,000 PIN-calculators are in use,
since 2002 over one million ID-cards have been issued.
But looking at the use for online authentication, the password-based authentication with estimated 80% still is the mostly used method today. It is considered
relatively secure as these password cards are issued personally in the bank office.
Trustworthiness of banks is generally considered as good. Therefore it is not
3
The use of the registry is regulated in the Personal Data Protection Act (English: http://www.legaltext.ee/
text/en/X70030.htm.
216
T. Martens
surprising that several eGovernment services like eTaxation and Citizen Portal make
use of the bank authentication.
The eID and the ID-card
Considering that the first generation of passports had to be renewed in 2002, the
Government had an historical chance to introduce a new type of identity document.
It was obvious that lot of people will come for a new passport starting from 2002 as
in 1992 people tried to get an Estonian passport as soon as possible.
The idea for a second ID-document emerged in 1997 in the form of a national ID
card, which could carry an eID and certificates for electronic signatures. It has been
launched in 2002 and roll out has been finished in 2006. It is obligatory. Every
citizen older than 15 years has to hold such an ID card. Estonia has about 1.3 million
inhabitants, and there are about 1 to 1.1 million cards active. The legal basis is the
Identity Documents Act of 2004.4 In addition to the eID on the national ID card in
2007 a mobile eID has been introduced.
The national ID card
Compared to the systems in Austria, Belgium, Germany and Spain as described by
Kubicek and Noack in this special issue the Estonian ID card and eID is quite similar
to the Belgian one (see Table 1).
The ID card contains the holder’s surname, given names, sex, citizenship, date of
birth, place of birth, personal identification code (PIC), a photo, a signature, the date
of issue and date of expiry, and a document number. For resident aliens with valid
papers, the ID card also contains residence and work permit or right of residence
data. In addition to many security features, the card has a machine-readable code
(Figs. 1 and 2).
The Estonian ID-card contains a data file, which is unprotected and includes the
same personal data that is visibly printed on the card—most notably name and PIC
of the cardholder. This allows for quick retrieval of personal data when the card is
inserted into a terminal/smartcard reader, e.g. when using the ID card as a loyalty
card, as an entrance card to libraries, sport clubs etc. or for quick registration to an
event or for entering premises.
The ID1-shaped card is based on PKI technology and contains two certificates:
one for authentication, and one for electronic signatures, both of them considered as
qualified. Each private key is dependent on the use of a different PIN-code. The
certificates contain name(s), surname(s), PIC (containing gender and date of birth)
and a government-assigned e-mail address in the authentication certificate. There is
no electronically usable biometric information on the card. The use of the certificates
is regulated in the Digital Signature Act.5
Initially ID-cards were issued for a lifetime of 10 years with certificate validity of
3 years. Renewal of certificates is without charge for end users and the process can
4
5
http://www.legaltext.ee/text/en/X30039K10.htm.
http://www.legaltext.ee/text/en/X30081K4.htm.
Electronic identity management in Estonia
217
Table 1 The Estonian eID and eID card in comparison with other European systems
AT
BE
GE
ES
EE
carrier card
identical with national ID-card
–
X
X
X
X
card character
obligatory / age
–
> 12
>16
>14
>15
card function
Authentication (online)
X
X*
X**
X
X*
Authentication (visual)
X***
X
X
X
X
e-signature
X
X*
X**
X
X*
Data on card
and chip
contact/contactless chip
Contact
Contact
RFID
Contact
Contact
* opt out,
** opt in,
*** depending
of used Card
visual data:
• address
X***
–
X
X
–
• owners photograph
X***
X
X
X
X
national register number
–
X
–
X
X
PIN-protected identity data
–
–
X
–
–
PIN-protected authentication data
X
X
X
X
X
Biometrics face fingerprints
–
–
X
X
–
–
–
X**
X
–
be performed over the Internet. From January 2006 both certificates and the card
have a lifetime of 5 years.
Mobile-ID
In addition to th eID on the national ID card in May 2007 a Mobile-ID was
introduced to Estonian market by the largest mobile operator EMT in co-operation
with SK, the Estonian Certification Authority. In order to get a Mobile-ID, the user
needs to replace his SIM-card by a PKI-capable one. As the registration process is
performed by the mobile operator, it is not considered trustworthy enough. Therefore
the user needs to “activate” his/her Mobile-ID with his ID-card. Thereby issuance of
the Mobile-ID is bound to the security and quality of the ID-card. Mobile-ID
certificates contain the same personal information on the subject.
Mobile-ID provides certain advantages for the end user compared to the ID-card:
the user does not need a smartcard reader nor any specific software. Currently the
Mobile-ID is available from one mobile operator only and the number of active users
is below 100, 00. Two other main mobile operators (Elisa, Tele2) launched their
Mobile-ID service in December 2009.
Applications of the ID card
Besides many online services there are two remarkable applications to be mentioned
separately:
&
ID-ticketing: Over 120,000 users are carrying the ID-card every day to prove
their entitlement to travel in public transportation in Tartu, Tallinn and
218
T. Martens
Fig. 1 Estonian ID card—front cover
&
surroundings (Harjumaa county). Tickets for one to two hours, or for one, three,
ten, thirty or ninety days can be obtained using the internet, mobile or landline
phone, or paying cash in more than 80 sales points. Checking officers are
carrying GPRS-enabled handheld terminals for quick and automatic entitlement
checking.
Partial replacement of driver’s documents: Almost all traffic police cars are
equipped with devices for querying information from the drivers license database,
car insurance and car registry. When a car driver has his ID-card with him, it would
allow checking the identity and retrieving all other relevant information.
All main web-based applications requiring strong user authentication make use of
the ID-card both in public and private sector. Most sites supporting ID-card login
also support Mobile-ID. Authentication is using standard TLS/SSL protocol. This
implies that the service provider receives the complete certificate of the user
including the PIC.
In public sector the most notable service is the Citizen Portal,6 which links the
majority of public services via a single point of entrance. Another important service
is provided by the Estonian Tax and Customs Board7 allowing tax declarations
online for natural persons as well as for companies. While most government
applications offer Bank ID authentication option as well, this is not the case in the
6
7
http://www.eesti.ee/.
http://www.emta.ee/.
Electronic identity management in Estonia
219
Fig. 2 Estonian ID card—back cover
eHealth field. The Health Information System8 does not accept Bank ID
authentication because of the higher security level demands, instead authentication
is only possible by the national eID.
The ID-card is also an enabler of Internet voting (I-voting), which in Estonia is an
official method of voting and produces binding results.9 It was introduced in 2005
for elections of local governments and repeated in 2007 for elections of the national
Parliament. I-voting is a major application for engaging new ID-card users: up to
40% of I-voters in 2007 were first-time users of the eID function. In 2009, I-voting
was enabled in two elections (European Parliament and Local Elections) and the
number of I-voters finally broke barrier of 100,000 which makes I-voting share more
than 15% of all voters. For full statistics please refer to National Electoral
Committee.10
One of the most popular e-services accessible with the eID is e-school,11 an easyto-use student information system, connecting parents, students, teachers and school
administrators over the Internet, making school information accessible from home
and decreasing the work routine of teachers and school management.
8
http://www.digilugu.ee.
http://www.valimised.ee/.
10
http://www.vvk.ee/index.php?id=11178.
11
http://www.ekool.ee/.
9
220
T. Martens
Internet banking12 is the most popular e-service in the private sector, although
logging in with an ID-card is not the most popular option. In the financial sector, the
Estonian Central Securities Register13 and Pension Register14 also make use of IDcard authentication. Telecom companies (for example: Elion, EMT, Tele2) and utility
companies (water, gas and electricity) make use of the ID-card authentication in their
self-service environments. A list of sites accepting ID-card authentication can be
found on http://id.ee/?id=10953.
Digital signatures with eID
One of the main reasons for introducing the ID-card was to implement the Digital
Signature Act and provide means for digital signing for Estonian residents. Free
tools for end-users and system integrators were released back in 2002 and are still
evolving. As a result, Estonians are sharing a common understanding of digitally
signed documents in file form, fully standardized and widely accepted by
everyone, including courts. A piece of software called “DigiDoc Client”, allowing
for digital signature creation and verification, comes with a package of the IDcard software and therefore can be installed on every computer with a smartcard
reader attached.
This development has resulted in massive use of digital signing as digital
signatures created with those tools are legally equivalent to a hand-written signature.
There are cases in the law where digital signatures are considered even to be stronger
than handwritten ones—e.g. in the establishment of companies.15 Digital signatures
are massively pushed by Internet banks as all transactions are required to be signed
digitally (in case the user logged in with his ID-card or Mobile-ID).
Authority to access the eID
The personal data on the ID card—data file and certificates—are available to every
card terminal as they are not PIN-protected. The authentication certificate is
available to Service Providers after successful ID-card login. The digital signature
certificate is available in the digitally signed document to everyone who sees the
document. As a result, the citizens’ PIC in the data file or in certificates is made
available with every electronic use of the ID-card. Furthermore, the PIC is used as a
key in almost every database—both in the private and public sector. The question of
cross-use of different registries and databases is a legal matter covered by the
Personal Data Protection Act16 and controlled by Data Protection Agency.17 Crossuse of databases is generally allowed only if granted on application.
12
http://www.hansa.ee, http://www.seb.ee, http://www.sampo.ee, http://www.krediidipank.ee, http://www.
sbmbank.ee, http://www.rahanet.ee.
13
https://www.e-register.ee/.
14
https://register.pensionikeskus.ee/public/authorization.jsp.
15
https://ettevotjaportaal.rik.ee/index.py?chlang=eng.
16
http://www.legaltext.ee/text/en/X70030.htm.
17
http://www.aki.ee/eng/.
Electronic identity management in Estonia
221
Production and distribution of the ID card and the eID
The eID card is issued by the Citizenship and Migration Bureau (CMB). The
Database of the CMB is communicating heavily with the Population Register (see
above) so that the integrity of identity management is ensured. All changes in the
Population Register (i.e. death of a person, change of name etc.) are communicated to CMB through the Population Register. In those cases CMB
invalidates the ID-card and issues a request for certificate revocation which is
carried out automatically.
CMB cooperates with private sector suppliers in the issuance process of the
ID-card. CMB receives an application from the resident (by post or in person)
and decides upon issuance and data on the card. Personalization and certification
services are outsourced to private companies as illustrated in the following
Fig. 3.
Personalization of the ID card is carried out by TRÜB Baltic AS, which requests
certificates from AS Sertifitseerimiskeskus (Certification Centre, SK). The latter also
provides after-service (PIN renewal, certificate renewal etc) though the bank offices
(Swedbank and SEB) operating as Registration Authorities. There is currently just
one CA in Estonia (SK).
Fig. 3 Production and distribution of the Estonian eID
222
T. Martens
Actor constellation
Main actors
On the political level there are two major ministries in Estonia involved in the eID
development:
–
–
The Ministry of the Interior (MoI) is supervising the Citizenship and Migration
Bureau18 (CMB), directly responsible for issuance and maintenance of identification documents and for maintaining (electronic) identities of residents at large.
The Ministry of Economic Affairs and Communications (MEAC) includes the
Department of State Information Systems (RISO) which is responsible for the
general ICT coordination in the public sector. The tasks of the department
include the coordination of state IT-policy actions and development plans in the
field of state administrative information systems. Furthermore the Estonian
Informatics Centre (EIC), a subdivision of the MEAC, is responsible for
implementation of the policies set by RISO.
State register of certificates functioning under MEAC is a supervision body for
certification and time-stamping service providers. As the number of this kind of
service providers is very low (one CSP and 2 TSP-s) the Register has been quite
inactive functioning as a mere registrar just receiving compulsory yearly audit
reports from service providers and filing them.
An eIdentity Working Group had been established under the auspices of MEAC
consisting of different stakeholders from the public and private sector. The group
held meetings on-demand basis addressing actual issues around the eID topics. The
group is supposed to advice the Minister but in reality functions as a roundtable for
exchanging information and ideas.
Private sector is playing a significant role in the Estonian eIDMS. ID-card
manufacturing and personalization is outsourced to TRÜB Baltic AG and certification
and validation services are provided by privately held AS Sertifitseerimiskeskus (SK).
The latter functions also as an excellence centre for electronic usage of the ID-card
providing software, including a digital signature software framework, end-user
support as well as support and services to Service Providers making use of the ID-card.
SK is owned by the “big four” of Estonian economy—two of the biggest banks
(Swedbank and SEB bank) and the two big telecom operators (Elion and EMT). This
set-up allows SK to act as a unique roundtable bringing together public sector,
telecom and banking sector. This is definitely one reason for having established the
ID-card as a preferred eID token across all sectors and a reason for the absence of
alternative strong eID tokens (besides Mobile-ID which is seen more like a tool
complementary to the ID-card). This set-up has also facilitated the broad-bottomed
introduction of digital signatures.
By definition the Department of State Information Systems and its executive branch
EIC are responsible for the implementation of the Digital Signature Act, including
software for digital signing. Lack of activities from these parties forced SK and its
18
http://www.mig.ee/index.php/mg/eng.
Electronic identity management in Estonia
223
owners to take over this role. As a result, SK has been filling the gap for 7 years now in
this area. With money from the European structural funds EIC finally announced a
tender for ID-card software in 2008, which shall be available late in beginning of 2010.
Actors and relations around eID in Estonia are illustrated in Fig. 4:
Importance of policy fields
Although the main reason for introducing the ID card with an eID was the provision
of electronic signatures, the design of the system included authentication
functionality. CMB under the authority of the Ministry of the Interior played the
main role through out the introduction phase of the ID-card and made most of the
decisions regarding the ID-card functionality (sometimes with help of the established
working groups). The card is and will always be “CMB-issued” i.e. coming from
Ministry of Interior. Although the card contains a certificate for a digital signature,
CMB is not supporting this field by any software or any other initiative.
With regard to the importance and the influence of different policy field according
to the categories applied by Kubicek and Noack in their comparison of Austria,
Belgium, Germany and Spain we may conclude that the Estonian picture is quite
similar to the German and Spanish one, although the outcome is quite different and
more like the Belgian system (Table 2).
Timeline of the development process
As mentioned above, preparations for a “new generation identity document” started
at CMB in 1997. Several working groups were formed with representatives from the
Fig. 4 Actors in the Estonian eID development
224
T. Martens
Table 2 Actors and their importance and influence in the eID development process
Actors and their importance and influence in the process (1=low, 3=high)
Actors / Policy Fields
GER
AUT
ESP
BEL
EE
Interior/Police
3
1
3
1
3
Public Admistration
2
3
2
3
2
Industry/Commmerce
1
1
2
1
2
Finance
1
1
1
1
1
Social/Health
1
2
1
2
1
Chancellery/Cabinet
1
3
2
1
1..2a
a
the one-time remarkable role of the Cabinet was the very first decision to introduce ID-card with full eID
functionality to everyone
public sector and private sector. Preliminary studies concluded that eID technologies
had developed far enough to allow application on a nationwide scale and that there is
a demand in society for electronic ID-cards, particularly in connection with digital
signatures.The following process can be divided in four additional phases: legal
provisions, organizational and technical preparations, roll-out and up-take (see
bottom line, Fig. 5).
The “legal phase” took longer than anticipated as topics of electronic identity and
digital signatures were uncommon at the time: The working group preparing a draft
of the Digital Signature Act started working in 1997 and took almost 3 years to
finish the job.
The “preparation phase” saw the formation of two new companies in 2001,
primarily for the sake of participating in the ID-card project: the establishment of AS
Sertifitseerimiskeskus (by the two largest banks and two large telecom companies) and
the creation of a Baltic subsidiary of Swiss-based company TRÜB AG. The decision
for delivering chip- and certificate-equipped ID-card to everyone, however, was made
in the last minute by the falling government under Prime Minister Mart Laar in
October 2001. That decision, initated by Mr. Linnar Viik, advisory to Prime Minister
on ICT matters played a crucial role in the success story of Estonian ID-card.
The first card was issued January 28th, 2002 to the President of Republic of
Estonia. The milestone of 1 million cards was surpassed in October 2006 and from
this time on the number of active cards has remained between 1.0 and 1.1 million.
During the roll-out phase several software releases have been issued in order to make
usage of the ID-card easy and comprehensive, including wide distribution of digital
signing software. Relatively low uptake of electronic usage of the ID-card became an
issue in 2006, resulting in a new program “Computer Security 2009” (CS 2009)
addressed in the next section.
Compared to Austria, Belgium, Germany and Spain the development process
took 5 years until the first card was issued and thus is rather short as in Austria and
Belgium, without the delays that occurred in Germany and Spain (see Kubicek and
Noack in this issue. Considering the generalizations derived from the four other
countries, we may confirm for Estonia that the rather straight development process
was due to a smooth cooperation of the two ministries via the working groups and
Electronic identity management in Estonia
225
Fig. 5 Time line and most important events in the development process
that with regard to important decisions the Prime Minister and his advisor formed a
successful couple of a power and an expert promoter.
Although these decision had been taken by a fallen government, change in
governments did not hinder steady introduction of the ID-card in the way it was
agreed at first. Thus the generalisation also applies also to Estonia: Changes in
government offices due to elections during the development process did not
influence the design and dissemination of the eID function.
With regard to the influence of industry we have to consider that there is no
Estonian chip industry that might have tried to be involved. However the telecom
and banking branches successfully have offered their services and influenced the
eIDMS. This is quite different from the four countries compared by Kubicek and
Noack in this issue, and much more like the Swedish case described by Aklund in
the following paper. Banks were involved from the beginning and became part of the
eIDMS via their shareholder role with SK. On one side the eID is in competition
with their previous authentication by password cards. But on the other hand they
have an interest in an additional system with qualified certificates and stronger
authentication as well. Thus it was better for them to join and gain some control over
the competitor.
Diffusion and promotion
Although the public perception was not positive after the launch of ID-card, it has
been rapidly changing into more positive direction. The lack of applications,
226
T. Martens
unawareness and news about outrageous investment of 20 million EURO into the
project raised a lot of criticism in the public. No one seemed to take care of ID-cardenabled applications and usage in 2002. Although the MEAC was in charge of that
by the book, they did not take this role at the time.
Significant breakthrough came with a decision of SK to enter the ID-card usage
business. SK developed and launched the digital signing system DigiDoc at the end
of 2002 and started systematical work in areas of public promotion and support for
application developers and service providers. The reason for entering this business
was quite straightforward: SK was in charge of selling certificates; in case no one
would use them SK would have to go out of business. In addition SK was backed by
powerful industry players, including banks which are No.1 e-service providers
making use of ID-card authentication and digital signing. This unique setup of
private and public cooperation with strong players enabled to build a uniform
platform. But it was extremely hard to achieve this status as there were attempts
challenge it. In 2002 AS Cybernetica (www.cyber.ee) launched an alternative digital
signing tool/system and tried to compete with DigiDoc via local Estonian
standardization. This attempt was not successful and named standards were replaced
by a DigiDoc-style standard in 2008.
Strong commitment from the private sector has definitely been the key for the
successful uptake of the ID-card. E-services by private sector (e.g. Internet banking)
are massively more heavily used than public sector e-services. It is obvious that
without private sector involvement there will be no incentive to make ID-card
holders overcome the barrier of smartcard reader acquirement and usage learning
curve. Lately, MEAC and EIC have woken up and are making significant
contributions to the ID-card uptake by procurement of a new generation software
for the ID-card and supporting the Computer Security 2009 initiative by a number of
promotional and educational programs.
Computer Security 2009 is an initiative by major banks, telecom companies and the
Government, who signed a co-operation agreement on May 2006.19 This initiative
addresses general IT-security topics for end-users (firewalls, anti-virus etc.) but with
high emphasis on a transition to PKI-based authentication methods, including
&
&
&
&
promotion and widened support of the ID-card and Mobile-ID,
increasing availability and affordability of smartcard readers,
introduction of alternative PKI-based authentication systems like Mobile-ID and
alternative eID cards,
significant increase of the user base of PKI-based authentication systems in
3 years (from 27,000 to 300,000 by the end of 2009 (Fig. 6).
The Computer Security 2009 initiative has notably accelerated growth of ID-card
users. An “ID-card user” in these figures is defined as a cardholder making use of
certificates, for e-authentication or digital signatures. As every electronic usage of
the ID-card involves a certificate validation from SK’s OCSP responder, the numbers
are draws from the statistics of the OCSP responder usage. Number of ID-card eID
functionality users reached almost 300,000 by the end of 2009.
19
http://www.sk.ee/pages.php/02030201,1107.
Electronic identity management in Estonia
227
350000
300000
250000
200000
150000
100000
50000
20
02
VII
I
20
02
XII
20
03
IV
20
03
VII
I
20
03
XII
20
04
IV
20
04
VII
I
20
04
XII
20
05
IV
20
05
VII
I
20
05
XII
20
06
IV
20
06
VII
I
20
06
XII
20
07
IV
20
07
VII
I
20
07
XII
20
08
IV
20
08
VII
I
20
08
XII
20
09
IV
20
09
VII
I
20
09
XII
0
Fig. 6 Development of eID card users
The authentication by Internet banks is another significant factor to be considered
when assessing usage of the ID-card as banks providing authentication services to
third parties. The following graphs illustrate the growth of ID-card usage during
1 year with the two largest Internet banks (Figs. 7 and 8):
The most popular e-government service is tax declaration. In addition to ID-card
and Mobile-ID authentication, the e-tax board allows login via Internet banks and
100%
13.74%
13.21%
77.40%
68.90%
8.37%
13.63%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%
May 2008
ID-card Mobile-ID
Fig. 7 Online authentication at SEB Bank
June 2009
Password card PIN-calculator
228
T. Martens
100%
14.15%
15.51%
79.48%
73.58%
5.95%
10.24%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%
May 2008
ID-card
Mobile-ID
June 2009
Password card
PIN-calculator
Fig. 8 Online authentication at Swedbank
also delivers its own password cards. Usage of PKI-based authentication methods,
however, has been increased almost five-fold over past 2 years:
The most popular e-government service is tax declaration. In addition to ID-card
and Mobile-ID authentication, the e-tax board allows login via Internet banks and
also delivers it’s own password cards. Usage of PKI-based authentication methods,
however, has been increased almost five-fold over past 2 years (Fig. 9).
Until today we find a similar pattern as reported by Kubicek and Noack in this
issue for Belgium, Austria, and Spain: As long as other modes of authentication are
accepted by the tax office, the share of the eID is rather low (Table 3). But as in
Belgium it is growing.
20%
18%
16%
14%
12%
10%
8%
6%
4%
2%
0%
2007-02
2007-06
2007-10
2008-02
2008-06
Fig. 9 Usage of ID-Card and Mobile-ID in the E-tax Board
2008-10
2009-02
2009-06
Electronic identity management in Estonia
229
Table 3 The share of eID authentication in online tax services
BE
ES
AT
EE
State of rollout
early in 2009
9.3 million, 90%
of the Belgians
entitled to an
ID card
3 million, 10% of
the Spaniards
entitled to ID
card
8.4 million
e-Cards, 100%
of all citizens
1.1 million
active cards,
roll-out
complete
eID function
activated
7.5 million
(80%)
not necessary
approx. 74000,
0,9% thereof
approx. 20000
office ID cards
Around 50%,
the rest have
expired
certificates.
Use rate for
electronic
income tax
2008: 24%
2009: 56%
21%
25.7%
87%
eID use rate for
income tax
(% of the
electronic
applications)
2008: 3.6% 2009:
14,2% (half of
them with the
help of civil
servants in the
tax office)
2008: 0.1%
2008: 0.7%
6% (yearly
average)
The authentication by banks was and still is the biggest enemy of the eID based
authentication. But in Estonia, several measures are employed to make users
favouring the eID-based authentication:
&
&
&
All banks have continuously lowered the maximum money transfer sum when
authenticating with password cards. This sum is currently € 200/day.
A number of e-services advertise ID-card and Mobile-ID based authentication
over “bank authentication” by displaying informational banners and requiring
users to make an extra step for bank authentication.20
Few services like e-health, Internet voting and digital signing can be used
exclusively with the ID-card or Mobile-ID only.
Promotion and stimulation of applications
SK has been the center of eID support, promotion and excellence from the very
launch of the ID-card. SK operates a 24/4 phone support (short number: 1777)
initially designated for certificate suspension only but providing full end-user
support nowadays. A website www.id.ee contains comprehensive information for
end-users and developers on a wide range of eID topics. This includes self-training
application, problem solver, massive amount of well-structure information etc.
The ID-card software is available as of 2003 from https://installer.id.ee. The
Installer is an intelligent application which analyses configuration of the computer
(including attached smart-card reader if any) and installs all essential software with
one-click button. The user can enjoy animation on topics of ID-card usage whilst the
software is being installed. Essential software covers smart-card reader drivers for
20
See for example e-tax board http://www.emta.ee/?Id=12223.
230
T. Martens
more than twenty readers, middleware for the ID-card, web plug-ins for web-based
signing, service certificates, card management utility and DigiDoc Client for digital
signing and digital signature verification in the desktop environment. The latter has a
self-update functionality in order to drive people to update the software when
important updates are available.
Smartcard reader distribution problems were first tackled in 2003 after launching
the Installer mentioned before. At that time a €20 package was made available in
Elion stores (a fixed-line telecom giant) containing smartcard reader, manual and CD
with installation software which contained the same software as was available from
the website, This package was not entirely successful as the software in the printed
CD tended to outdate rapidly and the price margin was above expectations of the
average consumer (Figs. 10 and 11).
The second wave of smartcard reader distribution was started in 2007 after a bulk
deal with smartcard reader vendor Omnikey. This allowed bringing USB smartcard
readers at a price around €6 in the retail market. According to the deal, selected
alternative models like one with PIN-pad and one PCMCIA reader are also available
with above-the-average price mark. These readers are available from a number of
competing retail channels. This low price has inspired a number of campaigns such
as banks giving out free readers for selected customers, political party distributing
readers for free in order to promote Internet voting etc.
Most of the measures for helping the uptake have been carried out under the
“Computer Security 2009” program described above. Currently a number of
educational programs are running in order to bring more (especially elderly) people
to Internet and use of ID-card such as a moving ID-bus, stands in shopping malls,
courses for beginners, advanced courses and courses for “mentors” in local
Fig. 10 €20 ID-card Starter Kit from 2003
Electronic identity management in Estonia
231
Fig. 11 €6 Omnikey smart card reader
communities. The program is expecting to bring some 100,000 more Internet and
ID-card users during 1 year by summer 2010.
The Estonian case in comparison
Path dependency
Comparing the Estonian case with the developments in Austria, Belgium, Germany
and Spain and considering the main hypothesis related to the threefold path
dependency formulated by Kubicek and Noack in this issue, for the Estonian eID we
may state a only a medium degree of path dependency and some significant path
creations.
With regard to the definition of the eID there was no change. The eID has been
defined according to the ID registered in the national Population Register. But new
organizational paths have been created for production, issuing and personalization as
well as running the infrastructure. While in the other countries existing organizations
have taken over additional eID related functions in Estonia the founding of CMB is a
unique approach.
With regard to technical features there is a high degree of path dependency similar
to the other countries: The decisions taken for most of the technical components of
the Estonian eIDMS follow established paths of smart card and authentication
technologies. However the introduction of an additional mobile eID solution is a
case path creation which offers an alternative to the necessity for smartcard readers.
The regulatory pattern was kept quite stable. Existing legislation only was
adopted to legalize the technical and organizational changes.
Privacy issues
Kubicek and Noack report that in Austria, Belgium and Germany there was no doubt
that, because the eIDMS concerns basic privacy rights, precise legal regulation is
required. In Spain the Ministry of the Interior took the view that no additional data
232
T. Martens
will be collected compared to the previous ID card and the filing of fingerprints in a
central database and therefore no parliamentary consent is required.
In Estonia, although the certificate reveals personal data such as the date of birth
and as these personal data on the card are not PIN-protected, there was no privacy
debate in the process of legislation or in the media. There is only one remarkable
exception. Initially all active certificates were published in the freely accessible
LDAP21 directory. This made it possible to find out the birthday and gender of any
cardholder. After several years and couple of scandals in the media the set-up was
changed so that certificates can be queried from the LDAP directory by PIC only.
As the PIC is used as a key in most databases, both in the public and the private
sector, technically different personal information can be correlated. However, the
Data Protection Agency is taking care of personal privacy. Cross-relating personal
data between different databases is possible only with official permit from the Data
Protection Agency. The citizen can find out via Citizen Portal22 what data is
recorded about him/her in different databases of public administration and in some
cases also who has accessed the data.
Estonia seems to be culturally close to Scandinavian countries where safety of
personal data handed over to the government is considered “safe enough” and
privacy concerns are not that acute.
Staatsverständnis
A remarkable difference to the development in Austria and Spain as described in
previous papers in this issue, but somehow in line with the Belgium development is the
recent intense promotion. Compared to these countries Estonia since 2006 is offering
much more support. However, it has to be noted that this support does not come from
government and therefore is not caused by an corresponding Staatsverständnis
according to the Welfare State model. Rather Estonian politics is called sometimes
“ultra-liberal” meaning that government tries to outsource what they can and therefore
building so-called “thin state”. This happened to the eID development as well.
ID-card is issued by the government and was subsidized (around 50%) during
2002–2007. Now the fee for the ID-card is raised to almost covering the costs of the
issuance. But government did nothing during this period about client software or
smartcard readers. Rather the privately owned company SK did this so far. But this is
expected to change from this year as government is in the middle of contracting for
developing new wave of ID-card software.
Both these changes have very little to do with political changes. In case of
subsidizing the ID-card it was just a matter of calculation and judgment of “people
have now enough money to pay the full prize”. Software procurement was a result of
5 year long lobbying and opening of EU structural funds. Therefore we can not fully
confirm the generalisation by Kubicek and Noack that differences with regard to the
“Staatsverständnis” did influence the opening for e-commerce, the provision for
electronic signatures and the supporting provisions for components, hotlines etc.
21
22
Light Weight Directory Access Protocoll.
http://www.eesti.ee.
Electronic identity management in Estonia
233
Future perspectives
There will be no major changes in the eID arena in Estonia, except for a possible
upgrade of the ID-card chip. A next-generation ID-card is envisaged to be launched
during 2011, which will contain an RFID chip with biometric information such as in
the electronic passports. This, however, will not change anything with regard to the
definition of the eID and the electronic functionalities and applications for the IDcard. Two other major mobile operators launched Mobile-IDs in December 2009.
This could result in more attention and usage in Mobile-ID field in the future. Thus,
in contrast to Belgium and Spain, we can not confirm, that once a technical choice
has been made and a new path has been created, this establishes path dependency for
the future.
Open Access This article is distributed under the terms of the Creative Commons Attribution
Noncommercial License which permits any noncommercial use, distribution, and reproduction in any
medium, provided the original author(s) and source are credited.
Background reading
Cimander R. eID in Estonia. Good Practice Case. MODINIS Stud¥ on Interoperability at Local and
Regional Level. Prepared in Cooperation with Andreas Aarma and Ain Jary, AS Sertifitseerimiskeskus, Estonia. Download from http://www.ifib.de/projekte-detail.html?detail=Study%20on%20
Interoperability%20at%20Local%20and%20Regional%20Level&id_projekt=194 (last visited December
28th 2009.
European Commission, eGovernment in Estonia. eGovernment Factsheets, Edition 11.0, May 2009.
Download from http://www.eptactice.eu/en/factsheets. Last visited December 28 2009.
IDABC (Ed.), National Profile Estonia. eID Interoperability for PEGS. Brussels, November 2007.
Kubicek H, Noack T. The path dependency of national electronic identities. A comparison of innovation
processes in four European countries. Identity In The Information Society, Special Issue, 2010.
Tepandi J. A population wide ID Card (Estonia). Case description on http://www.eptactice.eu/cases/
eIDEstonia, last updated 10 December 2009. last vistied December 28 2009.
Smith A, Pickles J. Theorising transition: the political economy of post-communist transformation:
political economy of post-communist transformations London. Routledge Chapman & Hall; 1998.
Subrena J-J (Ed). Estonia: identity and Independence: Amsterdam–New York; 2004.
eGovernment in
Estonia
ISA
WHAT’S INSIDE
Country Profile
History
Strategy
Legal Framework
Actors
Who’s Who
Infrastructure
Services for Citizens
Services for Businesses
Visit the e-Government factsheets online on Joinup.eu
Joinup is a collaborative platform created by the European Commission under the Interoperability
Solutions for Public Administrations (ISA) in Europe Programme. Joinup provides numerous services
around 3 main functionalities:
1. An observatory on interoperability, e-government, e-inclusion and e-health
2. A collaborative platform of open communities
3. A repository of interoperability solutions
This document is meant to present an overview of the eGoverment status in this country and not to be exhaustive in its
references and analysis. Even though every possible care has been taken by the authors to refer to and use valid data
from authentic sources, the European Commission does not guarantee the accuracy of the included information, nor does
it accept any responsibility for any use thereof.
Cover picture © Fotolia
Content © European Commission
© European Union, 2015
eGovernment in Estonia, January 2015, Edition 17
Country Profile ......................................................................................... 1
eGovernment History ............................................................................... 7
eGovernment Strategy ........................................................................... 18
eGovernment Legal Framework ............................................................. 24
eGovernment Actors .............................................................................. 28
eGovernment Who’s Who ....................................................................... 32
eGovernment Infrastructure .................................................................. 35
eGovernment Services for Citizens ......................................................... 39
eGovernment Services for Businesses .................................................... 43
eGovernment in Estonia
January 2015
Country Profile
Basic data and indicators
Basic Data
Population (1 000): 1,315,819 inhabitants (2014)
GDP at market prices: 18,739 million Euros (2013)
GDP per inhabitant in PPS (purchasing Power Standards EU 28=100): 72.8 (2013)
GDP growth rate: 1.6 % (2013)
Inflation rate: 0.5 % (2014)
Unemployment rate: 8.6% (2013)
General government gross debt (Percentage of GDP): 10.1% (2013)
General government deficit/surplus (Percentage of GDP): -0.5% (2013)
Area: 45,227 km2
Capital city: Tallinn
Official EU language: Estonian
Currency: EUR
Source: Eurostat
Political Structure
Estonia is a parliamentary republic.
Legislative power lies within the unicameral Parliament, called the State Assembly
(Riigikogu in Estonian). The Assembly has 101 members, elected by popular vote, to serve
four-year terms. Members are elected on the basis of a proportional system, and a 5 %
splinter party threshold applies for those wishing to take part in parliamentary activities.
Estonia’s Head of State is the President, elected for a five-year term by the Riigikogu. The
Government, exercising executive power, is formed by the Prime Minister, nominated by
the president and a total of 14 ministers. The Government is appointed by the President
with the approval of the Parliament.
Estonia is divided into 15 counties and 227 urban and rural municipalities (towns and
parishes), whose powers and responsibilities are established by the Local Government
Organisation Act of June 1993. The Government of each county is led by a County
Governor, who represents the national Government at regional level and is appointed by
the Central Government for a term of five years. Local self-government is exercised solely
at the municipal level.
The Constitution of the Republic of Estonia was adopted on 28 June 1992.
Estonia became a member of the European Union on 1 May 2004.
Head of State: President Toomas Hendrik Ilves (since 9 October 2006).
Head of Government: Prime Minister Taavi Rõivas (since 26 March 2014).
[1]
eGovernment in Estonia
January 2015
Information Society Indicators
Generic Indicators
The following graphs present data for the latest Generic Information Society Indicators for
Estonia compared to the EU average. Statistical indicators in this section reflect those of
Eurostat at the time the Edition is being prepared.
Percentage of households with
Internet access in Estonia
90%
80%
70%
67
69
83
79
74
Percentage of enterprises with
Internet access in Estonia
100%
96
96
97
96
2011
2012
2013
2014
90%
80%
60%
70%
50%
60%
50%
40%
40%
30%
30%
20%
20%
10%
10%
0%
2010
96
0%
2011
2012
2013
2014
2010
Source :
http://appsso.eurostat.ec.europa.eu/nui/show.do?dataset=iso
c_bde15b_h&lang=en
Source:
http://appsso.eurostat.ec.europa.eu/nui/show.do?dataset=iso
c_ci_in_en2&lang=en
Percentage of individuals using the internet at least once a week in Estonia
90%
80%
71
73
75
77
2011
2012
2013
82
70%
60%
50%
40%
30%
20%
10%
0%
2010
2014
Estonia
EU
Source : http://appsso.eurostat.ec.europa.eu/nui/show.do?dataset=isoc_bdek_di&lang=en
[2]
eGovernment in Estonia
January 2015
Percentage of households with a
broadband connection in Estonia
90%
80%
70%
73
64
78
81
Percentage of enterprises with a
broadband connection in Estonia
100%
90%
65
88
92
96
96
96
2012
2013
2014
80%
60%
70%
50%
60%
40%
50%
40%
30%
30%
20%
20%
10%
10%
0%
0%
2010
2011
2012
2013
2014
2010
2011
Source :
http://appsso.eurostat.ec.europa.eu/nui/show.do?dataset=iso
c_r_broad_h&lang=en
Source:
http://appsso.eurostat.ec.europa.eu/nui/show.do?dataset=iso
c_bde15b_e&lang=en
Percentage of individuals having
purchased/ordered online in the last
three months in Estonia
Percentage of enterprises having
received orders online within the
previous year in Estonia
45%
16%
40%
37
35%
12
12%
30%
10%
25%
10
11
11
2011
2012
10
8%
20%
15%
14%
16
17
16
6%
13
10%
4%
5%
2%
0%
0%
2010
2011
2012
2013
2014
Source:
http://epp.eurostat.ec.europa.eu/tgm/table.do?tab=table&init
=1&language=en&pcode=tin00067&plugin=1
2010
2013
2014
Source :
http://epp.eurostat.ec.europa.eu/tgm/table.do?tab=table&init
=1&language=en&pcode=tin00111&plugin=1
Estonia
EU
[3]
eGovernment in Estonia
January 2015
eGovernment Indicators
The following graphs present data for the latest eGovernment Indicators for Estonia
compared to the EU average. Statistical indicators in this section reflect those of Eurostat at
the time the Edition is being prepared.
Percentage of individuals using the
internet for interacting with public
authorities in Estonia
55%
50%
45%
40%
35%
30%
25%
20%
15%
10%
5%
0%
50
2010
53
55
48
2011
2012
2013
51
2014
Source :
http://appsso.eurostat.ec.europa.eu/nui/show.do?dataset=iso
c_bde15ei&lang=en
Percentage of individuals using the
internet for obtaining information from
public authorities in Estonia
55%
50%
45%
40%
35%
30%
25%
20%
15%
10%
5%
0%
49
2010
48
2011
51
45
2012
2013
48
2014
Source:
http://appsso.eurostat.ec.europa.eu/nui/show.do?dataset=iso
c_bde15ei&lang=en
Estonia
EU
[4]
eGovernment in Estonia
January 2015
Percentage of individuals using the
internet for downloading official forms
from public authorities in Estonia
40%
38
35%
Percentage of individuals using the
internet for sending filled forms to
public authorities in Estonia
40%
31
31
30%
30
20%
15%
15%
10%
10%
5%
5%
0%
0%
2013
30
2014
Source:
http://appsso.eurostat.ec.europa.eu/nui/show.do?dataset=iso
c_bde15ei&lang=en
32
25%
20%
2012
33
30%
25
2011
36
35%
25%
2010
38
2010
2011
2012
2013
2014
Source:
http://appsso.eurostat.ec.europa.eu/nui/show.do?dataset=iso
c_bde15ei&lang=en
Estonia
EU
[5]
eGovernment in Estonia
January 2015
eGovernment State of Play
The graph below is the result of the latest eGovernment Benchmark1 study, which monitors
the development of eGovernment in Europe, based on specific indicators. These indicators
are clustered within four main top-level benchmarks:




User Centricity – indicates to what extent (information about) a service is provided online and
how this is perceived.
Transparent Government – indicates to what extent governments is transparent regarding: i)
their own responsibilities and performance, ii) the process of service delivery and iii) personal
data involved.
Cross Border Mobility – indicates to what extent EU citizens can use online services in another
country.
Key Enablers – indicates the extent to which 5 technical pre-conditions are available online.
There are: Electronic Identification (eID), Electronic documents (eDocuments), Authentic
Sources, Electronic Safe (eSafe), and Single Sign On (SSO).
These top-level benchmarks are measured using a life-events (e.g. mystery shopping)
approach. The following life-events were used for measuring the eGovernment Benchmark
top-level indicators: Business start-up and early trading operations, Losing and Finding a
Job, Studying, Regular business operations, Moving, Owning and driving a car, and Starting
a small claims procedure. The figure below presents the development of eGovernment in
Estonia compared to the EU average score.
Source: http://ec.europa.eu/information_society/newsroom/cf/dae/document.cfm?doc_id=5550
1
http://ec.europa.eu/information_society/newsroom/cf/dae/document.cfm?doc_id=5812
[6]
eGovernment in Estonia
January 2015
eGovernment History
Main developments and key milestones (in reverse
chronological order)
For the latest developments, see: Joinup news.
Recent News
February 2015
General elections are held in Estonia. At the time of updating this document, the
percentage of internet voters (i-voters) in the total number of voters is not yet clear, but a
new i-voting record has again clearly been set with 176491 voters having cast their vote
electronically.
The Minister of Economic Affairs and Communications and the Minister of Education and
Research sign the Science and Technology Pact. The pact is a cooperation agreement
between the government, local authorities, educational institutions, the private sector and
non-governmental organisations to support the technology and engineering fields. The aim
of the Science and Technology Pact is the sustainable development of education and
entrepreneurship in the field, as well as the supply of an adequate workforce.
January 2015
The Minister of Economic Affairs and Communications signs an ambitious plan to increase
digital literacy in Estonia, funded by the EU Social Fund. The plan foresees a myriad of reand upper-skilling projects with dual aims of increasing both basic computer literacy skills
and fostering the development of ICT-skills for specialists within other sectors.
The Ministry of Economic Affairs and Communications starts cooperation with the University
of Oxford (UK) to study the implications of information society and cyberspace and to pass
that knowledge on to Estonian students outside ICT-subjects. This is a cutting-edge project
being the first systematic research and teaching initiative dedicated to cyber issues within
political science at any of the world's major universities.
December 2014
Estonia becomes a founding member of the D5 alliance of leading e-governance countries.
The purpose of the alliance, established in 2014 in London, is to exchange experience about
information society and the e-state.
In 2015, D5 will focus on the following topics: best practices of IT procurement,
programming studies for children, and connectivity (Internet availability and quality). The
2015 summit of D5 will be held in Estonia.
In addition to Estonia, the network includes the United Kingdom, South Korea, Israel, and
New Zealand.
The Government of the Republic approves a Green Paper on Open Data elaborated at the
leadership of the Ministry of Economic Affairs and Communications. In addition, a new
improved version of open data gateway at https://opendata.riik.ee/ goes live.
[7]
eGovernment in Estonia
January 2015
November 2014
Estonia becomes the first country in the world to issue e-residency. People from all over the
world now have an opportunity to get digital identity provided by the Estonian government
in order to get secure access to world-class digital services from wherever you might be.
E-residency is a state-issued secure digital identity for non-residents that allows digital
authentication and the digital signing of documents.
An e-resident will be a physical person who has received the e-resident’s digital identity
(smart ID-card) from the Republic of Estonia. This will not entail full legal residency or
citizenship or right of entry to Estonia.
Instead, e-residency gives secure access to Estonia’s digital services and an opportunity to
give digital signatures in an electronic environment. Such digital identification and signing is
legally fully equal to face-to-face identification and handwritten signatures in the European
Union.
October 2014
The e-Governance Academy of Estonia enters into an agreement with the government of
Namibia for the implementation of a data exchange layer similar to X-Road in Namibia over
the next two years.
The X-Road will enable Namibian public sector institutions to make secure, Internet-based
crossover use of data from different institutions and to develop e-services for the country’s
residents and companies. Estonia has assisted in the development of an information system
similar to the X-Road in Azerbaijan and is currently helping Palestine on this issue.
September 2014
The Government approves the Cyber Security Strategy for 2014–2017 with the objective of
increasing the capacity of the state in the area of cyber security and raising the awareness
of the population of cyber risks.
The strategy focuses on ensuring the provision of vital services, raising the efficiency of
combating cyber-crimes and development of the national defence capacity. The additional
supporting activities are the development of the legal framework, improvement of
international cooperation, raising the awareness and ensuring the availability of experts and
solutions for cyber security.
July 2014
An eHealth Task Force is set up at the leadership of the Government Office with a goal to
develop a strategic development plan for Estonian eHealth until 2020.
The role of the Task Force is to develop an Estonian eHealth Strategic Development Plan
until 2020 along with development activities, a financing plan and a detailed
implementation plan for 2015 - 2017.
[8]
eGovernment in Estonia
January 2015
June 2014
From June 2014, all ministries have similarly designed and structured webpages to allow
the visitor to access information faster and more easily than before as well as have a clear
overview of the goals and activities of the government and governmental authorities.
The similarly structured and designed webpages of the Government, Government Office
and 11 ministries now form a common online environment – the Government Portal.
April 2014
On April 23-30, the first ever Tallinn ICT Week is held in Tallinn. A number of different
seminars, conferences and workshops aimed at different target groups, e.g. ICT sector,
other sectors of economy, start-up community, policy-makers from all over the world etc is
held throughout the week. One of the central events of the ICT Week is the Nordic Digital
Agendas Day, organized at the initiative of the Ministry of Economic Affairs and
Communications. During the conference, ICT policy-makers from all Nordic countries share
their experience in developing information society and discuss regional co-operation in the
field. The week ends with a high-level freedom online conference "Free and secure internet
for all", organized in co-operation with the Ministry of Foreign Affairs of Estonia and the
Freedom Online Coalition.
March 2014
A new Tallinn-Helsinki cross-border fibre connection is launched between EEnet and Funet,
the Estonian and Finnish national research and education networks. The new high capacity
optical fibre connection between the two capitals provides major improvement of the
available network transmission capacity between the Estonian and Finnish research and
education networks. For more information, please see here
The world's most popular programming tool Codecademy.com is now available also in
Estonian. The project was carried out at the initiative of the Information Technology
Foundation for Education to facilitate teaching and learning of code-writing both in
educational institutions and on a wider scale in society. Estonian is one of the first working
languages of Codecademy after English language. For more information see here.
January 2014
The Estonian education minister Jaak Aaviksoo and Finnish education minister Krista Kiuru
sign a co-operation memorandum on the creation of a joint Estonian-Finnish Education
Cloud. The cloud provides a digital environment for stud materials and good practices,
which supports better learning and is open for all students and teachers.
December 2013
The prime ministers of Estonia and Finland conclude the first digitally signed
intergovernmental agreement (Memorandum of Understanding) focusing on joint
development of e-services between the two countries. One of the central elements of the
memorandum foresees that the state data exchange layer, known in Estonia as the X-Road,
will be developed jointly with Finland in the future.
[9]
eGovernment in Estonia
January 2015
November 2013
Digital Agenda 2020 for Estonia together with implementation plan for 2014-2015 is
approved by the Government of the Republic. The general objective of the Estonian new
ICT policy is to ensure a well-functioning environment for the widespread use and
development of ICT-solutions, contributing thereby to the economic growth, better public
administration and greater well-being of people. The document sets out actions in four
target areas: ICT infrastructure, better ICT skills, smarter governance and public
administration, and greater awareness of e-Estonia in the world. The strategy that was
elaborated in close co-operation with representatives of the private and the nongovernmental sector also sets out a vision for information society 2020.
An ambitious project entitled Nutikaitse 20017 is initiated in co-operation between the
public and the private sector. The aim of the project is to promote safer use of smart
devices and development of secure mobile services. For more information see here.
October 2013
On October 7, 2013, a specific programme is approved for carrying out different projects
aimed at increasing the efficiency and effectiveness of public services via ICT tools. The
programme is initiated and implemented at the leadership of the Ministry of Economic
Affairs and Communications.
September 2013
Neelie Kroes, the Vice-President of the European Commission, visits Estonia in order to
discuss the development of the digital single market as well as issues related to increasing
competitiveness, simplifying doing business and reducing bureaucracy through the use of esolutions.
When presenting the development of e-services in Estonia to Kroes, the Prime Minister of
Estonia, Andrus Ansip, gave her a personalised test-ID card as a gift and the Commissioner
could try giving a digital signature, while seeing its simplicity and performance. The goal of
Estonia is to reach the recognition and use of digital signatures across Europe.
May 2013
On May 16, 2013 the Government of the Republic approves the Green Paper on the
Organisation of Public Services in Estonia. The document:
 establishes the definition of "public service";
 identifies problems faced by citizens and enterprises in the usage of central and local
government services;
 proposes solutions.
On the same month, the Director General of the Estonian Information System's Authority
(RIA), Jaan Priisalu, and the Head of the State Portal (eesti.ee), Mihkel Tikk, meet the
President of the Portuguese Agency for the Modernisation of the Public Administration
(AMA), Paulo Neves, and its representatives. The purpose of the meeting is to exchange
best practices on the modernisation of the two states’ public administration.
AMA representatives are particularly interested in RIA’s Document Exchange Centre
(Dokumendivahetuskeskus - DVK, in Estonian). This is an information system that provides
[10]
eGovernment in Estonia
January 2015
a common central document exchange service for various document management systems
as well as other information systems that handle documents. In addition, both RIA and AMA
representatives agree to deepen collaboration and make a formal proposal to sign a
memorandum of cooperation.
April 2013
Annual information society conference is held at the initiative of the Ministry of Economic
Affairs and Communications. This year's event is designed to contribute to the elaboration
of the new ICT strategy and focuses, thus, on the priorities and objectives of information
society development in the next seven years.
In the framework of the conference, the winners of a competition "Best e-services in
Estonia" were announced. The overall winner of the contest, a company offering money
transfer service - Transferwise - was also nominated for the World Summit Award, where it
was chosen as one of the 40 best e-services in the world.
March 2013
The Estonian State Portal eesti.ee celebrates its 10th anniversary.
February 2013
Estonia and the UK sign a memorandum of understanding for the two countries to
exchange experience in creating user-friendly public e-services.
During the same month, a study by the Ministry of Economic Affairs and Communications
reveals that the use of electronic solutions has changed the way public services work by
being 12 times faster and of higher quality than the conventional services.
Margus Püüa, Ministry’s State Information Systems department mentions that despite the
limited research conducted so far, a substantive impact analysis pertaining to the use of
and satisfaction with eServices has yet to be conducted. He adds that the purpose of the
study is to develop a method and use it to assess how much time and money eServices can
save.
News 2012-2001
2012
On 27 September 2012, the Government approves a proposal, drafted by the Estonian
Information Society Strategy 2014-2020, which will constitute the basis for the Ministry of
Economic Affairs and Communications (Majandus- ja Kommunikatsiooniministeerium MKM, in Estonian) to prepare a new Information Society Strategy 2020. The greatest
benefits of this development include: good Internet accessibility, the use of services to
support the development of state information and security for citizens and businesses, as
well as the development of electronic services.
 In February 2012, since the launch of the national eID card ten years ago (28 January
2002), around 1.6 million cards have been issued, and citizens have well integrated
their use into their daily lives. Ms Tatjana Portnova, Estonian Police and Border Guard
[11]
eGovernment in Estonia
January 2015
Board's service centre director says that people have been showing a multiplied interest
in the use of the eID card, on a daily basis.
2011
 A new version of the State Portal 'eesti.ee' goes live in November 2011. The
development of the portal, led by the State Information System's Authority is based on
user involvement and their feedback. One of the major benefits of the new version is
that search for information is much faster, as articles, services and contacts are better
interconnected.
 During the same month, Tallinn, the capital of Estonia, is awarded with the European
Public Sector Award 2011 for citizen eServices.
 On 9 September 2011, a Memorandum on Mutual Assistance is signed between Estonia
and Greece. The objective of the co-operation was the reduction of corruption and
bureaucracy through ICT.
 Between 26-28 September 2011, an international eGovernment conference ICEGOV
(International Conference on Theory and Practice of Electronic Governance) is organised
under the auspices of the UN and held in Tallinn, Estonia.
 On 27 September 2011, the annual information society conference was held in Tallinn,
focusing on copyright in the information society, aiming to analyse the topic from a
balanced viewpoint, taking into account the interests and rights of creators, users and
the industry.
 In August 2011, the Information Society Yearbook 2010 is compiled by the Department
of State Information Systems, Ministry of Economic Affairs and Communications. The
Information Society yearbook of 2011-2012 is also available.
 Estonia's eAnnual reporting environment, which enables entrepreneurs to file annual
reports electronically is voted and announces a winner in the category of 'eGovernment
& Institutions' at the global eContent contest World Summit Award (WSA) 2011 on 16
June 2011. The eReporting environment enables entrepreneurs to submit their
compulsory annual reports via the eBusiness Registry Company Registration Portal.
 Following a reorganisation on 1 June 2011, the public authority in charge of Estonia's
information systems' security, is renamed from Estonian Informatics Centre to Estonian
Information System's Authority (EISA). It will help with and monitor the security of the
information systems of private and public sector organisations. It has 11 main
functions, but the reorganisation primarily affected the two departments dealing with
information security. These are:
 The Department of Critical Information Infrastructure Protection (CIIP) evaluates
the security of information systems in Estonia and carries out risk assessments.
 The Computer Emergency Response Team Estonia (CERT-EE) handles security
issues involving the '.ee' domain.
 In April 2011, a new information system for the management of draft laws is launched.
The Draft Information System (Eelnõude Infosüsteem - EIS) provides access to all draft
laws and other documents that have been submitted by government bodies for
consultation and approval or sent to the Government.
 On 6 March 2011, Parliamentary Elections are held in Estonia. For the fifth time in a
row, Estonians are able to cast their votes over the Internet during the advanced polling
days from 28 February to 2 March 2011.
 The Estonian Government launched the Rural Municipality Portal in February 2011. The
Portal aims to increase the transparency of local governments and expand citizen
[12]
eGovernment in Estonia
January 2015
participation. The service portal is based on an open source content management tool
which allows for easy and uniform site administration.
 On 1 February 2011, the Estonian Police and Border Guard (Politsei- ja Piirivalveamet)
made available a new type of digital identity, the mobile-ID, which enables users to
provide electronic identification and a digital signature using a mobile phone.
 On 31 January 2011, the Estonian Unemployment Insurance Fund opens its self-service
employment portal for public testing. Anyone interested could find and view in the
portal public-sector job vacancies. Users can log in by using their ID-card or mobile-ID
and then create their own CV, apply for jobs, manage their own work requests, review
the statements made to the Unemployment Insurance Fund about the outcomes and
decisions, and inform them of any changes to their data or situation.
 In 2011 good progress is made towards the goals of the Estonian broadband strategy,
EStWin, aiming to build a country-wide broadband network capable of delivering
100 Mbps connections to the majority of Estonian households and businesses by
the end of 2015. The Estonian Broadband Development Foundation (ELA) will be
responsible for the EstWin, a project with the aim of bringing the new generation
broadband networks into every home, business and institution and so eliminating the
digital divide between the Estonian countryside and the biggest cities.
2010
 Since August 2010, the section of the 'Eesti.ee', aimed at companies is updated and
translated into English to promote cross-border business and public services to the
benefit of European companies. The section for companies of 'Eesti.ee' works as a Point
of Single Contact that enables service providers operating all over Europe to solve the
formalities needed for starting or continuing their business activities in the European
Union (EU).
 'Diara' is an open source application that allows public administrations to use the
Internet in order to organise polls, referenda, petitions, public inquiries as well as to
record electronic votes using electronic identity (eID) cards; its first version went online
at the end of August 2010.
 On 1 July 2010, Estonia switches to digital-TV.
 On 5 July 2010, new domain rules come into force in Estonia, making the '.ee' country
code top-level domain (ccTLD) significantly more accessible. While according to the
previous rules, only companies could obtain '.ee' domains, private individuals and
foreigners will now be able to obtain them too. In addition, a person will be able to
register several domains. The new regime introduces a dual-level registration, the
interaction with registrants being delegated to registrars by the Estonian Internet
Foundation.
 According to the findings of a research study executed in June 2010, 75 % of the
Estonians who used the public electronic services are very satisfied. 1 020 Estonian
residents were interviewed for this study, in the framework of the 'Information society
awareness' campaign, which is funded by the European Union Structural Funds in
Estonia.
 The Estonian Government approved on 1 April 2010 an amendment bill to the Electronic
Communications Act and the Information Society Services Act regulating the use of
individuals' electronic contact data for sending out commercial emails.
 In February 2010, the Government of Estonia approves the Implementation Plan for
2010-2011 of the Estonian Information Society Strategy 2013.
[13]
eGovernment in Estonia
January 2015
 In January 2010, a digital prescriptions system is launched in Estonia, freeing the
patients from the fear of losing or forgetting their paper prescriptions and considerably
reducing the time doctors and pharmacies spend on them.
 A month-long campaign entitled 'Gateway to eEstonia' is launched in January 2010 to
promote State Portal eesti.ee both to the general public and to service providers. The
campaign's objective is to increase users’ awareness of the portal and invite them to
provide feedback on how to improve the website and increase its user-friendliness.
2009
 On 1 October 2009, the Estonian Informatics Centre - EIC (Riigi Infosüsteemide
Arenduskeskus - RIA) opened its Department for Critical Information Infrastructure
Protection (CIIP). CIIP aims to create and run the defence system for Estonia's critical
information infrastructure.
 In August 2009, Estonia’s largest ICT companies establish the Estonian Broadband
Development Foundation with the objective that the basic infrastructure of the new
generation network in Estonian rural areas is developed by the end of 2015.
 In July 2009, the Government of the Republic approved the amended version of the
'Estonian Information Society Strategy 2007-2013'. The update concerns measure
4.1.1, 'Broadening technological access to digital information' to which a chapter was
added on the development of broadband internet. In addition, the Estonian 'Rural
Development Plan 2007-2013' is amended in the summer of 2009 to allow for the use of
resources of the EU recovery package.
 During the second week of May 2009, the first company in Estonian business history is
created in the Company Registration Portal with a Finnish ID card, without the founders
of the company having had to leave their desks to have the company officially
registered in Estonia. The Estonian Company Registration portal which opened to the
users of Finnish ID-cards at the end of last year also accepts digital signatures from
Portugal, Belgium and Lithuania.
2008
 In August 2008, entrepreneurs are invited to activate their email address on the
eGovernment Portal to avoid company identity theft and detect it when it occurs.
Businesses which subscribe to the service will receive an automatic notification when
the Commercial Register receives an application for altering an entry.
 In May 2008, the Estonian Government adopts a Cyber Security Strategy. Cyber
security in Estonia is primarily based on reducing the vulnerability of the cyberspace in
the nation as a whole. This is accomplished through the implementation of domestic
action plans, but also through an active international cooperation which supports the
enhancement of cyber security.
 Since April 2008, residents of the Estonian capital city, Tallinn, can apply for and renew
parking permits electronically on https://www.parkimine.ee/en using their eID card,
Mobile-ID or Internet banking authorisation codes. The payment of the granted permits
is performed online.
 As of 15 February 2008, Estonians have made use of the improved Tax and Customs
Board's online service to submit their tax returns electronically can benefit from
refunds well before those who have chosen to complete theirs on paper.
[14]
eGovernment in Estonia
January 2015
2007
 During the last quarter of 2007, a new version of the Estonian State portal results from
the merge of the former State Information portal and the Citizen portal, created a single
integrated service. Access to information and eServices on the new portal depends on
whether the user is a citizen, entrepreneur or State official.
 During December 2007, a new, user-friendly tax and customs web service is
launched. Following a consultation period with Internet users, the website’s sections
have been designed to match the needs of different user groups, whether they are
private persons or representatives of legal entities.
 In November 2007, the Ministry for Economic Affairs and Communications approves the
programme 'Raising Awareness about the information society' whose objective is to
inform citizens on the possibilities of the information society. The programme is
implemented over the period 2007 - 2013 by the Estonian Informatics Centre with a
total budget of 50 million Estonian kroons (approx. € 3.2 million), funded from the EU
Structural Funds.
 In September 2007, the Informatics Council - an advisory committee for the
Government of Estonia – approved thehttp://www.riso.ee/en/files/Implementation Plan
2007-2008 of the Estonian Information Society Strategy_0.pdf Estonian information
society Strategy 2013, promoting the development of a citizen-centred and inclusive
information society, as well as the advancement of the knowledge-based economy.
 In August 2007, the Estonian Tax and Customs Board begins offering a new eService
to local authorities which enables them to make inquiries on the income of the
taxpayers living in their area.
 Due to the cyber-attacks against Estonia’s governmental and private web pages, the
Government approves an Action Plan to fight cyber-attacks in July 2007. The plan,
implemented by the Ministries in charge of Economic Affairs and Communications,
Defence, Internal Affairs and Justice, aims to create a strong legal basis for fighting
cyber-crime and seeks to improve the processes for preparing for such emergencies.
 Furthermore, the Osalusveeb website is launched; it allows everyone (Estonian citizens,
associations, civil society stakeholders) who has registered as a user to express
opinions on drafts published by the Government.
 Since June 2007, Estonian businesses can submit their annual accounting reports
electronically through the Company Registration Portal.
 Launch of the Mobile-ID service in May 2007. Mobile-ID enables the identification of a
person and the signature of digital documents via mobile phone, giving greater freedom
for performing transactions that require personal identification.
 In April 2007, Estonia’s governmental and private web pages suffer coordinated cyberattacks.
 On 4 March 2007, Estonia holds the world's first national general elections with an
Internet voting option. A total of 30 275 citizens uses this option to register their
preferences for the Estonian Parliament (Riigikogu).
 In February 2007, the newly launched Company registration portal makes it possible for
start-up companies to set up a new company electronically, in just a couple of hours,
using an eID card.
 Regulations for X-Road, the middle-tier data exchange layer enabling Government
databases to communicate with each other, are also published that month.
 The ‘Estonian Information Society Strategy 2013’ enters into force on 1 January 2007.
It is conceived as a sectoral development plan, setting out the general framework,
[15]
eGovernment in Estonia
January 2015
objectives and respective action fields for the broad use of ICT in the development of
the knowledge-based society and economy in Estonia for the period 2007-2013. The
plan focuses on the use of IT to improve quality of life and increase citizen involvement
in public life.
 Moreover, citizens can request an electronic voter card through the eGovernment portal
for citizens by 31 January 2007. Once registered for the eVoter card, citizens will no
longer receive paper voter cards through normal mail.
2006
 In December 2006, the Estonian Informatics Centre (RIA) conducts a legal analysis
to assess the legitimacy of electronic communications between the State and citizens.
The study coincides with the introduction of a new service called the ‘Notification
Calendar’ on the eGovernment portal.
 In July 2006, for the third year in a row, Estonian students taking national examinations
can register on the Estonian Citizen’s Portal to receive their results either by email or on
their mobile phones via SMS. Results reach examinees as soon as the marks are
entered into the central database.
 Moreover, the Estonian Government launches a new service enabling Estonian high
school graduates to apply to universities online. This new service is available on the
Citizen’s portal, or on the new Common Admissions Information Portal (SAIS).
 In May 2006, Estonia’s Computer Emergency Response Team (CERT) is officially
presented. This new unit of the Estonian Informatics Centre deals with security incidents
that occur on Estonian networks, carries out preventive actions and contributes to
awareness-raising on Internet security.
 During that same month, leaders of the largest banks and telecommunication
companies as well as the Ministry of Economic Affairs and Communications sign a cooperation agreement to launch a nationwide 'Computer Protection 2009' initiative so as
to increase end-user PC protection in Estonia while making the country the most secure
information society in the world by 2009.
 Publication of the Estonian IT Interoperability Framework, (version 2.0) in April 2006.
 In March 2006, the new initiative Küla Tee 3 (VillageWay 3) is launched. Its objective is
to improve access to permanent Internet connection in sparsely populated rural areas
by guaranteeing quality Internet coverage of 90 % of Estonia’s territory.
 Moreover, the Estonian Ministry of Economic Affairs and Communications releases the
annual report ‘IT in Public Administration of Estonia - Yearbook 2005’. It presents the
main achievements in the eGovernment field in 2005, the latest figures relating to the
information society progress in Estonia and a brief description of the Government’s
‘Information Policy Action Plan 2004-2006.
2005
 In November 2005, Estonia launches a nation-wide Information Security policy
which specifies and coordinates the upcoming eSecurity related initiatives, aiming to
create a secure ‘eEnvironment’ for business and consumers.
 In October 2005, Estonia becomes the first country in the world to enable its citizens to
vote over the Internet for political elections. To vote online, users must insert their eID
cards into readers connected to their computers and log on to the Internet voting
website.
[16]
eGovernment in Estonia
January 2015
 In June 2005, the Government adopts the Information Policy Action Plan for 20042006.
 In April 2005, the Estonian Parliament approves the Estonian Broadband Strategy
setting out the principles for the development of fast Internet connections until 2007.
2004
In May 2004, the Estonian Government adopts a new information society policy called
Principles of the Estonian Information Policy 2004-2006. An Information Policy Action Plan
for 2004-2006 is also adopted.
2003
 In May 2003, Finland and Estonia sign an agreement to harmonise the concepts and
practices between the two countries regarding digital signature, document format and
exchange. The project, codenamed 'OpenXAdES', is an open initiative which promotes
the 'universal digital signature'.
 In March 2003, the Estonian Government launches its eGovernment portal eesti.ee.
The site is intended to provide a single, one-stop umbrella for the many Government
services already online, as well as for all new services being developed.
2002
 In the summer of 2002, together with the United Nations Development Programme
(UNDP) and the Open Society Institute (OSI), the Estonian Government establishes an
eGovernance Academy (EGA) to enable Estonia’s neighbours to benefit from its
eGovernment experience and expertise.
 In January 2002, Estonia starts the introduction on national electronic ID cards. The
card functions are to be used in any form of business, governmental or private
communications.
2001
 In December 2001, the 'X-Road' system (‘X-tee’ in Estonian) is launched. 'X-Road' is a
middle-tier data exchange layer enabling governmental databases to communicate.
 In the summer of 2001, the Estonian Government launches an innovative
eDemocracy portal, TOM (Täna Otsustan Mina – 'Today I Make Decisions') whose aim
is to enhance citizens’ participation in the public decision-making process. This portal
has since then been renamed to ‘Osalusveeb’.
 In February 2001, the Government approves an updated Information Policy Action Plan.
[17]
eGovernment in Estonia
January 2015
eGovernment Strategy
Main strategic objectives and principles
Estonian Information Society Strategy 2014 - 2020
The Information Society Strategy 2020 does not
deal with the introduction of ICT in various
residential and policy areas, such as the use of
ICT in health care or business. Rather it focuses
on the use of ICT and smart solutions for the
creation of an enabling environment assurance.
The higher goal is thus to support the
competitiveness of the economy through ICT,
human well-being and an increase in the efficiency of state government.
The Information Society Strategy includes a number of steps necessary for development
activities. Indicatively these steps include the following:
 Construct a base ready for the ultra-fast Internet network, enabling that at least 60 %
of all Estonians use the Internet on a daily basis.
 Enhance the cross-border capability of eServices in joint cooperation with the Nordic
Institute of eGovernment Innovation aiming at developing X-roads, eIdentities, digital
signatures, etc.
 Enable that by 2020, 20 % of the population uses the digital signature.
 Provide people with the technological and organisational infrastructure to take control
over the use of their data and know at any time who, why, when and how these data
are being used by their government.
 Modernise Estonian public eServices and implement uniform quality standards and
support reform of old IT solutions.
 Improve related policies for better decision-making and service provision.
 Launch a virtual or eResidency by issuing a digital identity to non-residents and
providing its eServices in a similar way to Switzerland's banking industry.
Cyber Security Strategy 2014-2017
The Cyber Security Strategy 2014-2017 is the basic document for planning Estonia’s cyber
security and a part of Estonia’s broader security strategy. The strategy highlights important
recent developments, assesses threats to Estonia’s cyber security and presents measures
to manage threats. The strategy continues the implementation of many of the goals found
in the Cyber Security Strategy 2008-2013.
The new Cyber Security Strategy sets out four objectives:
1) A comprehensive system of security measures, consisting of different levels, will be
implemented in Estonia to ensure cyber security at national level.
2) Estonia will be a country that is characterised by a very high level of information security
competence and awareness.
[18]
eGovernment in Estonia
January 2015
3) Proportionate legal regulations serve to support the secure and extensive use of
information systems.
4) Estonia will be one of the leading countries in international co-operation to enhance
cyber security.
Implementation of the strategy will be coordinated by the Ministry of Economic Affairs and
Communications. All ministries and government agencies will participate in its
implementation, above all the Ministry of Defence, the Information System Authority,
Ministry of Justice, The Police and Border Guard Board, the Government Office, Ministry of
Foreign Affairs, Ministry of the Interior and the Ministry of Education and Research. The
strategy will be implemented in cooperation with non-governmental organisations, business
associations, local governments and educational institutions.
The total cost of implementation of the activities provided in the strategy is approximately
EUR 16 million.
Previous eGovernment Strategies
Estonian Information Society Strategy 2013 (2008-2013)
The ‘Estonian Information Society Strategy 2013’ was approved on 30 November 2006 by
the Estonian Government and entered into force on 1 January 2007. This strategy has been
designed as a sectoral development plan, setting out the general framework, the objectives
and the respective action fields for the broad use of ICT in the development of a
knowledge-based society and economy in Estonia for the period 2008-2013. This latest
strategy takes into account the objectives and priorities of the EU-level policy framework,
namely: the initiative ‘i2010: A European Information society for growth and employment’
and the related ‘i2010 eGovernment Action Plan’.
The strategy is dedicated to an ICT vision for Estonia, based on the beliefs that the country
is a constantly developing, inclusive society, raising the living standard of everyone and
that the wide take-up of ICT will improve citizens’ quality of life as well as actively involve
them in public life. Thus the strategy aims to place more emphasis on: the development of
a citizen-centric and inclusive society, a knowledge-based economy as well as a
transparent and efficient Public Administration.
Actions and measures
For each component of this 'Vision', actions and measures are being taken in three fields
of action, as follows:
Action field I: Development of a citizen-centric and inclusive society
In the information society, most of the information is stored in a universal digital form. To
ensure citizen welfare, citizens must possess the skills and have the willingness to use the
opportunities created by the information society, while benefiting from a multi-access
channel to digital information that suits their needs. In line with the strategy, by 2013,
75 % of Estonian residents should be using the Internet, while household Internet
penetration should amount to 70 %. Moreover, by 2010, all public sector websites complied
with the Web Accessibility Initiative (WAI) criteria. To such an end, the following actions are
foreseen:
 broadening technological access to digital information;
 improving skills and widening possibilities for participation.
Action Field II: Development of a knowledge-based economy
[19]
eGovernment in Estonia
January 2015
The strategy foresees that by 2013, the productivity per employee in Estonian enterprises
will account for 75 % of the EU average and that the share of ICT enterprises in the
national GDP will amount to 15 %. To reach this objective, the following measures will be
taken:
 promoting ICT uptake by enterprises;
 increasing the competitiveness of the Estonian ICT sector.
Action field III: Development of a citizen-centric, transparent and efficient Public
Administration
In line with this objective, the Administration should function efficiently while collecting,
using and managing data necessary for the provision of public goods in a common and
systematic manner. Public sector processes must be transparent and easy to understand.
In addition, public services for citizens and businesses must be fully available electronically,
widely used and structured around users’ needs. By 2013, the strategy sets the objective of
80 % of citizen satisfaction and 95 % of business satisfaction with regard to the use of
public sector eServices. In this light, the following measures will be taken:
 improving the efficiency of the public sector;
 providing user-friendly public eServices
Estonian Cyber Security Strategy 2012
Estonia belongs to the group of highly cyber dependent countries that considers ensuring
cyber security a matter of national security and societal welfare. Estonia has actively
addressed the question of cyber security on a national level since at least 2007, with the
aim of ensuring the security and availability of national institutions and essential services at
all times. The National Cyber Security Strategy developed in 2008 laid out a national action
programme up to 2013.
In 2011, the Estonian Information System’s Authority (RIA) was established as Estonia’s
central cyber security competence and coordination centre with related priorities such as
assembling the necessary competence to ensure security, creating and developing
cooperation networks, developing specific capabilities (e.g. SCADA/ICS security) and
supporting providers of essential services and critical infrastructure administrators in
ensuring cyber security. The responsibility for cyber security policy coordination was
handed over from the Ministry of Defence to the Ministry of Economic Affairs and
Communications in the same year.
On 21 March 2013, the Government approved a proposal according to which the Estonian
cyber security strategy for 2014 -2017 will be drawn up.
Estonian Broadband Strategy 2011
A report was issued in 2011 regarding Estonia's Broadband Strategy, related regulations
and developments. The Estonian Broadband Development Foundation (ELA) is responsible
for the EstWin, a project with the aim of bringing the new generation broadband networks
into every home, business and institution and so eliminating the digital divide between the
Estonian countryside and the biggest cities.
The ELA began building the network in rural areas where the private sector was not
investing due to its unprofitability. It is expected that the building of the base network will
ensure that 98 % of homes, businesses and institutions will be within 1.5 km of fibre optic
networks. The ELA does not build connections to end users.
[20]
eGovernment in Estonia
January 2015
Estonian Information Society 2004-2006
In 1998 the Estonian Parliament approved the Estonian principles of the initial ICT policy.
These principles serve as a basis for making public policy decisions to support the rise of
the information society on the basis of an action plan. The Information Policy Action Plan in
its turn is the basis for all government agencies to make specific proposals to the
Government, including that of schedules, sources of finances, and responsibilities for the
implementation of information policy programmes every year. The Action Plan was
approved by the Government in April 1998, May 1999 and February 2001.
According to the Government decision of 14 May 2002 the information policy priorities for
2002/2003 are as follows:
 develop services for citizens, business sector and public administration, especially the
elaboration of ID-card applications, proceeding also from the list of eGovernment
services defined in the eEurope+ Action Plan;
 improve skills and access of social groups in unequal position for using electronically
provided services;
 elaborate and introduce of systems for digital document management and archival
processing;
 develop of the system and infrastructure of state registers, including the development
of systems that ensure the maintenance of databases and the introduction of the data
exchange layer (project “X-road”) of information systems;
 provide schools with computers to achieve the ultimate goal - one computer per 20
students;
 launch of Tiger University program to support the development of information and
communication technology (ICT) infrastructure and academic ICT staff, and the
infrastructure for post-graduate training.
Further details are available through the related document on the principles of the Estonian
Information Policy 2004 - 2006.
Implementation Plan (2009-2011)
eGovernment in Estonia is part of the broader Information Society Policy under the
responsibility of the Ministry of Economic Affairs and Communications. Therefore
eGovernment strategy is embodied in strategic documents related/focused on information
society and IT. The most relevant recent document is the Implementation Plan for 20092011 of the Estonian Information Society Strategy 2013, giving an overview of the
activities on the Information Technology and Telecommunications front. The main areas of
focus of the implementation plan include to:
 develop the ICT’s export abilities, including international relations, sales and marketing;
 educate labour force on the ICT sector, by popularising the IT field, the quality of
professional education, etc.;
 promote intra-association cooperation;
 facilitate of cooperation with other professional associations on the uses of information
and communication technology;
 cultivate electronic communications;
 increase ICT companies' social responsibility.
[21]
eGovernment in Estonia
January 2015
The Plan seeks to ensure that the development of Estonia is understood, reckoned with and
appreciated as an information society based on the category of information. Thus it aims at
securing the existence of initiatives fostering the development of the information society in
the election platforms of Estonian political parties and boosting ICT management capacities
in the governing system of Estonia. In this view, the Estonian Association of Information
Technology and Telecommunications foresees the creation of a work group focusing on
developing the area of information society, participate in defining the parties’ expectations
on this field, setting the goals and priorities of the activity plan and launching a
development process of the ICT sector’s development programme.
Information Security Policy (2009-2011)
In November 2009, Estonia launched a nationwide Information Security Policy that specifies
and coordinates the upcoming eSecurity-related initiatives. The policy notably aims to
create a secure ‘eEnvironment’ for business and consumers.
The main goal of the Estonian Information Security Policy is to found a secure, securityaware, internationally cooperating and enabling Estonian information society. Specific goals
include the elimination of non-acceptable risks, the defence of basic human rights,
information security awareness and training, participation in international eSecurity-related
initiatives, as well as competitiveness of economy.
Secure eGovernment must be based on appropriate legislation, standards and
procedures, such as security requirements for databases, services, and State
procurement. Regulations in this field are coordinated by the Ministry of Economic Affairs
and Communications, together with the Ministry of Internal Affairs.
Information society Strategy for Local Governments (2008-2011)
In 2008, the Ministry of Internal Affairs elaborated a development plan called 'Information
society strategy for local governments 2008-2011'.
The main aims of the Strategy in question are the following:
 introduce electronic public administration to all local governments;
 develop Internet-based tools for citizens' involvement in the organisation of local life;
 ensure that all local government officials are aware of ICT possibilities;
 develop the preconditions for the use of eServices in all local governments;
 establish organisations for the coordination of information society development in
counties.
Programme for increasing awareness of the information society
(2007- 2013)
The aim of the programme funded by the Structural Funds of the European Union is to
widen the uptake of existing eSolutions; promote the development of new eServices; and
ensure, by raising awareness of information security, the sustainable development of the
information society.
The target groups of the programme include consumers of both existing and future
eServices; parties related to the development of eServices; and entrepreneurs, whose
increased awareness of the information society will increase their motivation to apply IT
[22]
eGovernment in Estonia
January 2015
solutions. In addition, the programme contains activities aimed at increasing the awareness
of opinion leaders and representatives of media, contributing thus to increased interest and
positive attitudes towards new eSolutions.
The programme’s implementation plan for 2007-2008 focused on three action lines:
 inform the general public of electronic functions of the ID card (i.e. electronic
authentication and digital signing);
 introduce the possibilities of the state information system;
 increase awareness about information security.
As part of this programme, a number of campaigns were held to increase the use of the
electronic functions of the ID card; to increase public awareness about threats related to
the use of computers and possibilities to protect oneself against these and to increase
awareness about information security both within the public sector and among the general
public of Estonia
Principles of the Estonian Information Policy (2004-2006)
This strategy set three year long-term objectives for the Estonian information policy:
 introduce eServices to all state agencies together with respective training and
awareness-raising activities for the whole society;
 keep the level of ICT use in Estonia at no less than the average level of the EU, ensuring
thus the efficiency of the Estonian economy and society in general;
 increase the export capacity of the IT sector.
The strategic document underlines that for the short-term, concerning the years 20042006, Estonia would proceed with the following goals:






develop eServices for citizens, entrepreneurs and public sector institutions;
promote eDemocracy, eLearning and eInclusion;
increase the efficiency in the public sector;
facilitate the interaction between the ICT industry and eBusiness;
establish IT security;
cultivate a strong position at the international arena.
Principles of the Estonian Information Policy (1998-2003)
‘Principles of the Estonian Information Policy’ was the first strategic document to present
ICT principles serving as a basis for an action plan for establishing an information society.
The action plan, in turn, is the basis for all Government agencies to present specific
proposals to the Cabinet, on an annual basis, together with schedules, sources of finances
and responsibilities for the implementation of information policy programmes. The
Government foresees the development of an information policy that will:
 promote and ensures democracy in the Republic of Estonia;
 support the development of an information infrastructure;
 create of a competitive economy, especially through demonopolisation, speeding up the
restitution of property, the development of electronic commerce and electronic banking;
 sustain the development of Estonian culture and language, considering also values
deriving from cultural diversity;
 modernise and improve State defence as a result of developments in information
technology.
[23]
eGovernment in Estonia
January 2015
eGovernment Legal Framework
Main legal texts
eGovernment
impacting
on
the
development
of
eGovernment Legislation
Current status
There is currently
legislation in Estonia.
no
overall
eGovernment
Freedom of Information Legislation
Public Information Act (2001)
The first version of the Public Information Act (PIA) took effect in January 2001. A newly
revised, updated Public Information Act entered into force on 1 January 2015, which has
started the transposition of the provisions of the revised Directive (2013/37/EU) into
national law. The Act covers State and Local Agencies, legal entities in public law and
private entities that are conducting public duties including educational, health care, social
or other public services. Any person may make a request for information, which is
registered; the holder of information must respond within five working days. Fees may be
waived, if the information is requested for research purposes. Departments and other
holders of public information have the duty to maintain websites and post an extensive list
of information on the Web. These entities are also required to ensure that the information is
not 'outdated, inaccurate or misleading'. In addition, email requests must be treated as
official requests for information. The Act is enforced by the Data Protection Inspectorate.
Since 1 January 2008, the Act has also been regulating the field of the former Databases
Act (in force from 1997 to 2007).
Digital Signatures Act (2000)
Approved on 8 March 2000, the Digital Signatures Act (DSA) entered into force on 15
December 2000. A newly revised, updated Digital Signatures Act entered info force on 1
July 2014. The Act gives the digital and handwritten signatures equal legal value and sets
an obligation for all public institutions to accept digitally signed documents and a chapter
regulating state supervision and administrative supervision over certification service
providers and time-stamping service providers was included. See a more detailed overview
at Public Key Infrastructure.
Archives Act (1998)
The Archives Act entered into force on 1 May 1998. The Act sets the principles for
collecting, evaluating, archiving, preserving, accessing archival documents and for archiving
activities. It furthermore sets the guidelines for private records entered in the archives'
register and the transfer of ownership of private records also entered in the archives'
register.
Data Protection/Privacy Legislation
System of Security Measures for Information Systems (2008)
[24]
eGovernment in Estonia
January 2015
This Regulation entered into force on 1 January 2008 and establishes the system of security
measures for information systems used for processing the data contained in state and local
government databases and for information assets related therewith. The system consists of
the procedure for the specification of security measures and the description of
organisational, physical and IT security measures to protect data. However, it is underlined
that this Regulation does not apply to security of information systems processing state
secrets.
Consumer Protection Act (2004)
This Act entered into force on 15 April 2004 and it regulates the offering and sale, or
marketing in any other manner, of goods and services to consumers by traders.
Furthermore, it determines the rights of consumers as the purchasers or users of goods or
services, and provides for the organisation and supervision of consumer protection and
liability for violations of this Act. Some minor amendments were included and entered into
force on 1 January 2015 (proceedings and punishments for legal persons).
Personal Data Protection Act (1996)
The Personal Data Protection Act (PDPA) entered into force on 19 July 1996. The Act was
amended in 2003, to be made fully compliant with the EU Data Protection Directive
95/46/EC, and once again amended in January 2008. The Act protects the fundamental
rights and freedoms of persons with respect to the processing of their personal data, in
accordance with the right of individuals to obtain freely any information that is
disseminated for public use.
The 2008 version of the Act introduced several changes. Firstly, the previous classification
of personal data into three groups (non-sensitive personal data, private personal data and
sensitive personal data) has been replaced by two data categories: (1) 'personal data' and
(2) 'sensitive personal data', the latter being the sub-class under special protection.
Secondly, all processed personal data are protected and registered by Chief processors (i.e.
controllers) with the Data Protection Inspectorate, the data protection supervision
authority. Moreover, the new PDPA Act extends all general principles applying to the
processing of personal data and to the processing of the personal identification code
(the unique number assigned to every Estonian citizen and resident). From 1 January 2015
the Data Protection Inspectorate may submit reports concerning significant matters which
have an extensive effect or need prompt settlement which become known in the course of
supervision over compliance with the Act to the Constitutional Committee of the Riigikogu
and the Legal Chancellor.
System of Security Measures for Information Systems (2008)
This Regulation entered into force on 1 January 2008 and establishes the system of security
measures for information systems used for processing the data contained in state and local
government databases and for information assets related therewith. The system consists of
the procedure for the specification of security measures and the description of
organisational, physical and IT security measures to protect data. However, it is underlined
that this Regulation does not apply to security of information systems processing state
secrets.
eSignatures Legislation
Digital Signatures Act (2000)
Approved on 8 March 2000, the Digital Signatures Act (DSA) entered into force on 15
December 2000. The Act provides for the use of digital signatures and digital ink, and the
conditions of certification and oversight procedures for time-stamping services. It, basically,
grants similar legal value to digital and handwritten signatures while setting an obligation
for all public institutions to accept digitally signed documents. The Act introduces the use of
[25]
eGovernment in Estonia
January 2015
digital stamps, namely, the technical and organisational means to set up data collection
system, which uses digital ink-holder of the certificate to prove the integrity of the digital
document and a document of their relationship. The Act was amended on 31 December
2007, and its last amendment took place on 31 December 2010.
eCommerce Legislation
Information Society Services Act (2004)
The information society services act was passed on 14 April 2004 and entered into force on
1 May 2004. It implements EU Directive 2000/31/EC on certain legal aspects of information
society services, in particular electronic commerce, in the Internal Market. It establishes
the requirements pertaining to information society service providers, as well as the
organisation of supervision and liability in the case of violation of these requirements. The
Act was lastly amended on 21 January 2010.
eCommunications Legislation
National Broadcasting Act (2007)
The National Broadcasting Act entered into force on 1 June 2007, providing the legal status,
objective, functions, financing, and organisation of management and activities of the
Estonian National Broadcasting. The objective of National Broadcasting is to assist in the
performance of the functions of the Estonian state provided by the Constitution of the
Republic of Estonia.
Electronic Communications Act (2004)
The Electronic Communications Act was passed on 8 December 2004 and entered into force
on 1 January 2005 in order to implement the EU Regulatory Framework for Electronic
Communications.
The purpose of this Act is to create the necessary conditions to promote the development of
electronic communications networks and communications services while ensuring the
protection of the interests of users of such services. The Act provides requirements for:
publicly available electronic communications networks and communications services; radiocommunication; management of radio frequencies and numbering; apparatus and State
supervision over the compliance with the requirements. The Act was lastly amended on 16
January 2011 and entered into force on 1 January 2015. It is already known that there will
be new amendments which will enter into force 1 January 2016.
eProcurement Legislation
Public Procurement Act (2007)
A new Public Procurement Act came into force in May 2007, thus transposing the EU
Directives on public procurement (2004/17/EC and 2004/18/EC). It includes legal
provisions enabling the further development of eProcurement (eAuctions, Dynamic
Purchasing System, eCatalogues etc.) so as to give better opportunities for taking forward
a fully electronic Procurement tendering process.
It is worth mentioning that the previous version of the Public Procurement Act (October
2000) had already established rules for the eNotification of public tenders through the
country’s Public Procurement State Register.
[26]
eGovernment in Estonia
January 2015
In order to implement EU directives 2014/24/EC, 2014/25/EC and 2014/23/EC the
legislative process is currently under way and the new Public Procurement Act should come
into force 1 April 2016.
Re-use of Public Sector Information (PSI)
Public Information Act (2001)
The Public Information Act covers the provisions of the EU Directive 2003/98/EC on the reuse of public sector information (PSI). Estonia thus notified full transposition of the PSIdirective in July 2009.
Transposition of the EU Directive 2013/37/EU into Estonian legislation is currently under
way.
[27]
eGovernment in Estonia
January 2015
eGovernment Actors
Main roles and responsibilities
National eGovernment
Policy/Strategy
Ministry of Economic Affairs and Communications
The Ministry of Economic Affairs and Communications holds political responsibility for the
development of the State information policy. It elaborates the state's economic policy and
economic development plans, while also drafts the respective legislation bills, in a variety of
fields, among which, informatics, development of state information systems, research, and
development and innovation.
Department of State Information Systems (RISO)
The Department of State Information Systems (RISO) of the Ministry of Economic Affairs
and Communications plays a major role in the elaboration of the Estonian information
society Policy. It embarks on developing information society-related activities in the field of
information technology and on the preparation of draft legislation in the relevant fields.
RIO's strategic tasks include the coordination of state IT-policy actions and development
plans in the field of state administrative information systems (IS), such as state IT budgets,
IT legislation, coordination of IT projects, IT audits, standardisation, IT procurement
procedures and international cooperation in the field of state IS.
Estonian Association of Information Technology and Telecommunications (ITL)
The ITL is a non-profit organisation, aiming to unite the Estonian information technology
and telecommunications companies; to promote their co-operation in Estonia's
development towards information society; to represent and protect the interests of its
member companies and to express their common positions.
The main activities of the association include the popularisation of information and
communication technology (ICT), promotion of vocational education and amendment of
legislation.
e-Estonia Council
The e-Estonia Council created in 2014 (formerly Estonian Informatics Council) is a
government committee that directs the development of digital society and e-governance in
Estonia.
Five experts and ICT sector representatives and three ministers are members of the
Council. It is chaired by Prime Minister. Other government institutions and experts are
involved in the work upon need.
Coordination
Department of State Information Systems (RISO)
The Department of State Information Systems (RISO), as part of the Ministry of Economic
Affairs and Communications, is the main actor in coordinating governmental ICT policy and
information society policy. In more detail, RISO coordinates: the state information policy
and the consequent development of sustainable energy development projects in the
initiation and implementation of information society; the development of national
[28]
eGovernment in Estonia
January 2015
information systems regarding international cooperation within its jurisdiction and the
initiated national information systems related to IT standardisation.
Department of Information Society Services (ITAO)
ITAO, also a department of the Ministry of Economic Affairs and Communications, coordinates the development of public sector services. It elaborates and disseminates
different guidelines and manuals regarding common quality criteria for public services, lifecycle approach to public service development, choice of service channels etc.
Estonian Information System's Authority (EISA)
Since 1 June 2011, the Estonian Informatics Centre has been re-organised to the Estonian
Information System's Authority (EISA). The Authority's mission is to "coordinate the
development and management information system so that Esthonian citizens are served in
the best possible way." It coordinates all Public Key Infrastructures related to the operation
of ICT and Information Technology, like the State portal www.eesti.ee, the middleware
system X-Road, the Government backbone network EEBone, the administration system of
the State information system (RIHA) and the electronic document exchange centre (DVK).
It is also liable to coordinate the state information system development projects and the
preparation and participation in international projects. Finally, EISA also monitors the
legislation process concerning the management information system requirements.
Estonian Association of Information Technology and Telecommunications (ITL)
The ITL is a non-profit organisation whose primary objectives are to: coordinate the cooperation of the Estonian information technology and telecommunications companies,
educational institutions and promote their co-operation towards the development of
information society in Estonia. Main activities of the association include the popularisation
of ICT and the amendment of legislation. The central coordination provided by ITL, deals
with strategic planning, setting priorities, ensuring financing and creating cooperation
networks while ensuring their functionality.
e-Estonia Council
The e-Estonia Council created in 2014 (formerly Estonian Informatics Council) is a
government committee that directs the development of digital society and e-governance in
Estonia.
Five experts and ICT sector representatives and three ministers are members of the
Council. It is chaired by Prime Minister. Other government institutions and experts are
involved in the work upon need.
Implementation
Department of State Information Systems (RISO)
The Department of State Information Systems, part of the Ministry of Economic Affairs and
Communications, is responsible for the development and the implementation of State IT
strategies at central level.
Estonian Information System's Authority (EISA)
EISA implements Estonia’s national eGovernment strategy, through the State portal
www.eesti.ee, the EEBone network, the State information system (RIHA) and the electronic
document exchange centre.
Government Departments and Agencies
Government Departments and Agencies are responsible for the implementation of the
departmental eGovernment projects falling within their respective fields of competence.
Since Estonia is a highly decentralised country when it comes to the information society
[29]
eGovernment in Estonia
January 2015
organisation, they play a very important role in the implementation of action plans and
projects.
Support
Estonian Informatics Council
Besides its role in coordination and policy formulation, the Estonian Informatics Council is
an expert committee advising the Government on ICT matters in a horizontal manner.
CERT Estonia
The Computer Emergency Response Team of Estonia (CERT Estonia), established in 2006,
is an organisation responsible for the management of security incidents in '.ee' computer
networks. Its duty is to assist Estonian Internet users in the implementation of preventive
measures in order to reduce possible damage from security incidents and to help them in
responding to potential security threats. CERT Estonia deals with security incidents that
occur in Estonian networks or incidents that have been notified of by citizens, or institutions
either in Estonia or abroad.
Estonian Information Technology Foundation (EITF)
EITF is a non-profit organisation aiming to assist in the preparation of the highly qualified
IT specialists and to support information and communication technology-related
developments in Estonia. For these purposes, the Foundation has established and manages
the Estonian IT College and administers ’Tiger University’, the National Support Programme
for ICT in Higher Education.
eGovernance Academy
The eGovernance Academy is a non-governmental, non-profit organisation, which aims to
promote the use of ICT in the work of Government and in democratic practices. Its mission
is to train and advise leaders and stakeholders in using information and communication
technology (ICT) to increase government efficiency and to improve democratic processes
with the aim of building open information societies. The Academy is a regional learning
centre set up by the Republic of Estonia, the United Nations Development Programme
(UNDP) and the Information Programme of the Open Society Institute.
Audit/Assurance
National Audit Office
The role of the National Audit Office (Riigikontroll) is to promote reforms while supporting
public bodies in their efforts to create, through their activities and services, best value for
the taxpayers. In this context, the National Audit Office assesses the performance
(economy, efficiency and effectiveness) and regularity of the activities of Public
Administration, and furthermore provides recommendations to assist the Parliament and
the Government in improving the operation of the State.
Data Protection
Personal Data Protection Inspectorate (DPI)
The Personal Data Protection Inspectorate is an independent agency placed under the
authority of the Ministry of Justice. The DPI supervises the legality of the processing of
personal data and databases, as well as the organisation of data protection activities. To
accomplish that, it acts as: a commissioner (ombudsman) and preliminary court; an auditor
and a licensor; an educator and consultant; a designer of legal practices; a political
consultant and an enforcer and a punisher.
AS Sertifitseerimiskeskus
[30]
eGovernment in Estonia
January 2015
AS Sertifitseerimiskeskus (SK) is the Certification Authority (CA) providing certificates for
the Estonian electronic ID card and related services pertaining to the use of these
certificates while giving legally-binding digital signatures. The authority's mission is to
ensure the reliability and integrity of the electronic infrastructure underpinning the Estonian
'eID card' project, and to offer reliable certification and time-stamping services. It also
functions as a competence centre for the eID card and spreads the knowledge necessary
for creating electronic applications for the card. To this end, AS Sertifitseerimiskeskus has
created 'DigiDoc', a universal system for giving, processing and verifying digital signatures.
'DigiDoc' can be connected to any existing or new software, but its components are also a
stand-alone client programme and web portal.
Regional & Local eGovernment
Policy/Strategy
Estonian Ministry of the Interior
The Estonian Ministry of the Interior has prepared a ‘Municipalities Information Society
Programme’ for the period 2008-2011 and an Action Plan for the years 2008-2011.
Other
Association of Estonian Cities
The Association of Estonian Cities is a voluntary union established for representing the
common interests and arranging co-operation among cities and rural municipalities. The
Association’s main goal is to ensure the development of Local Governments through joint
activities. The Association is also in charge of the Local Government Portal (KOP) created
2003, providing information, news and any development related to local government.
Association of Municipalities of Estonia
This Association gathers the majority of Estonian rural municipalities within the 15 Estonian
counties, communicating between them through a dedicated Intranet system, bringing
together local government units, and contributing to the development and strengthening of
self-government administration and decentralisation of power under the principles of
democracy.
[31]
eGovernment in Estonia
January 2015
eGovernment Who’s Who
Main eGovernment decision-makers and executives
Minister responsible for eGovernment
Urve Palo
Minister for Economic Affairs and Communications
Contact details:
Ministry for Economic Affairs and Communications
Harju 11
15072 Tallinn
Tel.: +372 62 56 304
Fax: +372 63 13 660
E-mail: info@mkm.ee
Source: http://mkm.ee
Government CIO
Taavi Kotka
Deputy Secretary
Information System
General
for
Communications
and
State
Contact details:
Ministry of Economic Affairs and Communications
Address: 11 Harju St, 15072 Tallinn, Estonia
Tel.: +372 63 97 680
Fax: +372 63 13 660
E-mail: taavi.kotka@mkm.ee
Source: http://mkm.ee
Head of eGovernment
Aet Rahe
Head of State Information Systems Department (RISO)
Contact details:
Harju 11, 15072 Tallinn, Estonia
Tel.: +372 63 97 640
Fax: N/A
E-mail: Aet.Rahe@riso.ee
Source: http://riso.ee/en/department-state-information-systems
[32]
eGovernment in Estonia
January 2015
National ICT Policy Advisor
Siim Sikkut
Head of State Information
Government Office of Estonia
Systems
Department
(RISO),
Contact details:
Stenbocki maja, Rahukohtu 3, 15161 Tallinn
Tel.: +372 69 35 626
Fax: N/A
E-mail: siim.sikkut@riigikantselei.ee
Source: http://valitsus.ee/et/
Information Society Services
Janek Rõzov
Director, Department of Information Society Services
Contact details:
Ministry of Economic Affairs and Communications
Address: 11 Harju St, 15072 Tallinn, Estonia
Tel.: +372 62 56 364
Fax: +372 63 13 660
E-mail: janek.rozov@mkm.ee
Source: http://mkm.ee/2581/
Head of Information Society Division
Karin Rits
Head of Information Society Division Information Systems
Department (RISO)
Contact details:
Ministry for Economic Affairs and Communications
Harju 11, 15072 Tallinn, Estonia
Tel.: +372 63 97 640
Fax: +372 63 13 660
E-mail: Karin.Rits@riso.ee
Source: http://www.riso.ee/en
[33]
eGovernment in Estonia
January 2015
National ICT Coordinator
Ave Lauringson
State Information Systems Department (RISO)
Contact details:
Harju 11, 15072 Tallinn, Estonia
Tel.: +372 63 96 40
Fax: N/A
E-mail:Ave.Lauringson@riso.ee
Source: http://riso.ee/en/
e-Government executive
Taimar Peterkop
Director General of the Estonian Information System's Authority
(EISA)
Contact details:
Estonian Information System's Authority (EISA)
Pärnu mnt 139a
15169 Tallinn
Tel.: +372 66 30 200
Fax: +372 66 30 201
E-mail: taimar.peterkop@ria.ee
Source: http://www.ria.ee/
[34]
eGovernment in Estonia
January 2015
eGovernment Infrastructure
Main eGovernment infrastructure components
Portals
'eesti.ee': eGovernment portal
Estonia’s eGovernment portal was first launched in March 2003 on the basis of the 'eCitizen'
project which was initiated in 2002. Since then, the portal has been constantly renewed. In
the last quarter of 2007, a new version of the portal merged the former ‘State Information
portal’ and the ‘Citizen portal’, creating a single integrated service. This portal coordinates
the information provided and the services offered by various State institutions. It features a
safe Internet environment for communication with the State and offers reliable information
and eSolutions for citizens, entrepreneurs and officials respectively. The access to relevant
information and eServices on the portal indeed depends on whether the user is a citizen,
entrepreneur or State official.
The State portal’s environment allows users authenticated with their national eID card to:
access and check their personal details; perform transactions with municipal and
Government bodies; complete and convey online forms and applications; sign documents
digitally; create email addresses with the suffix @eesti.ee; and receive email or SMS
notifications. In addition, it gives access to other registry services (e.g. the Forest Registry)
on more than 20 national databases. Based on the data held in the State Commercial
Register, entrepreneurs using the portal can access transactional services for businesses.
'DigiDoc' portal
'DigiDoc' portal is available for Estonian ID-card and Estonian and Lithuanian Mobile-ID
users and allows for digital signing, verification of validity of digital signatures, forwarding
of documents to other users of the portal and receiving documents from other users of the
portal. The DigiDocService provides a quick and easy way to raise the security of any web
service to meet the highest demands. It makes it possible to carry out authentication based
on strong authentication devices from different vendors and provides service providers with
the opportunity to enter legal signatures on any created data within their service, which
provides long-term validity and proof of action in courts across the EU.
Rural Municipality Portal
The portal was launched in February 2011 by the Estonian Government, with the view to
increase the transparency of local governments and expand citizen participation. The
concept of the portal is innovative as it is based on an open source content management
tool, which allows for easy and uniform site administration. The developed solution includes
a standard website structure for local governments, tools for site administration and built-in
interfacing with public registers.
Network
ASOnet's 'EEBone'
'EEBone' (PeaTee) is the broadband network of data communication among Government
institutions. It is a Government-wide backbone network, connecting more than 20 000
computers from all Government offices across the country, providing secure access to the
Internet and the Government's Intranet. The network was launched in October 1998, and
[35]
eGovernment in Estonia
January 2015
its development was based on the backbone network 'ASONet' elaborated by the Border
Guard Administration, the Customs Board and the Police Board in 1993. The network
currently provides approximately 50 % of all administrative services to the various
associations.
The Estonian Information System's Authority (EISA) is highly involved in running the
network, either as a mediator of customised value-added data services, or as a provider of
customer service. The use of the backbone network is financed centrally from the State
budget and is free-of-charge for subscribed clients. Clients only have to pay to access the
backbone network and to determine the access connection service themselves.
X-Road Middleware
Launched in December 2001, the 'X-Road' (X-Tee) is a middle-tier data exchange layer
enabling Government databases to communicate with each other. It was initially developed
as an environment facilitating the formulation of queries to different databases in a
standardised way. The system allows officials, as well as legal and natural entities to search
data from national databases over the Internet within the limits of their authority, using a
unified user interface.
In addition, the system has been further developed to enable the creation of eServices
capable of simultaneously using data held in different databases. Several extensions have
thus been developed for the 'X-Road' system. These include: writing operations to
databases, transmitting huge data sets between information systems, performing
successive search operations of data in different data sheets, providing services via web
portals.
The 'X-Road', as one of the cornerstones of the Estonian State Information system, offers
the following services: authentication; authorisation; MISP (mini-portal system); register of
simple queries; queries to various databases and registers; opportunities to write registers;
sending large amounts of data over the Internet; secure data interchange, recording logs
and search tracking option; running of citizen portal and operator's portal; central and local
monitoring and collection service description in a special database (WSDL mode).
eIdentification/eAuthentication
Electronic ID card
Estonia started issuing national ID cards in January 2002. The card, which fulfils the
requirements of Estonia’s Digital Signatures Act, is mandatory for all Estonian citizens and
residing foreigners over 15 years of age; applications can be made online. It is meant to be
the primary document for identifying citizens and residents and is used in any form of
business – governmental or private communications. It is furthermore a valid travel
document within the EU. Since 1 January 2007, the card issued by the Citizenship and
Migration Board, has become valid for 5 years (instead of 10 years in the past). The IDcard can be used to vote electronically (since 2005), create a business, verify banking
transactions, be used as a virtual ticket, and view medical history (since 2010). As of
January 2012, more than 1.1 million people in Estonia (almost 90 % of inhabitants) have
ID cards.
In addition to being a physical identification document, the card has advanced electronic
functions facilitating secure authentication and providing a legally binding digital signature
for public and private online services. An electronic processor chip contains a personal data
file, a certificate for authentication (along with a permanent email address
Name.Surname@eesti.ee for eCommunications with the public sector), a certificate for
digital signature, and their associated private keys, protected with PIN codes. The
certificates contain only the holder's name and personal code (national ID code). The data
[36]
eGovernment in Estonia
January 2015
file is valid as long as the identity card is, and so are the certificates, which thus have to be
renewed every five years.
Mobile-ID
'Mobile-ID' is the ID-card based identity verification and digital signature solution for users
of mobile phones in Estonia. This means that the mobile phone, based on a standardised
SIM application, will act as a secure signing device. Thus, similarly to the eID card, the
mobile-ID enables authentication and digital signing of documents, bearing the same
legal value. The user’s certificates are maintained on the telecom operator’s SIM card; to
use them, the user has to enter a PIN code.
The new mobile-ID service (wireless PKI) was launched in May 2007 by the mobile operator
EMT, in co-operation with several banks and the Certification Centre, AS
Sertifitseerimiskeskus. This service allows accessing Internet banking services without
entering eBanking codes. To authenticate oneself securely with the mobile-ID, the user will
click on a dedicated button in the web environment. Upon completion of this action, s/he
will be requested to enter his/her authentication PIN number. Once this operation has been
completed, authentication is performed. The same process applies to the signing of digital
documents. In addition, mobile phones can be used to pay for car parking (m-parking) by
phoning a certain number or sending an SMS. To inform the parking controller that the
payment is being effected by phone, an m-parking sticker is stuck on the windshield or the
right-side window of the vehicle. The m-ticket service allows the user to purchase a ticket
on public transport without cash. It is also possible to buy theatre tickets and pay at the
grocery store using a mobile phone.
The main advantages of the mobile-ID include user-friendliness and convenience; the
computer no longer needs to be equipped with a card reader, or have a special additional
software installed.
ePassport
To comply with EU regulation 2252/2004/EC on standards for security features and
biometrics in passports and travel documents issued by Member States, the systems of the
Estonian Citizenship and Migration Board (CMB) have undergone considerable changes that
have been implemented step-by-step. The first biometric passports were delivered as of
22 May 2007, containing the holder's biometrical data. Changes in the organisation of work
and supporting systems of the CMB are planned to occur at both customer service and
document issuance systems’ levels.
eProcurement
eProcurement Estonia
The Estonian eProcurement environment enables Contracting Authorities to carry out a
procurement procedure from start to end in the same web environment - prepare and
publish notices, upload tender documents, receive eTenders, award contracts and carry out
dynamic purchasing systems and eAuctions. Authorities are also able to communicate with
interested persons and tenderers and carry out inquiries into other state registers, for
example to check payment of taxes or registration in the Commercial Register. The
environment is divided into the Information Portal and the Public Procurement Register.
Instructions and guides are available in the portal while procurements are published in the
Public Procurement Register.
Public Procurement State Register
Established in 2001 and maintained by the Public Procurement Office, the Public
Procurement State Register is a register where all public procurement notices are published
[37]
eGovernment in Estonia
January 2015
electronically. The register uses CPV standards in the catalogue, and all the information in
the register is publicly accessible over the Internet, free-of-charge.
Knowledge Management
Document Exchange Centre (DVK)
The document exchange centre is an information system providing a common central
document exchange service for various enterprise content management (ECM) systems, as
well as other information systems dealing with documents. The Centre is responsible for
interfacing dispersed information systems (via the X-Road Middleware); preserving
documents in the short-term; processing documents in the near future; and support
services in the proceeding of documents.
The DVK is an infrastructure for the transmission of documents (i.e. a mediation layer for
document exchange services of information systems) relying on the X-Road as a transportlevel infrastructure. These can be letters, draft legislation, financial documents (including
eInvoices and payment orders), electronic forms and documents related to public
procurement procedures).
'eKool' web application
'eKool' is a simple web application that connects all education stakeholders in an easy way
over the Internet, helping them to collaborate and organise their teaching/learning related
information. 'eKool' is available as either a direct web service for end users, or as a hosted
white label service for distributing/promoting partners.
Other Infrastructure
Administration System of the State information system (RIHA)
The objective of RIHA is to ensure the interoperability of public sector information
systems and the re-use of technical, organisational and semantic resources, so as to give a
clear view of the State registers and the services provided by them. The creation and
maintenance of Government databases is governed by the Public Information Act of 2007
which establishes an Administration System for State information systems (RIHA), where
all the databases and information systems must be registered.
RIHA includes metadata about existing public sector databases – ranging from the
information on the administrators of the databases to the eServices offered and the
technical data concerning the environment/platform. Registration in RIHA is web-based;
the user is authenticated and permissions are given by using the national electronic ID
card.
In the same web-based environment, requests to other information systems can be made
in order to launch a new X-road-based service. RIHA additionally administers two
supporting systems of State registers: the system of classificators and the address data
system. The system of integrated registers allows applying new principles of administrative
arrangements: citizen-orientation, flexibility, swiftness, as well as cost and time
effectiveness for both the citizens and the State.
[38]
eGovernment in Estonia
January 2015
eGovernment Services for Citizens
Availability and sophistication of eServices for Citizens
The information in this section presents an overview of the 20 basic public services, which
were identified by the European Commission and Member States, in the eEurope initiative
of 2000, to measure the take-up by businesses and citizens of electronically-available
public services.
The 12 services for citizens are as follows:
1.
Income taxes: declaration, notification of assessment
2.
Job search services by labour offices
3.
Social security benefits
4.
Personal documents: passport and driver’s licence
5.
Car registration (new, used, imported cars)
6.
Application for building permission
7.
Declaration to the police (e.g. in case of theft)
8.
Public libraries (availability of catalogues, search tools)
9.
Certificates (birth and marriage): request and delivery
10. Enrolment in higher education/university
11. Announcement of moving (change of address)
12. Health related services (interactive advice on the availability of services in different
hospitals; appointments for hospitals)
1. Income taxes: declaration, notification of assessment
Responsibility:
Central Government, Tax and Customs Board
Website:
http://www.emta.ee/?lang=en
Description:
The eTaxBoard (eMaksuamet) enables taxpayers to file, view and correct
their income tax returns online and to check their tax account balances.
Citizens can use their electronic ID card as the identification method for
accessing eTaxBoard. Those having submitted their tax returns online can
benefit from accelerated tax refunds.
2. Job search services by labour offices
Responsibility:
Central Government, Unemployment Insurance Fund
Website:
http://www.tootukassa.ee/?lang=en
Description:
The website provides an updated list of all job offers at national and
regional labour offices in Estonia, with a short description of each job,
deadlines for application and contacts for applying.
[39]
eGovernment in Estonia
January 2015
3. Social security benefits
a. Unemployment benefits
Responsibility:
Central Government, Estonian Unemployment Insurance Fund
Website:
http://www.tootukassa.ee/?lang=en
Description:
Information and forms to download.
b. Child allowances
Responsibility:
Central Government, Social Insurance Board
Website:
http://www.eesti.ee/eng/teemad/perekond/riigi_rahaline_abi_lastega_pere
dele/pere_ja_lastetoetused/
Description:
Pursuant to the Parental Benefit Act, the online Parental Benefit service was
launched at the beginning of 2004. The service is 100 % electronic:
persons without Internet access can go to the Social Insurance Board to
submit their application, but even there the application is filed electronically
with the assistance of Insurance Board employees. The whole process is
paperless. Based on the X-road middleware system connecting different
State databases, this service does not require citizens to submit data
already known by the State.
c. Medical costs (reimbursement or direct settlement)
Responsibility:
Central Government, Estonian Health Insurance Fund
Website:
http://www.eesti.ee/eng/teemad/health_care/health_insurance/
Description:
The Health Insurance Fund covers the cost of health services required in
case of illness regardless of the amount of social tax paid by each citizen.
Since there is no refund system in Estonia, if the health service provider
has a contract with the Estonian Health Insurance Fund, then all costs are
directly paid to him/her by the Fund. The patient pays only a reduced
personal, non-refundable contribution. If the health service provider does
not have a contract, the patient must pay for the health service
himself/herself. Internet banking clients or holders of the Estonian eID card
can use eServices available through the national portal to check the validity
of their health insurance, their address and the payment of sickness
benefits.
d. Student grants
Responsibility:
Central Government, Ministry of Education and Research, Higher Education
institutions
Website:
http://www.hm.ee/?1
Description:
With the Study Allowances and Study Loans Act (2003), Estonia has
established a system of study allowances and created the possibilities to
obtain study loans. The main objective of the system of study allowances,
only accessible at a certain level of income and for students who
successfully progress in their studies, is to motivate students to study full
time and successfully complete the study programme within the nominal
period. Study loans secured by the State intend to give full-time students
who are not entitled to receive study allowances the possibility to finance
their studies. Applications, attributions and payments of study grants are
managed directly by Higher Education institutions.
[40]
eGovernment in Estonia
January 2015
4. Personal documents: passport and driver’s licence
a. Passport
Responsibility:
Central Government, Police and Border Guard Board
Website:
http://www.politsei.ee/en/teenused/isikut-toendavad-dokumendid/eestikodaniku-pass/
Description:
Information and application forms to download. The website allows for
online application for ID documents. This service requires the use of an
electronic signature.
b. Driver’s licence
Responsibility:
Central Government, Estonian Road Administration Department
Website:
http://www.mnt.ee/index.php?id=12659
Description:
Information only. Applications must be submitted in person at the Estonian
Road Administration Department.
5. Car registration (new, used, imported cars)
Responsibility:
Central Government, Estonian Road Administration Department
Website:
http://www.mnt.ee/index.php?id=10663
Description:
Information and forms to download. Car registration applications must be
submitted in person at the Estonian Road Administration Department
(ARK).
6. Application for building permission
Responsibility:
Local Government
Website:
http://www.eesti.ee/eng/teemad/eluase/eluaseme_soetamine/ehitus_ja_re
mont/
Description:
Information only. Planning permission applications are handled by local
authorities.
7. Declaration to the police (e.g. in case of theft)
Responsibility:
Central Government, Estonian Police
Website:
http://www.politsei.ee/en/
Description:
An online crime reporting service is available on the website of the Estonian
Police.
8. Public libraries (availability of catalogues, search tools)
Responsibility:
Central Government, National Library of Estonia
Website:
http://www.libdex.com/country/estonia/tallinn/library_22677.html
Description:
Online catalogue and reservation facility.
[41]
eGovernment in Estonia
January 2015
9. Certificates (birth, marriage): request and delivery
Responsibility:
Local Government
Website:
http://www.eesti.ee/eng/teemad/perekond/
Description:
Information only. Requests for certificates are handled by the local
authorities.
10. Enrolment in higher education/university
Responsibility:
Central Government, Higher Education institutions
Website:
https://www.sais.ee/index_en.html
Description:
Enrolment in higher education is managed by Higher Education institutions.
An enrolment information system called SAIS (SissAstumise InfoSüsteem)
has been developed to enable the entire enrolment, processing, decisionmaking and information in a single environment on the Internet for
participating universities. The system uses the eID card as an
authentication tool. It can however be entered through one of the Estonian
Internet Banks. Since the results of high school examinations are already in
the online database, students can see immediately if they have been
accepted to a participating university.
11. Announcement of moving (change of address)
Responsibility:
Central Government (Estonian Population Register)/Local Government
Website:
http://w3.andmevara.ee/?lang=en
Description:
On the Estonian Population Register’s website, it is possible for citizens to
make the announcement of moving by sending a digitally signed document.
In that case, a person is automatically identified. Consequently, there is no
need for any other identifying document.
12. Health related services (interactive advice on the availability of services in different
hospitals; appointments for hospitals)
Responsibility:
Ministry of Social Affairs
Website:
http://www.digilugu.ee/portal/page/portal/Digilugu/ETerviseProjektid
Description:
The East Tallinn Central Hospital became the first in Estonia to introduce an
ePatient portal in April 2008. Patients can access the portal from the
hospital’s website. Through the portal, patients can view their medical
records, book doctors’ appointments and pay consultation fees. It is also
possible to order an appointment reminder via SMS or email. The project
consists of four sub-projects: Electronic Health Record (EHR); Digital
Imaging; Digital Prescription; and Digital Registration.
[42]
eGovernment in Estonia
January 2015
eGovernment Services for Businesses
Availability and sophistication of eServices for Businesses
The information in this section presents an overview of the 20 basic public services, which
were identified by the European Commission and Member States, in the eEurope initiative
of 2000, to measure the take-up by businesses and citizens of electronically-available
public services.
The 8 services for businesses are as follows:
1.
Social contributions for employees
2.
Corporate tax: declaration, notification
3.
VAT: declaration, notification
4.
Registration of a new company
5.
Submission of data to statistical offices
6.
Customs declarations
7.
Environment-related permits (incl. reporting)
8.
Public procurement
1. Social contributions for employees
Responsibility:
Central Government, Tax and Customs Board
Website:
http://www.emta.ee/
Description:
Estonian employers are required by law to pay ‘social tax’ for all persons
employed. The tax rate is 33 % of the taxable salary. 20 % is allocated to
pension insurance and 13 % to health insurance. The social tax can be
calculated, filed and paid online using the eTaxBoard (eMaksuamet).
2. Corporate tax: declaration, notification
Responsibility:
Central Government, Tax and Customs Board
Website:
http://www.emta.ee/
Description:
The eTaxBoard (eMaksuamet) enables corporate taxpayers to file, view and
correct their corporate tax returns online, and view their tax account
balances.
3. VAT: declaration, notification
Responsibility:
Central Government, Tax and Customs Board
Website:
http://www.emta.ee/
Description:
The eTaxBoard (eMaksuamet) enables corporate taxpayers to view their
VAT returns, submit VAT refund applications and view their tax account
balances.
[43]
eGovernment in Estonia
January 2015
4. Registration of a new company
Responsibility:
Central Government, Centre of Registers and Information Systems
Website:
https://ariregister.rik.ee/
Description:
The Centre of Registers and Information Systems is a State Agency
working under the Ministry of Justice. Its main function is the
administration of a number of central databases and registers, e.g. the
Estonian enterprises register. Since February 2007, entrepreneurs have
been enabled to submit data to the Commercial Register through the new
Company registration portal. They can submit registry documents
processed within the next working day, at the earliest. Persons are
identified and procedures are performed using the Estonian eID card and
digital signature. Information only. Company registration services are
handled by local courts.
5. Submission of data to statistical offices
Responsibility:
Central Government, Statistical Office of Estonia
Website:
https://estat.stat.ee/
Description:
Data can be submitted electronically to the Statistical Office. The eSTAT is
a web-based channel which has been available since February 2006 for
filing official statistical reports. It offers an operational overview of the
reports filed through different channels in the Statistical Office, as well as
contacts with the providers of these reports.
6. Customs declarations
Responsibility:
Central Government, Tax and Customs Board
Website:
http://www.emta.ee/
Description:
The Estonian Tax and Customs Board developed an eCustoms application
(eToll) that enables online filing of customs declarations. A web-based
system called COMPLEX was launched in May 2006 for processing customs
declarations. This system can be used from every computer with Internet
access. The Tax and Customs Board updates and maintains the system on
a day-to-day basis: users do not have to do it themselves; that allows
greater savings for enterprises. Customs declarations can also be drawn up
and submitted in XML-format. To use COMPLEX, a client can enter the
eTaxBoard, via the Tax and Customs Board's web-page, or an Internet
bank.
7. Environment-related permits (incl. reporting)
Responsibility:
Central Government, Ministry of the Environment, Estonian Environment
Information Centre
Website:
http://klis.envir.ee/
Description:
Fully transactional service.
[44]
eGovernment in Estonia
January 2015
8. Public procurement
Responsibility:
Central Government, Public Procurement Office
Website:
https://riigihanked.riik.ee/
Description:
Established in 2001, the Public Procurement State Register is an 'eTenders'
portal where all public procurement notices are published electronically.
[45]
eGovernment in Estonia
January 2015
European Commission
The factsheets present an overview of the state and progress of eGovernment in European
countries.
Jounup is a joint initiative by the Directorate General for Informatics (DIGIT) and the Directorate
General for Communications Networks, Content & Technology (DG CONNECT).
Contributor: Karin Rits, Head of Information Society Unit, Estonia
Production/Publishing: ISA Editorial Team, Kurt Salmon S.A.
[46]
An action supported by ISA
This action is supported by ISA, the European
Commission’s programme for interoperability solutions
for European public administrations.
Why ISA?
Administrative procedures have the reputation of being
lengthy, time-consuming and costly.
Electronic collaboration between public administrations
can make these procedures quicker, simpler and cheaper
for all parties concerned, in particular when transactions
need to be carried out cross-border and/or cross-sector.
ISA supports this type of electronic collaboration.
With more than 40 actions it provides tools, services
and frameworks for the modernisation of public
administrations in Europe, across e-borders and sectors.
More on the programme:
http://ec.europa.eu/isa/
Contact ISA:
isa@ec.europa.eu
E-identity as a business
Case studies and lessons learned in networked identity
Peter Valkenburg, Wouter Meijers (Everett)
Douwe Lycklama, Vincent Jansen (Innopay)
Sponsored by
1
Table of Contents
1
Management summary .................................................................................................... 3
2
Understanding networked e-identity .............................................................................. 4
3
4
2.1
Why e-identity? ...................................................................................................... 4
2.2
What is the problem? ............................................................................................. 5
2.3
How is e-identity provided? ................................................................................... 5
Introducing e-identity solutions ..................................................................................... 7
3.1
A world of two-party networks .............................................................................. 7
3.2
Towards an open model: three-corner networks ................................................... 8
3.3
The generic e-identity model explained further ..................................................... 9
3.4
Key characteristics of an e-identity service .......................................................... 10
Case studies ................................................................................................................. 11
4.1
OpenID ................................................................................................................ 12
4.2
CardSpace ............................................................................................................ 18
4.3
Google Apps ........................................................................................................ 23
4.4
DigiD ................................................................................................................... 27
4.5
Estonian e-ID card ............................................................................................... 30
4.6
BankID ................................................................................................................. 33
4.7
SURFfederatie ....................................................................................................... 35
5
Conclusions .................................................................................................................. 39
6
About Innopay .............................................................................................................. 42
7
About Everett ................................................................................................................ 43
© Everett, Innopay (2010)
Reviewed by Kick Willemse (Evidos)
2
1 Management summary
After many trials, pilots, successes and failures the identity market is still finding its shape
and size. Its crucial role in the development of e-business is not disputed and more and
more the subject is coming out of the „technology geek scene‟. Business people become
interested, since networked e-identity, which we define as “identity across organisational
boundaries”, can be regarded as „the mother of all transactions‟. In the generic end-to-end
trade process, identity is at the heart of each step: contract, order, shipment, invoice,
payment and tax settlement. Service providers in all forms and shapes see opportunities,
also „in the cloud‟, enabling previously unheard scalability.
The upshot of this is that e-identity should develop out of the positioning of a pure „cost‟,
„control‟ and „compliance‟ subject into a growth-enabling topic. E-identity develops from an
enterprise identity to networked identity, were it becomes a two-sided market with two
distinct user groups: end users and service providers (aka „relying parties‟) who can grow
revenues en lower costs by offering better e-services to their clients.
This paper aims to discuss some of today‟s main e-identity business propositions, including
their business models. The main observations are:
a. Success is for providers and solutions who clearly serve the distinct needs of end-users,
and service providers. If one of them is underserved, the solution will not scale well.
b. Governments are still a major driver for e-identity, but long term success comes when
the private sector is included, simply because users then have more need for usage.
c. Different solution approaches exists, all with their own right of existence. Mass adoption
and success will only come when interoperability is secured, enabling more rapid
growth.
The document starts with an explanation of the business of e-identity (chapter 2) and a
generic framework with which networked e-identity solutions can be analysed (chapter 3).
Based on various cases in the public and private sector including cloud services (chapter 4),
the most critical issues are addressed for those having to take business decisions in the
field of e-identity (chapter 5).
3
2 Understanding networked e-identity
2.1
Why e-identity?
Business transactions involve people. Irrespective of whether the activity is about a
contract, order, shipment, invoice, payment or tax settlement, it involves individuals who
initiate, perform tasks and sign them off. Most business activities are nowadays supported
in some sense by IT, and increasingly transactions are available as end-to-end services over
the Internet separating time and distance. Figure 1 shows the generic description of the
end-to-end trade process.
Figure 1: Trust in each step of the end-to-end trade process
For these electronic transactions trust is required on an increasingly large scale. This trust
makes it possible to order, pay, deliver and provide reliable communications and
trustworthy information. Trust in the digital world hinges on electronic identity (e-identity),
where two interacting parties achieve enhanced trust through e-identity.
In generic terms: the end user is able to prove (relevant parts of) his identity to the „service
provider‟ and the service provider is able to demonstrate he is the authentic source of its
services. In the natural world, a person has an identity which can be defined according to a
series of attributes, or specific properties such as sex, age, hair and eye colour, profession,
location etc. A person‟s online e-identity is an often-similar set of attributes that are kept in
IT systems and can be related to a person‟s natural, physical identity.
4
Identity information of end users is kept in many places in today‟s world and is often made
available to various organisations and individuals
through the Internet, providing the trust to do e.g. online
Organisational digital identity versus
banking. This kind of networked e-identity is a crucial
enabler for large-scale transactions, both in the public
and private sectors. Increasingly, e-identity is being
offered as a service and in that respect it can be said to
be the „mother of all transactions‟.
networked e-Identity
The digital identity of a person has, up to a
few years ago, mostly been restricted to the
use for services within a single organisation.
Nowadays, an employee or client of an
organisation often has an electronic identity
within each organisation the person is involved
2.2
in. The need to use a single identity for
What is the problem?
seamless and cost effective access to
increasing amounts of services on the Internet
The problem is on two sides:
has led to the growing use of cross-
1. End user: the scattering of identity information of
individuals over numerous organisations does lead to
privacy issues and user burden to remember and
organisational electronic identities, which in
this paper is addressed as 'networked eidentity', often abbreviated to just 'eidentity'. The major difference between an
intra-organisational identity and networked e-
maintain identities.
2. Service provider: for organisations the scattering of
identities does not add to the required trust. Every
organisation provides its own identity mechanism
online, varying from passwords to advanced
certificate infrastructure, leading to cost and
management burden.
identity lies in the fact that the latter needs to
be provided by a network of organisations
that must be aligned to create the business
and trust needed. The various parties involved
make setting up networked e-identity a
different endeavour than the nowadays wellunderstood and often straightforward
hierarchical setup of intra-organisational
digital identity.
E-identity is a (so far) under-recognised two-sided
market, where two distinct users groups (end users and
providers) interact with each other. There is a business opportunity for parties in the
facilitation of these two users groups. Dealing with the aforementioned two basic problems
will prove essential.
Networked e-identity is identity, which is re-usable over multiple organisations, thereby
reducing the two-sided problem.
2.3
How is e-identity provided?
With more and more services being offered online, ranging from e-commerce to egovernment and banking, service providers need to know whom they are dealing with and
consumers must be assured they deal with an authentic partner and that access to their
personal information is assured. But how do you know whom you
are dealing with?
When dealing with people in the offline world, identity is easier to
asses because of the physical interaction between these individuals.
A person‟s face coupled with a picture ID is usually sufficient. A
signature, matched to that on the ID, can add security. In addition, assessments of a
person‟s trustworthiness can be made based on appearance or intuition.
5
A specific example to illustrate this is age verification. In many countries there is a legal age
limit for purchasing alcohol. Here the attribute „age‟ is verified. In this situation, age
verification can be based on a visual assessment of the person‟s age. A general assessment
that the person is over the legal age limit may be sufficient and the person‟s exacted date of
birth may not be required. Alternatively, age can be determined on the basis of an identity
document bearing a date of birth and a picture such as a passport or a driver‟s license. The
identity document is a tangible document with certain standard characteristics that prove its
authenticity. The picture on the document is compared to the visual appearance of the
person offering the document to match the two. In both cases there is an immediate visual
assessment by one individual of the other individual.
This relatively simple situation is complicated when it is carried out online. In an online
transaction, the two parties, the end user and the service provider, are separated by time
and space, rendering visual means of authentication
unusable.
In the past two decades many technologies have been
developed to make identities usable in the digital
domain. Think of e.g. user names/ passwords, tokens,
certificates and biometrics, all tools for making e-identity happen. Many initiatives are
available now with all distinct characteristics. In the next chapter e-identity will be
introduced and a generic framework will be presented.
6
3 Introducing e-identity solutions
In this chapter we discuss e-identity solutions in a systematic way to allow the next chapter
to discuss different examples in a structured manner. First we introduce the evolution of eidentity solutions from a closed model to an open service provider model. From this
introduction we derive a description of a generic model for e-identity solutions.
3.1
A world of two-party networks
As an example to demonstrate the evolution of e-identity, let us consider Amazon.com.
Amazon.com was founded in 1994 as an online bookstore. It later diversified its product
range and grew into a leading global online retailer.
At Amazon.com, like at many other web shops, end users create an account with a
username and password. The account contains payment and shipping details (identity
attributes) and can be used to give product reviews. Amazon.com only accepts orders from
account holders that are properly authenticated, e.g.
through a successful credit-card payment.
In this solution there are only two parties involved: the
end user and Amazon.com. We call this a two-party
solution (or closed model). Amazon.com has all the
information and provides all functionality necessary to authenticate the end user.
Identity solutions have started as purely technical solutions, where the end user has a
relation with the service provider. The service provider stores the (relevant) identity
(attributes) of the end user and gives out authentication means to end-users. Only two
parties are involved.
Having (many) two party solutions is far from ideal for three main reasons:
1. End users have to create accounts for each service provider they visit ending up with a
great amount of identities (often usernames and passwords).
2. End users have to maintain their profiles (identities) at every service provider they visit.
Apart from the burden of having to maintain this information, a potential privacy risk is
introduced by having personal data scattered over all service providers.
3. Service providers have to implement and maintain their own identity solution. This is a
cost and time-consuming operation that keeps service providers away from their core
business.
In two party solutions the identity solution is often positioned as a cost to the service
provider.
7
3.2
Towards an open model: three-corner networks
The solution to the described drawbacks of the two-party solutions is actually quite simple:
introduce a third corner. Often this is referred to as „three party model‟, but the same party
can fill in the two corners. An identity provider (the third corner) can focus on implementing
and maintaining an identity solution that it offers to both the end user and the service
providers. This results in less credentials to remember and profiles to maintain for end
users and focus on core business for service providers while increasing profile accuracy. The
figure below shows a generic model for e-identity:
Figure 2: A generic three-corner model for e-Identity
It should be noted the needs of the two distinct user groups (end user and provider) are
catered for by only one provider. Therefore the service provider has two propositions: one
for the end user and one for the service provider.
Three party models come in two ways:
1. Government sponsored. Government gives out authentication means, mainly for use
with their own services
2. Service providers re-use. Service providers with large customer bases (e.g. Amazon.com,
PayPal, Google, Face book) re-use their credentials over each other‟s services. A specific
scheme has been created, which is called OpenID.
The business model of three corner models is still unclear. Either they do not have a
business model (e.g. OpenID or government issued ID cards) or they provide authentication
as part of a payment service (e.g. Amazon, Google and PayPal).
Three corner models overcome some of the drawbacks of two party models, because it
increases the re-usability of the credentials for the end user and reduces the integration
efforts for the service providers. The main problem however is that there is a multitude of
8
three corner models. Every initiative strives for „world domination‟ and becoming the „de
facto‟ solution. As a result, service providers do not reside all with the same three-corner
identity provider and therefore the end user is left with the management of multiple
identities.
This can only be overcome when all service providers and all end users concentrate at a few
identity providers. For competition and privacy reasons this could not be a preferable
situation.
3.3
The generic e-identity model explained further
In the previous paragraphs we saw a closed model evolve into a more open model. Within
this model we clearly can distinguish four core roles:
1. End users
End users request identity services from the e-identity provider. With such a service the
end user can transact on-line real-time. End users can be individuals acting on their
own behalf or on behalf of organisation.
2. Service providers
A service provider can be a private or public party who offers on-line services. Think of
e.g. tax filing, permit request, bookshop, airline ticket and banking. When using these
services the end user has to identify himself during the process. Also certain relevant
attributes might be checked, such as e.g. age or gender.
3. e-identity provider and broker
These two roles are often combined in one corner or party.
An e-identity provider role is the proposition towards the end user, whose identity
elements are managed by the e-identity provider. Therefore there must be a trust
relationship of some form. The level of trust is depending on the purpose. The identity
provider also facilitates the actual checking of the identity by service providers through
their e-identity broker. This is always triggered by the use of credentials issued to the
end user. Credential can be e.g. passwords, tokens, phones and certificates. One of the
core processes of the e-identity provider is the registration or issuing of identities. The
trust level towards the service providers is often determined by the registration process
(e.g. physical appearance is regarded as more reliable) in combination with the security
level of the tokens.
The e-identity broker role is the proposition to the service provider. Through the eidentity broker one or more e-identity providers can become part of the service towards
the service provider.
In order to assure that the interaction between the four roles (end user, service providers, eIdentity Providers) proceeds smoothly, securely and according to a prearranged set of
policies and regulations, one or more scheme owner organisations can be established.
Typically in a three corner set up, the party offering the central platform can be regarded as
the scheme entity.
9
In situations where the two proposition roles (e-identity provider and broker) can be offered
by different parties (four corner model), the scheme entity lays down the ground rules upon
which the various transactions take place. Also compliance with these rules is governed by
the scheme organisation. Scheme owners typically consist of a number of cooperating
parties that have a common interest in the creation and exploitation of a particular identity
management scheme.
3.4
Key characteristics of an e-identity service
With the generic e-identity model in mind, we will discuss in the following chapters various
e-identity initiatives. The analysis will be done according to certain characteristics. These
characteristics are chosen for the purpose of this white paper. Many more characteristics
exist, but they are not considered relevant for this paper.
Any e-identity service has two distinct aspects:
1. First is the registration phase where individuals register and are issued the e-identity by
the identity provider. The registration procedure, the process by which the e-identity is
issued and the integrity of the e-identity provider are fundamental for the integrity of
the e-identity service as a whole. If the registration phase is susceptible to fraud, the
integrity of the entire service is compromised.
2. Following registration is usage phase where the claimed identity of an individual is
authenticated, authorised, etc. Important aspects in this phase are the process by which
information regarding the identity is transacted between parties, the purpose of this
transaction process and who has control over the credentials.
Additionally, the working of the business model as well as issues regarding privacy and
trust are important elements in the authentication phase.
Different e-identity services can be described according to a number of key characteristics.
These include:

Registration – The registration process describes the procedure of initial registration and
the issuing of the e-identity.

Transaction – The authentication transaction process and the model of the service are
described.

Business model – The fees and revenues are described.

Privacy and trust – Any issues relating to privacy and trust such as the exchange of
attributes and the integrity of parties in the network.
In the next chapter a selection of current e-identity initiatives are discussed, along the lines
of the four characteristics.
10
4 Case studies
This chapter will present a number of case studies of e-identity services and standards in
use today. We have selected a wide range of services from e-commerce to online banking
and e-government and from different countries. We can learn a great deal from the way
these services are set up and how they operate.
The first two cases, OpenID and CardSpace, are technology driven but vendor-neutral
approaches1and have been selected because of their potential impact on the e-identity
marketplace. The remainder of the cases are business oriented and have been chosen to
depict how commercial, governmental or educational organisations have implemented
various technologies to solve specific business issues. Some of these solutions (e.g. Google
Apps, SURFfederatie) utilize open standards such as OpenID; some are based on proprietary
technology (e.g. DigiD).
1 We can argue whether CardSpace is in fact vendor-neutral, given the dominant role of Microsoft in the
development of the standard. However, Microsoft has stated to be committed turning the associated InfoCard
standard into a true open standard and has released all specifications and actively cooperates with third-parties to
make the standard a success.
11
4.1
OpenID
The power of OpenID is based on the explicit lack of a pre-existing relationship between the
service provider and the identity provider (in this particular case called the OpenID Provider).
Instead, the scheme relies on the user providing a claim of ownership of a URL to the service
provider. The service provider verifies this claim by establishing a shared secret in
cooperation with the server hosting the claimed URL (identity provider). The user must be
able to represent this shared secret when obtaining access to a resource owned by the
service provider. Because the scheme is entirely based on self-issued claims, OpenID is only
suitable for low-risk transactions. In practice, the scheme is mainly used to provide access
to social networking sites2.
Figure 3: the OpenID authentication scheme
4.1.1
Registration
A user can simply create an OpenID account by registering a URL on a server that can act as
an OpenID provider. This can be any one of the public OpenID servers but it can also be a
server owned and operated by the user. Example of an OpenID:
http://usermike.myopenid.com
Currently, many of the popular social networking sites have implemented the OpenID
protocol, allowing people with an account on one of these sites to login to any site
supporting OpenID. A non-comprehensive list of participating sites is: Google, Yahoo,
LiveJournal, Facebook, Hyves, Blogger, Flickr, Orange, MySpace, WordPress.com and AOL.
Apart from these, the user can also register a free account with any of the public OpenID
Providers such as Chi.mp, ClaimID, myID.net, myOpenID, VeriSign or yiid.
The following screenshots show a number of popular sites that offer OpenID as an
authentication method:
2
However, this situation might change in the future as more and more providers are adding extensions in-and-
around OpenID. One example is Google, who combined OpenID with the OAuth authorisation protocol (see chapter
4.3). Another example is the Japanese telecom giant NTT Docomo (over 55 million subscribers), who facilitate an
interface that providers can use to obtain additional identity information in the context of an OpenID authentication
and which can be used (among other things) to perform on-line payments.
12
Figure 4: MapQuest provides either an AOL or an OpenID login box
13
Figure 5: Plaxo provides a number of external authentication mechanisms, including OpenID
14
Figure 6: SourceForge offers an extensive range of external authentication methods, including OpenID
4.1.2
Transaction
OpenID entirely depends on existing and well-established Internet protocols and standards
such as HTTP and XML. The figure below depicts what happens when a user attempts to
access a site that supports the OpenID protocol:
Figure 7: The OpenID authentication sequence
The user enters his/her OpenID URL in the “OpenID login” box at the service provider (step
1). The service provider uses a discovery protocol (such as Yadis3) to find the location of the
Identity provider, based on the contents of the provided URL (step 2). The protocol might
3
The Yadis protocol (located at http://yadis.org) is closely related to OpenID, but can also be used by other
authentication schemes. Yadis translates the user-specified URL (the Yadis-ID) into an eXtensible Resource
Descriptor (XRD) document that provides a list of service identifiers applicable to this user-specified URL.
15
use a separate discovery service, depending on the format of the OpenID URL provided by
the user. Once discovered, the service provider and identity provider establish a “shared
secret” (step 3).
The discovery service can be considered the “e-identity broker” from our generic model. The
discovery service selects an identity provider based on the structure and content of the URL
provided by the user and thus allows the service provider to utilise a potentially large
number of different identity providers.
The user is now redirected to the identity provider (step 4) and is requested to authenticate
using any method supported by this provider. The authentication mechanism can be
anything from simple username/password to certificates, tokens or Info Cards (see: chapter
4.2, CardSpace). The identity provider asks the user whether he/she trusts the service
provider to receive the user‟s credentials and identity details (step 5). This is an important
step since it provides the user with a mechanism to control which information is disclosed
to the service provider.
If the user is satisfied with the requested information, he/she is redirected back to the
service provider, which verifies the received user credentials against the “shared secret”
established earlier. If all is satisfactory, the user is granted access to the requested
information.
Note that the exact set of credentials that can be exchanged varies between service
providers. When registering ones OpenID, the identity provider typically facilitates the
creation of user profiles and negotiates with a service provider regarding the attributes to
be returned as part of the credential request. In a typical case, the user is shown the list of
attributes that the relying party requests and the user can accept or refuse any of these
attributes before being redirected back to the service provider.
4.1.3
Business Model
The roots of OpenID are in the social networking domain where users expressed a desire to
obtain access to Blogs, Wiki‟s and other social networking sites without the need to register
and authenticate separately for each and every site. Instead, OpenID provides one, easy to
remember, URL-based user identity and associated profile that can be used to obtain access
to a large number of different sites.
Since users can run their own OpenID provider, they have maximum control over the identity
attributes that are used for authentication. Even when using a public provider (such as
MyOpenID), the user still has to maintain only a single shared profile that can be used to
obtain access to a large number of different sites. This central profile provides a good
incentive to users to keep the information up-to-date, which in turn is a benefit to the
service providers, which are more likely to receive accurate information.
The second advantage for the service providers is the delegation of user registration
information and authentication to the identity provider. Instead of having separate
registration forms, local authentication schemes and associated data stores, user properties
are maintained at the identity providers and are obtained during authentication by a usercontrolled process. Note that there exists no explicit trust relationship between service
16
providers and identity providers. This facilitates a federated authentication network that can
scale almost infinitely.
On the downside, this lack of trust relationship combined with the use of self-issued claims
means that services provided by service providers to the users are limited to relatively lowrisk service types, such as the aforementioned access to Blogs or other social networking
sites.
4.1.4
Privacy & Trust
The OpenID scheme is based on self-issued claims. Users maintain their own OpenID profile
(either at one of the many public OpenID identity providers, or at a provider managed and
operated by the user). During authentication, users can manage the properties that are
passed from the identity provider to the service provider. While this scheme provides a high
level of privacy protection from the user‟s point of view, the lack of explicit trust
relationships between the service provider and the identity providers, combined with the
fact that the service provider has no control over the strength and quality of the
authentication scheme implemented by the identity provider, also implies that the service
providers cannot depend on the quality and accuracy of the received user credentials.
The OpenID protocol relies heavily on redirection, in which the user is sent from service
provider to identity provider and back. This particular behaviour makes the OpenID protocol
vulnerable to “phishing” attacks (e.g. the introduction of rogue providers that insert
themselves into the authentication chain, thereby facilitating digital identity theft).
17
4.2
CardSpace
CardSpace, (otherwise known as “Info Cards”) is an identity management scheme originally
devised by Microsoft as a means to provide more control to the end user compared to the
more traditional schemes. CardSpace basically routes all traffic through the end user‟s
device and thereby provides maximum control of the identifying properties that are
exchanged between service provider and identity provider (in this particular case called the
Security Token Provider).
Figure 8: the CardSpace identity management scheme
Apart from being integrated in Windows Vista and Windows 7, CardSpace is currently
supported by a number of Identity Management software suppliers. Examples are the Bandit
project, IBM, FuGen solutions, the Higgins project, Ping Identity, the Shibboleth project,
Siemens, Sun, Oracle, VeriSign, WSO2 and the XMLDAP project. Since CardSpace is build
upon a set of open standards4, any application that supports these standards can integrate
with CardSpace. Microsoft actively promotes the standard and works together with the
open-source community to ensure that coexisting and interoperable implementations are
created.
4.2.1
Registration
The end user maintains a “wallet” of Info Cards that is maintained on the user‟s device
(desktop PC, laptop or mobile device). This wallet can be compared directly with a physical
wallet, containing any number of credit cards, debit cards or identity cards. Info Cards
basically come in two flavours:
1) Personal Cards, or “self-issued” cards, are created by the user and can contain any
information that the user desires to disclose about him/her. Since these are self-issued
claims, they have value only for low-security scenarios such as providing user-profile
information to web sites or an OpenID transaction (see chapter 4.1).
4
In particular, CardSpace uses the Web Services protocol stack, which consists of a number of open standards (WS-
Security, WS-Trust, WS-MetadataExchange and WS-SecurityPolicy).
18
2) Managed Cards are created and maintained by an external identity provider and have to
be verified by a third-party. These can be considered “digital credit cards” or “digital
identity cards”. Managed Cards can be used as a secure authentication or electronicsignature mechanism.
4.2.2
Transaction
The Info Card “wallet” is otherwise known as a “card selector” and plays an important role in
any CardSpace authentication transaction. The figure below depicts such a transaction:
Figure 9: The CardSpace authentication sequence
The CardSpace authentication sequence starts when the user attempts to access a protected
resource at the service provider‟s web site (step 1). In order to allow access, the service
provider requests a number of claims from the end user. The relying party informs the card
selector of these claims (step 2).
Based on the requested claims, the card selector determines which Info Cards, present in
the wallet, are suitable to fulfil these claims and presents a list of these cards to the user.
The user subsequently picks a card to be used in the transaction (step 3).
The selected card determines which identity provider must be consulted to validate the
claims present on the card. The card selector requests an encrypted and signed message
containing these validated claims. This message is called a “security token”. The token,
holding the claims, is returned to the service provider for verification and subsequently
allows the user access to the requested resource.
CardSpace does not recognize a separate “e-identity broker”, since all traffic is routed
through the user device. One could thus state that the user himself acts as a broker, since it
is the user who selects the appropriate identity provider by selecting a specific card.
Microsoft has attempted to act as “the mother of all brokers” in the Microsoft Passport
project (now „renamed‟ Windows Live ID). However, this initiative has failed completely since
the market did not want to trust Microsoft in such an important role. Microsoft has learned
19
from this experience and designed CardSpace around the user instead of attempting yet
another broker function.
The card selector is available in Windows as an integrated feature (see figure below). The
open-source community provides some card selectors for the Firefox browser, Apple OS/X
and Linux.
Figure 10: Windows CardSpace card selector.
Figure 11: Card selector for Firefox
20
Figure 12: And a card selector for Apple OS/X
4.2.3
The seven laws of Identity
Business Model
Following the failure of Microsoft Passport as an
The CardSpace scheme places the user in the
infrastructure for Internet-wide authentication and
driver seat. Instead of requiring the user to
keep track of multiple authentication profiles at
identity management, Kim Cameron, a security architect
working for Microsoft, has devised a set of rules
various sites (each with possibly conflicting
applicable to an Internet-wide identity ecosystem.
requirements), the user can select the most
Following is a summary of these rules, which are
otherwise known as “the seven laws of identity”:
suitable Info Card for each authentication
1 User control and consent: the user must be able to self-
request. Although the need to remember
manage the use of his or her identity information.
usernames and passwords does not go away,
2 Minimal disclosure for a constrained use: the user does
the entire authentication process becomes
more transparent from the user‟s point of view.
Even better, the user has the option to mix and
match the best fit for each authentication
not have to provide any more information than required
for successful execution of the service requested by that
user.
3 Justifiable parties: identity information must only be
request, thereby remaining in full control at all
provided to relevant and trusted parties.
times.
4 Directed identity: an identity system must support
identities for large-scale, general use as well as specific,
Even though the user might be requested to
directed use.
authenticate when contacting an identity
5 Pluralism of operators and technologies: the identity
provider, the number of different
system can be implemented and supported by different
authentication mechanisms to manage is now
directly related to the set of Info Cards that the
user holds and is no longer a function of the
parties.
6 Human integration: the presentation and use of identity
related information must be unambiguous and user-
service providers that the user attempts to
friendly.
access. This scheme can be compared directly
7 Consistent experience across contexts: the identity
with the use of “physical” Credit Cards or Bank
system must provide a consistent user experience,
independent of technologies and services.
Cards: even though each card requires a
separate PIN code, the user relies on a limited
number of cards to conduct transactions at a large number of different facilities.
The CardSpace scheme facilitates loose coupling between users, service providers and
identity providers by means of the broker function of the card selector. Service providers
simply have to issue a set of required claims and do not depend on a particular mechanism
21
in order to fulfil these claims. The card selector, in combination with the identity providers,
perform the role of translating claims into security tokens and provide an open standards
based, secure token verification facility which is independent of any particular combination
of service provider and identity provider. Authentication is effectively “externalized” from
the service providers.
CardSpace seems to be designed with the user strongly in mind. It is unclear how the service
provider fits in: does he have an attractive enough proposition? Does he have to contract
with Info Card provider, similar to credit cards or banks? That aspect gives Info Card limited
network scalability since the service provider is never sure he can address every end user
who uses CardSpace. As of this moment, there are no major Card Space implementations
present on the Internet. Even Microsoft does
The STORK project
not offer it as an option on their community
sites. Although some implementations were
The aim of the STORK project is to establish a European
attempted back in 2007 (e.g. the German
eID Interoperability Platform that will allow citizens to do
transactions and communication across borders, by
retailing giant OTTO used to have a CardSpace
presenting national eIDs.
implementation), most of these initiatives are
Cross-border user authentication for such e-relations
no longer active today.
4.2.4
takes place in the project by means of five pilot projects
using existing government services in EU Member States.
Privacy & Trust
In time however, additional service providers should
The advantage of the CardSpace model is that it
almost perfectly fulfils all of the seven laws of
become connected to the platform thereby increasing the
number of cross-border services available to European
users.
Identity (see frame “The seven laws of Identity”
Thus in the future, a citizen should be able to start a
on the previous page). By putting the user in
company, get a tax refund, or obtain university papers
the middle of the transaction, he/she has
without physical presence. To access these services one
optimal control over privacy and can determine
enters personal data using the national eID, and the
exactly which information to disclose to service
providers.
STORK platform obtains the required guarantee
(authentication) from the respective government.
The role of the STORK platform is to identify a user who is
CardSpace offers two levels of trust:
in a session with a service provider, at a defined (and
cross-national) trust level, and to send the identification
1. Personal Cards provide a low-level of trust
to this service. Whilst the service provider may request
in return for user convenience and can be
various data items, the user should be in control of the
used to provide e.g. profile information in
data to be sent. The explicit consent of the owner of the
data, the user, is always required before data can be sent
low-security contexts, such as the
to the service provider, which fits various EU privacy
provisioning of customisation information
regulation. In this respect STORK can be said to be user
to social networking sites.
centric, since the user acts as the broker of identity data.
2. The concept of Managed Cards provides the
More information: www.eid-stork.eu
required level of trust to conduct business
transactions between service providers, the user and identity providers.
It is striking to notice that to date there are few e-Identity services that actually use
CardSpace although cases in which privacy is considered paramount would seem logical
applications. A case in point here may be the EU STORK project which addresses crossnational eID subject to privacy regulation; see the text box on STORK.
22
4.3
Google Apps
Back in 2006, Google introduced their cloud-computer offering, Google Apps, as an
evolution of the popular Gmail webmail application. Google Apps offers a growing number
of business productivity tools (mail, calendar, documents, groups and more). Google Apps
are “true” cloud applications, meaning that the applications are hosted by Google, including
all associated data and are offered as a set of services, accessible by means of only a web
browser. Users need a subscription from Google and in return receive the rights to use the
services. Thus, Google Apps can be considered a service provider in a two-party network.
Since Google has made the underlying Google Apps engine available to software developers,
the number of available applications that run on the Google Apps framework is growing
rapidly. Starting from March, 2010, Google provides an on-line marketplace of available
applications at http://www.google.com/enterprise/marketplace. At the time of opening this
marketplace, approximately 50 vendors had application offerings available, targeted at the 2
million organisations using Google Apps (with a total of over 25 million users).
What makes the Google solution interesting in the scope of this document is an associated
service, Google Accounts, which utilises the Google account database to act as an identity
provider as well as a service provider. Google Accounts utilises the OpenID protocol (see
chapter 4.1) for this purpose and can thus be considered a “regular” identity provider in an
OpenID network. Furthermore, Google combines OpenID with the OAuth protocol, which
allows a user (with a Google account) to authorise a third-party service provider to use
Google services on behalf of that user. The key feature of OAuth is that this authorisation
process does not disclose any account information to the third-party service provider.
Figure 13: the Google Apps combined authentication and authorisation model
The solution depicted above positions Google as an identity provider, in which case access
to Google Apps (or services provided by third-party service providers) is governed by the
Google Accounts database. Google offers a second solution, based on the SAML open
standard, in which case the roles are reversed: Google acts as the service provider and a
third-party has the identity provider role. Users trying to access a Google Apps application
23
are now authenticated against an external identity store, managed by a third-party identity
provider. In the scope of this paper, we only consider the case in which Google acts as an
identity provider.
4.3.1
Registration
Google differentiates between Google Apps “Standard Edition” and “Premier Edition” (as well
as some special editions for the educational, governmental and non-profit markets).
Standard Edition is free and is targeted towards individuals or home users and offers basic
messaging, collaboration and document processing. The Premier Edition requires an annual
subscription fee and provides access to the full suite of applications, provides large
amounts of storage space and is targeted to commercial users. All Google Apps
subscriptions are acquired on a per Internet domain basis (e.g. “mycompany.com”). Google
facilitates self-service of domain accounts and prevents domains from accessing each
other‟s information.
Any user with a Google account (either Standard or Premier Edition) can utilize Google
Accounts as an OpenID identity provider, e.g. they can authenticate to any web site that
utilizes the OpenID protocol by providing their Google account identifier as an Open ID.
Also, any user with a Google account can request service access from third-party service
providers by means of combined OpenID authentication and OAuth authorization. For the
OAuth authorization to work, the third-party service provider has to be registered at
Google. Registration implies that certificates and shared secrets have been exchanged
beforehand since these are required by the OAuth protocol to establish the necessary trust
between identity provider and third-party service provider.
4.3.2
Transaction
Assuming the user wants to access services provided by a third-party service provider and
these services in turn require Google Apps services then the transaction might look as
depicted below:
Figure 14: The Google authentication + authorisation transaction
24
The authentication sequence starts when the user attempts to access a resource at the
third-party service provider‟s web site that requires additional services from Google Apps
(step 1).
The user selects the OpenID protocol to authenticate, using his Google account. The service
provider redirects the user to Google for authentication (step 2). This process utilises the
standard OpenID protocol as described in chapter 4.1.2. However, as part of the “shared
secret” information exchange (step 3 in the OpenID transaction), the third-party service
provider requests an OAuth “Request Token”. The OAuth protocol uses these tokens to
validate the credentials of the third-party service provider, based on pre-registered
certificates. Assuming that validation proves to be successful, the request token is returned
to the third-party service provider together with the user identity (the result of the OpenID
authentication).
Request tokens do not provide access to resources, they are only used to authenticate the
third-party service provider in the context of the user session and typically have a limited
validity time (e.g. 1 hour). Within this time period, the third-party service provider has to
ask the identity provider to swap the request token for an “Access Token” (step 3). Access
tokens have (at least with Google) an unlimited validity time and can only be revoked
through the Google Apps management interface for the domain that initially requested the
token. Token revocation implies that the third-party service provider has to go through the
complete sequence again (authenticating the user, obtaining a request token and exchange
this token for an access token). This process assures that no tokens are exchanged without
the proper user consent.
Once the third-party service provider has obtained the access token, the token can be used
to request Google Apps services, in which case the token acts as a “valet key”, e.g. it
provides limited access to a specific set of services defined by the contents of the token
(step 4).
4.3.3
Business Model
Today‟s Google business model relies heavily on advertising services. E-identity services are
currently just „a cost of doing business‟. However, in the long term this could change, when
cloud-computing takes off and Google start selling to large amounts of organisations and
end users. Currently, the income from Google‟s cloud computing ventures is minimal
compared to the other sources of income. However, Google expects a massive growth of
revenue in the coming 5 to 10 years, since the potential savings for end users is very high.
By investing heavily in the underlying technologies, pushing standards, giving away the
“Standard Edition” for free and opening the underlying Apps engine to the software
developers community, Google expects to become a major player in the cloud computing
arena within a couple of years.
Since the Google Accounts database is tightly integrated with the Apps engine and contains
tens of millions of accounts, it makes sense for Google to use the contents of this database
for additional purposes besides simple authentication for their own applications. Opening
the accounts database to the Internet as an identity provider places Google in a favourable
position compared to many other identity providers, given the sheer number of accounts (as
25
an example, by mid 2009 there were over 140 million GMail users, all of whom are in the
Google Accounts database).
Each and every transaction that involves Google services (e.g. accessing Google search,
Google Apps, GMail, YouTube, OpenID authentication, etc.) is logged and processed by
Google to produce valuable marketing information, telling Google exactly what their users
do and what their areas of interest are). As of 2006, the Google logging databases, not
counting all applications, contained over 1 Petabytes (1.048.576 GByte) of information. By
opening the accounts database to the Internet for third-party authentication and
authorisation, even more valuable marketing information will be collected.
For the end user, the advantages of using only a single account for accessing cloud
applications as well as logging in to hundreds (or even thousands) of web sites supporting
the OpenID and/or the OAuth protocol are evident.
For third-party service providers, utilizing the massive Google Accounts database offers a
unique authentication resource with a number of available accounts that would be very
difficult, or even impossible, to establish by themselves.
4.3.4
Privacy & Trust
Google utilises the OpenID protocol for authentication. As stated in chapter 4.1, there is a
limitation to the level of trust related to this protocol. Given that the majority of accounts
that are present in the Google Accounts database are free accounts, established by the users
and used to obtain access to free services such as GMail or Apps “Standard Edition”, the
trust level offered by Google is currently limited to low-trust types of services.
The OAuth protocol offers a reasonable level of trust, given that all messages exchanged
between service provider and identity provider are encrypted and signed by pre-registered
certificates and shared secrets. The integration of OAuth with the OpenID protocol creates a
higher level of trust compared to “plain-vanilla” OpenID. Also, OAuth requires service
providers to be pre-registered at the identity provider, which implies that the service
providers know in advance the quality and the strength of the authentication facilities
offered by Google, which is an improvement over the standard OpenID protocol.
Regarding privacy: users perform “self-registration” with Google in order to obtain a Google
account. With the exception of paid accounts (which are still a minority), there is hardly any
guarantee that provided information is correct. Also, given that Google logs all information
that flows through their systems for purpose of analysis (and potential marketing), there is a
high potential for privacy violations. In their privacy statement, Google explicitly states that
it claims the right to combine user information with data collected from other services with
the purpose to improve products and services provided by Google to the end users. The
privacy statement also states that no personal information will ever be disclosed or used,
either within Google or to third parties, without the proper user consent5. However, it is still
5 “Google considers the privacy of its customers important and is serious regarding data protection. Google
adheres to the US Safe Harbor Privacy Principles of Notice, Choice, Onward Transfer, Security, Data Integrity, Access
and Enforcement and is registered with the U.S. Department of Commerce‟s Safe Harbor Program. The processes
and systems related to data security and privacy protection have been successfully audited for SAS 70 Type II
compliance.”
26
difficult (if impossible) for end users to verify that all information flowing through the
Google systems is indeed protected properly against privacy violations, identity misuse or
theft. This is a serious issue for organisations that consider the use of cloud applications,
since they have to trust the service provider to treat the, potentially sensitive, corporate
information properly according to pre-defined service level agreements (in which Google
explicitly denies any responsibility beforehand and explicitly states that the services are not
meant to be used for “high-risk” activities).
The OAuth protocol that is used to grant third-party service providers access to Google
services offers a fair amount of privacy protection, since no account information is ever
disclosed to these third-party providers. Also, OAuth assures that any user-related
information that needs to be exchanged between Google and the third-party provider has to
be approved by the end-user in order for the transaction to succeed.
4.4
DigiD
DigiD is a single sign-on and authentication service launched in 2003 by the Dutch
government that enables legal residents of the Netherlands to use e-government services. It
is mostly used to file income tax statements online with most users using it only 1.2 times a
year on average. From an end user perspective it is not a great success, because the
relevance in a person‟s life is limited. From the identity provider point of view it is more of a
success since at least 8 million people have enrolled for DigiD, because of the obligation to
use DigiD for tax filing. The figure below depicts the scheme:
Figure 15: The DigiD authentication scheme
The DigiD Scheme operator is “Logius”, a Dutch Government Agency that is also responsible
for hosting and exploitation of the DigiD application itself.
27
4.4.1
Registration: leveraging citizenship
Users request a DigiD through the DigiD website. The DigiD is based on the Citizens Service
Number (BSN) that is issued to each legal resident of the Netherlands by the municipality in
which they live and on the Municipal Basic Administration (GBA) to which the BSN refers. The
GBA is regulated by Dutch law, which stipulates how the information can be acquired,
altered and used. An independent body, the Dutch Data Protection Authority (CPB), oversees
the GBA and its compliancy to national and international law.
The picture below depicts the registration procedure:
Figure 16: DigiD Registration
1) A DigiD can be requested from the DigiD website. End-users fill in their BSN, postal
address and email address and can then select a username and temporary password.
The account can be used from here on, but with severely limited functionality (security
level “temporary”).
2) DigiD verifies the provided information against the Municipal Basic Administration (GBA)
and if proved to be correct, creates the account.
3) On correct registration, an activation code is sent to the End-user‟s home address by
mail. This activation code has to be used at the DigiD website to activate the account. At
this time, the user also has to select a permanent password. The account is now ready to
be used for authentication transactions.
A key point is that the DigiD identifier is the Citizens Service Number (BSN). Only legal
residents of the Netherlands are issued a BSN and only government organization are allowed
to use the BSN for authentication purposes. Because DigiD is based on the BSN, any
restriction applying to issuing or the use of BSN applies to DigiD as well.
Only government organizations can be service providers. This means that DigiD cannot be
used for non-governmental e-services such as financial services, e-commerce or social
networks. However, Dutch law is able to designate exemption and it has done so for medical
28
insurance companies providing the mandatory basic health care insurance. Thanks to this
exemption, DigiD can be used to apply for this service online or login at insurance
companies.
4.4.2
Transaction
DigiD can only be used as an authentication facility. These authentication transactions are
stateless, which implies that DigiD does not “remember” whether a specific user has
authenticated earlier within the same browser session. The net-result is that the user will
have to re-authenticate for each and every government site that the user is visiting in the
same session.
Figure 17: DigiD authentication sequence
The DigiD authentication sequence is invoked when the user visits a government web site
and selects the “DigiD login” button (step 1). Selecting “DigiD login” will redirect the user to
the DigiD web site for authentication using username/password (step 2). If required, the
user can select a “stronger” authentication level, in which case a one-time code is sent as an
SMS to the mobile number provided during registration. The user has to enter this number
as part of the authentication transaction.
Assuming that authentication has been successful, the user is now redirected to the
requested web resource at the service provider. In case of unsuccessful authentication, the
user is left at the DigiD site to try again.
The service provider invokes a DigiD service in order to verify the authentication transaction
data that has been received from DigiD and finally grants access (step 3).
Since the DigiD scheme only contains a single identity provider, there is no use for a
separate e-identity broker in this case.
4.4.3
Business model: not-for-profit
DigiD is free for end users as well as service providers to use. As a government service it is a
not-for-profit initiative, which is subsidized by the Dutch Ministry of Internal Affairs.
29
The main purpose of DigiD is to replace the many different username/password
combinations that citizens required to obtain access to government web sites. Since DigiD
only provides a user identifier (authentication only), these web sites still have to maintain
local profiles to store all additional information they require. DigiD thus only solves part of
the problem (authentication) and leaves the issues of maintaining identity assets to the local
government sites.
Also, although penetration of DigiD is high, use of DigiD is limited for most users to a few
occasions per year for government transactions only.
Against this background the Dutch government has started developing a new network called
eRecognition6 that allows private sector employees to access government services based on
an open market for identity services. eRecognition is a based on a 4 corner model, of which
the government supports the scheme, and is expected to also support B2B services.
4.4.4
Privacy and trust
DigiD differentiates between three security levels that are to be used for different types of
services:

The first level requires only a username and password (one factor authentication), and is
suitable for services that require a limited level of security, privacy and trust.

The second level requires the username and password in addition to a One Time
Password (OTP) sent by SMS to the End-user‟s mobile phone (two-factor authentication).
This level is intended to be used for services that require a high level of security, privacy
and trust.

A third level was planned and would involve a physical electronic identity card that is yet
to be introduced and a face-to-face registration process. However, this program has
been put on hold indefinitely.
DigiD provides limited trust, since each authentication session is only based on a
transaction between the DigiD identity provider and a single service provider. Users still
have to authenticate repeatedly when visiting other identity providers, even if these are also
supporting DigiD. A new initiative called “mijnoverheid.nl” (my-government.nl) will improve
on this situation by establishing a federation of cooperating, trusted, parties. In this case, a
user who authenticated (using DigiD) with “any” service provider within this federation is
allowed to travel between all service providers that are member of the federation, without
the need to re-authenticate.
4.5
Estonian e-ID card
The Estonian e-ID card is a national identification card that can also be used for a whole
range of online authentication services including e-government services, online banking,
online financial services and e-commerce. A single ID card can be used for offline as well as
6
See http://www.eoverheidvoorbedrijven.nl/afsprakenstelseleherkenning/english/english.html; a whitepaper on
the eRecognition network approach can be downloaded at http://innopay.com/publications
30
online authentication. Online, the card can also be used for digital signatures while offline
the card can also be used at a ticket in public transportation. The digital version of the
Estonian ID card is provided by Sertifitseerimiskeskus (SK, www.sk.ee) as a certificate issuing
and validation service.
Around 80% of Estonians have an e-ID card and they each use it for online authentication 25
times a year on average. Compared to other Estonian authentication methods, such as those
offered by banks, this figure is relatively low. The power of the Estonian e-ID service is that
it leverages the identity card already mandatory for all legal residents over 15 years old. For
those already owning a card, using it for online authentication is a small step.
Figure 18: E-identity provider SK using the Estonian ID card
4.5.1
Registration: leveraging the ID card
Registration for the Estonian e-ID card has two parts: the issuing of the card and the issuing
of the information needed for online authentication. Most often both parts will be carried
out simultaneously but they can also be carried out independently.
1. Issuing the card. In the first part of registration the physical identity card is issued to the
End user through the Citizenship and Migration Board (CMB) after a request made by the
End user. The card is picked up and activated at a bank branch. The card is a standard
polycarbonate card containing the end user‟s name, date of birth and other information
in addition to a photograph of the end user. Every Estonian citizen and legal resident of
the country over the age of 15 is required to have such an identity card. The card is
linked to the 11-digit Personal Identification Code (PIC) that uniquely identifies each
Estonian legal resident and is provided to the CMB by the Population Register of Estonia.
The card also contains a microchip that can be used for electronic authentication online
as well as at terminals. The creation of the card is outsourced to TRÜB Baltic, a company
that personalizes cards.
31
2. Issuing the digital content. In the second phase of registration, the information on the
chip in addition to other information needed for online authentication is issued. The
information issued is: the digital content of the chip, PIN and PUK codes, and a national
e-mail address. There are three pieces of digital content stored on the chip: basic
personal data equivalent to that printed on the card, a digital certificate for online
authentication, and a digital certificate for digital signatures. Both certificates contain
only the End user‟s name and their PIC, with the certificate for online authentication also
including the End user‟s national e-mail address. The card thus carries little
authentication data and function primarily as a key to access the databases where the
information is stored. Each certificate is protected by a different PIN.
The digital content of the card is added by TRÜB Baltic. TRÜB forwards the end user‟s
personal information to SK in order to create a database entry. Once the content is
loaded onto the card, and the PIN and PUK codes have been generated, everything is
sent to a bank branch for pickup.
Figure 19: The registration of e-identity for SK
4.5.2
Transaction
SK serves as a certificate provider, a validation authority, maintains the technical
infrastructure and develops the necessary services and software. All authentication
transactions carried out by End users are routed through SK and the central directory
containing all authentication data. SK is a private organization owned by banks Swedbank
and SEB and telecommunication companies Elion and EMT.
All service providers connect directly to SK. To facilitate this connection, SK provides
downloadable applications and requires little further technical integration.
32
For end users to use the Estonian e-ID card for online identification, several things are
required:

the physical e-ID card

a PIN code (self chosen)

a username (self-chosen, can vary across services)

a card reader connected to the computer

software installed on the computer.
An end user can initiate a transaction on any website connected to the service.
4.5.3
Business model
For End users, acquiring the physical e-ID card costs approximately EUR 10. Updating or
changing authentication related information such as PIN codes or certificates is free of
charge at the Citizenship and Migration Board while SEB and Swedbank bank branches
charge a small fee of approximately EUR 2-4. Card readers can be purchased at SEB and
Swedbank branches for approximately EUR 6. Aside from these small set-up fees, the
service is free for End users.
Service providers pay a monthly fee for the service. This fee ranges from EUR 25 for 400
transactions per month to EUR 6,000 for 750,000 transactions per month. The price is
therefore between 0.008 and 0.06 EUR per transaction, which is substantially lower than
other electronic transaction services such as online payments. A six-month 8.000
transaction starter‟s package is free of charge.
4.5.4
Privacy and trust
With the exception of the CMB, all parties involved in the issuing of the card and digital
content are private entities. This may raise concerns over security and trust. In Estonia, all
public and private organizations are subject to the Personal Data Protection Act that
regulates the use of personal data and databases containing personal data. Adherence to
the Act is overseen and enforced by the Estonian Data Protection Inspection.
The Estonian e-ID card uses two factor authentications: the combination of the PIN and the
card. As the personal information contained on the card is considered public information in
Estonia, the card does not contain any private data. It functions only as a key to access the
central database. Thanks to the two factor authentication, a stolen card does not give access
to online services. The PIN code is self-chosen but cannot be easily altered.
4.6
BankID
BankID is a Swedish e-identity solution developed by Swedish banks that was subsequently
expanded to become an authentication mechanism for a variety of e-services. These eservices range from online banking to e-commerce and e-government. BankID is issued by
33
banks to their internet customers. Today 10 banks are issuing BankID and 2 million
BankID‟s have been issued of a potential market of 5 million online bank users.
BankID‟s main usage is for financial transactions (around 50% of the transactions) and egovernment transactions (40% of the transactions). The remainder is for transactions with
private companies and this percentage is growing. Today BankID has 10 million transactions
monthly. BankID has two usage modes: authentication and digital signing.
The power of BankID is that it is an open and scalable network allowing any consumer and
any type of e-service provider to easily get access to the service and the entire network.
Also, it leverages existing and trusted credentials.
Figure 20: The four corner network of BankID
Figure 20 shows clearly that the roles are similar to the ones depicted in the generic eidentity three-corner model, but that one corner is split in two. Since there can be multiple
e-identity providers and e-identity brokers, interoperability and scalability needs to be
ensured by the independent scheme organisation.
4.6.1
Registration: leveraging an existing relationship
One of the most important aspects of BankID is the way the identities are provided; by
banks to their account holders. This enables secure authentication, the leveraging of an
existing infrastructure and enabled the achievement of critical mass.
Banks generally have long lasting relationships with their account holders and know a great
deal about them. Users can only open a bank account after making a physical appearance at
a bank and offering some form of identification. Banks are also required to comply with
„Know Your Customer‟ (KYC) and anti-money laundering regulations that requires banks to
know who they are dealing with. These regulations were put in place to prevent financial
crime and to prevent financing of terrorism.
Since most Swedish banks participate, critical mass has been reached for further growth.
34
4.6.2
Transaction: scalable 4-corner model
In BankID, the role of identity provider has been decentralized to create a quickly scalable
four-corner model. The transactions are routed from the end user to the service provider,
via the e-identity broker and the e-identity provider.
The role of the single identity provider has been split into three roles. The reason for this is
scalability. In a three-corner model, all end users and relying parties must maintain a
technical connection and legal relationship with the same party. In small markets this may
not pose a problem, but it can stifle growth.
In a four-corner model, the role of the identity provider is split allowing end users to receive
their credential from their identity provider of choice. The service providers forwards the
credentials received from the end user to the e-identity broker for authentication. The
service provider only has a relationship with the e-identity broker and not with the eidentity provider.
The advantage of the four-corner model is that each actor in the network only needs to
connect to one other actor, even if the service grows very rapidly. The network is therefore
highly scalable.
The BankID network runs on a single infrastructure owned by the major banks. The Swedish
Payments Clearing Housing BGC handles the operations of BankID.
4.6.3
Business model
For banks the services strengthen their position as trusted party for end users and service
providers. Banks do not need to maintain their owned identity infrastructure, once they
issue BankID's. The end user does not pay for the basic service separately; it is part of the
online banking service. However, additional services are charged to the user. The service
provider pays- and the e-identity provider receives a fee for each transaction. It is a 4-party
model with bilaterally agreed interchange fees.
4.6.4
Privacy and trust
BankID is based on electronic signatures. Transactions with BankID are legally binding
throughout the EU, since BankID issuers serve as certificate authorities who are bound to
strong legal requirements regarding security, privacy and trust.
BankID certificates come on USB devices, smart cards and just recently on mobile phones.
4.7
SURFfederatie
SURFfederatie is an initiative of the Dutch organisation SURFnet. SURFnet is a subsidiary of
the SURF foundation, in which Dutch universities, universities for applied sciences and
research centres collaborate nationally and internationally on innovative ICT facilities.
35
The SURFfederatie is a federative, multi-protocol7, authentication facility, which has been
established to facilitate students and staff to access services provided by various
educational institutions as well as a selection of third-party service providers.
In the past, students who wanted to use services from different institutions were required to
have multiple accounts, one at each institution they wanted to access. Since students are
increasingly using facilities of different educational institutions, this situation needed to
improve. The SURFfederatie facilitates access to various service providers (including thirdparty commercial organisations, educational organisations and research centres), using only
one single account. The role of identity provider is assigned to the “native” institution of the
student, e.g. the institution at which the student is registered.
Figure 21: The four corner network of the SURFfederatie
Similar to BankID, the SURFfederatie is implemented as a four-corner model, in which
SURFnet acts as a broker and protocol translator. The SURFfederatie allows different
federation protocols to be used by both the service providers and identity providers.
4.7.1
Registration: leveraging an existing relationship
The federation utilizes the existing relationships between the student and the educational
institution at which the student is registered. The advantage of this approach is the
availability of critical mass, utilization of existing trust relationships between student and
educational institution and reuse of existing infrastructure (especially important given the
large amounts of changes occurring each year as students graduate and new students
arrive).
In order to connect to the federation, all providers are required to establish a contract
between the provider and SURFdiensten (a subsidiary of SURF and responsible for all
products and services provided by the SURF organisation). When the contract is in place, the
7
Since different service providers and identity providers might utilize different protocols, a unique feature of the
SURFfederatie is its capability to act as a broker and protocol translator. Currently, the federation supports the
SAML 2.0, WS-Federation, A-Select and Shibboleth federated authentication protocols.
36
provider can utilize one of the supported protocols to establish the technical connection. By
supporting multiple protocols, the barrier for providers to connect to the federation is kept
low.
4.7.2
Transaction: scalable 4-corner model
The SURFfederatie utilizes an award winning 8, decentralised, distributed model for identity
providers and service providers. This approach facilitates a scalable four-corner model (see
also chapter 4.6.2 for a description of the advantages of this model). The transactions are
routed from the end user to the service provider, via the e-identity broker and the e-identity
provider. The e-identity broker also performs protocol translation, thereby facilitating
providers to connect using different protocols.
4.7.3
Business model
Educational institutions leverage their existing infrastructure and position as trusted party
for end users and service providers. Without extensive changes in account management,
students can access services from multiple service providers. The federation thus provides a
compelling business proposition to both the educational institutions (who can offer a large
set of services to students) as well as third-party service providers (who get access to a
large potential customer base without the need to invest in an expensive identity
management infrastructure).
By supporting multiple protocols, the extra cost for providers to establish a connection to
the federation is kept low, thereby providing an extra stimulus for providers to connect and
thus pushing both the number of potential customers as well as the services offered to
those customers9.
Connected parties (service providers and identity providers) pay a fee to SURFdiensten for
services obtained. These services include the use of the federation and development of new
and/or updated features.
4.7.4
Privacy and trust
The federation builds on the existing trust relationship between students and educational
institutions. In many cases, identity information does not need to leave the institution (e.g.
the fact that a student is registered at an institution might be sufficient proof to obtain
access to a service).
An additional level of trust is provided by the contracts between providers and the SURF
foundation, which assures that all communication between providers and the federation
adheres to the strict policies implemented by SURF. A high level of trust exists between the
institutions and the SURF foundation, given that the joint universities founded this
8
In 2008, SURFnet and Everett have received the eema Award for Excellence for the SURFfederatie solution.
9
To illustrate the success of this approach, in February 2010, Google has signed a 3-year agreement with
SURFdiensten to connect to the federation and make available the Educational Edition of Google Apps, as well as all
third-party applications offered through the Google Applications Marketplace, to all connected educational
institutions. Google uses their SAML-based single sign-on facility (see chapter 4.3) to establish the role of service
provider with external identity providers.
37
foundation in 1987. Today, the foundation represents over sixty institutions (academic
universities, universities of applied sciences, research centres and centres for documentary
information services).
38
5 Conclusions
The e-Identity business is still in its infancy and it has often been a case of trial and error
when starting a service in this area. For achieving success, it is clear that scale, in terms of
the number of transactions and number of participants, is a major factor. In that sense most
initiatives discussed can be said to be successful, although the usage of dedicated
government initiatives and of the pure user centric approach of Cardspace is, to date,
limited.
Based on the analysis of e-identity as a two sided market, serving end users on one side and
service providers on the other, various aspects appear crucial in setting up a successful eidentity network. We have listed the cases of this report in the table below to provide an
overview of key aspects.
39
Domain
OpenID
CardSpace
DigiD
Estonian e-ID
Google
BankID
SURFfederatie
Technology, web
Technology, user
Government, easy
Government,
Cloud computing,
Re-use what‟s
Re-use what‟s
2.0 / social
centric
to use, only for
trusted transactions
SaaS
already there,
already there.
private and
Educational sector
citizens
government sector
Network
4 corner, Internet
3 corner, user acts
model
DNS acts as broker
as broker
Registration
Mostly self
Depending on
registration
InfoCard scheme
3 corner
3 corner
3 corner
4 corner
4 corner
Local government
Local government,
Self registration
Bank issued
Issued by
certificates
educational
institutions
Transaction
Authentication,
Card dependent
Authentication
profiling
Authentication,
Authentication,
Authentication,
signing
authorisation
signing
Authentication
Business
Low-cost trust,
Currently only
Subsidised,
Wide range of
Advertisement,
Wide range of
Wide range of
Model
more traffic
technology
government only
transactions
generating more
transactions
transactions
traffic
Privacy &
Minimal trust
User centric, privacy
Government
Government
Google policy
Government and
Educational sector
control
controlled
controlled
regulated privacy
bank regulated
regulated
Fits well for large-
User centric,
High penetration,
Re-use
World domination
Re-use bank-ID for
Restricted to
scale, limited trust
technology driven,
limited usage for
government-ID for
through attractive
private and public
education, high
networks.
still to be proven
citizens
private transactions
applications
transactions
usage.
Trust
Take away
Figure 22: Overview of e-Identity initiatives
40
Conclusions that can be drawn from the various cases investigated are
1. In terms of solutions, there is no one size fits all. E-identity is used for many situations
with different risks, trust and user profiles. From a privacy point of view it makes sense
to have multiple identities, per usage context. Hard privacy guarantees cannot be given
from a technology point of view only. This is why the scheme holder must be a trusted
party. What lacks in terms of convincing end users about their security and privacy may
be solved by technology only if the transactional stake is limited. This is exemplified by
the loose coupling between service providers and identity providers in common OpenID
and CardSpace scenarios where little trust exists between the parties in the network and
consequently the transactions served are perceived to be of limited risk.
2. The cost of the identity administration process and the handing out of means of
authentication, needed to establish trust for individual transactions, is a major factor in
the business model. Successful sharing or transferral of that cost is key in any eidentity network. This is illustrated in some of the cases that reuse existing
administration processes and authentication means, e.g. by government (DigiD, Estonian
e-ID Card), banks (BankID) or the educational sector (SURFfederatie).
3. E-identity seems to be underestimated as a two sided market serving end users on oneend and service providers on the other. An important aspect of a two-sided market is
that the propositions should be attractive to stakeholders at both ends. Successful larger
scale solutions do address this aspect and these can be, in the context of the framework
proposed, 3 or 4 corner models. In contrast, an initiative such as CardSpace seems to
focus on the end user only, providing a less clear business case to service providers.
4. Interoperability of e-identity solutions is the way forward for mass adoption. End-users
and service providers do not want to be bothered with the selection problem of which
technology or solution is the best. They just want a service delivered. The EU STORK
initiative (see text box in paragraph 4.3) clearly has this in mind from a cross border
perspective. A private solution such as Google‟s mitigates this by providing multiple
standards, including OpenID and SAML2.0, to bridge the gap between services and
communities. Another good example is the SURFfederatie, which offers multiple
protocols for providers to utilize, thereby significantly reducing the cost and effort to
connect.
Finally, we want to propose a thesis:
In successful e-identity networks, the business case and the gain for each party
(identity providers, service providers, users) is transparent to all parties.
If there is widespread doubt on what gain (money or otherwise) some party in the network
takes from it, trust in the network will erode and it cannot scale towards higher value
transactions. This may be the reason why some of the more successful initiatives have a
government supported scheme, which, at least in Europe, appears to provide the required
trust. However, the amount of interaction of citizens and companies with governments is
limited and involvement of the private sector is crucial for widespread adoption and growth
of e-Identity.
41
6 About Innopay
Innopay is an independent full service consultancy firm specialised in payments and related
transaction services. Our key practices include online payment, e-invoicing, e-identity,
mobile payment, cards and related regulation.
Given our independent position, we work for all players in the industry. We devote research
time and investments to help peer professionals ‘structure & understand’ these topics and
actively facilitate industry knowledge transfer, which we consider crucial for the further
development of global e-business. Our leading industry reports can be downloaded from
www.innopay.com.
With our in-depth knowledge and experience gained on both the demand side and the
supply side, we are ideally positioned to help our clients determine the direction of their
growth. This often results in new products and/or markets that we successively help to
‘develop & manage’ and bring to market in a controlled and effective way. We do this for
single clients but also for groups of clients. Consequently, we have extensive experience in
developing multi-party transaction schemes and accompanying messaging standards in
diverse industries such as financial services, insurance and document exchange.
On the other side, we help corporate users to ‘choose & use’ the transaction services that fit
their specific business needs from the wide array of often industry tailored transaction
services on offer. We use a multi-disciplinary approach covering commercial, operational
and technical aspects.
Innopay is a member of the European Payments Consulting Association (EPCA) and the
Payment Systems Market Expert Group (PSMEG) of the European Commission and an
associate member of the Euro Banking Association (EBA).
For more information visit www.innopay.com or mail to info@innopay.com
42
7 About Everett
Everett (www.everett.nl) is a systems integrator and consultancy firm specialized in
interaction, identity and integration. Everett has offices in Nieuwegein (Netherlands, head
offices), London (UK), Milan, Rome (Italy) and Bangalore (India). Everett also provides 24x7
solution support services via its ESSC support centre. Since its inception in 1999, Everett has
proven itself as a leading specialist on identity enabled services and middleware in general,
and portal, secure remote access, identity & access management, IT compliance and service
oriented integration technology in particular.
Our aspiration is the „identity enabled‟ enterprise, with its strategic objective of facilitating
secure, personalized and integrated ICT services with a minimal time-to-service.
Implementing these identity enabled services poses a challenge for the modern day ICT
organisation since it has to find a cost effective balance between user demand,
organisational goals and rules and regulations. Everett‟s core activity is assisting
organisations in this area with consultancy, implementation skills, knowhow and solution
support.
In the past ten years, Everett has realised a large number of projects. We are active in a
number of different business domains such as Education, Research & Development, Telecom
& Media, Finance, Transport & Logistics, Government, Energy, Manufacturing and
Healthcare.
Customer projects include the whole range of identity & access management infrastructure,
and the realisation of personalized web portals and composite applications, using Service
Oriented Architecture and most of the of Web 2.0 technologies. At the core of all of these
projects is an agile project approach aimed at producing immediate business value in the
context of a long-term vision and target architecture.
For more information visit www.everett.nl, or mail info@everett.nl.
43
ESTONIAN
INFORMATION SOCIETY
STRATEGY 2013
2006
FOREWORD
Dear reader,
The document you are holding in your hands is called the „Estonian Information Society Strategy
2013”. The development plan serves as a good example of the systematic character of information
society development in Estonia – its elaboration was not initiated due to an unexpected need to
change course, but because the time frame of the previous information policy had come to an end.
The strategy is special for several reasons. Never before have activities related to the development of
the information society in Estonia been planned for such a long period. We have reached a level,
where these are not single projects, services and technologies that need to be focused on, but more
general and long-term goals rather. When reading the strategy, one might note the less frequent than
expected use of the prefix “e”. This is because the strategy seeks to contribute to the improvement of
the living standard, economy, and public services, not just to some individual phenomena beginning
with “e” that have been developed for a chosen few.
It is only natural and reasonable to use information technology for a more rationalized organization of
living. Preconditions and possibilities for this have, to a large extent, already been developed. The
more citizens, enterprise and the public administration get established in the information society, the
more important it becomes, how to employ the new possibilities in a manner that would benefit us all.
Information technology can help us in our daily lives, in entrepreneurship as well as in the public
administration. It allows us to continuously develop and achieve success – isn’t this the kind of future
we all wish for the years to come?
I hope that the following pages give you an overview of shaping a better future in Estonia from the
standpoint of the information society.
Enjoy reading!
Edgar Savisaar
Minister of Economic Affairs and Communications
2
Table of contents
FOREWORD .............................................................................................................. 2
INTRODUCTION ........................................................................................................ 4
1.
PRINCIPLES FOR THE DEVELOPMENT OF INFORMATION SOCIETY ....... 5
2.
CURRENT STATE OF AFFAIRS AND FUTURE CHALLENGES .................... 6
2.1.
State of affairs ......................................................................................................................................... 6
2.2.
Future challenges................................................................................................................................... 7
2.2.1.
Computer and internet access. Information society infrastructure............................................ 7
2.2.2.
ICT and internet use......................................................................................................................... 8
2.2.3.
Competitiveness of the Estonian ICT sector .............................................................................. 10
2.2.4.
ICT and public administration ....................................................................................................... 11
3.
VISION ............................................................................................................ 13
4.
ACTION FIELDS AND MEASURES ............................................................... 14
Action field I: Development of citizen-centred and inclusive society ................................................ 14
Action field II: Development of knowledge-based economy ................................................................ 16
1. Promotion of ICT uptake by enterprises:................................................................................................ 16
2. Increasing the competitiveness of the Estonian ICT sector................................................................. 17
Action field III: Development of citizen-centred, transparent and efficient public administration
17
1. Improving the efficiency of the public sector .......................................................................................... 18
2. Providing user-friendly public sector e-services .................................................................................... 20
5.
IMPLEMENTATION OF THE STRATEGY...................................................... 21
3
INTRODUCTION
In the modern globalizing world, economic success and high quality of living are achieved only in
countries attaching great importance to the efficient handling of knowledge and information and using
them for the benefit of the society. There is no doubt that information and communication technology
(ICT) has a significant impact on economic growth, employment and human behaviour. Thus, for a
small country with limited resources like Estonia, the development of knowledge-based economy,
compact yet efficient functioning of public administration and inclusion of all citizens in the organization
of public life are of particular importance.
According to the European Union’s information society strategy i20101, ICT accounts for 25% of GDP
and 40% of productivity growth in the EU. In Estonia, too, modern ICT solutions developed and used
both by the public and private sector give reason to regard the development of the information society
as a strategic choice.
The term “information society” usually denotes a society, where the majority of values created by
mankind are contained in information. Most of the information stored by the society is maintained,
transformed and transmitted in a universal digital form. By using a data exchange network, all
members of society have access to information. Furthermore, in the information society, all the routine
mental work is entrusted to machines2.
In Estonia, the development of the information society is based on the Principles of Estonian
Information Policy, adopted by the Estonian Parliament in 1998. A follow-up to the document, the
Principles of Estonian Information Policy 2004-2006, was elaborated and approved by the
Government of the Republic in 2004. The strategy you are holding in your hands right now – the
Estonian Information Society Strategy 2013 – entered into force in January 2007.
The Estonian Information Society Strategy 2013 is a sectoral development plan, setting out the
general framework, objectives and respective action fields for the broad employment of ICT in the
development of knowledge-based economy and society in Estonia in 2007-2013. Several international
and EU-level policy documents, notably the EU i2010 and eGovernment action plans, were taken into
consideration when elaborating the strategy.
Activities to be carried out in the framework of the strategy are in line with the priorities set out in the
Estonian Action Plan for Growth and Jobs 2005-2007 and the Estonian National Development Plan for
the Implementation of the EU Structural Funds 2007-2013. In addition, the strategy is mutually
complementary with several other sectoral development plans, such as the Estonian Enterprise Policy
2007-2013, the Estonian R&D strategy “Knowledge-Based Estonia 2007-2013”, the Strategy for the
Preservation of Estonian Digital Heritage 2007-2010 etc.
The development of the information society as well as the application of ICT for an increased
efficiency in economic and societal processes requires co-coordinated efforts from all government
agencies. Thus, the Ministry of Economic Affairs and Communications as the main co-ordinator of
information society related developments in Estonia involved all ministries, the State Chancellery, as
well as organizations representing the third sector and scientific circles in the elaboration of the
strategy.
1
2
”i2010 – A European Information Strategy for growth and employment”
An article entitled ”Information society and its signposts” by Valdo Praust in “IT in Public Administration of Estonia 1998”
4
1. PRINCIPLES FOR THE DEVELOPMENT OF INFORMATION SOCIETY
Principles for the development of the information society in Estonia were first set out in 1998. Though
most of them have maintained their topicality, the fast development of technology has necessitated
certain shifts of emphasis.
The principles to be followed in the development of the information society in Estonia are the following:
•
the development of the information society in Estonia is a strategic choice
with public sector leading the way in pursuing its principles;
•
the information society is developed in a co-ordinated manner in co-operation
between the public, private and third sector;
•
the public sector is a smart customer, ensuring that in public procurements as
much freedom as possible is left for innovative solutions;
•
the information society is created for all Estonian residents, whereas
particular attention is paid to the integration of social groups with special
needs, to regional development and to the strengthening of local self-initiative;
•
the consistency of the Estonian language and culture is ensured;
•
the interests of both the creators and the users of intellectual property are
taken into account;
•
the development of the information society must not undermine people’s
sense of security. The protection of basic rights, personal data and identity
must be ensured, and mitigation of non-acceptable risks in information
systems must be guaranteed;
•
activities aimed at the development of the information society are linked to the
R&D efforts in Estonia;
•
the information society and the opportunities it brings are taken into account
in the elaboration of all sectoral policies;
•
trends occurring in the EU and elsewhere in the world are taken into
consideration. Furthermore, as an active partner, Estonia shares its
experience and learns from others;
•
the public sector employs the already existing technological solutions (i.e. the
ID card, the data exchange layer X-Road) and avoids duplication of IT
solutions;
•
the public sector re-organizes its business processes so as to ensure a oneoff collection of data from citizens, entrepreneurs and public bodies;
•
the public sector gives equal treatment to different hardware and software
platforms and ensures interoperability of information systems by using open
standards;
•
the collection of data and the development of ICT-solutions proceed from the
principles of re-usability.
5
2.
CURRENT STATE OF AFFAIRS AND FUTURE CHALLENGES
2.1. State of affairs
Estonia has, on its way to the information society, made considerable progress. The following includes
some examples of that:
•
advanced communications network and good internet availability;
•
innovative mindset in the public sector and its high-quality IT solutions:
o
service-oriented approach to the development of state information systems and a
secure data exchange layer called the X-Road, which constitute the cornerstones of
the so-called common service space;
o
single-point-entry to the state at www.riik.ee;
o
Citizen portal at www.eesti.ee reflecting the state as an integral whole, where
authorized users have three possible roles: that of the citizen, the entrepreneur and
the official;
•
high-quality IT solutions in the private sector, in particular internet banking and mobile
applications;
•
success stories in the Estonian ICT sector (i.e. internet communications company Skype,
provider of various GIS and mobile positioning solutions – Regio, provider of different mapplications and m-solutions – Mobi Solutions etc);
•
wide use of ICT in education as a result of the Tiger Leap programme aimed at the internetization
of general education schools and improvement of IT skills among teachers;
•
the largest functioning public key infrastructure in Europe, based on the use of electronic
certificates maintained on the national ID card and allowing to considerably improve the security
and functionality of IT solutions. More than 80% of the population possess the ID card that
enables both electronic authentication and digital signing. Relevant legislation is in place, giving
the digital signature equal power with the handwritten one, and imposing a responsibility on public
authorities to accept digitally signed documents;
•
eagerness of the Estonians to use innovative solutions (wide take-up of IT solutions provided by
the Tax and Customs Board, internet banking, m-parking etc).
Estonia’s achievements in developing the information society have been recognized in various EU and
international surveys, such as the European Commission’s Information Society Benchmarking Report
2005, Global Information Technology Report 2004-2005 (published by the World Economic Forum),
Top 10 Who are Changing the World of Internet and Politics (compiled by the global eDemocracy
Forum in 2005) to name a few.
This success has been based on the implementation of priorities set out in the Principles of Estonian
Information Policy. So far, information policy related activities in Estonia have mainly been focused on
the development of ICT infrastructure and the creation of systems necessary for implementing sectoral
policies. However, in order to increase the competitiveness of the society, more emphasis needs to be
placed on the development of citizen-centred and inclusive society, knowledge-based economy as
well as transparent and efficiently functioning public administration.
6
2.2. Future challenges
2.2.1.
Computer and internet access. Information society infrastructure
Participation in the knowledge-based society presumes access to the internet and ICT-based services.
As a result of the early liberalisation of the telecommunications market and intense competition,
Estonia has a well-developed communications network: all central and local government agencies,
public libraries as well as educational and health institutions have an internet connection, as do 90%
of Estonian enterprises. Approximately 90% of the Estonian population lives in areas with immediate
availability of broadband internet. Technology convergence, development and increased supply of
triple play (digital TV, internet connection and telephone) solutions and mobile data communications
will facilitate access to the internet further. At the same time, it should be kept in mind that the use of
information society services will raise the bar for the speed and quality of data communications.
Though regionally the spread of the internet is rather even, significant discrepancies still exist locally.
The launch of new and advanced services tends to be focused in bigger centres, while in dispersed
areas high-quality broadband still remains a challenge. However, the internetization of rural areas
largely contributes to rural development, ensuring the availability of operational information and
services as well as helping to increase the quality of life in rural areas.
For a certain part of the population, in particular for the economically underprivileged and the elderly,
access to the internet is often restricted by lack of home PCs. Survey results reveal that for half of
non-users, lack of home PCs due to high computer prices is the main reason for not using the internet.
At the same time, a third of today’s non-users would start using the internet if their economic situation
improved. Thus, continuous efforts are needed to ensure internet access in public places. In addition,
awareness needs to be raised about intellectual property rights. Half of the respondents to a survey
carried out by the Estonian Software Association in spring 2006 claimed that their home PC contains
legal software, whereas a third of them did not consider the legality of software in their home PC
important at all.
Wireless Estonia
In Estonia, wireless internet is a rule rather than an exception – for its 45,000 square kilometres
surface area there are nearly 900 wi-fi hotspots in Estonia, most of them free.
In Tallinn, wi-fi is offered in numerous cafes and petrol stations; in addition, in summer 2005 wireless
internet was made available for free in all the capital’s beaches and many parks. Wireless internet can
also be used on commuter trains, allowing thus to stay in touch with your friends/colleagues and keep
working while travelling around Estonia.
Village Road 3 (KülaTee 3)
Village Road 3 is a target programme aimed at the internetization of rural areas. It serves as a followup to similar programmes Village Road 1 (aimed at the internetization of local government agencies)
and Village Road 2 (targeted at the internetization of public libraries).
The objective of Village Road 3 is to improve the availability of broadband internet in scarcely
populated areas, where the private sector has no economic interest to invest. By the time of the
completion of the programme, the availability of broadband internet in remote areas will be as high as
that in densely populated regions. The target group of the programme includes local government
agencies as well as people residing in areas of market failure.
7
2.2.2.
ICT and internet use
Internet use in households
Despite good and affordable internet availability, computer and internet use in Estonian households
still lags behind that in the public and private sector. In spring 2006, 58% of the population aged 15 to
74 used the internet and 39% had an internet connection at home. As mentioned earlier, one of the
challenges lies in raising the quality and availability of the internet in different regions, especially in
areas of market failure, where it is not profitable for the private sector to invest. However, internet use
does not solely depend on the availability of infrastructure, or the price of service, but, to a
considerable extent, also on motivation – the existence of useful and necessary content as well as
awareness of opportunities the information society offers. Though Estonia has been successful in
bringing public sector services online, further efforts are necessary to increase people’s awareness of
the population about new convenient services still needs to be strengthened.
Furthermore, for some non-users the use of the internet is restricted due to insufficient consideration
of their specific (i.e. regional, cultural and social) needs and expectations. A significant part of nonusers, in particular the skilled labour and the elderly, lack motivation to use ICT due to the shortage of
interesting and necessary content. As a result, they do not regard the internet as part of their life.
Survey results indicate that eHealth and other social services have a strong potential of boosting
motivation to use the internet and e-services. In addition, more can and should be done in the field of
eAccessibility. In the elaboration of centrally developed portals, such as www.eesti.ee, www.riik.ee,
etc, WAI (Web Accessibility Initiative) guidelines have been followed. However, compliance to WAI
standards still needs to be raised in individual public agencies.
The development of an inclusive society requires the creation of trust towards electronic channels.
The growth of internet-based attacks, limited awareness of IT security issues, and possibilities to
quickly copy and integrate voluminous data might pose a threat to people’s privacy, lower their sense
of security and, thus, their interest to use the opportunities of the information society. Trust in the
internet and motivation to use it depend on people’s skills to use the computer and e-services. Public
sector e-services are considered difficult to use by slightly more than a quarter of internet users in
Estonia, in particular by the over-60 age group. Thus, computer and internet training for the entire
population must be continued. It is also important to realize that ICT does not only create opportunities
for fixing bottlenecks, but also offers additional options for participating in public life (eDemoracy), for
continuous, flexible and personalized self-perfection (eLearning), entertainment, etc. Similarly, it has to
be kept in mind that more than half of today’s internet non-users have no intention of starting to use it.
In order to avoid the deepening of the digital divide between those with access to the internet and eservices and those without it, public service provision must be ensured via multi-channel systems.
eVoting
At local government elections of 2005, the Estonians could, for the first time, cast their votes
electronically, using the secure ID card as an authentication mechanism. eVoting does not aim to
replace the traditional voting methods, but provides, with the help of new technology, additional
options for enhanced inclusion. Thus, people could vote electronically on advance polling days with a
possibility to change their vote on the election day at the polling station, making the previously given
eVote void.
Estonia is the only country intending to make use of eVoting also at its general elections (to be held in
March 2007). This time, an additional feature will be added to the process: voters can request their
elector cards to be sent to them electronically, eliminating thus the need for the paper card and doing
one’s bit for the environment.
Computer Protection 2009
The objective of the joint project of the private and public sector is to increase public awareness about
IT security and teach people, how to use the internet safely. To this end, a number of sub-projects will
be launched, one of the priority fields being the promotion of ID card based authentication in the use of
e-services.
8
One of the first steps taken within the project was the launch of an IT security portal
www.arvutikaitse.ee, which provides information on how to protect one’s computer from cyber
criminals and gives advice on how to be safe and avoid falling victim to fraud when shopping online.
The project is carried out by the Look@World Foundation, which was established in 2001 by ten
leading companies in Estonia with the aim to considerably increase the number of internet users, and
raise, thereby, the living standard. The projects implemented so far include basic computer and
internet training for 100,000 people, development and implementation of the eSchool environment,
and opening nearly 500 public internet access points in Estonia. The state is represented in the
partnership by the Ministry of Economic Affairs and Communications.
ICT and internet use in enterprises
Though most Estonian enterprises have an internet connection, the use of ICT and the internet for
eCommerce and eBusiness is still limited. In 2005, 24% of Estonian companies received orders from
customers and business partners via the internet (e-mail excluded) and 69% of companies placed
orders to other companies online. The limited spread of eCommerce can be explained by Estonia’s
geographical size and unsuitability of the internet for the purchase and sale of certain service and
product groups. Without sufficient consumer demand investments in the development of internetbased purchasing and selling might not pay off. However, the competitiveness of enterprises is clearly
jeopardized by the limited use of eBusiness, i.e. use of ICT-ies in their basic business processes. The
development of ICT has reached a stage where, from the viewpoint of economic competitiveness, it is
not only the strength and export capacity of the ICT sector itself that plays a significant role, but also
the take-up of ICT in all sectors of economy. Despite the continuously fast economic growth the
productivity growth in Estonia still remains to be desired – in 2004, it only accounted for 50.6% of the
EU average. The use of ICT-ies allows enterprises to significantly increase their productivity and
launch more innovative products and services, in particular if organizational change and upgrading of
skills are accompanied with the implementation of new technology. While the public administration as
well as the banking sector and telecom companies have changed their business processes through
the use of ICT, the awareness of eBusiness among SMEs just as well as their capability to apply ICTies in their basic processes are more limited.
Furthermore, increased efforts are needed to improve companies’ understanding of the impact of ICT
on their economic activities. According to a survey on eBusiness carried out in 2006, only 16-18% of
Estonian enterprises found that ICT-ies play a significant role in cost reduction, increase of turnover
and profit, and launch of new products or services. The survey results reveal that the main reason
enterprises do not use eBusiness solutions lies in the need to make huge investments the profitability
of which is uncertain.
Understanding the impact of ICT on entrepreneurship and economy in general is, in fact, a challenge
not only for businesses, but for the public administration as well. Therefore, research efforts aimed at
analyzing the influence of ICT on economic growth and society at large will be increased.
Set up a business in two hours!
Beginning from January 2007, a business can be set up in Estonia by way of expedited procedure
over the web at: http://ekanded.eer.ee/.
One of the main differences between the traditional and expedited procedure lies in the fact that in
case of the latter, one does not have to go to the notary: persons are identified with the national ID
card and documents are concluded by digital signature.
In case of the expedited procedure, petitions for entry are reviewed within the next working day after
the receipt of the petition. The objective is to achieve a situation, where a business could be set up in
2 hours.
Initially, expedited procedure will only be applied to the first entries of limited liability companies, selfemployed entrepreneurs, general and private limited partnerships. In addition, businesses will be able
to change the data they have submitted in the Commercial Register – this possibility is open also for
public limited companies, commercial associations and branch offices.
9
2.2.3.
Competitiveness of the Estonian ICT sector
In 2004, the Estonian ICT sector contributed 9.2% of the country’s GDP. However, more should be
done to improve the competitiveness and added value generated by the sector. Many large ICT
companies mainly operate in a market segment determined by their international parent company or
perform subcontracting. In addition, the sector can be characterized by a rather high level of
fragmentation, which may pose problems for actively launching innovative products and services as
well as for entering new markets. Furthermore, lack of qualified IT professionals is a growing
challenge for the sector, both in terms of vocational and post-graduate skills. To ensure the
development of innovative products and services, co-operation between research institutions and
entrepreneurs needs to be intensified.
In the light of the above, the sector would benefit from re-orientation from low value-added activities to
those generating higher added value. This, in its turn, presumes sufficiency of qualified IT
professionals. In order to facilitate the internationalization of the Estonian ICT cluster, it is necessary,
among other things, to provide business support measures aimed at marketing and sales promotion,
to facilitate the migration of foreign labour with post-graduate degree, and to attract large corporations
to Estonia.
The convergence of IT, voice telephony and media will give rise to entirely new business models and
forms of partnership. In this context, issues related to the protection of intellectual property represent a
significant challenge in terms of avoiding a situation, where the desire to create intellectual property or
use it legitimately might be suppressed from the outset. The creation of intellectual property as well as
its legitimate use can be promoted by ensuring efficient legal protection and raising public awareness.
State orders constitute a considerable part of the ICT sector’s turnover. However, in public
procurements the determining factor usually tends to be the price, which is why the private sector
often lacks motivation to offer the best solutions. By becoming a smart customer, the public sector
can, in addition to meeting its own needs better than so far, contribute to the development of
competitive products and services that could be marketed abroad.
Information security has become crucial both in Estonia and in the rest of the world. Compared to the
situation several years ago, the volume of information assets has grown, threats and attacks have
become more massive, security measures have become more costly, and risks are higher. Information
security can no longer be guaranteed by one agency, enterprise, working group or a state – it requires
the co-operation of all stakeholders in Estonia and elsewhere.
Competence Centre Programme
The Competence Centre Programme was launched with the objective to increase the competitiveness
of Estonian enterprises through long-term strategic co-operation between research institutions and
companies. One of the recipients of the support is ELIKO – a competence centre for electronics,
information- and communications technologies – which brings together eight technology companies
and the Tallinn University of Technology.
The main objective of the competence centre is to develop innovative technologies and products
based on intelligent embedded systems. The main areas of its activities are embedded networks, selforganizing ad hoc RFID reader networks and non-classical signal processing.
Thanks to its shared competence, ELIKO has been able to launch a Europe-wide project on robotics
th
called ROBOSWARM. The project, funded by the 6 Framework Programme, aims to develop an
open knowledge environment for self-configurable, low-cost and robust robot swarms usable in
everyday applications.
10
Tiger University+
The objective of the programme is to support ICT academic staff and degree courses’ infrastructure as
well as to contribute to the development and modernization of ICT infrastructure at higher education
establishments.
Support is given, for example, for the participation of ICT professors in international conferences,
seminars and workshops, to promote the mobility of post-graduate ICT students etc.
2.2.4.
ICT and public administration
Wide use of ICT in the public administration allows to improve the efficiency of the state machinery,
influencing, thus, also the availability and quality of public services and increasing opportunities to
participate in decision-making processes.
Estonian central and local government agencies have developed and taken into use a number of
modern and well-functioning information systems. The development of the state IT architecture is
service-oriented, a data exchange layer X-Road has been developed and is fully operational, and a
number of e-services have been created both at central and local level. However, increased efforts are
needed in order to improve the functioning of different information systems as an integral whole. In
addition, more needs to be done in terms of semantic interoperability and re-use of geographical
information.
The shift of emphasis from the development of technological solutions to that of information society as
a whole poses new challenges also to the national ICT co-ordination model. Today, agencies primarily
proceed from an institution-based or local view. Modern ICT solutions, however, allow to develop
horizontal (cross-institutional) solutions based on an integral view and corresponding better to citizens’
needs.
Increasing the efficiency and transparency of the public sector through the wide take-up of ICT will
change the way the public administration functions and pose challenges in terms of skills of civil
servants. Organizational changes necessary for the efficient functioning of the public administration in
the information society need to be analyzed in depth and implemented. Besides, the fast development
of technology and paradigm changes it brings along necessitates an increase in socio-economic
research so as to ensure that policy formulation would respond to the needs of the information society.
As mentioned before, smart use of ICT allows to increase the efficiency of public service provision
both for citizens and enterprises. A number of convenient complex services have already been
developed (e.g. the parental benefit service, the service of informing about state graduation
examination results via e-mail, applying for the European health insurance card etc.) and gained
popularity in Estonia. Nevertheless, more efforts are needed in order to make service development in
the public sector more systematic and responsive to the needs of potential customers.
The use of ICT allows the state to communicate with its citizens in their different roles in a more
personalized manner. The Citizen portal at www.eesti.ee provides additional options for that and
needs, thus, to be developed further. In the light of the above, principles for the design and
development of public e-services are to be agreed upon. The development of e-services should give
more consideration to customer expectations and needs. While to date, the main focus has been on
the development of services for citizens, in the future more attention needs to be paid to the
identification and development of e-services for enterprises.
ICT-ies represent an efficient tool for increased inclusion of citizens in public debates and decisionmaking processes. Today, public sector websites are mainly used for giving information and, to a
certain extent, for the provision of e-services. Their role, however, in increasing citizen participation
should still be enhanced.
Public information is generally widely available, yet it is frequently scattered. The importance of an
integral systematic approach is increasing, as this would largely facilitate information search and use
of e-services. Citizens’ trust in the state can be boosted through proper handling of personal data,
allowing people to conveniently monitor, who and why uses their data.
11
Paperless document management
To increase the efficiency of document exchange in the public sector and to facilitate the transition to
entirely paperless management of business, a nationwide document repository has been developed in
Estonia. Figuratively, the information system functions as an intermediate storehouse where the
document sender sends the document to and from where the document receiver can download it.
The document repository is connected to the data exchange layer X-Road. As documents are
submitted to the system in a universal digital form, they can be automatically registered in document
management
systems.
Traceability of the use of one’s data
The wide take-up of ICT as well as the constant availability of information and data may raise
concerns over loss of privacy and, thus, undermine people’s trust in e-services and ICT solutions. In
order to ensure transparency when dealing with personal data collected by the sate, the Citizen and
Migration Board has made it possible on the Citizen portal (www.eesti.ee) to trace, who and when
has been checking the citizen’s data from their databases. In case any doubts arise regarding the
justifiability of such checking, the citizen can contact the respective agency and demand an
explanation.
12
3. VISION
Estonia is a constantly developing, inclusive society, raising the living standard of everybody. The
wide take-up of ICT in all fields of life (i.e. culture, education, health care, employment, and internal
security) allows to improve citizens’ quality of life as well as to actively involve them, risk groups
included, in public life. Estonian enterprises use ICT and reorganize their business processes and
management models, increasing, thus, their productivity and competitiveness. There are sufficiently
qualified IT professionals in the Estonian ICT sector, our ICT solutions are known worldwide, and the
ICT sector is successful in exporting its products and services. Rational use of ICT enables the public
administration to function efficiently and be inclusive for all. Public sector services for citizens and
enterprises are secure, optimized and accessible via one service space. In the governance of the
state, needs and expectations of citizens in their different roles are considered. To this end, ICT-ies
are made use of so as to ensure the development of individualized and citizen-centred solutions.
13
4. ACTION FIELDS AND MEASURES
In order to realize the vision, measures have to be elaborated and implemented in three dimensions
on which the functioning of the society is based – social, economic and institutional. Therefore, the
objectives of the Information Society Strategy are the following:
•
each member of the society leads a full life, using the opportunities of
the information society in every possible way and actively participating
in public life (“nobody will stay or will be left behind”);
•
Estonia’s economic growth is based on the wide use of ICT solutions;
•
public sector is citizen-centred, transparent and efficient.
Action field I: Development of citizen-centred and inclusive society
In the information society, most of the information is stored in a universal digital form. The availability
of information and skills to use it create preconditions for increasing the welfare and quality of life of
citizens. Citizens’ welfare also depends on how much their needs are taken into account when
organizing public life. Participation in the information society requires, on one hand, multi-channel
access to digital information and, on the other hand, skills and willingness to use the opportunities
created as well as motivation to actively participate in decision-making processes.
•
By 2013, 75% of Estonian residents will be using the
internet, while household internet penetration will
amount to 70%
•
By 2010, all public sector websites will comply with
WAI quality criteria
To achieve the objective, two measures will be focused on:
1. Broadening technological access to digital information;
2. Improving skills and widening opportunities for participation.
Within the two measures, the following activities are planned:
1. Broadening technological access to digital information
•
Development of data communications networks in areas of market failure and ensuring their
commercialization. The objective is to ensure the availability of high-quality internet service
throughout Estonia. Thus, the development of internet connections will be facilitated in
regions, where the private sector lacks economic interest to invest, and in areas, where the
quality of internet does not correspond to the needs and requirements of the information
society.
Responsible authorities: Ministry of Economic Affairs and Communications, Ministry of Internal
Affairs
•
Ensuring favourable environment for the development of new telecommunications
technologies and technological convergence, including the take-up of digital TV. The objective
of the activity is to ensure a smooth launch of new telecommunications-based services and
guarantee the possibility to use services of similar quality irrespective of technological
solutions used for their transmission.
14
Responsible authority: Ministry of Economic Affairs and Communications
•
Bringing public sector websites into compliance with WAI quality criteria so as to ensure their
accessibility for all, including people with special needs.
Responsible authorities: central and local government agencies, with Ministry of Economic
Affairs and Communications taking responsibility for the awareness raising and monitoring of
the process
•
Further development of the Citizen portal at www.eesti.ee. For citizens, the portal serves as a
secure personalized “virtual office” through which they can, in their different roles, manage
their affairs (use public services etc.) and communicate both with the state, enterprises and
other citizens. All public sector services will be made available via the Citizen portal.
Responsible authority: Ministry of Economic Affairs and Communications
2. Improving skills and widening possibilities for participation
•
Continuous upgrading of knowledge and skills of all members of society in order to ensure
their ability to cope in the information society. Provision of basic computer and internet training
for the elderly and people with special needs will be continued. It will be ensured that curricula
of all levels of education would facilitate the acquisition of computer and internet skills. In
addition, the development of public sector e-services will include relevant instructions and
guidebooks.
Responsible authorities: Ministry of Education and Research, Ministry of Economic Affairs and
Communications
•
Development and promotion of internet-based learning environments (eLearning). The
objective of the activity is twofold:
o
to facilitate the improvement of existing and the acquisition of new skills in continuing
education and retraining;
o
to make traditional learning processes more flexible and individualized.
Responsible authorities: Ministry of Education and Research, Ministry of Social Affairs
•
Raising public awareness about the information society. The objective is to increase the
awareness of the Estonian population about internet-based services as well as the
opportunities and threats related to the information society.
Responsible authorities: Ministry of Economic Affairs and Communications, Ministry of Internal
Affairs and other agencies
•
Digitization and digital preservation of cultural heritage, making it available via the internet for
citizens, and integrating it with eLearning environments. Information about objects of historic,
scientific, artistic, technological, social etc. value will be digitized and made available for the
public. Planned activities include the development of a digital library and a virtual museum,
establishment of a digital archive and a portal on cultural heritage.
Responsible authority: Ministry of Culture
•
Widening opportunities for participation in decision-making processes (eDemocracy).
Ministries and local governments will develop internet-based environments for the inclusion of
citizens and interest groups in decision-making processes. In addition, eVoting will continually
be used.
Responsible authorities: State Chancellery, Ministry of Justice
•
Implementation of flexible work arrangements. Barriers to teleworking will be identified and
solutions will be developed to overcome these.
Responsible authorities: Ministry of Social Affairs, Ministry of Internal Affairsr, Ministry of
Finance
15
Action field II: Development of knowledge-based economy
In its economic dimension, the strategy aims to increase the ICT uptake in all economic sectors. It will
contribute to the increase of productivity in enterprises, as well as their capability to develop innovative
products and services, and improve thereby the competitiveness of the Estonian economy. On the
other hand, the strategy seeks to create necessary pre-conditions for greater competitiveness and
internationalization of the Estonian ICT sector.
•
By 2013, the productivity per employee in Estonian
enterprises will account for 75% of the EU average
•
By 2013, the share of ICT enterprises in the national GDP
will amount to 15%
To achieve this, the following measures will be pursued:
1. Promotion of ICT uptake by enterprises;
2. Increasing the competitiveness of the Estonian ICT sector.
1. Promotion of ICT uptake by enterprises
•
Supporting the ICT uptake and use of eBusiness through business and innovation support
measures. The planned activities are the following:
o
elaboration and implementation of a specific ICT programme;
o
raising awareness about the opportunities of eBusiness in the framework of the
Innovation Awareness Programme;
o
supporting feasibility studies related to technology transfer;
o
giving investment support to manufacturing enterprises for the modernization of
technology;
o
provision of training and consulting for enterprises, including IT companies;
o
giving support for enterprise diagnostics to identify the development barriers and
opportunities of enterprises. A part of the diagnostics focuses on the level of ICT
uptake in a company and related possibilities.
Responsible authority: Ministry of Economic Affairs and Communications, implementing
agency: Enterprise Estonia
•
Re-organization of general, vocational and higher education so as to ensure conformity of
labour skills to the requirements of knowledge-based economy. The objective is to provide
workers of all professions with ICT skills and competence in order to cope in the knowledgebased economy. To this end, national curricula will be modernized and electronic study
materials, learning environments and e-courses will be developed and taken into use at all
educational levels.
Responsible authority: Ministry of Education and Research
•
Development of a common service space for the public, private and third sector to facilitate
communication between the three sectors.
Responsible authority: Ministry of Economic Affairs and Communications
•
Widening the opportunities of re-using public sector information by the private and third sector.
The objective is to ensure barrier-free use, both in terms of financial and administrative
obstacles, of public sector information, including for commercial use. To this end, the usability
of digital information created by the public sector will be increased through the modernization
of legal environment and development of relevant IT solutions.
Responsible authorities: Ministry of Justice, Ministry of the Environment, Ministry of Economic
Affairs and Communications
16
•
Ensuring a favourable environment for the development of eBusiness. Relevant legislation,
including privacy, consumer protection and information security related aspects, will be
reviewed.
Responsible authorities: Ministry of Justice, Ministry of Economic Affairs and Communications
and other ministries
2. Increasing the competitiveness of the Estonian ICT sector
•
Bringing IT education in accordance with the requirements of the ICT sector. To this end,
training opportunities will be widened for IT lecturers both at vocational and higher education
level; the apprenticeship system will be improved, and mechanisms will be developed for
increasing motivation among post-graduate students.
Responsible authority: Ministry of Education and Research
•
Supporting the internationalization of the Estonian ICT sector. Planned activities include,
among others, the following:
o
making the software procured by the public sector available in order to avoid
duplication of similar solutions and to facilitate the exports of Estonian ICT solutions;
o
facilitating the participation of Estonian ICT enterprises in EU and international
programmes and networks by supporting the preparation of project applications and
ensuring the availability of required national self-financing;
o
facilitating the migration of highly qualified foreign labour;
o
distribution, creation, and publishing of relevant standards.
Responsible authority: Ministry of Economic Affairs and Communications; implementing
agency: Enterprise Estonia
•
Facilitating the development of high-quality and innovative information society and media
services as well as settling intellectual property related issues. Favourable environment will be
ensured for the development of multimedia services provided via the internet, digital TV and
mobile communications. Legal questions related to the principles of service provision will be
solved.
Responsible authorities: Ministry of Culture, Ministry of Economic Affairs and Communications
•
Elaboration and implementation of principles concerning the outsourcing of services
necessary for the functioning of the state information system. The objective is to standardize
the requirements, guidelines and practices related to services outsourced in order to ensure
the functioning of the state information system (i.e. data communications, server hosting,
application hosting, support services etc) in a way that would, on one hand, improve the
service quality of different components of the state information system, and, on the other
hand, favour the development of the market offering those services.
Responsible authority: Ministry of Economic Affairs and Communications
•
Increasing the role of the Estonian ICT sector in the development of the country’s defensive
capacity. To this end, more use will be made of the potential of the Estonian ICT sector in
organizing military offset and in promoting civil applications related to development works in
the field of defence.
Responsible authorities:
Communications
Ministry
of
Defence,
Ministry
of
Economic
Affairs
and
Action field III: Development of citizen-centred, transparent and efficient public
administration
The strategy aims to achieve a situation, where the public sector functions efficiently while collecting,
using and maintaining data necessary for ensuring the provision of public goods in a common and
systematic manner. Public sector business processes are transparent and easy to understand; public
services for citizens and entrepreneurs are accessible via electronic channels, they are widely used
and take into account user needs.
17
•
By 2013, citizen satisfaction with public sector eservices will reach 80%
•
By 2013, satisfaction of businesses with public sector
e-services will be 95%
To achieve this, two measures will be focused on:
1. Improving the efficiency of the public sector;
2. Provision of user-friendly public sector e-services.
1. Improving the efficiency of the public sector
•
Transforming public sector business processes so as to make better use of advantages and
possibilities enabled by the application of ICT. The objective is to simplify and speed up
administrative procedures and ensure their efficiency.
To this end, the following activities are planned:
o
all management of business in the public sector, including proceeding and archiving of
documents, will be made electronic;
o
an analysis will be carried out about changes that have to be made in the legal
environment and organizational management in order to ensure paperless
management of business and automation of business processes. Necessary changes
will be implemented;
o
the availability of public sector information will be ensured in a unique digital form;
o
the capability of civil servants to cope with changes brought along by the development
of the information society will be ensured, leading to increased efficiency in their daily
work processes;
o
those responsible for the development of the public administration will have sufficient
ICT competence.
Responsible authorities: Ministry of Finance, State Chancellery, Ministry of Economic Affairs and
Communications, Ministry of Justice, and other ministries.
•
Increasing the efficiency of policy formulation through better use of data and increased research
about the impact and challenges of the information society. Research into different aspects of
the information society both from the economic, societal and individual perspective will be
increased. In addition, the definition of the ICT sector will be reviewed, and a system of ICT
statistics and economic analysis will be developed, allowing thus improved evaluation of the
impact of the ICT sector on the economy.
Responsible authorities: Ministry of Economic Affairs together with other ministries
•
Modernisation of state information systems so as to ensure their integration into a single
interoperable whole functioning on the basis of user needs, not institutional structures.
To this end, the following activities are planned:
o
ensuring that the data used in different parts of the state information system would
have a single meaning. To achieve this, the following actions will be undertaken:
development of mechanisms for the re-use of semantic assets; elaboration of XMLbased descriptions for main types of public sector documents; development of an
XML competence centre; development of a common thesaurus for the indexing of
services and websites; standardization of the structure of public sector websites and
development of mechanisms for their re-use;
o
transition of state databases and registers to a service-oriented architecture;
o
ensuring full traceability of all public sector services by stages;
18
o
development of the administration system for state information systems (RIHA), which
contains service descriptions and ensures the re-use of services and their fragments;
o
ensuring the re-use of geo-information generated by different public sector bodies;
o
establishment of a competence centre and a repository for open source software for
the re-use of developed solutions and knowledge.
Responsible authorities: Ministry of Economic Affairs and Communications with other ministries
•
Development of electronic authentication and authorization mechanisms, including participation
in cross-border eID (electronic identity) projects. The objective is to ensure the organizational
interoperability of public and private sector organizations providing and using the public key
infrastructure. Work planned under this activity seek to achieve a situation, where:
o
the ID card is the main personal identification tool in the electronic environment both
for the public and private sector;
o
digital stamp or the “Business ID” procedures have been taken into wide use;
o
the ID card and the respective software always correspond to new technological
possibilities and international standards;
o
legislation concerning the personal identification code and the ID card is reviewed so
as to ensure its conformity to the requirements of the information society.
Responsible authorities: Ministry of Economic Affairs and Communications, Ministry of Internal
Affairs and other ministries
•
Ensuring the functioning and development of support systems for the maintenance of the state
information system.
Responsible authorities: Ministry of Economic Affairs and Communications together with other
ministries
•
Development of systems necessary for increasing the efficiency of state and local government
agencies. The objective is to improve the provision of e-services at local level and avoid multiple
development of similar solutions by different local governments.
19
2. Provision of user-friendly public sector e-services
•
Integration of the public, private and third sector into one service space to improve the quality of
service provision in the public sector. Citizens will be able, in their different roles, to make use of
a common secure service space (based on the “single window” principle), allowing them to use
public services and communicate in one environment with the state, businesses as well as other
citizens.
Responsible authorities: Ministry of Economic Affairs and Communications together with other
ministries
•
Identification, development, launch and active implementation of high impact services
(eProcurement, eInvoicing etc).
Responsible authorities: central and local government agencies
•
Development of public sector e-services in different fields of life for citizens, businesses and
public sector agencies. Relevant information systems will be developed and implemented in
order to increase the efficiency of service provision through ICT, including making health and
social services available irrespective of one’s location.
Responsible authorities: central and local government agencies
•
Opening up of Estonian e-services for the citizens of other countries, especially those from the
EU member states.
Responsible authorities: central and local government agencies
20
5. IMPLEMENTATION OF THE STRATEGY
The Estonian Information Society Strategy 2013 sets out the basic principles of the Government of the
Republic for the development of the information society in Estonia. These principles are taken into
account and translated into relevant activities in the process of updating and elaborating of
organizational, sectoral and regional development plans by government agencies.
The strategy is implemented on the basis of annual Information Society Implementation Plans. At the
beginning of each year, agencies whose fields of activity and competence are encompassed by the
strategy submit to the Ministry of Economic Affairs information about the ICT development works they
intend to carry out during the following year. The Ministry of Economic Affairs and Communications as
well as other related ministries take this information into account when elaborating their organizational
strategies, which serve as an input for the State Budget Strategy. The Ministry of Economic Affairs
and Communications submits the draft of the Information Strategy Implementation Plan that has been
amended according to the State Budget Strategy to the Government for approval.
The implementation plan is realized in the form of project-based development works in accordance
with the principles set out in the Estonian IT Architecture and Interoperability Framework. Projects are
financed both from the state budget and the EU structural funds. Expenses related to the activities to
be funded from the state budget are planned by the respective implementing agencies, while central
and cross-institutional activities are financed via the Structural Funds.
In order to achieve the objectives of the strategy, sectoral expert groups will be established for all
three action fields. The expert groups will bring together representatives from respective ministries, the
third sector as well as from academic circles. Their task will be to continuously analyze the current
situation and evaluate the topicality and significance of objectives set out in the Information Society
Strategy. Based on their analysis, expert groups will make reasoned proposals to be considered in the
drafting of the priorities and activities of the Information Society Implementation Plan. In addition, the
results of their analyses will contribute to the updating of the Information Society strategy itself.
21
The Estonian ID Card and
Digital Signature Concept
Principles and Solutions
Ver 20030307
Contents
Contents .........................................................................................................................2
Status of the document...............................................................................................3
Introduction................................................................................................................3
Intended audience ......................................................................................................3
Current project status .................................................................................................3
Principles........................................................................................................................4
Digital signature regulation........................................................................................4
Digital signature concept .......................................................................................4
Certification Service Providers (CSP-s) ................................................................4
Time-stamping Service Providers (TSP-s) ............................................................4
Supervision – Registry and Ministry .....................................................................5
Foreign Certificates................................................................................................5
Identity Document Regulation...................................................................................5
Mandatory document .............................................................................................5
Card appearance and layout ...................................................................................5
Electronic data on card...........................................................................................6
Certificates .............................................................................................................7
E-mail address........................................................................................................7
Data protection.......................................................................................................7
Organizational structure, card issuing and operation.............................................8
Solutions ......................................................................................................................10
Certificate profiles and e-mail addresses .................................................................10
Certificate validity verification methods .................................................................10
OCSP, time-stamping and evidentiary value of digital signatures ..........................10
Document format and DigiDoc................................................................................11
Roles, authorizations and organizations' validations ...............................................12
New ideas: replacement and alternative cards .........................................................13
2
Status of the document
This document is prepared by AS Sertifitseerimiskeskus (www.sk.ee). You may
freely distribute it in original verbatim form (without making any changes). The
Estonian ID card project information, including the newest version of this whitepaper,
is available online at http://www.id.ee. You may contact us at info@id.ee.
Introduction
Estonia has implemented ID card as the primary document for identifying its citizens
and alien residents living within the country. The card, besides being a physical
identification document, has advanced electronic functions that facilitate secure
authentication and legally binding digital signature, in connection with nationwide
online services.
This whitepaper gives an overview of the principles behind the project and explains
the choices and decisions made while carrying out the card project. It also presents an
overview of how the associated services and applications are implemented.
Intended audience
The first part of the whitepaper, "Principles", is written for decision-makers and
potential common users from a legal and economic perspective. The second part,
"Solutions", is for implementers and assumes knowledge about basic PKI concepts.
Current project status
The first Estonian ID cards were issued in January 2002. In one year, more than 130
000 cards have been issued, and the total figure is expected to grow to more than 350
000 by the end of 2003 (about 25% of the whole population).
The card is meant to be universal and its functions are to be used in any form of
business, governmental or private communications. It is already helping people to
make everyday communications more convenient. You can find more details about
the implementation and applications below.
3
Principles
Digital signature regulation
Estonian parliament (Riigikogu) passed the Digital Signature Act (hereinafter DSA)
on March 8, 2000, and it entered into force on December 15, 2000. The law regulates
issues that are essential for implementing a nationwide PKI and digital signature
infrastructure. The law is available online at
http://www.legaltext.ee/text/en/X30081K3.htm.
Digital signature concept
According to the Estonian DSA, digital signatures are equivalent to handwritten ones,
provided that they are compliant with the requirements set forth in DSA and if other
laws do not regulate otherwise. Thus as a rule, digital and handwritten signatures
should be equivalent in document management in both public and private sectors.
DSA also states that public sector organizations must accept digitally signed
documents.
The requirements set forth in DSA to digital signatures state that digital signature
must uniquely identify the signatory, be bound to the signed data in such a way that
makes changing the data after signing impossible without invalidating the signature,
and identify the time of signing (assuming the use of time-stamping or equivalent
time establishment technology).
In the terms of EC directive 1999/93/EC, DSA only regulates advanced electronic
signatures. Other types of electronic signatures can of course be used, but DSA does
not give them legal power.
Certification Service Providers (CSP-s)
DSA regulates the work of CSP-s in Estonia, setting forth requirements to them and
regulating their operation and supervision. CSP-s may only be legal entities with a
regulated minimum share capital, they must be entered in the National Certificate
Service Provider Registry (see below) and must carry out an annual audit to ensure
organization and system reliability. CSP-s must also have liability insurance to
safeguard against compensating faults made while providing the service.
It is important to note that according to DSA, CSP-s certify only real persons
identifiable by name and ID code – issuing certificates to pseudonyms is not currently
covered by DSA. It was discussed in the parliament during the law adoption process,
but was considered to be an additional unnecessary risk and so far, no need for this
has been seen.
Time-stamping Service Providers (TSP-s)
DSA also regulates the work of TSP-s and the comparison of time stamps between
TSP-s. The requirements to service providers are generally the same as those to CSP4
s. According to DSA, a time stamp is simply a data unit that proves that certain data
existed at a certain moment. DSA does not define time stamps in more detail, but
states that they must be bound to the timestamped data and issued in such a way that it
would be impossible to change the timestamped data without invalidating the
timestamp.
Supervision – Registry and Ministry
The National Registry of Certification Service Providers contains data about all
Estonian CSP-s and TSP-s. Although it confirms the public keys of CSP-s, it is
technically not a root CA in Estonia. Instead, it functions as a supervisory authority,
confirming the results of service providers’ annual audits among other things. The
Ministry of Economy and Communications, in whose administration area the registry
works, has the right to verify audit results and inspect the service providers’ premises
and relevant information.
Foreign Certificates
DSA regulates the recognition of foreign certificates, stating that in order for them to
be recognized equivalent to those issued by Estonian CSP-s, they must be either
confirmed by a registered CSP, be explicitly compliant with DSA requirements or
covered by an international agreement.
Identity Document Regulation
Identity documents in Estonia are regulated by the Identity Documents Act. The law
is available online at http://www.legaltext.ee/text/en/X30039K7.htm.
Mandatory document
According to the Act, possessing an ID card is mandatory for all Estonian residents
and also for all aliens who reside permanently in Estonia on the basis of a valid
residence permit with a period of validity of at least one year. There are no sanctions
for not having a card, but it is expected that as the first Estonian passports were issued
in 1992 with validity period of 10 years and they are expiring, most people will apply
for either only ID card, or ID card together with passport when renewing their
documents in the period 2002-2006. By the end of 2006, one million cards will have
been issued.
There is only one version of the document: there are no different optional features that
users can opt out of or choose to (not) have. All documents are equipped with a chip
containing electronic data and certificates (see below). It is understood that some
users may have doubts or fears about electronic use of the card, but remedies are
provided for that: if users do not wish to use the electronic functions of their cards,
they can suspend the validity of their certificates, thus making it impossible to use the
card electronically. Certificate suspending or revoking also removes user's data from
public certificate directory.
Card appearance and layout
The card looks as follows.
5
Front side of the Estonian ID card.
Back side of the Estonian ID card.
The front side of the card contains the card holder's signature and photo, and also the
following data:
• name of card holder
• personal code (national ID code) of card holder
• card holder birth time
• card holder sex
• card holder citizenship
• residence permit details and other information (if applicable)
• card number
• card validity end
The back side contains the following data:
• card holder birth place
• card issuing date
• card and holder data in machine-readable (ICAO) format
Electronic data on card
Each ID card contains various pieces of data. All the above data except photo and
handwritten signature are also present on the card in electronic form, in a special
publicly readable data file. In addition, the card contains two certificates and their
associated private keys protected with PIN codes. The certificates contain only the
holder's name and personal code (national ID code). In addition, the authentication
6
certificate contains the holder's unique e-mail address. Read more about certificates
and e-mail address below.
Certificates
Each issued ID card contains two certificates: one for authentication and one for
digital signing. There are also two associated private keys, protected by two separate
PIN codes, on the card. The certificates contain no restrictions of use: they are by
nature universal and meant to be used in any form of communications, whether
between private persons, organizations or the card holder and government. They
contain no roles or authorizations: those most come using some out-of-band method
(also see below, "Roles, authorizations and organizations' validations").
The certificates contain the card holder's name and national ID code. It is agreed in
Estonia that this data is public by nature. The certificates identify the card holder
uniquely because even though there may be name overlaps, the national ID code is
unique. In addition, the authentication certificate contains the card holder's e-mail
address.
E-mail address
The authentication certificate on each ID card contains the card holder's governmentassigned e-mail address in the format firstname.lastname_NNNN@eesti.ee, where
NNNN are four random numbers. The random numbers are necessary to provide
unique e-mail addresses even to persons with the same name. The address does not
change with subsequent certificate or card issuing – it is guaranteed to be a person's
"lifetime" address.
There is no real e-mail service associated with the address. It is a merely a relay
address which forwards e-mails to users' "real" addresses (e-mail accounts). Each user
must configure the forwarding addresses using an online service made available for
this purpose, and may reconfigure the addresses as often as he or she pleases. Up to
five forwarding addresses can be specified.
The address is supposed to be used in communications from government to the
person, but it can also be used in communications between persons and companies
and private persons themselves. The addresses are available online to anyone through
CSP-s certificate directory.
The address can be used as a simple e-mail address, but using the address and the
authentication certificate on the card, users can also digitally sign and encrypt their email. The digital e-mail signature is not legally binding and not covered by DSA, but
it provides receivers additional confirmation of sender authenticity. E-mail encryption
and signing using certificates on smart card is a standard function of various e-mail
applications.
Anti-spam measures are implemented in the forwarding server. In addition, spamming
is illegal in Estonia and spammers will be prosecuted accordingly.
Data protection
The data protection question is not very relevant in the context of Estonian ID card
because there is very little private data involved in the card issuing and further
7
utilization process. There is a broad Personal Data Protection Act in effect in Estonia
which regulates the use of personal data and databases containing personal data by
public authorities and private entities, and Estonian Data Protection Inspection is the
government body overseeing that the requirements of the act are met and enforcing
compliance if necessary.
The certificates on the card are available publicly in a directory service and contain
only the card holder's name and personal ID code, which are considered public data
by nature in Estonia. In addition, e-mail addresses in authentication certificates are
also available in the directory. The directory contains only valid (active) certificates:
if a person suspends or revokes his certificate, it is also removed from the directory
and the data are no longer available.
The public data file is not published anywhere online. The personal data on the card in
visual and electronic format are accessible only to those persons to who the card
holder physically presents the card.
The general stance to ID card and data protection in Estonia is that the card should
contain as little private data as possible. Instead, the data should be kept in databases
at relevant authorities, and a person can use the card as key (authorization method) to
access his or her data in the database.
Organizational structure, card issuing and operation
The card issuing as well as its further operation is done in close public private
partnership. There are three main organizations who are associated with issuing and
operating the ID card and the associated infrastructure.
Estonian Citizenship and Migration Board (hereinafter CMB) is the government
organization responsible for issuing identification documents to Estonian citizens and
alien residents, as required in the Identity Documents Act. CMB is in the supervision
area of Estonian Ministry of the Interior. CMB receives the card application from
citizens.
AS Sertifitseerimiskeskus ("certificate centre", hereinafter SK), founded by two
major Estonian banks Hansapank and Eesti Ühispank and two telecom companies
Eesti Telefon and EMT, functions as CA, maintains the electronic infrastructure
necessary for issuing and using the card, and develops the associated services and
software. SK also takes care of delivering the card to its holder through Hansapank
and Eesti Ühispank bank offices.
TRÜB Baltic AS, subsidiary of Swiss TRÜB AG, is the company that personalizes
the card.
The card issuing process consists of the following steps.
1.
person fills in application for the card, indicating the bank branch office where
he or she would like to receive the card
2.
CMB receives application from person
3.
CMB stores the application and forwards its data to TRÜB
4.
TRÜB personalizes the card
8
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
TRÜB gives the card the order of generating private keys (internal function of
the card, the keys will never leave the card) and prepares the secure PIN
envelopes
TRÜB formulates certificate requests (2 per card) and forwards them to SK
SK issues the certificates, stores them in its directory and returns the
certificates to TRÜB
TRÜB stores the certificates and personal data file on the card chip
TRÜB prepares the final delivery envelope, enclosing the card, secure PIN
envelope and an introductory brochure
TRÜB hands the final delivery envelope over to CMB
CMB hands the final delivery envelope over to SK (CMB has outsourced the
card delivery to SK)
SK sends delivery envelope to the bank branch specified in the original
application (done using security couriers)
person receives the delivery (containing card and PIN codes in separate
envelopes) from the bank branch office
upon receipt of the card, certificates are activated and published in directory
For further operation of the card, SK maintains the associated electronic services
including an LDAP directory service, OCSP validation service and other necessary
services for online validity and digital signature confirmations. SK also provides the
software to anyone interested in creating applications to the card and digital signature,
and provides a readymade client and web portal for giving and verifying digital
signatures (see below, "Document format and DigiDoc"). In addition, SK maintains a
24-hour telephone hotline which can be used for immediately suspending the validity
of certificates in case of card loss or theft.
9
Solutions
Following are a number of issues and questions that have been solved when
implementing the Estonian ID card and digital signature infrastructure.
Certificate profiles and e-mail addresses
The certificates on Estonian ID cards are standard X509v3 certificates. The
authentication certificate contains the card holder's e-mail address. The certificate
profile is available in a separate document.
Certificate validity verification methods
According to Estonian DSA, CSP-s must provide "a method of verifying certificate
validity online". SK as the issuer of certificates to ID cards provides users three ways
of checking certificate validity.
CRL-s are provided, containing the list of suspended and revoked certificates. CRL-s
are standard but outdated method, because as of January 2003, CRL size has grown to
over 1 MB in one year and it is not very convenient to use. CRL-s are mainly
provided for backwards compatibility and standards compliance. SK updates its CRL
twice a day. Delta CRL-s are not provided.
The second method is an LDAP directory, containing all valid certificates. The
directory is updated in real time – if a certificate is activated, it is uploaded to the
directory, and if it is suspended or revoked, it is removed from there. Among other
things, this provides everyone a chance of finding the e-mail address of any ID card
holder. Restrictions are in effect as to the maximum number of responses returned to
one LDAP query to protect against server overload.
The most convenient method of verifying certificate validity is SK-s OCSP service. It
can be used for simple certificate validity confirmations, but also for validity
confirmations ("notary confirmations") to digital signatures. SK provides a standard
OCSP service compliant with RFC 2560. An important detail is that according to the
RFC, OCSP responses are supposed to be based on CRL-s and therefore may not
necessarily reflect the actual certificate status. In contrast, SK has implemented its
OCSP service in such a way that it operates directly off its master CA certificate
database and does not use CRL-s. Thus, SK-s OCSP responses reflect actual (realtime) certificate status. In terms of the RFC, the response's thisUpdate and
producedAt fields are equivalent.
OCSP, time-stamping and evidentiary value of digital
signatures
For legally binding digital signatures, time is an extremely important factor.
According to the Estonian DSA as well as common sense, only signatures given using
a valid certificate are to be considered valid. On the other hand, to provide remedy to
the risk that the signing device (ID card) may be stolen together with PIN-s and
digital signatures could be given on behalf of the user by someone else, users have the
chance of suspending their certificate validity using a 24-hour telephone hotline
operated by SK. With these two concepts combined, users must be able to clearly
10
differentiate the signatures given using a valid certificate from those given using a
suspended or revoked certificate. Thus, there is a need for a time-stamping and
validity confirmation service which binds the signature, time and certificate validity.
Another important concept concerning signature validity is that the signature must be
valid also when the certificate has already expired or been revoked. If a certificate is
suspended by the card holder or anyone else, the card holder can reactivate it at a
bank office.
A number of experimental time-stamping protocols and technologies have been
proposed, but no common understanding or agreements of time-stamping is present,
the experimental technologies are under constant development and not in mass use.
Thus, an innovative approach was needed. SK chose to base its time-stamping
implementation on standard OCSP. The protocol contains a Nonce field, which
protects against replay attacks. Instead of cryptographically random data, the Nonce
field is set to contain the hash of the data to be signed, because it can also be
interpreted as just a random number. According to the RFC, the OCSP responder
signs its response which in SK-s case, contains the original nonce (document hash),
response providing/signing time and ID of the certificate used to give the signature,
binding the three pieces of data together and providing the validity confirmation for
the digital signature. SK stores the signed response in its log as evidence material.
SK has implemented all of the above, including both client and server parts, in its
DigiDoc digital signature architecture.
Document format and DigiDoc
In order to bring digital signatures into everyday life, common understanding and
signature handling practices are required. In addition, software and technology must
be available for anyone interested, in order to create compatible applications. After
all, the key to unleashing potential digital signature benefits lies in communication
between organizations, not within one organization. Therefore, it is vital that all
organizations in a given community interpret and understand digital signatures the
same way. In case of Estonia, the community is the whole country.
A number of digital signature implementations and applications are available on the
market, all claiming to be suitable for specific purposes. However, no known
application or implementation of the latest standards was found which would suit the
needs of the Estonian project, and reliance on foreign software providers guaranteeing
the functioning of a country's everyday life relying on digital signatures can also be
seen as a strategic risk. Therefore, a whole new approach – and a whole new software
architecture – was needed.
In 2002, SK together with its partners created an all-around digital signature
architecture dubbed DigiDoc. As the name suggests, DigiDoc aims to meet all the
needs users might have about digital signature creation, handling and verification.
On the server side, DigiDoc provides an RFC2560-compliant OCSP server, operating
directly off the CA master certificate database and providing validity confirmations to
certificates and signatures. On the client side, it provides a number of components.
11
The most important component is digital document format, which is key to common
digital signature implementation and practice. As of 2002, a number of standards have
been adopted or are in preparation. SK based the DigiDoc document format on XMLDSIG standard. However, it has several shortcomings such as allowing only one
signature per document, and in February 2002, ETSI published its extensions to
XML-DSIG as ETSI TS 101 903, also known as XAdES. DigiDoc document format
is a profile of XAdES, containing a subset of its proposed extensions. The DigiDoc
format is described in a specification document.
Based on the document format, a library was developed in C language which binds
together the following:
• DigiDoc document format
• SK-s OCSP validation service
• Interfacing with the user's ID card using Windows' native CSP interface or
cross-platform PKCS#11
The DigiDoc library provides easy-to-use interfaces to all of the above and there is no
need for application developers to know OCSP protocol specifics or DigiDoc
(XAdES, XML-DSIG) format internals. It can be embedded in any application and on
top of it, a COM interface has been implemented, making it easy to add DigiDoc
support to any Windows application supporting COM technology. A Java
implementation is also provided.
However, providing the libraries and formats was not enough because these do not
add value to end users without real applications. Although it is expected that DigiDoc
support will eventually be present in most Estonian document management systems,
web sites dealing with documents etc, a number of example or "reference"
applications are also provided. DigiDoc Client is a Windows application that lets
users simply sign and verify documents, and DigiDoc portal is an application that lets
users do the same online without the need to install any stand-alone software.
Naturally, both are based on the same DigiDoc library and thus fully compatible –
signatures given in Client can be verified in portal and vice versa.
The libraries, specifications and applications are provided to Estonian public free of
charge, and it is expected that digital signature usage in common life and everyday
business and government practices will grow significantly already in 2003. The first
official digital signatures in Estonia were given using DigiDoc Client only on October
7, 2002, and implementing the digital signature on a national scale naturally takes
some time.
Roles, authorizations and organizations' validations
In connection with implementing PKI and digital signatures, the question of roles and
authorizations has arisen in various projects. It is assumed that certificates for digital
signing may be issued for specific purposes only, and that a person's roles can be
embedded in role certificates that are then used for authenticating the certificate
holder into different systems and giving digital signatures in different roles. Thus, a
person needs additional role and signature certificates for each different role he or she
has, and the number of certificates grows, creating substantial interoperability and
scalability issues.
12
The Estonian approach states (as also said in the Estonian DSA) that a digital
signature given using a digital signing certificate is no different than a handwritten
one. A person's handwritten signature does not contain his or her role – the role and
authorization are established using some out-of-band method (out-of-band in the
context of certificates). The same approach also goes for authorization while
authenticating – a person's certificate should not contain his or her authorization
credentials. Instead, everyone has a similar universal key (authentication certificate),
and the person's role and authorization can be determined using some other method
(e.g. an online database) based on that key.
An exception to the above is organization's validation. Digital documents sometimes
need to be validated by organizations, so that other organizations can be sure of the
identity of the organization where the document originated. This is useful for e.g.
signing pieces of databases (e.g. bank statements) online, to be presented to other
organizations. For this, SK issues certificates to organizations that can be used to sign
documents digitally. Technically, they are equivalent to personal signing certificates
on everyone's ID card, but legally, they are not viewed as signatures and need not be
covered by law, because according to the Estonian law, only real persons can give
signatures. The "organizations' signatures" must therefore be viewed simply as
additional tools for proving information authenticity (that it really originated from a
specific organization) which may or may not be accompanied by a digital signature of
a real person working in that organization. Still, the PKI complexity stops here, and
besides personal and organizational signature certificates, there is no need for
personal role certificates or anything else more complex.
New ideas: replacement and alternative cards
As of the beginning of 2003, a number of ideas are being discussed for improving the
availability and usability of digital signatures in Estonia. One of them is the
"replacement ID card", or backup card. The main concern here is that the card issuing
process described above is quite complex and according to current regulations, it may
take up to 30 days for a person from the moment of presenting the application to
receiving the card. If a card is lost or damaged and a person needs to get a new one,
this may mean that he or she may not be able to give digital signatures for 30 days
which may not be acceptable in some high-stake business environments. Therefore, a
possibility could be established that current ID card holders might get a "backup card"
to minimize the extent of the above problem. However, this is currently not
implemented, and another remedy for the problem is that the above organizations will
just implement an "express service" which would be more expensive but quicker
method of getting an ID card in the "normal" way.
Another idea is that of "alternative card". National ID card need not be the only
carrier of digital signing certificates. Some large companies are already using smart
cards for their internal services, and would like to have digital signing certificates
issued by SK to be added to their internal cards. The company itself would then act as
Registration Authority, and SK would be responsible for issuing certificates in
response to certificate requests, as is also the case with regular ID cards. Still, this
"alternative card" will remain a niche solution and for the general public, the Estonian
national ID card is the universal signing tool for whatever role a person may be acting
in.
13
Towards cross-border use of digital signatures between the Baltic States:
Work programme for 2014 Estonia’s chairmanship of the Baltic Council of
Ministers (BCM) in the area of ICT cooperation
The Baltic States are frontrunners in the adoption of secure electronic identity (eID) and
digital signatures domestically. Furthermore, the eID solutions of Estonia, Latvia and
Lithuania are built on similar principles. This provides a good starting point for joint use of
digital signatures in daily business and life between the three countries.
Cross-border digital signatures would be a key step for enabling cross-border use of digital
services, both public and private. This would make the conduct of business and movement of
people between Estonia, Latvia and Lithuania much easier. It would also allow the Baltic
States to lead the way in developing the Digital Single Market in Europe, especially in the
crucial area of trust services.
In order to realize these benefits, we aim to reach the following targets by the end of 2014:
 Estonian, Latvian and Lithuanian eIDs can be used together for digital signing;
 Estonian, Latvian and Lithuanian eIDs can all be used for cross-border authentication
in at least one pilot electronic service in each of the three countries;
 a longer-term roadmap for further cooperation and developments in the area of eID
and digital signatures – the intention should be to make legally valid digital signing
possible and simple for Estonian, Latvian and Lithuanian citizens and enterprises in all
of their everyday devices and solutions by 2016.
In order to reach the targets, the following discussions and steps are planned:
1) Mutual recognition and joint use of each other’s eIDs
There exist 2 main ways forward in this regard:
a) supporting each other’s eID certificates in each country’s authentication solutions, i.e.
building support for other countries’ eID into services (e.g. Latvian shared
authentication service or all main Estonian and Lithuanian e-service portals);
b) adopting in full the solution created in EU STORK project, for which three countries
need to make technical-level agreements. Estonia and Lithuania as STORK members
can assist Latvia in implementation with technical know-how.
As first step, each country will conduct a feasibility analysis of these two approaches from
their national perspective. The results will be discussed and the way forward determined
together with next steps at a technical experts’ meeting in March 2014.
1
Once the technical approach has been decided, the experts will discuss and agree on the
electronic services that each country will pilot the joint use of others’ eID with.
2) Mutual use of digital signatures
A short term and quick-win solution would be to build support of all three countries’ eIDs
into each country’s digital signing solutions. This requires technical level agreements, e.g. on
contents and exchange of Trusted-Service Status Lists, and then work and investment by each
country themselves. Another option to consider would be building the support for each other’s
main digital signature file formats into each country’s digital signing middleware and provide
easy-to-find information online on validation possibilities. Consideration should also be given
to how to support development of cross-border private services in the area.
A meeting of technical experts in March 2014 will map out all relevant details, discuss the
options and agree on the next concrete steps forward.
For the longer term, discussion needs to focus on digital signature file formats. We should
seriously consider the option of moving to the same or at least compatible digital signature
file formats in all three Baltic States. The aim should be to make cross-border digital signing
as easy as possible for users. At the same time, we have to avoid investing into solutions that
are due to become outdated, e.g. when the new EU regulation on electronic identification and
trust services (eIDAS) comes into effect. A meeting of technical experts in March 2014 will
launch in-depth comparative discussion of possible models, file formats and specifications
together with the required next steps.
3) Joint procurement and development of eID related solutions
Joint procurement and development of eID tokens, software solutions (e.g. signing clients),
etc. could be launched in longer-term future. The idea would be to join forces for better
solutions and savings through cost sharing, while making interoperability and mutual
recognition matters easier. These options will be discussed in policy level meeting in autumn
2014, as the substance will depend on outcome of discussions under other points.
In summary, the work programme for 2014 will be as follows:
 March 2014 – meeting of three countries’ technical experts to discuss and agree on:
o technical details for mutual eID support in digital signing solutions;
o the way forward with digital signature file formats;
o the way forward with mutual recognition and joint use of eIDs.
 Continuation meetings, agreements and domestic work in three countries as required.
 September/October 2014 – policy level meeting between three countries to take stock
of the results of previous activities and prepare the longer-term cooperation roadmap,
incl. way forward in joint procurement and development.
 November/December 2014 – reporting on the results of work programme to Prime
Ministers in BCM meeting and agreement on further cooperation roadmap.
2
This work programme was prepared based on the meeting of Estonian, Latvian and
Lithuanian policy officials and technical experts in Tallinn on 27 January 2014.
The work programme was discussed and endorsed by the informal meeting of the Prime
Ministers’ Council of the BCM in Tallinn on 3 February 2014.
3
UNIVERSITY OF TARTU
FACULTY OF MATHEMATICS AND COMPUTER SCIENCE
Institute of Computer Science
Computer Science
Aleksei Gorny
Analysis of Chip-card Based Authentication
Bachelor’s thesis (6 EAP)
Supervisor: Sven Laur, PhD
Author: .................................................................... ”........” June 2009
Supervisor: ............................................................... ”........” June 2009
Admitted to thesis defense
Professor ................................................................... ”........” June 2009
Tartu 2009
Contents
Introduction
3
1 Background and technical details
1.1 ID-card hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 The Transport Layer Security protocol . . . . . . . . . . . . . . . . . .
1.3 Software architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
5
6
8
2 Attacking the authentication process
2.1 Logging authentication codes . . . . . . . . . . . . . .
2.2 Logging authentication codes: implementation . . . . .
2.3 Phishing and substituting certificates . . . . . . . . . .
2.4 Phishing and substituting certificates: implementation
2.5 Session hijacking . . . . . . . . . . . . . . . . . . . . .
2.6 Session hijacking: implementation . . . . . . . . . . . .
.
.
.
.
.
.
11
11
11
12
15
16
17
3 Building a better driver
3.1 Security model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Suggested solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
19
20
References
21
Kiipkaardipõhise Autentimise Analüüs
23
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Introduction
Most chip card solutions for personal computers assume they are used in a secure environment and that the communication between the card and applications cannot be
modified. This assumption is largely unjustified, since most users lack technical knowledge to have sufficient control over their machines. Indeed, as yet another attestation
of the fact, earlier this year, a botnet comprising of approximately 1.9 million infected
devices, of which many belonged to government and business institutions, was discovered [15]. The scope of this work is the use of chip cards in untrusted environments.
The research has been conducted in accordance with the agreement between the author
and AS Cybernetica and some findings may have been left out from this paper version
due to contractual obligations.
For simplicity, we explain the basic concepts of chip card use by the example of the
Estonian ID-card. ID-card is the Estonian primary personal identification document,
issued by the national Citizenship and Migration board. As it is the case with national
chip cards of most countries, the card enables its holder to create digital signatures
and to authenticate to both state and private enterprise services. This functionality
can also be used online from a personal computer equipped with a smart card reader,
some third-party software and an internet connection. Important web-based services
accessible this way include electronic banks, e-voting polls, health and education related information systems etc.
In this work, we review the situation where a cardholder authenticates to a remote
server over a network. We show that due to implementation issues there currently
exists a way for a malevolent party with temporary user-privileged access to the cardholder’s computer to effectively tamper with the process. This may potentially result
in the honest user unintentionally authenticating to some other entity instead or the
server believing that the client resides at a different IP address. The consequences of
this may in turn include loss of privacy and personal data, financial losses and incorrect
depiction of the cardholder’s opinions and preferences to other entities.
In the following chapters we present a detailed overview of the authentication process
with the currently employed chip card software, describe possible attacks, evaluate
their feasibility and conclude by introducing obvious security-enhancing modifications
to the affected components. We also comment on the exploits as we implemented them
on the Ubuntu Linux operating system for demonstration purposes. The code itself
does not accompany this work, but is available on request from AS Cybernetica.
3
1
Background and technical details
Though the basic design principles of different chip cards are similar, specific cards
often have technical peculiarities and are subject to different standards and legislation.
In this section, we review the concepts by an example national chip card, the Estonian
ID-card. The development process of the card has been mostly open for public inspection and information found here can also be gathered from online sources.
Since the introduction of the ID-card to the public in 2002, the number of cardholders
and applications for the card has been steadily increasing. The Citizenship and Migration board reported that by the first of April 2009, there were 854 675 registered
ID-card owners, a large number, considering the population of Estonia. It is expected
that more than half of the cardholders use the card to access online services.
The reason ID-cards exist and are increasingly popular is the joint efforts of government institutions, security researchers and businesses. At the same time when the
Citizenship and Migration board became interested in replacing the passport with
a simpler modern identification document in 1997, researchers from AS Cybernetica
and Hansapank were working towards developing a solution for digital authentication
and signing. Eventually, the goals of both interest groups were united in the ID-card
and legislation was modified to accommodate electronic authentication mechanisms [5]
and acceptance of digital signatures [6]. Businesses and institutions were encouraged
to adopt ID-card based authentication methods and use digital signatures to reduce
paperwork and allow simple and secure digital access to various services, making it
favorable for citizens to switch to the new technology. The full timeline and the development story can be found at the ID-card support site [1].
As now, the card can be physically used for authentication in place of the passport
for travel in the European Union, customer cards of several Estonian shops and store
chains, library cards of most of the Estonian libraries, etc. A large list of web service providers allowing ID-card based authentication is maintained online [1]. The list
includes but is not limited to the following:
• Financial institutions: Swedbank, The SEB Group, Eesti Krediidipank, Sampo
Pank, Nordea Bank, BIG Bank, Parex Bank, Nasdaq OMX Estonian securities
market,
• Government services: the National Electoral Commitee, Estonian Motor Vehicle
Registration Centre, the Commercial Register, Estonian Tax and Customs Board,
• Education services: study information systems of the Tartu University and Mainor
Business school, the eKool system,
• Medical services: patient information systems of the East Tallinn Central Hospital and the Medicum health center.
For a cardholder, accessing these services from a personal computer is as easy as purchasing a smart card reader and installing software from the ID-card support page. The
necessary software consists of drivers for the card and the reader and extensions for the
browser that allow it to query the drivers to access the card functionality when needed.
4
What would happen if a vulnerability in the authentication process was found? Some
services like e-banks and e-voting polls would remain relatively secure from the functional standpoint, as they require digital signatures for finalizing critical transactions
like money transfer or vote casting. However, an attacker able to exploit such a vulnerability could still perform many potentially damaging, but non-critical operations
without the cardholder’s knowledge. Additionally, one could gain unauthorized access
to personally identifiable sensitive information contained in above-mentioned information systems, like financial status, health conditions, study grades, electoral preferences
etc. A possibility of large scale exploitation, for example, if the vulnerability was common to national chip cards of multiple countries, would serve as motivation for cyber
criminals and bear drastic consequences to card users.
In this chapter, we review the prerequisites for understanding the current state of
ID-card based online authentication. We look at the functionality the chip of the card
provides, the specification of the authentication protocol that is used and at how this
protocol is implemented in software.
1.1
ID-card hardware
From the hardware perspective, the Estonian ID-card is a chip card conforming to the
ISO-7816 standard [9] and based on the Orga Micardo Public 2.1 chip [7]. It hosts some
minor technical modifications that allow it to be used with a larger variety of smart
card readers and changes to the instruction set that forbid formatting and EEPROM
memory initialization. This way the card is better suited for wide-scale public use and
prevents users from deleting or improperly modifying important data it contains.
The data stored on the card and available operations are subject to a strict immutable
access policy. Significant objects accessible to a common user constitute of the cardholder’s personal information file, signing certificate and authentication certificate.
Figure 1: Objects on the ID-card. Translated from [3].
5
In addition to the operations for reading these objects, the card provides cryptographic
operations with internal secret keys – in the case of authentication, computing a response to a SSL/TLS challenge [13] using RSA or SHA1 with RSA. Cryptographic
operations require the cardholder to set different security environments on the card
by supplying appropriate PIN codes. Optionally, additional codes may be entered to
enforce the interaction between the card and host applications to be encrypted using
3DES.
PIN codes are protected from brute force attacks by counters of consecutive incorrect
entries. After three unsuccessful entries, a PIN is blocked and has to be revalidated
or replaced using the PUK code, that is itself subject to an analogous counter. The
PUK code can, however, be unblocked only at accredited Token Management Centers bank offices and the service offices of the Citizenship and Migration board. Other card
management operations, like updating user data and certificates, are also performed
under official supervision - either on-site and the centers or remotely over the network,
secured via cryptographic means. This again is beneficial for protection against unauthorized or accidental data modification and deletion.
For a full list of objects and operations supplied by the card, one may refer to its
reference manual [3].
1.2
The Transport Layer Security protocol
Transport Layer Security (TLS) [13], the successor of Secure Socket Layer (SSL) [14],
is a popular protocol for providing communication confidentiality and integrity by establishing a reliable private channel between two peers. TLS achieves its security goals
by using symmetric cryptography with unique keys generated for each connection and
message authentication codes. The TLS handshake sub-protocol provides a secure and
reliable way to negotiate the parameters of a connection and allows peers to authenticate to each other using asymmetric or public key cryptography. In a typical setting,
TLS dwells on an available public key infrastructure and is unilateral, meaning that
the server gets authenticated to the client, while the latter may remain anonymous.
Figure 2: Negotiation of anonymous or unilaterally authenticated TLS
In the first part of the TLS handshake, the negotiation phase (Fig. 2), the client and
the server agree on the strongest cipher suite and hash functions they both support,
exchange random values and agree on a common secret. During this phase, the server
6
usually shares its certificate with the user, who is expected to verify the server’s identity. If necessary, the server sends an additional message containing cryptographic data
allowing the client to communicate the premaster secret. Both parties then compute a
master secret key based on the premaster secret and random values. This key is used
for symmetric encryption of the final handshake messages and communication later on.
The handshake finishes with the peers validating its correctness. First, the client
informs the server that all of its following communication shall be sent encrypted using
the freshly computed symmetric key. Next, it sends an encrypted message containing
a MAC over the protocol transcript (Fig. 3). The server decrypts the message, verifies
the hash and responds with two analogous messages. Now, if either party fails to decrypt the received final message or verify the MAC inside, the connection is terminated
and has to be renegotiated. This ensures both peers agree on the generated security
parameters and keys and that the handshake has not been tampered with.
Figure 3: TLS handshake final messages
TLS also supports a bilateral mode, known as mutual authentication. In this case, the
client also sends out a certificate and afterwards proves that one indeed owns it by
showing one has access to the corresponding private key (Fig. 4). For this, the client
sends a certificate verification message, containing the concatenation of all previous
handshake interaction signed with the key. If the protocol is successful, then unlike
the unilateral case, both parties are assured of each other’s identity.
Figure 4: Negotiation of mutually authenticated TLS
After the handshake is finished, relevant data messages can be transferred in a way
similar to the final handshake message - encrypted with the negotiated symmetric key
7
and verified with a message authentication code.
TLS is one of the most common protocols for securing application layer data when
communicating over customized networks or the Internet. It can run on top of a reliable transport protocol such as TCP and beneath application layer protocols such as
HTTP, FTP, SMTP etc. TLS can also be used for creating virtual private networks
by tunneling the entire network stack. For our purposes, we are mostly interested in
the scenario where mutually authenticated TLS is used in combination with HTTP for
accessing various web services.
1.3
Software architecture
In practice, communication between a web service and a chip card passes through
multiple modularly composed software layers. The layers are similar for all operating
systems, so for conciseness we describe the detailed architecture as it is common for
Ubuntu Linux. Low-level operations, like communicating bits to and from the card, are
handled by a low-level driver for smart card readers, typically OpenCT [11] or PC/SC
Lite [12]. On top of the driver resides OpenSC [10], an open-source framework for
high-level operations with smart card tokens. It implements methods for recognizing
different card hardware and vendor-specific hexcode instructions.
For integration into existing applications, OpenSC compiles a dynamic library based
on the PKCS#11 standard [8]. PKCS#11, also known as Cryptoki, is a widely-used
standard for cryptographic token libraries that specifies common names for objects
and operations. This dynamic library interface is, for example, used by most of the
popular browsers, so that when the token is initialized, they are able to request data
and perform card-assisted cryptographic operations by communicating with the driver.
As an illustration, let us see how these components interact when a user attempts
to authenticate to a server using a capable chip card and TLS mutual authentication
(Fig. 5). In this case, the user’s browser takes care of the TLS protocol messages and
makes two requests to the driver. The purpose of the first request is to retrieve the
authentication certificate and the purpose of the second is to compute the response to
the protocol challenge using the secret key stored on the card and corresponding to
the certificate. As computing the response requires toggling the security environment
on the card, the driver expects the browser to obtain the PIN code from the user.
This architecture is secure under the assumption the user actually has full control over
the client machine. Indeed, an adversary is then unable to eavesdrop or modify the
communication between both the software and hardware components - effectively between the browser and the smart card. Also, properly executed mutually authenticated
TLS, as reviewed earlier, eliminates the possibility of client- and server-side identity
switching on the network.
The authentication process becomes insecure once we assume the adversary has temporary user-rights level logical access to the machine. Note, that on modern operating
systems, this type of access is sufficient for local installation of software packages and
browser extensions, but does not allow to change preferences of the system itself or
files of drivers and properly installed applications.
8
Figure 5: Authentication with a chip card
The main problem lays in the fact that the relation between the TLS session the
user is attempting to establish and the challenge message send to the driver is never
verified. This implies that in customized software, the PIN code of the user may actually be used for computing the a challenge response for another session. This problem
is not unique to any particular chip card, but common to all chip cards used with this
software framework.
An example exploit for this would be a custom browser extension that hijacks chip
card based authentication sessions by sending the driver challenges that are different
from the intended ones (Fig. 6).
Figure 6: A malicious browser extension
For a second example exploit, temporary access can be used for local installation of a
malicious Cryptoki-based library. Here the attacker can rely on the fact that pointing
out the location of OpenSC to the browser needs user rights only. The substitute
library could then act as a mediator between the browser and the chip card and perform
operations like publishing PIN codes, modifying user queries or establishing unwanted
TLS sessions (Fig. 7).
9
Figure 7: OpenCT is substituted for a malicious library in the browser
For the cardholder, the consequences of these exploits may be as severe as mentioned
in the beginning of this chapter. Note that active presence of the adversary that introduces software modifications is not necessary in either case. After the software is
changed, session hijacking and other activities, for example using the hijacked session
for gathering personal data, can happen in an automated fashion.
10
2
Attacking the authentication process
In this chapter, we review some attacks associated with authentication and evaluate
their successfulness and feasibility against chip-card based authentication. These attacks can be conducted by cyber criminals or otherwise malevolent individuals against
honest users using chip cards or other methods to authenticate to some entity over a
network. For each attack, we first give its general description and explain its background and then reflect on our experiments with it in practice.
2.1
Logging authentication codes
Keystroke logging in general refers to a practice of noting the keys pressed on the
keyboard, often without the computer user’s knowledge. It is a common method for
obtaining sensitive data from a user when the adversary has physical access to the machine or is able to either install or convince the user to install custom software. There
are various mechanisms for logging keystrokes, ranging from software based solutions,
for example hook based loggers that utilize the operating system functionality to subscribe to keyboard events, to acoustic and electromagnetic loggers that log the pressed
keys based on the physical behavior of the keyboard.
Countermeasures against this attack include drivers with signed code, anti-spyware
applications able to detect loggers either by their activity or resident files and alternative data input methods like speech-to-text applications or on-screen keyboards.
Key logging is effective against standard username and password combination authentication, but does not, for example, work against one-time-password methods, where
a password is rendered obsolete once it is used. Against two-factor authentication
methods, like the chip card based approach, key logging does succeed in collecting
PIN codes. However, the codes on their own are useless without the ownership of the
physical token.
One can circumvent the additional protection added by two-factor authentication, if
one knows the PIN code and is able to partially control the machine at the time the
chip card is inserted. Large scale attacks of this type, where the adversary has collected
several PINs and has control over the user machines, are, however, rather unlikely due
to the need for synchronization and in any case much more difficult then simple password logging. Session hijacking, an approach discussed later on, is a variation of an
automated attack against chip-card authentication, which does not rely on logging the
PINs, but instead utilizing them for chosen operations in real-time when the user is
trying to access some of the card’s functionality.
2.2
Logging authentication codes: implementation
For implementing a PIN logger, we wrote a simple patch to the OpenSC library. The
patch modified the function for forwarding the codes to Micardo cards. When the
function was accessed, it wrote down the PIN to a file on the hard drive (Fig. 8).
11
Figure 8: The PIN logging setup
Summary. This modification was trivial to write, once the correct place in the driver
code was located and the custom C structures used understood. Both tasks require
minimal knowledge of the C language. For setting up the logger up on the client computer, it is necessary to have temporary user- privileged access to either locally compile
or transfer a pre-compiled modified version of OpenSC to some chosen location on the
machine and point the Firefox browser to use it. This can be done via adding the
library directly to the secmod.db file stored in the browser user profile folder, adding it
via the browser graphical interface or adding it from a webpage using Javascript hooks
for handling PKCS#11 libraries.
The exploit enables an attacker to gather chip card PIN codes entered by the users of
the infected machines. To guard against this, the browser should secure the secmod.db
file storing the locations of token libraries by requiring administrative rights or alternative authorization for its modification. However, this might be hard to implement
and maintain in practice, as in multi-user machines it often makes sense for users to
have different token libraries installed.
2.3
Phishing and substituting certificates
The term phishing describes the process of a malicious entity masquerading as a trustworthy one in electronic communication, in attempt to acquire sensitive information
or involve an unsuspecting user in unsafe transactions.
For example, a user may receive an email or an instant message claiming to be from a
bank and requesting for some reason to reply with the password to the e-banking service
or follow a link to a webpage hosting a fraudulent password entry form. Alternatively,
a user browsing the web may, due to network anomalies or webpage vulnerabilities, be
redirected to a fake website that visually resembles some legitimate site, but employs
different functionality. The general mechanisms of phishing are well explained in [19].
Due to its relative technical simplicity and high success rates, phishing is a popular
form of electronic crime. PhishTank [17], one of the major phishing-report collators,
reported a monthly average of 6000-8000 websites positively identified as phishing sites
in the first months of 2009. Preventive measures to combat phishing include user education, spam filters that filter out phishing emails by general characteristics and publicly
12
maintained blacklists of servers that often host fraudulent websites. The prevalent reactive approach is issuing site take-down notices based on verified used reports.
One of the solutions browsers provide to remedy the problem is employing public
key infrastructure (PKI) to verify the server’s identity. PKI refers to a binding between the public key of a host and the host’s identity, established by the means of
a trusted authority. The authority verifies the authenticity of the binding claim and
issues a certificate to confirm it. In practice, an individual or a company interested
in obtaining a verified certificate for one’s webpage typically generates an appropriate
certificate request and forwards it to a commercial authority. The authority then takes
the necessary steps to verify that the webpage really belongs to the claimant, charges
for the service, and signs the request with its private key. For other parties to be sure of
the authenticity of the signature, the authority provides a self-signed certificate issued
to its own name. It is obvious, that these self-signed certificates have to be distributed
to the users in a secure manner, since if a malicious authority gets to be trusted, all
webpages certified by it will be seen as trusted as well. Modern browsers ship with a
built-in list of audited popular certificate authorities, so webpages certified by these
authorities are trusted by default. Trusted pages are typically identified by a padlock
displayed in a dedicated area of the browser’s graphical user interface (Fig. 9).
Figure 9: A padlock displayed in the lower right corner of the Firefox browser when
connected to a webpage with a trusted certificate
Firefox makes a clear distinction between authority certificates, private keys corresponding to which can be used for signing other certificates, and simple server certificates and has default assumptions about their trustworthiness. If a webpage aiming
to establish a secure connection presents a certificate signed by an authority unknown
to the browser, the user is shown an option to mark the domain name as a security
exception. An exception like this does not, however, grant trust to the certificate authority that had signed the freshly accepted certificate. This means exceptions set this
way are valid on per-domain basis only and cannot be used for gaining implicit trust
for websites not visited by the user.
Certificates still leave several problems open. First of all, due to organizational hurdles, browsers often contain certificates crafted using encryption or hashes that have
been rendered insecure by recent cryptographic research. For example, at the time of
13
writing, the latest version of Firefox for Mac OSX, Firefox 3.0.10, still had ca. 15%
of its about 150 built-in certificates using the MD5 hash function. MD5 was proved
not to be collision resistant by 2004 by the latest [20] and the fact was exploited to
fake certificate validity in practice in 2008 [21]. Firefox also holds several MD2-based
certificates, although MD2 is considered broken as well [25]. Second, as the number
of certificate authorities has grown, it has become increasingly easy and cheap to get
a domain name certified. There have been reported cases of well-known authorities
issuing certificates for arbitrary domain names without proper ownership verification.
As a result, a certificate alone cannot serve as an adequate indication of the website’s
identity.
Extended validation certificates, a concept developed by the certificate authority and
browser forum [16], add additional visual cues (Fig. 10) for convincing browser users
that the viewed page can be trusted. Before issuing such a certificate, the authority
has to take extra steps to verify the trustworthiness of the requesting party. The steps
include establishing the legal identity and the operational and physical presence of the
website owner, verifying ownership and control status for the domain name in question
and confirming the identity and authority of the individual representing the website
owner. The list of EV certificate authorities in the browsers cannot be modified using
trivial means.
Figure 10: A green address bar and additional information on a webpage with an EV
certificate
Studies of the effectiveness of visual notifiers of both common and EV certificates seem
to indicate, however, that uneducated users still find it hard to distinguish between
legitimate and untrustworthy sites and tend to ignore security warnings. For example,
see [18].
In our model, where we assume the adversary to have user-priveleged access to the
machine, all browser-related anti-phishing protection can be effectively circumvented.
The adversary can, for example, add self-generated certificates for arbitrary domains or
untrusted certificate authorities to the browser’s safe list, so chosen webpages would appear secure to the user. Alternatively, the adversary can just install a browser extension
that changes the graphical user interface of the browser so visual cues corresponding
to certified or EV-certified webpages would appear without actual grounds.
In regard to phishing, two-factor authentication methods like chip-card based authentication seem to have an obvious advantage over simple knowledge factor methods like
14
username and password combinations. By this we mean that since authenticating with
a chip-card requires both ownership of the physical chip card and the knowledge of the
PIN codes, then even if an adversary learns the PINs, one will not be able to establish
an authentication session to a third entity. The best one can achieve is to present a
user with fake functionality, which either simply deters the user from accessing some
real system or prompts the user to disclose further sensitive data and perform unsafe
transactions, for example issuing digital signatures for documents created by the adversary.
Some security experts have argued that two-factor authentication methods are inherently insecure against man-in-the-middle phishing attacks, where the malicious server
simply forwards the changing part of the authentication credentials is to the legitimate
server in real-time [22]. This may be true for one-time-passwords, but does not hold
for chip cards. Indeed, here the changing credential, namely the response to the TLS
challenge, depends on the identities of the peers participating in the protocol, as it is a
signature over all protocol messages, including the certificate messages of both peers.
Now, the adversary does not know the secret keys of the legitimate server and the chip
card, so if it forwards the certificate of the legitimate server to the client, one will not
be able to decrypt later communication. On the other hand, if the client is presented
with a different certificate, one will not be able to respond to the TLS challenge of the
legitimate server based on the user’s response. This again shows that in the case of
chip cards, phishing itself does not allow the adversary to authenticate to a third party
using the client’s credentials.
2.4
Phishing and substituting certificates: implementation
As a target website, we chose a site of a widely used information system. The particular choice was motivated by several reasons. First of all, the site has acquired its
certificate from AS Sertifitseerimiskeskus, an Estonian certificate authority not trusted
by default in Firefox. This implies, that for a first-time user, the webpage displays an
appropriate warning anyway, prompting to add a security exception for its certificate.
Sertifitseerimiskeskus does not issue EV certificates, so there is no visual indication of
the connection being secure, except for the standard padlock. Second, the information system offers optional chip-card based log-in, so we were able to play through the
phishing scenario with card based authentication.
Note, that as described in an earlier section, phishing alone is not sufficient to mount
a man-in-the-middle attack against the chip-card based authentication. Still, it can be
successfully used to provide fake functionality, deter the user from accessing the actual
system and obtain sensitive data via web-forms. In the case of our information system,
the attacker could use the fake website to request the user to update personal details
or preferences and prevent the user from accessing the time-critical functionality of the
legitimate system.
For the set-up, we generated a certificate chain consisting of three certificates having the same human-readable parameters as in the original chain using the OpenSSL
console utility. We then set up a wireless router with a fixed DNS entry for the domain
of the information system, pointing to a dedicated server computer, a Ubuntu desk15
top with the Apache 2.2.8 web server extended by mod ssl 2.28 and OpenSSL 0.9.8g
modules (Fig. 11). The server was configured to require a secure connection with
optional client authentication accepting chip cards, display a page visually similar to
the original and present the fake certificate chain.
Figure 11: The phishing setup
This situation corresponds to a scenario where the adversary gets hold of the configuration of a public WiFi access point or sets up a rogue access point. In most local
switched networks, the situation can also be achieved by successful ARP or DNS attacks that grant a man-in-the-middle status to the attacker. Based on the resulting
user view, we believe an incorrectly installed certificate makes it fairly easy to fool even
a technically competent user into thinking a connection to be legitimate.
As a side-note, during the course of our work we discovered that the server of the
information system was vulnerable to the automated HTTPS cookie hijacking attack
[24] and notified its adminstrators.
Summary. The attack requires the experience of generating and manipulating OpenSSL
certificates with various parameters, configuring a web server and creating simple webpages. It also requires the ability to lure the user to the set-up page, either by effectively
gaining man-in-the-middle status on the local network, poisoning entries of DNS servers
or using standard phishing practices like spam and social engineering. For creating an
illusion of a secure interaction, the attacker needs user-privileged access for adding
certificates to the victim’s browser.
Typical methods to combat phishing are described in the previous section. However,
even with good user training, it can be difficult to recognize that a fake webpage is
being served instead of the original one, when the look-and-feel are almost identical and
the browser displays visual security cues. In addition to using standard methods, one
can install additional extensions to the Firefox browser, that try to correctly identify
websites based on secondary parameters like behavioral differences in different sessions
etc.
2.5
Session hijacking
Session hijacking refers to the scenario, where a party attempts to establish a communication session with a certain entity, but an adversary-controlled session under the
name of this party is established with some other entity instead, possibly without the
victim party’s knowledge.
16
Session hijacking scenarios vary depending on the underlying technologies, in this section we will concentrate specifically on chip-card based authentication.
2.6
Session hijacking: implementation
The general idea of our exploit was to modify the OpenSC driver or specifically the
part of it that handles the functionality of Micardo cards to turn to an external script
when the challenge response computing operation was called. The script would then
initiate a TLS connection to some chosen remote server and switch the challenge bytes
sent to the card (Fig. 12).
Figure 12: Hijacking the TLS challenge request
The implementation process worked out as follows. We wrote a simple python script
that created a HTTP connection over TLS. For handling the TLS protocol, we used
a public domain python library tlslite [23], which we had to modify in order to
accommodate token-based client authentication. It was worth the effort though, as in
addition to taking care of the protocol, the library provided our sample script a convenient interface for later requests to the server. We then introduced changes to the
part of OpenSC concerned with the challenge response computation of Micardo cards.
The changes consisted of bindings using python/C API, so that our script was called
once the operation was accessed. The script initialized a connection to a chosen server
and returned the bytes needed to be signed to the driver, which took advantage of the
user’s authorized status to obtain a valid response from the chip card. The script then
used this response to complete the authentication to the server.
For testing the implementation, we used the same server software setup as in the
previous section. This time, the server was assigned a self-signed certificate and configured to require client-authenticated SSL/TLS on the index page and log all visits.
After the setup, we opened Firefox, linked it to the modified OpenSC and tried to
access the information system introduced in the phishing section. Indeed, our server
17
logged a successfully established secure connection and a HTTP-GET request to the
index page.
Summary. In theory, the attack requires only superficial understanding of the structure of the OpenSC driver suite and sufficient programming skill to write a script
interacting with a webpage via HTTP queries and to bind this script with an appropriate TLS library. In our case, some time was spent on linking the script and OpenSC
and on extending tlslite. As this was a proof-of-concept implementation, we also
made some simplifications: the script would only react to the signing event of Micardo
cards and a specific subset of possible cipher suites and fixed TLS protocol behavior was
chosen, so that the script would work with our server. These technical restrictions can
be overcome by spending more time on testing the TLS library with different servers
and testing OpenSC with different chip cards. For deploying the modified library, the
same methods can be used as in the case of the logging application. For users to guard
against the attack, we again recommend the current situation with the database file
storing locations of dynamic token libraries to be reviewed.
All in all, we believe it is moderately easy for an experienced programmer to develop
a session- hijacking module for all OpenSC-supported chip cards that can be extended
to communicate with chosen servers. This module could work in a covert manner and
activate with a certain probability, so that the only indication of its presence would
be the once in a while increased latency and connection failures when authenticating
online. The latency obviously results from the need to establish a new connection after the browser has contacted the driver. For additional stealth, the script could act
depending on the speed of the internet connection and seize its operations after a fixed
timeout. In our test case, the internet connection was fast enough for the script to go
unnoticed to a typical user.
The shortfalls of our current approach are the need for local compilation and the resulting dependence on the environment. Implementing the session hijacker as a browser
extension, as described in the first chapter, would solve these problems, as Firefox aims
to be a cross-platform browser. We started developing such an extension, but the task
grew rather complex. This came from the fact that Firefox provides many options for
extending browser functionality, but not always for modifying the existing one. For
example, graphical user interface components and their behavior can be easily replaced
or overloaded, but determining whether the next connection shall be mutually authenticated TLS is non-trivial. Nevertheless, such an extension can surely be engineered,
for example if it is to target authentication attempts to specific websites based on the
URL address. With the current policies for developing browser extensions, there would
be no way to guard against the attack but to monitor the list of the activated extensions in the browser. This list is implicitly stored in the user’s browser profile folder,
so an example solution would be an automated administrative process monitoring this
folder.
18
3
Building a better driver
By now we have shown, that the solution for smart card based authentication employed
as now may be vulnerable to certain types of misuse, most notably, session hijacking.
In this section, we investigate whether it is possible to change the current software and
hardware architecture so the implementation improves with respect to security against
the above-mentioned attacks. For this, we first formalize the strongest security we can
achieve assuming the operating system core and drivers cannot be compromised. We
then discuss the feasibility of changes that bring the architecture closer to the defined
security goal.
3.1
Security model
One can view a computer network as consisting of physical entities - network nodes
and computers - and logical entities, the users of physical devices (Fig. 13). We assume
that each physical entity is used by a single logical entity at a time. If necessary, servers
and other multi-user devices can be seen as groups of multiple network nodes. In our
model, the adversary is mobile, meaning it is able to dynamically corrupt any number
physical entities for arbitrary periods of time. The adversary is also assumed to have
full control of the network traffic.
Figure 13: A computer network abstraction
The goal of entity authentication protocols is to establish an association between physical and logical entities. In practice, if a protocol is successful, it is followed by a
communication session, as seen in the example of TLS. It is obvious, that if the adversary has compromised a network node, one can modify the contents of this session.
However, it is unclear, whether the adversary can still modify the session once one
has lost control over the node. Also, it is unclear, whether the adversary can force
the user to authenticate to some entity other than the user intended even if one has
control of the user’s node. This motivates us to say, that the architecture of a device achieves maximal security with respect to a entity authentication protocol if the
following conditions are met.
19
• The adversary cannot under any circumstances force a user to authenticate to
some other entity unintentionally.
• When the adversary does not actively control either of the physical endpoint
nodes, it cannot modify the content of the communication session.
One can see, that due to the possibility of hijacking attacks described in the previous
section, the current architecture of the chip card related software stack does not provide
maximal achievable security with respect to TLS.
3.2
Suggested solutions
There do indeed exist authentication schemes that provide the security level defined
above. Consider a network, where the device hardware is secure and all network cards
contain internal secret keys. When establishing an end-to-end connection, the operating systems of these devices specify only the physical address of the communication
partner and negotiate a TLS channel using the available infrastructure. The distribution of public keys does not have to be authentic, that is, the adversary can generate
key pairs, that claim to belong to some other address. Additionally, every client device
has a chip card reader with a pin pad and a display. For client authentication and
application data transfer, another TLS channel is created between the chip card and
the server. The display shows the user of the client machine excerpts from the TLS
protocol, notably the identity of the server and its certificate authority. It is easy to
verify that this configuration achieves the maximal achievable security. Indeed, the
display makes sure the user does not authenticate to any other party unintentionally.
Due to the end-to-end physical communication channel, the adversary looses the ability
to modify or listen to the communication session messages on withdrawal. However,
such a configuration is surely infeasible because of the organizational costs.
Let us see how we can achieve the security goals by improving on the technologies
used today. First, we need to eliminate the possibility of the attacks with a substitute
chip card library. This can be achieved by protecting the link between the browser
and the library by administrative rights. The second step is to transfer the client-side
mutual TLS protocol handling functionality to the driver level. This means giving up
the modularity of the software stack and engaging in browser- level protocol based
software proxying, but this way the TLS challenge is guaranteed to belong to the correct session, as it is computed by the driver based on its own communication. As the
graphical user interface of the operating system can be manipulated by locally installed
malicious applications, its authenticity generally cannot be verified, so an appropriate
security measure for securing PIN input and assurance of the peer’s identity in the TLS
protocol could be a physical pin pad reader with a display from the previous example.
The display would again show the user the appropriate parts of TLS messages, notably
the domain name of the peer and the certificate authority by whom its certificate was
signed.
Such changes can be implemented with reasonable means: some developing work on
the current software solutions and engineering of a custom pin pad reader. Purchasing
the latter would translate into additional costs to a single user, but surely make up in
the gained security.
20
References
[1] The ID-card support site. http://id.ee
[2] ID Süsteemide AS. EstEID Turvakiibi rakenduse kasutusjuhend, 2007.
http://id.ee/public/EstEID_kaardi_kasutusjuhend.pdf
[3] ID Süsteemide AS. EstEID Turvakiibi rakendus ja liides, V2.01.
http://id.ee/public/EstEID_Spetsifikatsioon_v2.01.pdf
[4] AS Sertifitseerimiskeskus. Sertifikaadid Eesti Vabariigi isikutunnistusel, 2004.
http://www.sk.ee/file.php?id=364
[5] Isikut tõendavate dokumentide seadus, RT I 1999, 25, 365. Up-to-date version
available at http://www.riigiteataja.ee/ert/act.jsp?id=742623.
[6] Digitaal-allkirja seadus, RT I 2000, 26, 150. Up-to-date-version available at
http://www.riigiteataja.ee/ert/act.jsp?id=694375
[7] Sagem Orga GmbH. Micardo 2.1 Chip Card Operating System Manual.
[8] RSA Laboratories. PKCS#11 Cryptographic Token Interface Standard.
[9] ISO/IEC 7816 standard for electronic identification cards with contacts.
[10] The OpenSC smart card driver framework, version 0.11.8, with libopensc 2.0.0.
http://www.opensc-project.org/opensc/
[11] The OpenCT smart card reader driver framework, version 0.6.14.
http://www.opensc-project.org/openct/
[12] PC/SC Lite
http://pcsclite.alioth.debian.org/
[13] RFC 5246. The Transport Layer Security (TLS) Protocol Version 1.2, 2008.
http://tools.ietf.org/html/rfc5246
[14] A. O. Freier, P. Karlton, P. C. Kocher. The SSL Protocol Version 3.0, 1996.
http://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt
[15] Finjan security. How a cybergang operates a network of 1.9 million infected computers. http://www.finjan.com/mcrcblog.aspx?entryid=2237
[16] CA / Browser forum. http://www.cabforum.org
[17] The PhishTank phishing report collator. http://www.phishtank.com
[18] C. Jackson, D.R. Simon, D.S. Tan, A.Barth. An Evaluation of Extended Validation
and Picture-in-Picture Phishing Attacks. In proceedings of the Workshop on Usable
Security, 2007.
[19] T. Moore, R. Clayton. An empirical analysis of the current state of phishing
attack and defense, In Proceedings of the 2007 Workshop on the Economics of
Information Security, 2007.
21
[20] Xiaoyun Wang, Dengguo Feng, Xuejia Lai, Hongbo Yu. Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD, 2004.
[21] A. Sotirov; M. Stevens, J. Appelbaum, A. Lenstra, D. Molnar, D. A. Osvik, B. de
Weger. MD5 considered harmful today, 2008. Available online at
http://www.win.tue.nl/hashclash/rogue-ca/
[22] B. Schneier. The failure of two-factor authentication.
http://www.schneier.com/blog/archives/2005/03/the_failure_of.html
[23] The tlslite python TLS library. http://trevp.net/tlslite/
[24] M. Perry. Automated HTTPS cookie hijacking.
http://fscked.org/blog/fully-automated-active-https-cookie-hijacking
[25] L. R. Knudsen, J. E. Mathiassen. Preimage and collision attacks on MD2, Lecture
notes in computer science, Volume 3557, 2005.
22
Kiipkaardipõhise Autentimise Analüüs
Aleksei Gornõi
Bakalaureusetöö (6 EAP)
Kokkuvõte
Enamik kiipkaardiga töötavatest rakendusest eeldab vaikimisi, et liidestus kaardi ajuriga
ei ole pealtkuulatav ning et sellele saadetavad andmed pole muudetavad. Selline eeldus
pole üldjuhul mõistlik, sest tavakasutajal puuduvad vastava turvataseme tagamiseks
vajalikud tehnilised teadmised. Antud lõputöö käsitleb kiipkaartide autentimisfunktsionaalsuse turvalist kasutamist olukorras, kus pahatahtlikul kolmandal osapoolel on
olemas ajutine kasutajaõigustega ligipääs kaardi omaniku masinale.
Selleks uurime kõigepealt võimalikke ründeid teoreetiliselt, lähtudes standardsetest
lahendustest rakenduste ja operatsioonisüsteemide arhitektuuris. Seejuures loeme igasuguse kiipkaardi-vastase ründe edukaks, kui see ei nõua ründajalt jätkuvat aktiivset
osalust ning kui ründe käigus kasutatakse kaarti selle omaniku tahte vastaselt.
Teiseks, implementeerime vastavad ründed konkreetsel platvormil, mis koosneb Ubuntu
Linux operatsioonisüsteemist, OpenSC kiipkaardi-ajurist ning veebilehitsejast Mozilla
Firefox.
Kolmandaks, määrame, millised muutused mainitud platvormi komponentides tagavad
maksimaalse turvalisuse kasutaja-privileegidega ründaja vastu.
23
STORK / STORK 2.0: QAA-model and eID
eHealth Governance Initiative eID Workshop
11th February 2013, Brussels
Robert Scharinger
STORK2.0 WPL 5.4 eHealth
Austrian Ministry of Health
Stork 2.0 is an EU co-funded project INFSO-ICT-PSP-297263
BACKGROUND STORK 1
Quality of Authentication Assurance (QAA) and eID
Stork 2.0 is an EU co-funded project INFSO-ICT-PSP-297263
2
Government eID projects …
• Early birds started late 1990’s early 2000
 Finish eID card:
December 1999
 Estonian eID card:
from January 2002
 Austrian citizen card: from 2003, mass-rollouts 2005
 Italian CIE / CNS:
test phase 2003 (CIE)
 Belgian eID card:
from 2nd half 2003
National eIDs landscape
• Heterogeneous in various dimensions
 Technology
o Smartcards:
AT, BE,EE, ES, FI, GE, IT, PT, SE,
…..
o Mobile eID: AT, EE, FI, LU, NL, NO, UK, …
o Soft certif.: ES, SE, SI, …
o usern./pass.:
NL, UK, …
 Operational
o Issued by public sector, private sector, combined
o Issued at federal, local, regional level
o Use of identifiers
 Legal
o (limited) use of identifiers; flat, sectoral, combined
One problem tackled: Trust levels
Different technologies
and security levels:
•
•
•
•
Smart cards
Software certificates
Mobile Phones
Username-password
STORK QAA levels
(Source: STORK D2.3 – Quality authenticator scheme)
Stork 2.0 is an EU co-funded project INFSO-ICT-PSP-297263
6
STORK: eID profile of STORK countries (phase 1)
Technical factors influencing STORK QAA levels
Country & credentials
Token Types
Relation to 1999/93/EC
# of
cred.
Smart
card
mobile
eID
soft.certif.
qualified cert
Austria
3
yes
yes
-
Belgium
1
yes
-
Estonia
2
yes
Germany
1
Finland
Token Issuer
is a SSCD
public sector
private sector
all
all
yes
yes (all. qual.c.)
-
all
all
yes
-
yes
-
all
all
yes
-
yes
-
-
optional
all
yes
(opt. qual.certs.)
1
yes
-
-
qualified
all
yes
-
Iceland
2
yes
-
-
all
all
-
yes
Italy
2
yes
-
-
all
all
yes
yes (sig.-card)
Lithuania
1
yes
-
-
all
all
yes
-
Luxembourg
3
yes
yes
-
all
all
-
yes
Portugal
1
yes
-
-
all
all
yes
-
Slovenia
3
yes
-
yes
all
yes (QAA 4)
yes
yes
Spain
1+80
yes
-
yes
all
yes (QAA 4)
yes (QAA 3-4)
yes (QAA 3-4)
Sweden
12+
yes
yes
yes
-
tbc
yes
yes
(signature-cert)
Organisational factors
influencing STORK QAA levels
(Source: STORK D2.3 – Quality authenticator scheme)
Stork 2.0 is an EU co-funded project INFSO-ICT-PSP-297263
8
Technical & organisational
assessment of STORK QAA levels
(Source: STORK D2.3 – Quality authenticator scheme)
Stork 2.0 is an EU co-funded project INFSO-ICT-PSP-297263
9
Approach: Mapping to QAA levels
STORK I success story
• Six pilots live as “pioneering applications”
– Online authentication
– Safer Chat
– Student Mobility
– eDelivery
Affili
– Change of Address
ate
– ECAS
Example Austria: STORK Service
Signature “mobile phone signature”
• Developed during STORK
– Zero-footprint full-fledged eID
– Qualified electronic signature
– No changes on phone or SIM
• Key success
– Started piloting Q3 2009
– Full production in major
Austrian applications
(tax) in May 2010
– Promotion July 2012
– Outperforms smartcard eID
activation since Jan. 2011
Stork 2.0 is an EU co-funded project INFSO-ICT-PSP-297263
12
DEMO
– European Commission Authentication Service
» Authentication portal for EC staff and external
» Implemented an PEPS to link to STORK
• SEE IT RUNNING AT https://circabc.europa.eu
Stork 2.0 is an EU co-funded project INFSO-ICT-PSP-297263
13
STORK 2.0
Stork 2.0 is an EU co-funded project INFSO-ICT-PSP-297263
22
Introduction to STORK project
Main achievements
Implemented from 2008 to 2011, STORK Pilot A achieved to establish a
European eID Interoperability Platform that allows citizens to establish
new e-relations across borders, just by presenting their national eID.
• Common specifications
• Common code
• Framework for sustainable
deployment at a pan-European level
23
STORK 2.0 project
STORK 2.0
Secure idenTity acrOss
boRders linKed 2.0
3 year duration:
from 2012 to 2015
19 participating
countries
58 partners
24
Political framework
The Digital Agenda & its eGovernment Action Plan
2011-2015, ISA Work Programme (2009/922/EC),
the European Directive on Electronic Services
 address the importance of pan–European interoperability & of eIDs
as key enablers for eGovernment Services and for strengthening the
Digital Single Market
 stress the development and use of a pan-European infrastructure
for eID for citizens and businesses.
25
The Vision
STORK 2.0 will contribute to the realization of a single European
electronic identification and authentication area by:
– building on the results of STORK
– establishing interoperability of different approaches at national
and EU level, eID for persons, eID for legal entities and the
facility to mandate
26
Objectives
Accelerate the
deployment of
eID for public
services
Maximize the
take-up of its
scalable solutions
throughout the
EU
Seek & showcase
uses of eID for the
authentication of
both legal and
natural persons
throughout the
EU
Test in real life
environments
secure and
easy-to-use eID
and attribute
solutions in 4
relevant crossborder pilots
27
Work packages in STORK 2.0
Work packages
WP1
WP2
WP3
WP4
WP5
5.0
5.1
5.2
5.3
5.4
WP6
WP7
WP8
Description
Project Management
Existing Infrastructures & Resources
Legal & Trust Analysis
Common specs & Building Blocks
Pilots
Pilots Coordination
eLearning & Academic Qualifications
eBanking
Public Services for Businesses
eHealth
Pilots Evaluation
eID as a Service Offering
Marketing, Communication & Dissemination
WP Leader
Atos
IST
TIME.LEX
MINHAP
Atos
ES UJI
BUAS
IC
TUG
VKA/HEC
BUAS/UK CO
SU
28
STORK 2.0 Pilot
WP 5.4 eHealth
eHealth - Objectives
• The pilot is fully in line with Key Action 13 “Undertake pilot actions to
equip Europeans with secure online access to their medical health
data by 2015” of the Digital Agenda as well as with the patients’ right
of getting access to their personal medical data in crossborder
healthcare as a topic in the EU Directive 2011/24/EU.
• The pilot leverages the existing STORK infrastructure to processing
medical data, i.e. an area with the highest data protection
requirements due to special categories of data that receive particular
protection under the Data Protection Directive 95/46/EC.
29
STORK 2.0 Pilot
WP 5.4 eHealth
eHealth - Partners
Austria
Belgium
Italy
Slovenia
Sweden
Switzerland
Turkey
United Kingdom
(TUG)
(FEDICT, HEALTHCONNECT)
(LISPA)
(MoHRS)
(SU)
(BUAS)
(TUR)
(UK CO, YAP)
30
STORK 2.0 Pilot
WP 5.4 eHealth
(Source: STORK2.0 M5.4.1 – Draft eHealth Pilot Requirement Definition)
31
LSP Collaboration
• Interaction with the other LSPs building on gained
experience and lessons learned
• Close liaisons foreseen with epSOS for integrating
STORK 2.0 solutions for eID-based authentication with
eHealth infrastructure
• New: eSENSE
32
• Visit STORK 2.0 website www.eid-stork2.eu !
• Subscribe to STORK 2.0 Newsletter!
HOW TO GET
INVOLVED…
• Participate & “like” Stork eID Facebook page!
• “Follow” us on Twitter @StorkEid !
• Connect to Stork 2.0 EID LinkedIn page!
• Register in STORK 2.0 online groups!
• Contact us at info@eid-stork2.eu !
33
Thank you for your attention!
robert.scharinger@bmg.gv.at
Stork 2.0 is an EU co-funded project INFSO-ICT-PSP-297263
eServices in Estonia: a success
story
A Secure Identity Alliance Visit Report
June 2014
Table of Contents
Table of Contents
1. Executive Summary ...................................................................3
2. The history of eServices in Estonia ............................................5
3. Key Success Factors ...................................................................6
4. Estonian eServices in action ......................................................9
5. Case Studies ............................................................................13
5.1. Case study #1 Income tax returns ..................................................... 14
5.2. Case study #2 e-Police ....................................................................... 14
5.3. Case study #3 Elections ..................................................................... 14
5.4. Case study #4 National census .......................................................... 14
5.5. Case study #5 ePrescriptions ............................................................. 14
5.6. Case study #6 eHealth services .......................................................... 15
5.7. Case study #7 Energy smart grids ...................................................... 15
6. Looking to the Future...............................................................16
7. Concluding observations ..........................................................16
June 2014 • eServices in Estonia: a success story
2
1.
Executive Summary
At the end of April 2014, the Secure Identity Alliance undertook a three day visit to Estonia to meet with
key players in the eGovernment and eServices ecosystem. The aim was to identify how eID, authentication
and the interoperability framework that underpins eGovernment in Estonia has enabled the creation of
state-of-the-art eServices and built the all important trust between citizens and government that has
powered the take-up of these services.
Universally recognized as one of the advanced electronic administrations in the world, Estonia’s
comprehensive e-Services platform has fundamentally changed how citizens access basic, daily services
from both the public and private sectors.
e-Government in action
The Estonian e-Government centralized system has two key aspects.
First, its data architecture allows agencies and private-sector entities
to retain their own records rather than combining all data on
centralized servers. Second, access is provided through a secure
nationwide electronic ID system. Users simply swipe their physical ID
cards through a reader and then enter their personal ID number.
Recently Estonia has added secure mobile access via smartphones.
This digital infrastructure has enabled a digital society to blossom,
transforming interactions among government agencies and between
the government and its citizens. As a result e-Services have become
a routine aspect of everyday life, with almost 100 percent of public
services for both businesses and citizens now available online: eelections, e-policing, e-healthcare, e-banking, e-tax filing and eschools are all standard practice.
Estonia: Fact File
Population: 1.3 million
Mobile Penetration:
128%
Internet Penetration:
78%
ID Card: Compulsory
Other eDocuments:
DigiID, Mobile ID,
Passport, eStamp,
Driving License, Resident
Permit
eID providers: Police and
Today, Estonia’s e-Government platform allows access to more than
Border Guards
550 e- and m-services. Citizens can register for unemployment
benefit, file for parental leave, undertake property registration, utilize
notary services, access digital medical records, and order prescription-drug renewals online – and more.
The implementation of e-Government has revolutionized citizen/government interactions in Estonia; in
2011, 94 percent of all personal income tax returns were submitted online and 25 percent of votes in the
last parliamentary elections were cast over the Internet.
“The only thing you can’t do online is get married or buy a house! However, contracts for these
activities can be generated online, ready for download and signature when you visit the public
notary’s office.”
Annela Kiirats, eGovernance Academy, Estonia
June 2014 • eServices in Estonia: a success story
3
Powered by eID
The Estonian e-Services ecosystem is underpinned by eID. In 2002 the first nationwide eID card was
launched to all Estonian citizens and aliens residing within the country. A multifunctional card containing
both visual and electronically accessible information, the eID acts as a regular identity document, can be
used to generate digital signatures, and also operates as an access key to eServices.
In 2010 two new derivations of the eID card were launched: a digi-ID (the first ‘pure’ identity document
that establishes a person’s identity in an electronic environment and can be used for digitally signing
documents) and a Mobile-ID (the second ‘pure’ identity document which allows citizens to use a mobile
phone as a form of secure electronic ID to access secure e-Services and digitally sign documents).
All transactions that take place over the X-Road (the Government’s interoperable ICT data distribution
architecture) are made possible using e-ID/digi-ID/Mobile-ID identification, giving people the confidence
that the person on the other side is the person they say they are, and that the digital signature is real and
will stand up in a court of law when necessary.
X-Road is the backbone of ‘e-Estonia’, allowing the nation’s various e-Services databases - both in the
public and private sector - to link up and operate in harmony. Launched in 2001, the X-Road data exchange
layer is a technical and organizational environment which enables secure Internet-based data exchange.
Both public and private sector organizations can connect their information systems with X-Road, giving
both institutions and citizens the ability to securely exchange data, and access data maintained and
processed in state databases.
Sharing expertise and learning
The SIA found a striking level of transparency in the Estonian eGoverment system. Indeed, Estonia has
already moved beyond eGovernment to the beginnings of true e-Democracy.
All the key agencies we met in Estonia strongly welcomed the new eIDAS Directive for European
interoperability and security, stating their belief that security levels should not be lowered.
“American Cloud players request you sign the ‘conditions of use’, just like a marriage contract.
When you marry, you sign up too, but you don’t know what for!”
Jaan Priisalu, Director General, Estonian Information System Authority (EISA)
Eager to collaborate, cooperate and share the practices that underpin its implementation of government
eServices, Estonia is only too happy to cooperate with other countries looking to initiate e-Government.
The SIA recommends that any country on the brink of making the move to e-Government should spend
some time visiting Estonia to see for themselves how the country’s eGovernment infrastructure and
eServices operate.
A number of countries have already taken advantage of Estonia’s development cooperation outreach
project, which is coordinated by the country’s e-Governance Academy, to discover how they could go about
delivering better, more transparent public services. In 2013 Estonia welcomed 250 international delegations
and is currently exporting its X-Road data exchange layer to several countries.
June 2014 • eServices in Estonia: a success story
4
2.
The history of eServices in Estonia
When Estonia first became independent in 1991, its leaders faced a
grim reality. As small country, with limited resources, the government
took the conscious decision to build an open e-society – a cooperative
project involving government, business and citizens that create a
brighter future for all. Estonia wanted to make bureaucracy a thing of
the past, ensuring that all levels of government ran more efficiently
than before. It also wanted to create a better community for citizens
and enable a prosperous environment for business and
entrepreneurship. To achieve this vision, they decided to use local IT
companies and make use of the standard Internet to digitize services.
In this decade, legislation was passed that would pave the way for
the creation of the national ID card and the X-Road platform; both
would be critical to developing the digital society systems that were
to come.
Estonia passed the Digital Signatures Act in 2000 and standardized
the national Public Key Infrastructure (PKI). Meanwhile the X-Road
data exchange layer became the basis for the creation of a new estate and the in 2002 the first electronic IDs were implemented.
Today every person over 15 years of age is required to have an IDcard; in addition to establishing an individual’s identity in an
electronic environment, the ID-card can also be used by Estonian
citizens as a travel document.
In general, all decisions taken in the development of the national
eServices program were based on pure pragmatics – the population
and the country’s resources where not overly abundant. It was
therefore critical to come up with something clever and future
proofed.
Estonia based its e-Services digital infrastructure on the Internet and
avoided the creation of separate and specific data networks to ensure
its people have constant access to the services built for them. It also
launched the innovative ’Tiger Leap’ project to seed technology savvy
skills among Estonia’s citizens to prepare them to use the developing
digital society systems that were to come. Today, Estonia ranks
among the most wired and technologically advanced countries in the
world, with free WiFi connections nationwide delivering direct access
to public and private eServices.
Key Milestones
1992: Personal Identity
Code (PIC)
1992
Population
register (holds PIC)
1996: Internet bank
authentication (1st elD )
2000:
Digital
Signatures Act
2002:
ID
card
introduced,
certificates,
PKI (2nd elD)
2007: Mobile ID system
comes online (3rd eID)
2009: Concept of digital
documents
2009: DIM becomes the
responsibility
of
the
Ministry of the Interior
2010: DigiID (1st “pure”
digital identity document)
2011: Mobile ID (2nd
“pure”
digital
identity
document)
2014: 4,000 e-Services
provided by the public and
private sector
2017 (?): Use of biometric
credentials: state issued
max
5
years
valid
compulsory ID document
from 15 years age. Usable
for visual and electronic
authentication.
The other crucial step taken was raising the awareness of the
population and promoting the use of the ID card. Introducing people
to the idea of using technology and e-services was done in stages –
for example, 10 percent of the adult population tried their first e-skills
out registering for national events, such as the Estonian Song
Festival, which became their gateway ’first experience’ of eServices.
June 2014 • eServices in Estonia: a success story
5
Public Internet access points were built at 500 locations in Estonia, such as libraries and post offices, to
cater for citizens with no access to the Internet at home or who do not own a computer. In addition, the
government-backed technology investment body - the Tiger Leap Foundation -ensured that all Estonian
schools were online by the late 1990s. Children and young people encounter electronic communications as
soon as they enter school. In a sense, e-school acts as a technological and educational partner for
Estonians.
Today the e-school system allows parents, students, teachers and school administrators to connect. Exam
marks, assignments and attendance in class are all available to parents at the click of a mouse.
Since the first eID cards were inaugurated in 2002, a total of 152 million documents have been signed by
means of digital signatures (as of March 2013) and 246 million authentications have been undertaken.
3.
Key Success Factors
All too often the success of e-Government in Estonia is attributed to the ‘green field’ situation or the small
scale of this tiny country. But what makes this country interesting is not just that people can elect their
parliament online, or get tax overpayments back within two days of filing their returns. It’s that is that the
level of service citizens today enjoy did not result by the government simply building a few websites.
Instead, Estonia took the decision to redesign its entire information infrastructure from the ground up with
openness, privacy, security and ‘future proofing’ in mind. Its vision was to combine all day-to-day
transactions and processes into one e-government infrastructure that’s easy to use and productive.
To maximize the successful evolution of digital-democracy, Estonia established an e-Governance Academy
– a non-governmental, non-profit organization established by the Government of Estonia, the Open Society
Institute and the UN Development Program – to increase the awareness and capability of Estonian local
governments in the implementation of open, transparent and engaging governance and the sharing of best
practices.
‘A can do, will do’ mindset
A strong political will to develop a convenient and transparent society, based on ICT, was the starting point.
Political leaders worked closely with the ICT community to implement initiatives that would support the
creation of a minimal, highly efficient state.
Viewed as a force of progress, the promotion of e-Government was widely supported by officials and the
private sector. This positive viewpoint led to the launch of initiatives such as the Tiger Leap program, which
provided information technology to schools in the 1990s.
The first building block was the introduction of a unique ID methodology across all systems – from paper
passports to bank records to government offices and hospitals - that identifies every citizen. To enable
citizens to transact with one another, Estonia passed the Digital Signatures Act in 2000 and introduced a
standardized national Public Key Infrastructure (PKI) which binds citizens’ identities to their cryptographic
keys – making a signature, a signature in the eyes of the law.
June 2014 • eServices in Estonia: a success story
6
Private public partnership
To accelerate innovation, the state tendered the building and securing
of its digital signature-certificate systems to private parties – a
consortium led by local banks and telecoms. Public and private players
can also access the same data exchange system (X-Road), enabling
truly integrated e-Services.
In 2002 the government introduced eID-cards to support online
transactions. At that time 57 percent of Estonian Internet users were
using Internet banking. This trust in e-banking helped to seed the
take-up of eID verification system which would enable government
services to work online.
Banks cooperated with the government to reap the benefits of
convenient and secure eID. Smartcard ID readers were distributed to
customers free of charge by banks, enabling them to authenticate and
transact online, and banks became hubs in the government network.
For banks, the advantages were clear: utilizing the highly secure
National ID was free and minimized the need for them to maintain or
manage an ID database – it’s the reason why increasing numbers of
retail and loyalty companies today utilize the government’s eID.
“‘People may not trust their government, but they trust their
bank. The early popularity of online banking was a gateway
for gaining acceptance of eGovernment services within the
population.”
Mary Pedak, Estonia’s eGovernance Academy
Estonia: creating
an information
society
100% of schools
government
organizations are
equipped
and
ICT
97% of businesses use
computers
76% of families have a
computer at home
75% of homes
broadband
have
78.6% use the Internet
(15-74 years)
93% of tax declarations
in 2013 were submitted
online
99.6%
of
banking
transactions
are
performed online
63% of people use
electronic versions of
Acts and laws
Keep it simple – but logical
1140 free WiFi areas
The foundational 2002 law forced all decentralized government
systems to become digital ‘by demand’ – no part of the government
can turn down a citizen’s digitally signed document and demand a
paper copy instead. Yet a social worker, in a small village, can still
provide the same service by handling the small number of digitally
signed email attachments the office receives.
In other words, Estonia did not try to change the way things are done
on paper overnight – instead, implementation has evolved, with
citizens and businesses receiving incentives to utilize eServices where
they exist.
“Instant access to the
Internet has become a
social right.”
Anna Piperal, ICT
Center
“Everything takes ten years.”
Mary Pedak, Estonia eGovernance Academy
June 2014 • eServices in Estonia: a success story
7
Everything hinges on the provision of a compulsory national ID card to citizens at a reasonable cost, and
full process automation: for example, when a child is born the birth certificate is automatically generated
by the hospital; by the time the mother returns home, the benefits she is entitled to are already in her
bank account.
More recently, a Mobile-ID service has been launched, giving Estonians the option of using their mobile
phone as a secure electronic ID. The system is based on a specialized Mobile-ID SIM card which users must
request from their mobile phone operator. Without installing additional hardware or software users can
access secure systems and affix their signatures by simply typing a mobile ID PIN code into the phone.
Transparent, open and accountable
The movement of data between systems relies on a fundamental principle to protect people’s privacy. In
Estonia, the citizen owns his or her data and retains the right to control access to that data. For example,
in the case of fully digital health records and prescriptions, people can assign access rights to the general
or specialized doctors of their choosing.
In scenarios where citizens can’t block the state from seeing their information – such as a policeman using
a real-time terminal – they’re able to get a record of who accessed their data and when. If, having visited
the online portal, a citizen sees a government official has accessed their personal data without good reason
they are able to file a complaint online and initiate an inquiry. The unauthorized access of citizen data is
punishable by law; individuals may lose their job or go to jail.
Incentivizing citizens
Alongside educating citizens on the benefits of secure ID in relation to the convenience and ease of access
to government and private sector eServices such as banking, the government has also introduced a number
of ‘soft handcuff’ style incentives to promote the acceptance and use of secure eID.
For example:
secure eID is required for any monetary transfer of 200 Euros or more
in 2007 all businesses were required to use the e-tax system exclusively and paper filing was abolished
citizens utilizing the e-Tax board to file their returns online are guaranteed to obtain any tax refund
within 3-5 days.
The introduction of the ID bus ticket proved – after e-banking – to be the second major trigger that
incentivized people to apply for ID cards: for example, the Municipality of Tallinn offers a 30 percent ticket
price discount for ID holders and today 90 percent of Estonians hold an ID-card.
Creating an open, decentralized system
The Estonian e-digital society has been made possible by the creation of an open, decentralized system
that links together various services and databases. The flexibility provided by this approach has enabled
new components to be developed and added.
June 2014 • eServices in Estonia: a success story
8
The interoperable ICT distributed architecture means that each Government agency has its own database.
Utilizing a “only-once” principle, no government agency is allowed to ask a person for information that
another government institution already has asked for.
“IT is about saving time and this is what we do: automate processes. Governments should use
budget crisis to move to eGovernment. X-Road was created because of the lack of Money in
Estonia. You also need to solve the ID issue; without ID, nothing works. Transparency is key
and you need to define interfaces between agencies.”
Jaan Priisalu, Director General, Estonian Information System Authority (EISA)
International collaboration
Estonia is now starting to provide citizens of other countries access to its own secure and convenient eServices. A virtual, or e-residency, service is being launched that will provide electronic identity in the form
of a digital ID to non-residents, including:
expatriates
foreign clients of banks
members of companies’ governing bodies
scientists and consultants
students
e-enthusiasts
Friends of Estonia.
4.
Estonian eServices in
action
Technical Overview:
Estonian eServices
Model: Centralized
eServices in Estonia are divided into three categories,
dependant on the status/role of the user:
•
citizen
•
entrepreneur
•
official.
Each citizen has a unique ID and may have several roles.
As a result, their access rights are determined by their
roles.
eID providers: Police and Border
Guard
PKI: Yes
Population Registry: Yes
Biometrics: No
Program access: Card reader, mobile
Certification Authority: SK (joint
venture between banks and telecom
operators)
June 2014 • eServices in Estonia: a success story
9
The Estonian ecosystem
In Estonia the Ministry of Economic Affairs and Communications holds political responsibility for the
development of the state information policy. It elaborates the state's economic policy and development
plans, and drafts legislation bills in a variety of fields - including informatics and the development of state
information systems.
The Estonian Information System Authority (EISA) is under the authority of the Ministry of Economic Affairs
and Communication. The Authority's mission is to "coordinate the development and management
information system so that Estonian citizens are served in the best possible way". It oversees the
coordination of all Public Key Infrastructures related to the operation of ICT and Information Technology,
such as the state portal www.eesti.ee, the middleware system X-Road, the Government backbone network
EEBone, the administration system of the State information system (RIHA) and the electronic document
exchange centre (DVK). It is also responsible for state information system development projects and the
preparation and participation in international projects. Finally, EISA monitors the legislation process
concerning the management information system requirements.
The Police and Border Guard Board, issuer of the ID-Card, is under the authority of the Ministry of Interior.
In March 2013, the Police and Border Guard Board had issued over 1.2 million active ID cards.
A total of 246 million authentications and 152 million digital signatures have been made (March 2013).
Source: Mark Erlich, Estonian Information System Authority
June 2014 • eServices in Estonia: a success story
10
ID-Card
In January 2002, Estonia started issuing national ID cards. The card, which fulfils the requirements of
Estonia’s Digital Signatures Act, is mandatory for all Estonian citizens and residing foreigners over 15 years
of age.
Applications can be made on line, and the card acts as the primary document for identifying citizens and
residents. It can also be used in any form of business – governmental or private and is a valid travel
document for domestic travel and movement within the European Union. In January 2007 the card, which
is issued by the Citizenship and Migration Board, became valid for five years (previously it was valid for 10
years).
The card contains advanced electronic functions that facilitate secure authentication and provide a legally
binding digital signature for public and private online services. An electronic processor chip contains a
personal data file, a certificate for authentication (along with a permanent email address: Name/Surname
@ eeesti.ee for eCommunications with the public sector), a certificate for digital signature and their
associated private keys, protected by PIN codes.
In other words, the chip carries two certificates: one for legal signatures and the other for authentication
when using a website or service that recognizes the government’s ID system (online banking, for example).
The certificate contains only the holder’s name and personal code (national ID code). The data file and
certificates are valid only for the duration of the identity card and thus have to be renewed every five years.
“There has been no fraud in 12 years. Estonia is the only country in the world where all IDs have
the same legal value. This is a powerful incentive for use.”
Helar Laasik, Chief Expert, Estonian Police and Border Guard Board
eID, digi-ID and mobile-ID – what’s the difference?
Technically they’re all the same; the only thing that differs is the issuance and identity management
process. State issued certificates (the mandatory national card) are issued by Police and Border Guard
Board and there are a number of services that require this state issued identity document for access; for
example, you can't vote or access some services with a mobile-ID that is not issued by the state.
Digi-ID is an additional token for electronic use only (it can’t be used as a physical document for travelling
like an ID-card) and is founded on the same concept: a pair of keys, certificate, same identity management,
etc. The level of eID penetration in Estonia has reached a point where people are required to use their eID
to do their daily work; issuing of digi-ID takes less than an hour as pre-produced cards are used (only the
physical identification and certificate issuing process takes time). Examples of how digi-ID is being utilized
by citizens include:
doctors working in hazardous laboratories can bring things into the workspace, but can’t take them out:
they need an additional token they can leave at work
if someone loses their ID-Card they can’t wait for weeks for a new one and can use an additional token
at work
June 2014 • eServices in Estonia: a success story
11
people who don’t want to use their personal identity document (the ID-card is a physical mandatory
document that can also be used as a travel document) as a working tool have the option of using a digiID instead.
The Estonian PKI mobile-ID has been developed as a convenient solution on a SIM card for authenticating
and digital signing. The mobile ID solution is used for both public and private eServices.
Certificates are issued by Police and Border Guard Board (http://www.politsei.ee/en/) to the user (a
certification authority acts on behalf of Police). First the user has to apply for a mobile-ID from his mobile
operator, to get special SIM card and apply for the appropriate certificates from the police (we call this a
following process for the activation of mobile-ID). The police system checks if the user is allowed to apply
for a mobile-ID and sends information to the certification authority (CA) which then checks if the application
data is correct (that given phone number is connected to the individual, for example) and the public key is
sent to the CA. When the certificate is issued, it is stored on a public repository and not on a SIM; the CA
is using an SMS service, which has a limitation on amount of data, as a communication channel. All
processes are automated and applications prefilled and can be done over the Internet (the user needs an
ID-Card to apply and sign digitally).
Charging for the state ID system has been kept low to encourage maximum citizen uptake and usage. The
ID-card price is 24.28 Euros, which includes 10 e-transactions; and mobile-ID costs 60 cents, with limited
transactions. Businesses are charged for all their e-transactions.
Currently uptake on mobile-ID remains low; it is mostly being utilized by mobile users keen to overcome
the no-reader obstacle. But mobile operators, in conjunction with the SK certification authority, are about
to launch a number of initiatives to further its adoption.
SK – Estonia’s primary certification authority
SK is Estonia’s primary, and currently only, certification authority (CA) providing certificates for the
authentication and digital signing of Estonian ID Cards.
Established in 2001 by two leading Estonian banks (Hansapank – a member of the Swedbank group, and
SEB) and two telecom companies (EMT and Elion) following the adoption of the digital signature law a year
earlier, this private company provides certification services for the state (the Estonian Ministry of the
Interior). Its services include:
certification and time stamp services for the ID-Card
technology for digital signature (the DigiDoc system is widely used in Estonia for storing, sharing and
digitally signing documents); checking certificate validation/file encryption
validation services
consultation services.
SK is paid by the Estonian government to issue certificates, and receives payment from private sector
eServices providers for transaction signing/verification services.
Aware that eID is a long term business, SK is also in charge of incentivizing the population to take up the
use of e-signature and eServices.
“We’re in the business of changing people’s behaviors!”
Tarvi Martens, Development Director, SK Certification Center
June 2014 • eServices in Estonia: a success story
12
X-Road provides a distributed, secure, unified web-services based inter-organizational data exchange
framework. Built to satisfy the highest security requirements, X-Road does not centralize the data and does
not change the ownership of the data.
Designed with no single point of failure, all components of the system can be doubled for resiliency against
failures and attacks. Components available over shared or public network employ protective measures
against denial of service (DoS) attacks.
All web-service requests and responses are digitally signed, time stamped, encrypted and archived by
security servers. Adapter servers - a custom component that implements the web-services that will be
shared via X-Road – contain the business logic of the particular X-Road service. The adapter server will
query the registry or information system using a suitable protocol (SQL, EJB, SOAP, etc.) and transform
the results back into a web-services response.
The platform for an adapter server can be freely chosen by the organization to suit its existing platform
and IT policies; adapter servers have been successfully implemented on .NET, JEE, Python, various ESB
and other platforms. The adapter server also includes a developer toolkit which consists of source codes,
manuals, and templates for developing a needed adapter.
X-Road is an open source software. This means that its owner knows the code it contains and no one from
the outside has the power to set its own limits or regulations, or change something in its structure.
In effect the eID is just the key to the data, which is stored at the service side. Each database is separate,
making fraud more difficult. The data itself is secured by a solution developed by Guardtime. To review
more about the technical structure of X-Road, visit www.ria.ee/x-road/
5.
Case Studies
Today around 3,000 eServices are available in Estonia: 600 government-to-citizen and 2,400 governmentto-business services.
From the top down, Estonia has embraced an open yet secure e-Society approach. In August 2000, the
Government changed its cabinet meetings to paperless sessions, using a web-based document system. By
2004, five information systems from five different government institutions were made interoperable so that
parental benefits could be delivered as an eGovernment service. Today, new parents can log onto the state
portal, register their child, select a link to the relevant state benefits and simply add their digital signatures
to complete the process.
The penetration of eServices has been enormous; today nearly 99 percent of all banking transactions are
done online in Estonia. Here we take a look at how eServices have changed the way people live their lives
and do business in Estonia.
June 2014 • eServices in Estonia: a success story
13
5.1.
Case study #1
Income tax returns
First launched in 2000, today 95 percent of all income tax returns are completed via the e-Tax board.
Citizens can log into the system and review the data which appears in a pre-filled form, implementing any
necessary changes before submitting their declaration. In countries where tax returns are still submitted
on paper it can take up to two days to collect the data and complete the form. The Estonian e-Tax system
enables citizens to complete their return in less than 10 minutes. The motivation for people to complete
their income-tax declarations online is that it is convenient, free-of-charge, provides pre-completed
information which is extracted from employers monthly tax reports – plus the government guarantees to
pay back overpaid tax in just five days.
5.2.
Case study #2
e-Police
Every police car is equipped with a mobile workstation that allows police to submit queries to police related
databases – including the Traffic Insurance Fund, the Motor Vehicle Registration Center, the Weapons
Register and the Population Register. Queries can also be submitted to Europol, Interpol and Schengen
Zone’s information system. All of which ensures that if a driver is pulled over there is a good reason. The
e-Police system also plays a role in wider-scale prevention work: for example, reminding owners if their
car is due a check-up. All of which adds up to faster response times, decreased road fatalities, and increased
security on the roads.
5.3.
Case study #3
Elections
In Estonia, voters can cast their ballots from any Internet-connected computing. The i-Voting system is
proving a powerful way to attract more people to participate in elections, especially the younger generation,
those that travel, soldiers and citizens not permanently domiciled in Estonia. The system eliminates the
need to visit a polling station or search out an embassy when travelling or living abroad. In 2013, 25
percent of all votes were cast over the Internet.
The online voting service adopts all the principles of paper voting, offering a convenient alternative to the
paper ballot. Digital voter registration is based on the national population register, with voters’ identification
being confirmed using eID.
5.4.
Case study #4
National census
Estonia holds the world record for census participation via the Internet. In January 2012, Statistics Estonia
held the first e-census in the country and 66 percent of the population completed their census form online.
The e-census questionnaire, which consisted of over 100 questions, was completed by 1.29 million
permanent residents.
You can find out more about the e-census program and its success factors at http://eestonia.com/estonian-e-census-winning-trust-and-breaking-world-records/
5.5.
Case study #5
ePrescriptions
More than 90 percent of medicines prescribed in 2011 were e-prescriptions. Today, citizens can get a
prescription renewal over the phone, e-mail or Skype; if a patient calls their doctor on the way to the
pharmacy, by the time they reach the counter their prescription is waiting for them. Patients can select
their specific brand of a prescribed medicine, as GPs simply fix the active medicine substance. For
pharmacies it has meant the end of having to decipher handwritten prescriptions, while licensed doctors
June 2014 • eServices in Estonia: a success story
14
are instantly able to access the patient’s medical history and medicine purchases – helping to avoid drug
misuse. For the state, the introduction of ePrescriptions has reduced paperwork in hospitals and pharmacies
and provided a clear overview of activities in the field of pharmaceuticals.
5.6.
Case study #6 eHealth services
The Estonian e-Health Foundation was established in 2005. Created by the Ministry of Social Affairs and
six medical institutions, the Foundation is responsible for developing e-solutions in health-related services,
assisting in the provision of high quality accessible health care services, and the development and
management of the nationwide electronic health record system (EHR). In 2008, health care providers were
obligated to forward medical data to the Estonian National Health Information System (ENHIS) and in 2009
the EHR system and the patient portal (Digilugu) were launched.
Today the EHR system integrates data from Estonia’s healthcare providers to create a common record for
each patient, providing doctors with access to a patient’s records from a single electronic file. Medical staff
can view test results as soon as these are entered, together with image files such as X-rays. In an
emergency, a doctor can use a patient’s ID card to view time-critical information such as blood group,
allergies, recent treatments, ongoing medication and so forth. Citizens can log into the patient portal with
an eID card to view their medical data and related information (such as recent appointments, prescriptions)
– and the records of their children. They are also able to control which doctors have access to their files.
The system also automates the compilation of national statistics data so government ministries can
measure health trends, track epidemics and ensure health resources are being spent wisely.
5.7.
Case study #7 Energy smart grids
Estonian entrepreneurs and software developers have created smart metering and billing management
software for use by utilities providers. The systems allow end users to monitor consumption in real time,
compare packages to find the best deal and select how much of their energy comes from renewable sources.
The same system can predict when a local electricity supply is likely to be under pressure, automatically
offering consumers an instant bonus for cutting their consumption at these times. The approach has
generated up to 25 percent savings on their electricity bill for residents in the village of Kelvingi.
June 2014 • eServices in Estonia: a success story
15
6.
Looking to the Future
Estonia has a number of bold plans for the future. For example, its e-Receipt program could see the paper
receipts you receive after every purchase become a thing of the past. Instead, you’ll be able to view every
item you’ve ever bought, together with the warranties associated with the goods you’ve bought. For
consumers, there’s no worry about losing receipts if you need to return an item and the environment will
be ‘greener’.
And, because every person in Estonia has been provided with an e-mail address that’s only accessible with
an ID-Card, the moment you move physical address, you’re always assured your mail gets delivered –
electronically. No more missing envelopes or post going astray.
Similarly, goods and services are imported – and exported, for that matter – on a daily basis. So, why
shouldn’t state provided e-Services move across borders too? The e-Business Register already allows
entrepreneurs to establish a business in Estonia using just their ID-cards from Belgium, Portugal, Lithuania
and Finland. And the list is growing longer every day.
But the ambitions don’t end there. Plans are afoot to introduce an e-Resident service for anyone living
outside the country. This will enable people to use Estonian online services, open bank accounts and start
companies without ever having to physically visit the country. The plan, which will require e-resident
applicants to pass a background check similar to the visa application process and sign up to identify
themselves with biometrics such as fingerprints or iris scans, could see the Estonian Ministry of the Interior
being ready to hand out the first ID cards for e-residents at the end of the year.
By 2025, the Ministry projects that potentially 10 million people could have gained Estonian e-identity,
boosting the potential influx of business and investment in the country and stimulating the digital economy
significantly.
7.
Concluding observations
From the very start, the mindset in Estonia was to utilize the Internet to maximize participation in a digitized
eSociety in which eGovernment would support the delivery of services to citizens and businesses alike.
Determined to get the key infrastructure right – creating a platform that was flexible enough to develop
and evolve – the Estonian government worked in collaboration with ICT companies and private companies
to develop the key components it needed to ensure eServices could function optimally: e-signatures, legal
frameworks, trust, eID.
The information platform Estonia has developed today enables citizens, businesses and government
agencies to transact with one another with openness, privacy and security.
June 2014 • eServices in Estonia: a success story
16
Prepared for the eGovernment Unit
DG Information Society and Media
European Commission
Good Practice Case
eID in Estonia
Case Study
17 October 2006
Case study prepared by Ralf Cimander
(ifib, Germany) in co-operation with
Andres Aarma and Ain Järv from AS
Sertifitseerimiskeskus, Estonia.
eGovernment Unit
DG Information Society and Media
European Commission
Table of contents
1.
eID in Estonia
2
1.1
Case Summary
2
1.2
1.2.1
1.2.2
1.2.3
Problem addressed
Specific Problem
General Background
Policy context and strategy
3
3
4
6
1.3
1.3.1
1.3.2
1.3.3
Solution
Specific Objectives
Principles of eID card
Implementation
- Workflow description
- Security and Privacy
- Awareness and Marketing
8
8
8
13
14
16
17
1.4
1.4.1
1.4.2
18
18
1.4.3
Features making it a candidate for good practice exchange
Impact
Relevance of the case for other administrations that could learn
from the experience
Transferability
1.5
Results
21
1.6
Learning points and conclusions
23
1.7
References and links
26
19
20
Annex 1: Assessment Questionnaire for the MODINIS Case Descriptions
GP - Case: eID in Estonia
10-2006, vs 1.0
27
1
1.
eID in Estonia
1.1
Case Summary
Estonia has implemented the ID card as the primary document for identifying its citizens and alien
residents living within the country. Before introduction of this card, no national personal
identification document - neither physically nor electronically - did exist in Estonia. The card,
besides being a physical identification document, has advanced electronic functions that facilitate
secure authentication and legally binding digital signature, in connection with nationwide online
services.
There is only one version of the national ID card — no optional features or variations exist. All
cards are equipped with a chip containing electronic data and a pair of unique digital certificates
relating to each individual. In emergency cases (e.g. loss of the card) the certificates can be
suspended if required — disabling the ability to use the card for electronic authentication and
transactions.
The Estonian ID card scheme is the overall responsibility of the Estonian Government's Citizen and
Migration Board (CMB) and is regulated by the government's National Identity Act. The process
itself is managed through a tight public and private partnership with two key private organizations,
the AS Sertifitseerimiskeskus which is a joint venture between banks and telecommunications
organizations in Finland – acting as Certification Centre - and TRÜB Baltic AS which is the
company that personalizes the card itself — both physically and electronically.
The overall aim of the CMB was the introduction of a reliable and trustworthy identification
infrastructure in Estonia, receiving high acceptance by citizens and businesses and hence
becoming a success in terms of effectiveness and efficiency of its use in everyday life. As an (e-)ID
infrastructure is a very sensible area in public administration of a country, which need to be highly
reliable and requires full-time technical support in case of problems, a solution had to found that is
based on already proven technology and that is provided by inner country software and vendors.
Besides, this infrastructure had to be scalable, flexible and standards-based for expansion to other
services as well as forward-looking to enable also cross-border use.
Considering these overall goals, specific objectives and the organisation of service delivery, the
interoperability requirement is that of different public services which have to use the same
auxiliary services, i.e. digital signature, authentication, document encryption. Beside the use for
application of public services or signing of documents, the approach is universal and is also
applicable to private use and services. The interoperability requirement is met by employment of
standardised workflows in form of a common document format applicable to each service
independent of its provider (DigiDoc) and a central common public, service-rendering resource,
connecting national databases (X-Road). In addition, a centralised infrastructure of a national,
unique identification number for each Estonian resident has been employed serving their
authentication (not only) in electronic processes. Each workflow where digitally signed data or
documents are integrated in the legacy systems, IOP in the front-office to back-processes has
been achieved, in the other cases front-office to front-office flows are concerned. Almost 70 per
cent of Estonian residents own an ID card out of which 2.5 per cent use the electronic features of
the card. Several applications are already working with eID, like e.g. e-voting pioneered at the
local government elections in 2005 and with the e-ticketing of public transport tickets as one of
the most massively used application.
GP - Case: eID in Estonia
10-2006, vs 1.0
2
1.2
Problem addressed
1.2.1
Specific Problem
Prior to introduction of the present ID card there was no personal
identification document which could be applied both physically as
well as electronically. The same applied to residence permits.
Specific problems
addressed:
• No personal
identification
document existed;
neither physically nor
electronically
In terms of interoperability in the Estonian eIDentity Management
project, interoperability had to be employed where auxiliary services
(digital signature, authentication, document encryption) are to
support different primary services.
IOP requirement 1:
IOP between eID card
functions (auxiliary
services) and different
services
As the main objectives of the Estonian eID card is to digitally sign,
documents, encrypt documents and to authenticate users, the
natural focus of service delivery is on the front-office to front-office
processes and where documents are directly integrated in the
respective legacy system, front-office to back-office processes are
also concerned.
Service delivery
model:
IOP among front-offices
and where data are also
integrated in the legacy
systems, front-office to
back-office processes
are also concerned
To meet the interoperability requirement, a central database of
unique identification numbers, allocated to each Estonian resident
has been established providing authentication of the card holder (i.e.
the applicant or signing person). To enable identification and
authentication for different services via a corporate infrastructure, a
common public, service rendering resource – X-Road - has been
developed. Based on Internet, X-Road connects public databases
and information systems, tools centrally developed by the state (i.e.
the State Portal Centre) and the X-Road Center (management and
control of the gateway) with the Certification Centre for the (e-)ID
cards. The eID card of citizens is just a secure token for different
purposes where access to these purposes, i.e. public services is
provided by a single point of entry - the E-Citizen Portal. To digitally
sign documents, a communication model using standardised
workflows in form of a common document format (DigiDoc) has been
employed. DigiDoc format is based on the XML Advanced Electronic
Signatures standard (XAdES) and is a profile of that standard.
XAdES defines a format that enables structurally storing signed data,
GP - Case: eID in Estonia
10-2006, vs 1.0
Basic organisational
model employed:
• Centrally provided
unique identification
number for each
Estonian resident
• Common public,
service rendering
resource to connect
national databases (XRoad)
• Central single point of
access to public
services (E-Citizen
Portal)
• Standardised
workflows in form of a
uniform document
format (DigiDoc)
3
signature and security attributes associated with digital signature
and hence caters for a common understanding.
1.2.2
General Background
Issued by the Estonian Government’s Citizen and Migration Board
(CMB), national ID cards represent the primary source of personal
identification for people living within Estonia and are mandatory for
all citizens and resident aliens above the age of fifteen.
The Estonian identification card carries two discreet functions:
−
Physical Identity – can be used as a regular ID in conventional
real-world situations — anywhere one would typically need to
prove identity, age and so on.
−
Electronic Identity – enables citizens to use the same card to
electronically authenticate to Web sites and networks, and/or
digitally sign communications and transactions as required.
There was no national ID card scheme in place in Estonia before the
launch of the new ID card project. Conventional ID card schemes
(e.g., corporate cards) have been in operation for some time within
Estonia; however the dual-purpose physical/electronic ID cards were
not so familiar. To fulfil the scheme's requirements, the Estonian
Government’s Citizen and Migration Board required a single, holistic
system which could process and provision users with a dual-purpose
smart identification card. The process had to be straightforward for
citizens (to register and receive), easy to administer (for technology
controllers) and above all, be secure and reliable. In conjunction
with the ID Card initiative, the CMB were also eager to drive the
adoption of electronic signatures within the region, thus streamlining
key public service and commercial processes for residents and
businesses.
The Estonian ID card scheme is the overall responsibility of the
Estonian Government’s Citizen and Migration Board. It is responsible
for the issuance of identity documents to citizens and alien residents
as required by the government's National Identity Act. The CMB is
the institution that physically receives card application forms from
residents. However, the process itself is managed through a tight
public and private partnership. Two key private organizations work
with the government to support the ID card project:
−
AS Sertifitseerimiskeskus (hereinafter 'SK') – a joint venture
formed in 2001 between two of Estonia’s largest banks
(Hansapank,
Eesti
Ühispank)
and
telecommunications
organizations (Eesti Telefon and EMT). SK functions as the
certificate authority for the Estonian ID card project and
manages a complete range of associated electronic services —
GP - Case: eID in Estonia
10-2006, vs 1.0
Service:
Electronic Identity –
enables citizens to use
the same card to
electronically
authenticate to Web
sites and networks,
and/or digitally sign
communications and
transactions as required
Types and level of
agencies involved:
• Estonian
Government’s Citizen
and Migration Board
• AS
Sertifitseerimiskeskus
as Certification
Authority which is a
joint venture between
two of Estonia’s
largest banks and
telecommunications
organizations
• TRÜB Baltic AS – a
subsidiary of the TRÜB
financial services
organization
• Certification Service
Providers (CSPs)
• Time-stamping Service
Providers (TSPs)
• As Supervising
Authority the Ministry
of Economy and
Communications, in
particular the National
Registry of
Certification Service
Providers
4
including the LDAP (Lightweight Directory Access Protocol)
directory service, OCSP (Online Certificate Status Protocol)
validation service, and other certificate-related services. SK also
manages the end-user distribution channel (through its parents'
retail bank outlets).
−
TRÜB Baltic AS – a subsidiary of the TRÜB financial services
organization — headquartered in Switzerland. TRÜB is the
company that personalizes the card itself — both physically and
electronically. TRÜB receives the card application from CMB and
manufactures the card, printing and engraving the personal data
on the card, generating keys on the chip and embedding the
certificates on the card.
Besides, for the processing and controlling of digital signatures,
following authorities and agencies are relevant:
According to the Estonian Digital Signature Act (DSA), Certification
Service Providers (CSPs) certify real persons identifiable by name
and ID code and must be legal entities fulfilling specific legal
requirements.
DSA also regulates the work of Time-stamping Service Providers
(TSPs). The requirements to such service providers are generally the
same as those to CSPs. According to DSA, a time stamp is simply a
data unit that proves that certain data existed at a certain moment.
The National Registry of Certification Service Providers contains data
about all Estonian CSP-s and TSP-s. Although it confirms the public
keys of CSP-s, it is technically not a root CA in Estonia. Instead, it
functions as a supervisory authority, confirming the results of service
providers’ annual audits among other things. The Ministry of
Economy and Communications, in whose administration area the
registry works, has the right to verify audit results and inspect the
service providers' premises and relevant information.
GP - Case: eID in Estonia
10-2006, vs 1.0
5
1.2.3
Policy context and strategy
The Republic of Estonia is a small, independent Baltic state with a
population of just below 1.4 million people. Estonia is structured into
15 sovereign counties. While Estonia is a relatively small country (in
terms of other European population sizes, land area, GDP levels,
etc.), the nation is an innovator when it comes to introducing and
adopting new technology products and services. According to spring
2006 data (TNS Emor Gallup e-Ratings study), 58 per cent of the
population regularly use the Web — the figure shows that Estonia
has one of the highest Internet-usage rate in Eastern Europe.
Internet connectivity is also very high and well accessible at homes,
offices and schools.
Institutional context:
• Estonia is structured
into 15 sovereign
counties
• Highest Internetusage rate in Eastern
Europe
The legal framework associated with the issuance and government of
ID cards was established through the Identity Documents Act, which
was passed in 1999 and took effect on January 1, 2000. The specific
legislation associated with digital signatures - the national Digital
Signature Act (DSA) - was passed separately by the Estonian
parliament (Riigikogu) on March 8, 2000 and came into force on
December 15, 2000. This law regulates the framework and rules
required to effectively govern a national PKI and digital signature
infrastructure.
Legal framework:
• Identity Documents
Act of 1 January 2001
• National Digital
Signature Act (DSA) of
15 December 2000
• Rules and regulations
for Certificate Service
Providers (CSPs)
• Rules and regulations
for Time Stamp
Providers (TSP)
• Personal Data
Protection Act
The primary aim of the DSA was to give electronic signatures the
same level of trust and assurance as handwritten ones. As a rule,
digital and handwritten signatures should be equivalent in both the
public and private sector. The DSA also states that public service
departments must accept digitally signed documents. The DSA
requires that each digital signature can:
−
Uniquely identify the signatory.
−
Bind the individual to the signed data.
−
Ensure that signed data cannot be tampered with retrospectively
— without invalidating the signature itself.
While there is no direct sanction for not holding an ID card, it is
expected that as the first Estonian passports were issued in 1992
(following independence from the Soviet Union) with a 10-year
validity period, most people will apply for a card when renewing their
passport — if not already done so independently. By 2007, the
government expects over one million cards to be issued (almost the
entire registered and qualified population).
In terms of EU status, all certificates issued in association with the
ID card scheme are qualified certificates as per the European digital
signature directive 1999/93/EC. The Estonian DSA only regulates
advanced electronic signatures with regard to the EU directive.
Naturally, other types of electronic signatures can also be regulated,
but the DSA does not give them legal power or status.
One of the core components of the DSA was the establishment of
rules and regulations with regard to Certificate Service Providers
GP - Case: eID in Estonia
10-2006, vs 1.0
Interoperability
Framework:
All certificates issued in
association with the ID
card scheme are
qualified certificates as
per the European digital
signature directive
1999/93/EC
6
(CSPs) — who issue digital certificates to users and manage related
security services. The Estonian DSA mandated a number of stringent
requirements (financial and procedural) to ensure that CSPs are set
up and managed properly — to perform their function to the highest
possible standard.
The DSA also regulates time stamping services which are provided
by dedicated Time Stamp Providers (TSP). These TSP service
providers have to adhere to similar laws and regulations as CSPs.
The time stamp is simply a piece of data which attests to the
occurrence of an event at a specific time. The DSA does not define
time stamps in great detail, but ensures that time stamped data
cannot be tampered with or amended without invalidating the time
stamp itself.
A national registry of service providers contains all the relevant
information associated with registered CSPs and TSPs.
A broad Personal Data Protection Act regulates the use of personal
data and databases containing personal data by public authorities
and private entities.
GP - Case: eID in Estonia
10-2006, vs 1.0
7
1.3
Solution
1.3.1
Specific Objectives
In order to drive the adoption of digital signatures within the region,
software and technology had to be available for parties looking to
incorporate compatible applications.
When technical experts looked for a generic application or
implementation that would fulfil this requirement, no ideal solution
was found. It was also not optimal to rely on a foreign software or
technology vendor to provide and guarantee support for a critical
piece of national infrastructure. This reliance could have detrimental
impact on the country’s day-today functioning going forward.
Because of these considerations, a bespoke software model was
developed specifically to cater for Estonia and its digital signature
constituents.
In order to issue and manage the PKI-based digital credentials, the
following objectives were set by SK:
−
Selection of a PKI product which is already value proven in a
range of successful deployments in similar environments;
−
Scalability and Flexibility of the product;
−
To have a technology structure that is based on standards since
the PKI has to interoperate with a broad range of
complementary technologies;
−
Consideration of internationalization aspects since the Estonian
language is rich in non-ASCII characters that need to be
correctly processed and embedded in the certificates;
−
Auditable security and the possibility to construct reliable
processes. Technology is just one aspect of security, equally
important are the organizational and physical security measures.
Estonian legislation requires annual external info system audits
from the PKI providers.
1.3.2
Objectives to be
achieved in general:
• Raise the adoption of
digital signatures
• Good availability of
software and
technology for
interested parties
• Not to rely on foreign
software or vendors
for this sensible piece
of infrastructure
Specific objectives:
• Implementation of an
already value proven
technology
• Scalability and
Flexibility
• Standards-based
solution to enable
expansion to other
services
• Processing and
embedding of nonASCII characters that
are common in
Estonian language
• Auditable security and
possibility to construct
reliable processes
Principles of eID card
The front side of the card contains the card holder's signature and
photo, and also the following data:
−
name of card holder
−
personal code (national ID code) of card holder
−
card holder day of birth
−
card holder sex
−
card holder citizenship
−
card number
−
card validity end
GP - Case: eID in Estonia
10-2006, vs 1.0
8
The back side contains the following data:
−
card holder birth place
−
card issuing date
−
residence permit details and other information (if applicable)
−
card and holder data in machine-readable (ICAO) format
Electronic data on card
Each ID card contains all the above data except photo and
handwritten signature in electronic form, in a special publicly
readable data file. In addition, the card contains two certificates and
their associated private keys protected with PIN codes. The
certificate contains only the holder's name and personal code
(national ID code). In addition, the authentication certificate
contains the holder's unique e-mail address.
GP - Case: eID in Estonia
10-2006, vs 1.0
9
- Certificates
Each issued ID card contains two discreet PKI-based digital
certificates – one for authentication and one for digital signing. As
said, the certificates contain only the holder's name and personal
code (national ID code). These certificates are standard X509 v3
certificates and have two associated private keys on the card – each
protected by a unique user PIN code. The certificates contain no
restrictions of use: they are by nature universal and meant to be
used in any form of communications, whether between private
persons, organizations or the card holder and government. They
contain no roles or authorizations: those where required must be
managed using some out-of-band method (see below, "Roles,
authorizations and organizations' validations").
The certificates contain the card holder's name and national ID code.
It is agreed in Estonia that this data is public by nature. The
certificates identify the card holder uniquely because even though
there may be name overlaps, the national ID code is unique. In
addition, the authentication certificate contains the card holder's email address.
In terms of the European Council and Parliament digital signature
directive 1999/93/EC, all the certificates on Estonian ID card are
qualified certificates.
- E-mail address
The authentication certificate on each ID card contains the card
holder's government-assigned e-mail address in the format
firstname.lastname@eesti.ee. Random numbers can be used in
addition to provide unique e-mail addresses even to persons with the
same name. The address does not change with subsequent
certificate or card issuing – it is guaranteed to be a person's
"lifetime" address.
There is no real e-mail service associated with the address. It is
merely a relay address which forwards e-mails to users' "real"
addresses (e-mail accounts). Each user must configure the
forwarding addresses using an online service made available for this
purpose, and may reconfigure the addresses as often as he or she
pleases. Up to five forwarding addresses can be specified.
The address is supposed to be used in communications from
government to the person, but it can also be used in
communications between persons and companies and private
persons themselves. The addresses are available online to anyone
through CSP's certificate directory.
The address can be used as a simple e-mail address, but using the
address and the authentication certificate on the card, users can also
digitally sign and encrypt their e-mail. The digital e-mail signature is
not legally binding and not covered by DSA, but it provides receivers
additional confirmation of sender authenticity. E-mail encryption and
GP - Case: eID in Estonia
10-2006, vs 1.0
10
signing using certificates on smart card is a standard function of
various e-mail applications.
Anti-spam measures are implemented in the forwarding server. In
addition, spamming is illegal in Estonia and spammers will be
prosecuted accordingly.
Roles, authorizations and organizations' validations
In connection with implementing PKI and digital signatures, the
question of roles and authorizations has arisen in various projects. It
is assumed that certificates for digital signing may be issued for
specific purposes only, and that a person's roles can be embedded in
role certificates that are then used for authenticating the certificate
holder into different systems and giving digital signatures in different
roles. Thus, a person needs additional role and signature certificates
for each different role (s)he has, and the number of certificates
grows, creating substantial interoperability and scalability issues.
The Estonian approach states (as also said in the Estonian DSA) that
a digital signature given using a digital signing certificate is no
different than a handwritten one. A person's handwritten signature
does not contain his or her role – the role and authorization are
established using some out-of-band method (out-of-band in the
context of certificates). The same approach also goes for
authorization while authenticating – a person's certificate should not
contain his or her authorization credentials. Instead, everyone has a
similar universal key (authentication certificate), and the person's
role and authorization can be determined using some other method
(e.g. an online database) based on that key.
Case capitalises
mainly on following
layers of IOP:
• Technical and
syntactic IOP is
provided by the use of
the Internet-gateway
X-Road connecting the
national databases
and by DigiDoc which
is based on
OpenXAdES and hence
on ETSI standard.
DigiDoc provides a
common document
format and is a key
feature of the
semantic
standardisation. A key
feature enabling
semantic IOP is the
use of the national ID
number for
authentication
throughout any public
service
A practical example illustrating the above concept is signing
documents in organization using power of attorney. In traditional PKI
environments, this has been done using some form of attribute
certificates where issues described above arise. In Estonian and PKI
context, we could ask how power of attorney given in real life is, and
use the same principles in electronic document management.
Traditionally, power of attorney is granted in the form of a document
signed by the person giving the authorization. The document is then
given to the person who receives the authorization and who can then
present the document to relevant parties if necessary. The same can
be done electronically: the person giving the power of attorney can
sign the document using his/her own universal personal certificate,
and forward the document to the person who is given authorization.
The person can then enclose the digital power of attorney with any
further documents (s)he signs. The person receiving the document
can then verify both the original signed document and the enclosed
power of attorney that confirms that the person indeed had the right
to sign such a document.
Attribute certificates can of course be used in connection with the
universal certificates and documents outlined above, but the
Estonian concept is geared more towards universal certificates.
GP - Case: eID in Estonia
10-2006, vs 1.0
11
An exception to the above is organization's validation. Digital
documents sometimes need to be validated by organizations, so that
other organizations can be sure of the identity of the organization
where the document originated. This is useful for e.g. signing pieces
of databases (e.g. bank statements) online, to be presented to other
organizations. For this, SK issues certificates to organizations that
can be used to sign documents digitally. Technically, they are
equivalent to personal signing certificates on everyone's ID card, but
legally, they are not viewed as signatures and need not be covered
by law, because according to the Estonian law, only real persons can
give signatures. The "organizations' signatures" must therefore be
viewed simply as additional tools for proving information authenticity
(that it really originated from a specific organization) which may or
may not be accompanied by a digital signature of a real person
working in that organization. Still, the PKI complexity stops here,
and besides personal and organizational signature certificates, there
is no need for personal role certificates or anything else more
complex.
GP - Case: eID in Estonia
10-2006, vs 1.0
12
1.3.3
Implementation
In order to bring digital signatures into everyday life, common
understanding and signature handling practices are required. In
addition, software and technology must be available for anyone
interested, in order to create compatible applications. After all, the
key to unleashing potential digital signature benefits lies in
communication between organizations, not within one organization.
Therefore, it is vital that all organizations in a given community
interpret and understand digital signatures the same way. In case of
Estonia, the community is the whole country.
SK, together with its partners, delivered a comprehensive digital
signature architecture called DigiDoc. DigiDoc is a universal system
for giving, processing and verifying digital signatures created by AS
Sertifitseerimiskeskus. It can be connected to any new or existing
piece of software, but its components are a stand-alone client
program and a Web portal.
The core components of DigiDoc are:
− Client Program – DigiDoc Client is available to anybody to
download for free. Anyone can use it to verify digital signatures
or, if you have an Estonian ID card and smartcard reader,
generate digital signatures.
−
Web Portal – The portal is located at http://digidoc.sk.ee and is
available to all ID cardholders free of charge. Its functions are
similar to the client program — you can use it to generate and
verify digital signatures. In addition, you can use it to have a
document signed by a number of people. With a few clicks of the
mouse, you designate the people whose signatures you need on
the document, and they can all sign it in the same portal. Every
user has a directory of his or her documents which no one else
sees but where anyone can send documents to be signed by
you.
−
File Format – DigiDoc specifies the file format for storing a digital
signature and other technical data in a container file, together
with the original file that was signed. All DigiDoc-enabled
programs must support this format, and it must be possible to
export files from all the programs into stand-alone files, to be
verified with the stand-alone DigiDoc Client.
−
Software Library – The DigiDoc library is available to all
developers as a program library in C and as a Windows COM
component. It can be connected to any existing or new software.
For example, you could add DigiDoc support to accounting
software, document management system, Web and intranet
applications, and so on.
Supporting
infrastructure
employed:
• Web Portal to
generate and verify
digital signatures
• Software Library
(DigiDoc library
program in C
• DigiDoc document
format
• SK's OCSP validation
service
• X-Road, the Internetgateway connecting
the national databases
(public authorities),
Banks and the
Certification Authority
On the server side, DigiDoc provides an RFC2560-compliant OCSP
server, operating directly off the CA master certificate database and
providing validity confirmations to certificates and signatures. On the
GP - Case: eID in Estonia
10-2006, vs 1.0
13
client side, it provides a number of components — the most
important being the digital document format, which is key to
common digital signature implementation and practice.
SK based the DigiDoc document format on XML-DSIG standard. In
February 2002, ETSI published its extensions to XML-DSIG as ETSI
TS
101
903,
also
known
as
XAdES
(see
also
http://www.openxades.org). DigiDoc document format is a profile of
XAdES, containing a subset of its proposed extensions.
Based on the document format, a library was developed in C
language that binds together the following:
−
DigiDoc document format
−
SK's OCSP validation service
−
Interfacing with the user's ID card using Windows' native CSP
interface or cross platform PKCS#11.
Workflow description
The eID card is used for identification at the E-Citizen Portal. This
portal serves as a gateway to the services of approximately 20
different databases. Here, a person can check his or her data in
these various national databases and fill out application forms, sign
and send documents, and receive information about planned
electrical supply interruptions in the specific area. The DigiDoc
system described above is needed by citizens to start giving and
receiving digital signatures.
After identification at the E-Citizen Portal, services mainly of the
central public authorities like Benefits and Social Assistance,
Citizenship, Health Care or many others may be applied for (see
www.eesti.ee). The validity of the citizens' certificates will be
confirmed (OCSP) and a time-stamp given to the applications. Via a
common public, service rendering resource which connects the
national databases - the Internet X-Road - the application messages
are securely exchanged. More than 350 organisations already joined
this Internet-gateway.
GP - Case: eID in Estonia
10-2006, vs 1.0
14
Architecture of service delivery via eID in Finland
GP - Case: eID in Estonia
10-2006, vs 1.0
15
In 2004, The Parental Benefit Service was awarded for the best
government agencies cooperation solution.
Five information systems interact the data (real time).
−
Citizens' Portal
−
Register of Social Insurance Board
−
Population Register
−
Information system of Health Insurance Fund
−
Information system of Tax and Customs Office
Security and Privacy
The data protection question is not seen to be very relevant in the
context of Estonian ID card because there is very little private data
involved in the card issuing and further utilization process. There is a
broad Personal Data Protection Act in effect in Estonia which
regulates the use of personal data and databases containing
personal data by public authorities and private entities, and Estonian
Data Protection Inspection is the government body overseeing that
the requirements of the act are met and enforcing compliance if
necessary.
The certificates on the card are available publicly in a directory
service and contain only the card holder's name and personal ID
code, which are considered public data by law in Estonia. In addition,
e-mail addresses in authentication certificates are also available in
the directory. The directory contains only valid (active) certificates:
if a person suspends or revokes his/her certificate, it is also removed
from the directory and the data are no longer available.
GP - Case: eID in Estonia
10-2006, vs 1.0
Warranty of security
and privacy:
• Only little data is
saved on the ID card
• Estonian Data
Protection Inspection
controls that
requirements of the
Personal Data
Protection Act are met
• Personal ID code is
held publicly together
with card holder's
name and are
considered public data
by law in Estonia
16
The public data file is not published anywhere online. The personal
data on the card in visual and electronic format are accessible only
to those persons to whom the card holder physically presents the
card.
The general stance to ID card and data protection in Estonia is that
the card should contain as little private data as possible. Instead, the
data should be kept in databases at relevant authorities, and a
person can use the card as key (authorization method) to access his
or her data in the database.
Requests by third parties (e.g. representatives of authorities) for
private data are logged and logs are available online for the
individual upon request (via the citizen's portal). Thus such approach
presumes justified interest on behalf of authorities. An individual can
submit additional queries regarding the requests.
Warranty of security
and privacy:
• Card holder can
suspend or revoke
their electronic
certificate form the
card (for only "offline"
use of the card)
• Public data file is not
published anywhere
online
• Card is used as key to
access his/her data in
databases in public
authorities instead of
containing these data
Awareness and Marketing
Till now, the electronic usage of eID cards has been mostly the
realm of professionals and enthusiasts. This mainly due to:
-
the time required to change the mindset;
-
lack of inevitable applications (e.g. compared to free Internet
telephony);
-
initial technical glitches which discouraged some first-movers
and resulted in lack of hype for the ID card;
-
relative expensiveness of ID card readers (currently readers are
offered at more than three times cheaper price than some years
ago).
However, currently the card is used very actively as the token for
verification of a valid e-ticket in city public transport. One of the key
drivers behind a rapid and successful adoption of e-tickets is the
price difference between e-tickets and paper tickets.
The eID function of the bank card is currently much more often used
as that of the ID card. However, in order to strengthen the use of
the eID card instead of the bank card citizens as well as banks shall
be convinced by economic logic: As Internet use is affected by
viruses and other similar things updated security features and other
applications are permanently required in order to provide secure
services. This costs lots of money for the banks for services which
are not directly related to their own business. Also citizens need to
update their systems for these purposes which would not be the
case if they use the eID functionalities.
Currently, the Computer Security 2009 initiative has been launched
with the aim to ensure a more secure use of internet by application
of PKI products and services. E.g. internet banking transaction limits
which presume usage of higher security means (e.g. PKI tokens)
shall be decreased significantly. Also, new PKI products and services
are in production.
GP - Case: eID in Estonia
10-2006, vs 1.0
Awareness and
Marketing:
• Currently, the use of
the e-function for
identification is mostly
the realm of
enthusiasts
• However, card is
widely used as token
for verification of valid
e-tickets in public
transport
• e-tickets are cheaper
than paper ones and
force their use
• Increase of Internet
security envisaged by
development and use
of PKI products and
services
• As the use of the eID
card saves costs for
banks and also for
citizens in terms of
Internet security,
economic logic will
support the change
from using banking
cards to eID cards for
public service
applications
17
1.4
Features making it a candidate for good practice exchange
1.4.1
Impact
The Estonian eID roll-out is known to be one of the most successful
in Europe. It has been organised in a valuable public-private
partnership and there are already many applications working with it.
E.g. Estonian citizens can use it to buy e-tickets for public transport
and it allows drivers permit verification. Citizens can browse through
their information in the population register; they can digitally sign
documents or check their telephone bill. The card is also be used for
health insurance and banking purposes.
Outreach:
• > 950,000 residents
own an ID card, i.e.
almost full national
roll-out
• e-functions are active
by default and 2.5%
are using it
The first Estonian ID cards were issued in January 2002. In the first
year, more than 130,000 cards were issued, and the total figure up
to now (mid 2006) is more than 950,000; i.e. almost everybody has
one, considering that citizens under the age of 15 do not need one.
2.5% are users of the e-function of the ID-card in terms auf
identification and authorisation in public services.
Estonia has a PKI penetration of more than 67%. The reason for its
major success is that Estonia is a relative small country with almost
1.4 million residents.
The card is meant to be universal and its functions are to be used in
any form of business, governmental or private communications. It is
already helping people to make everyday communications more
convenient.
Although the ID card project is a success it took five years instead of
the originally expected 14 months to implement the infrastructure
and raise awareness and high uptake due to legislative and political
issues. Another challenge was to promote the use of the card and to
make people getting used to it.
Like in many cases the take-up of eGovernment service applications
based on the eID card was very slow due to the reasons mentioned
in the Awareness and Marketing chapter above.
With the DigiDoc library easy-to-use interfaces to the signature
relevant features are provided and there is no need for application
developers to know OCSP protocol specifics or DigiDoc (XAdES, XMLDSIG) format internals. It can be embedded in any application or on
top of it. A COM interface has been implemented, making it easy to
add DigiDoc support to any Windows based application supporting
COM technology. A Java implementation is also provided.
Despite these strengths, providing the libraries and formats was not
enough — because these do not add value to end users without real
applications. Although it is expected that DigiDoc support will
eventually be present in most Estonian document management
systems and Web sites dealing with documents, a number of sample
or reference applications were also provided. The parental benefit
service, the health care services or taxation services are good
GP - Case: eID in Estonia
10-2006, vs 1.0
Performance:
• DigiDoc support will
eventually be present
in most Estonian
document
management systems
and Web sites
• Easy to use function
as DigiDoc client is a
Windows application
• No need to install
stand-alone software
on user side as
functions are provided
via a web portal
• Libraries,
specifications, and
applications are
provided free of
charge to Estonian
public
18
examples in this regard. DigiDoc Client is a Windows® application
that lets users simply sign and verify documents, and DigiDoc portal
is an application that lets users do the same online — without the
need to install any stand-alone software. Both are based on the
same DigiDoc library and thus fully compatible e-signatures given in
Client can be verified in portal and vice versa. The libraries,
specifications and applications are provided to the Estonian public
free of charge, and it is expected that digital signature usage in
common life and everyday business and government practices will
grow significantly through 2003–2008. The first official digital
signatures in Estonia were given using DigiDoc Client on October 7,
2002.
1.4.2
Relevance of the case for other administrations that could learn from the experience
With the national eID card the Estonian government follows a
pragmatic and simplicity approach avoiding some of the contentious
aspects of ID cards in general:
−
ID cards do not contain any digital biometrics;
−
ID cards do not contain any roles or authorizations. Where such
is required these must be managed using some out-of-band
method;
−
The certificates are simple and only contain the holder's name
and personal code (national ID code);
−
There is not central aggregation of loads of user data as the card
is only the 'key' to user data stored in public authorities;
−
The certificates contain no restrictions of use: they are by nature
universal and meant to be used in any form of communications;
−
The use of the eID card is easy to understand for users as it only
contains two functions to be used with two different PIN codes,
one for digital signing and one for authentication;
−
Users may disable the electronic functions of the card in case
they have lost it or they have doubts or fears about using these
functions;
−
Users do only need card and card reader for using the system.
Innovativeness:
• Simplicity of the card
(no digital biometrics)
• Simplicity of the
certificates (only
contain name and ID
code)
• Simplicity of its use
(only two functions:
digital signature and
authentication)
• No restrictions in use
since certificates are
universal
• No central aggregation
of loads of user data
• Possibility to disable
the electronic
functions of the card
However, the use of a unique national ID code for identification still
bears some risks for abuse and privacy concerns are present. The
success of such applications is highly dependent on the trust users
have in the system including the legal regulations encompassing also
the control of its use. In addition, as an objective and a possible
killer application of the card is its multifunctional use, in particular in
the private sector, one has to consider whether it is appropriate that
these private sector organisations know the identity of their clients.
GP - Case: eID in Estonia
10-2006, vs 1.0
19
1.4.3
Transferability
Foreign Certificates
DSA regulates the recognition of foreign certificates, stating that in
order for them to be recognized equivalent to those issued by
Estonian CSP-s, they must be either confirmed by a registered CSP,
be explicitly compliant with DSA requirements or covered by an
international agreement.
DigiDoc and OpenXAdES
Estonia launced the OpenXAdES initiative which is, as the name
indicates, an open initiative where anyone is welcome to join.
OpenXAdES is a free software development project aiming at
profiling XAdES (XML Advanced Electronic Signatures), technical
standard
(TS
101
903)
published
by
ETSI
(European
Telecommunication Standards Institute). With digital signatures,
common understanding of the document format is critical as digital
signatures can't be converted. Open XAdES' mission is to
concentrate efforts on developing a common document format and
share implementations supporting this. With DigiDoc, a uniform
platform based on XAdES has been developed which has the
following important features:
−
Can be verified offline without any additional information;
−
Signature can be given to several original documents at the
same time;
−
Protection against format attacks – type of signed document is
also signed;
−
Original document can be in the container or stored separately;
−
Original document can be XML or any binary file (Word, Excel,
PDF, RTF etc);
−
Zero, one or more signatures per container;
−
One validity confirmation per signature.
Transferability:
• Foreign certificates
can be dealt with
when they are
confirmed by a CSP or
are compliant with
DSA requirements
covered by
international
agreement
• Launch of the Open
XAdES Initiative
aiming at commonly
(with other countries)
profiling XAdES which
is a standard
published by ETSI
• Agreement on IOP
between Estonia and
Finland
In
June
2003,
AS
Sertifitseerimiskeskus
and
Finnish
Väestörekisterikeskus (Population Register Centre, PRC) signed an
agreement for improving digital signature interoperability between
the countries, with the goal of making digital documents a reality
within and between Finland and Estonia. Estonia and Finland invite
other parties from other communities to join the project and thus
expand the network of "digital countries".
GP - Case: eID in Estonia
10-2006, vs 1.0
20
1.5
Results
The Government's objective is to reach one million ID cards issued
by 2007. Besides the use of the national ID card, Estonian residents
can also use their Internet banking identification data to access
online public services (more than 70% of Estonian residents use
Internet banking, the highest proportion in Europe).
The most important application for public services, - the e-Citizen
portal – can be used by both cards for authentication purposes. As
internet banking already started in 1995, citizens are more used to it
and tend to login to their bank and then go to the portal. E.g. many
people (65%) declared their tax online with bank codes but not
through the eID card. Hence authentication is currently not the killer
application for eIDs in Estonia though the main purpose of the eID
card is to authenticate its owner.
Benefits:
• Unique identification
throughout public and
private services
• Provision of secure email account and
unique e-mail address
• Possible encryption of
documents
• e-tickets for public
transportation is a big
success as it is used
110,000 times per day
Beside authentication, the card can also be used for secure e-mail.
The idea was to give a lifetime e-mail address to the citizens so the
authentication certificate contains an e-mail address. The e-mail
address provided by the government looks like the perfect
communication channel. Since it works voluntarily, and the citizen
has to login to the citizen portal and register the address, not
everyone does this.
The card can be also used for encryption of documents so that only
the person intended to view the document can decrypt it. This is a
very efficient means for secure transfer of documents using public
networks.
One of the most successful applications is the electronic ID-ticket
which can be used for travel in the public transport of Tallinn, Tartu
and Viimsi as well as in the county of Harjumaa. During year 2005,
passengers using this e-ticket service purchased a total of 975,263
electronic ID-tickets. Today, more than 110,000 persons use the ID
ticket system every day.
Another application is Internet voting piloted in 2005. As the
infrastructure was in place, it was desired to use it via the eID card.
I-voting was based on an envelope scheme. The citizen makes a
choice and the choice is then encrypted with the public key of the
whole system. Many international observers were present at its first
run. However, there were and still are some privacy concerns about
the I-voting and the buying of public transport ticket with the eID
card mentioned above. E.g. even if the personalisation of tickets
actually eliminates the risk of forgery (which is an issue with nonpersonalised paper tickets) the transport company knows the
identity of the person who bought the ticket. The success of these
applications is highly dependant on the trust users have in the
system. Of course one can always travel anonymously by buying a
paper ticket.
GP - Case: eID in Estonia
10-2006, vs 1.0
21
In May 2006, the largest banks and telecoms (SEB Eesti Ühispank,
Hansapank, Elion, EMT) as well as the Ministry of Economic Affairs
and Communications of Estonia signed a co-operation agreement to
launch a nationwide "Computer Protection 2009" initiative, pledging
to invest up to EEK 60 million to increase end-user PC protection and
awareness in Estonia.
The initiative aims at making Estonia a country with the most secure
information society in the world by year 2009. To this end, a number
of sub-projects have been launched, one of the priority fields being
the promotion of ID card-based authentication in the use of eservices. Thus PKI should become the main method of authentication
as well as transaction verification within the three years with a total
of ca 600,000 active users. Parallel to the existing ID card, mobile ID
will be launched by the beginning of 2007 enabling secure
authentication and digital signing using a mobile phone.
GP - Case: eID in Estonia
10-2006, vs 1.0
Future developments:
• Launch of the
nationwide "Computer
Protection 2009"
initiative in order to
making Estonia leader
in secure information
management
22
1.6
Learning points and conclusions
Critical success
factors for IOP:
Many lessons were learned while organising, developing,
implementing, and running eIDs in Estonia and are presented below.
As Estonia is a main driver in the OpenXAdES initiative and eID
adheres to this standard, many lessons can also be stated on a
rather general level which stem from the OpenXAdES group.
Digital signature is universal
Think of your handwritten signature. Whether you sign a paper as a
citizen, the CEO of your company, the head of some non-profit
hobby association or as a bank customer - the scribbling that you
draw on paper and that is called a signature always looks the same,
regardless of your role. Whether you were indeed authorized to sign
the document or did agree to its content or other such questions are
totally different matters, just as in the traditional world. Aim merely
at providing users a way of working with legally binding digital
signatures.
Document must be self-contained
No additional validation services should be needed for verification
after the signature has been created and saved. Documents should
contain the digital signature, original signed data and all other data
necessary for document verification. Using the data in the document
file, it is possible to firmly establish whether the digital signatures
are valid (whether the certificates were valid at the time of signing
etc).
Legislation is important
Since we are talking about legally binding signature, legal framework
for digital signatures is critical. Different countries have different
digital signature regulations and you should provide solutions which
are as flexible and universal as possible. OpenXAdES is such a
solution which fully complies with the Estonian digital signature
regulation, as well as the EU directive 1999/93/EC, regulating the
general use of digital signatures within the EU. There is also a
chance that OpenXAdES is already compliant also with the regulation
in your country.
• Aim merely at
providing users a way
of working with legally
binding digital
signatures
• Document must be
self-contained - no
additional validation
services should be
needed after the
signature has been
created
• The use of legally
binding signatures
requires a valuable
legal framework
• As different countries
have different legal
frameworks, provide
flexible and universal
solutions to be
connective with these
countries
Additionally, when talking about legislation, we cannot only
concentrate on strictly digital signature and PKI-related acts:
whether you can use digital signatures or not depends also on the
legislation of other generic areas of life, e.g. administrative
procedure, civil relations, court proceedings etc. A number of
European countries are at a disadvantage in this respect: although
digital signature law is in place, other laws foresee that documents
can only be used on paper. Estonia is in a good position because
many of the country's laws have recently been passed or updated to
GP - Case: eID in Estonia
10-2006, vs 1.0
23
reflect the vision described above: digital documents and paper
documents should be used interchangeably in everyday life in private
and business relations and should be considered equivalent in all
respects.
PKI hype is over, business value is important
It is no more the year 2000 where technology opened all the doors
(and buzzwords guaranteed immediate funding). Set the focus on
added business value to organizations and end users. This may
sound painful to some PKI enthusiasts: many PKI projects carried
out so far do not justify the costs made and do not add significant
value to anybody. Avoid this pitfall by trying to be as simple as barebones as possible, while adding considerable value to any business
process which uses legal documents. This ensures hat the business
requirements would take precedence and that the most appropriate
technology would be used to implement them.
Open standards and trust are critical for user confidence and
interoperability
Digital signatures and the whole PKI is based on trust and confidence
- implementers and end users need to be aware of what actions
cause what outcomes in the system, and that the system is really
doing what it claims to be doing. Open source and free software,
based on public standards enable that anyone can examine the
project and document internals if necessary. E.g. do not use any
heavyweight and cutting-edge time-stamping protocol for signature
timing and validation - instead, use lightweight and proven
standards such as OCSP.
Our main competitor is pen and paper
Remember that we are talking about giving signatures to
documents. This has been done the same way for many hundreds
and thousands of years. Telling people that it can also be done
differently is a very complex task and you are facing fierce
competition from traditional signing tools, pen and paper. If you
cannot explain the benefits of the new method to people and
organizations and do not credibly demonstrate that it is more cost
effective to them, you will fail and people will continue using paper
documents.
PKI business model must be based on certificates and
corporate services, not end-user services and transactions
This is a direct consequence of the above point: Understanding and
accepting the new system is already hard enough for people. If you
want to charge them lots for using the digital signature, they won't
ever use it. A place where persons can be charged is issuing a
certificate for them, but after that, it should be free, both the
services and the software.
GP - Case: eID in Estonia
10-2006, vs 1.0
Critical success
factors for IOP:
• Business requirements
should be the driver
not the most
sophisticated PKI
solution
• Base your project on
open standards to
enable trust in the
system
• Use open standards to
be prepared for
interoperability
• Demonstrate the
additional benefit by
using the new solution
in contrast to the
traditional way
• Base your business
model on certificates
and corporate services
in stead of end-user
services and
transactions
24
Critical success
factors for IOP:
Capitalize on already existing IT investment
Much of the infrastructure that is necessary for using digital
signatures is most often already in place. Most people and
businesses have access to PC-s and the Internet. Countries and
communities are starting to distribute universal national or regional
ID cards. Having an ID card and access to smartcard-reader
equipped PC should be the only thing a person needs for using the
digital signature.
The costs to businesses and end users should be limited
We do not need to construct complex expensive PKIs for each
different service: single PKIs, perhaps even on a national scale such
as in Estonia, are suitable for all purposes.
People should be able to understand digital signatures
Complexity has been the key inhibitor in successfully providing PKI
services to end users, and much of that complexity is due to the fact
that current services and products have been specific to one service
or organization only. People have to learn new approaches and new
interfaces for each communication pattern, and it is very frustrating.
Having a single certificate and PIN code for all digital signature
purposes is all that a person needs, and people can also understand
this, exactly as they can understand using ATM cards and mobile
phones.
Single tokens are more secure
When people have only a single token to look after, they know they
have to be very careful with it. If a single card carries the
authentication and digital signature functions such as in Estonia,
security-critical functions can be easily established and maintained,
such as a round-the-clock helpdesk for suspending card and
certificate validity in case of loss or theft. Problems associated with
outdated or insecure passwords are eliminated, as smartcard- and
certificate-based authentication gains momentum.
GP - Case: eID in Estonia
10-2006, vs 1.0
• Capitalize on already
existing IT
investments in to
protect investments
also on user side
• One unique PKI
system for all public
services would be
more beneficial than
having one for each
service
• Provide easy to
understand services in
order to drive their
dissemination
• Provide single tokens
as they are more
secure than having
different solutions
25
1.7
References and links
All URL's worked out on the last visit on 04.09.2006:
The Estonian ID card project information, including the newest version of their Whitepaper, is
available online at http://www.id.ee. Contact at info@id.ee.
Important papers which also build the basis of this case study are:
Cybertrust 2005: Managing Digital Identities and Signatures through Public/Private Partnership
(http://www.cybertrust.com/media/case_studies/cybertrust_cs_easton.pdf)
The Estonian ID Card and Digital Signature Concept. Principles and Solutions. Whitepaper.
Version: June 5, 2003 (http://www.id.ee/file.php?id=122)
Acts:
Digital Signature Act: http://www.esis.ee/ist2004/101.html or PDF:
(http://www.esis.ee/legislation/digital_signatures_act.pdf#search=%22digital%20signature%20ac
t%20estonia%22)
Personal Data Protection Act: http://www.esis.ee/ist2004/103.html
Further useful references and websites:
−
AS Sertifitseerimiskeskus: http://www.sk.ee
−
DigiDoc
Format
Specification.
Version
1.3.0,
12.05.2004
(http://www.id.ee/file.php?id=342#search=%22digiDoc%20format%20specification%22)
−
Modinis IDM 2006: National profile for eGovernment IDM initiatives in Estonia. In: D 3.5: IDM
Initiatives
Report.
(Estonian
example:
https://www.cosic.esat.kuleuven.be/modinisidm/twiki/bin/view.cgi/Main/EstonianProfile)
−
OpenXAdES group: http://www.openxades.org
−
Web Portal to generate and verify digital signatures: http://digidoc.sk.ee
−
E-Citizen Portal: http://www.eesti.ee
GP - Case: eID in Estonia
10-2006, vs 1.0
26
Annex 1: Assessment Questionnaire for the MODINIS Case
Descriptions
In order to ensure the case descriptions meet the information needs of stakeholders in
interoperability at the local and regional level, we ask you to complete this short assessment
questionnaire. Your feedback will be used to improve the next version of the present case and will
also be taken into consideration when writing up more cases to be described in the course of the
project.
Case being reviewed:……………………………………………………………………………………………………………………….…
1.) Information content
a) Completeness of description
1
5
|-----------|-----------|-----------|-----------|
only few
all
relevant
relevant
aspects
aspects
b) Detail of description
1
3
5
3
1
|-----------|-----------|-----------|-----------|
too
right
too many
general
level
details
2.) Length of description
1
3
5
3
1
|-----------|-----------|-----------|-----------|
too
right
too
short
length
long
3.) Structure / headings
1
5
|-----------|-----------|-----------|-----------|
unclear
clear
GP - Case: eID in Estonia
10-2006, vs 1.0
27
4.) Margins
1
3
5
|----------------------|-------------------- --|
misleading
not necessary
good
orientation
5.) Learning potential
1
5
|-----------|-----------|-----------|-----------|
none at all
many new insights
6.) Usefulness for your own work
1
5
|-----------|-----------|-----------|-----------|
not at all
very much
7.) Transferability of case to your country
1
5
|-----------|-----------|-----------|-----------|
not at all
very high
8.) Will you get into contact with the contact person?
1
5
|-----------|-----------|-----------|-----------|
certainly
for sure
not
Comments
______________________________________________________________________________
______________________________________________________________________________
Your affiliation
local/regional
government
GP - Case: eID in Estonia
national
government
IT
business
10-2006, vs 1.0
academia
28
Prepared by:
Ralf Cimander and Herbert Kubicek
Institut für Informationsmanagement Bremen GmbH (ifib)
Am Fallturm 1, D-28359 Bremen, Germany
www.ifib.de
Tel.: (+49 421) 218 26 74, Fax: (+49 421) 218 48 94, email: info@ifib.de
http://www.ifib.de/egov-interoperability
European Institute of Public Administration (EIPA)
Center for Research and Technology Hellas / Institute of Informatics and Telematics
(CERTH/ITI)
Prepared for:
European Commission
Information Society and Media Directorate-General
eGovernment Unit
Tel
Fax
(32-2) 299 02 45
(32-2) 299 41 14
E-mail
EC-egovernment-research@cec.eu.int
Website europa.eu.int/egovernment_research
GOVERNMENT OFFICE Estonia’s Open Government Partnership Action Plan: Self-­‐Assessment Report Tallinn 2013 TABLE OF CONTENTS
1. Introduction ......................................................................................................................... 3
2. The preparation process of Estonia’s action plan ............................................................... 4
3. Implementing the action plan.............................................................................................. 6
4. Summary ........................................................................................................................... 24
Appendix 1. Open government round table: People’s Assembly in Estonia – crowd-sourcing
solutions for complex problems ............................................................................................... 26
Appendix 2. An open governance partnership case study from Estonia – the development of
the government portal eesti.ee .................................................................................................. 27
2 1. INTRODUCTION
The Estonian experience proves it: a modern successful state means freedom of speech and
press, the supremacy of law, eliminating corruption, the involvement of citizens - everything
without which democracy and the rule of law would be unthinkable.
Toomas Hendrik Ilves, the President of Estonia
Estonia has been an official participant in the Open Government Partnership1 since April
2012, joining the initiative in its first group of expansion after the first eight founding
countries. Becoming a member of the Open Government Partnership was initiated and
coordinated by the Ministry of Foreign Affairs.
For Estonia, the main goal when joining the Open Government Partnership was to draw
the attention of the government and the entire society to the quality of state governance,
learn from the experience of other countries and share Estonia's experience with other
countries in the Partnership.
Each country in the Partnership follows an action plan that has been prepared in accordance
with the goals and principles of the Open Government Partnership. In Estonia’s action plan
for participation in the Open Government Partnership the activities of the government
were focused on two of the key areas of the Partnership – the development of public
services and addressing public official ethics2. The goals and activities in the Action
Programme of the Government of the Republic 2011-2015 were taken into account as well as
those in national development strategies. The implementation of the action plan will be
evaluated annually and the plan will be amended as deemed necessary.
Estonia's action plan was prepared by the Government Office, which is the institution in
charge of coordinating the implementation of the Action Programme of the government. The
goals and activities in the action plan were consulted and coordinated with the civil society
organisations in the Open Government Round Table3 network who represent the third sector,
as well as with the ministries contributing to the implementation of the action plan. The draft
action plan also went through a round of public consultation via Estonia’s public engagement
website osale.ee.
The key areas of the action plan were identified on the basis of the realisation that the
principles of open government can be implemented in Estonia in the most effective way
if these two – the development of public services and addressing public official ethics –
will be focused on. This does not imply that the principles of open government in other key
1
See the overview of the Open Government Partnership at http://www.opengovpartnership.org/.
Descriptions of all key areas can be found at http://www.opengovpartnership.org/.
3
http://www.avatudvalitsemine.ee (in Estonian),
http://translate.google.com/translate?sl=et&tl=en&js=n&prev=_t&hl=en&ie=UTF8&u=www.avatudvalitsemine.ee (in English via Google Translate)
2
3 areas are less important – it is the aim of the government to implement them all throughout
the government sector.
The development of public services is one of the central goals of the government in the
coming years. Three main fields of activity have been identified, one of them being the
development of public e-services with the aim of improving their user-friendliness and
accessibility, and increasing their security level. The second field of activity is granting free
use of public sector data with the aim of developing new applications, increasing the
transparency of governance and creating new business opportunities for companies. The third
important field of activity is a more open and predictable policy-making process, the aim
being to increase the role of civil society organisations in the government policy formation
and enhancing the dialogue between the government and citizens.
Upon addressing public official ethics, the government will focus on preventing corruption
and conflicts of interest among politicians and officials. In 2012, Estonia ranked 32nd in the
Corruption Perceptions Index of Transparency International. The fact that Estonia's rank has
not improved significantly in the last few years is a motivator for efforts in this key area. The
government’s goal is to achieve a situation whereby citizens actually find that corruption has
decreased in Estonia.
The present self-assessment report has been prepared by the Government Office about the
first implementation year of the action plan. The guidelines from the Open Government
Partnership and the Good Engagement Code of Practice4 have been followed in the process.
The report will be supplemented by an independent evaluation from experts.
The implementation of the Open Government Partnership principles is a journey. We have
much to be proud of, but we also have enough things to be critical about and to improve in the
future. Last year has enabled us to take some significant steps in this journey. In addition to
progress in the planned activities, this period is characterised by a strong increase in the
activity of citizens and in the expectations for a more open government. The People's
Assembly5 is a landmark event of 2012, presented also to the Bright Spot competition of the
Open Government Partnership by the Estonian Open Government Round Table, and gaining a
chance to share the experience at the Open Government Partnership Annual Summit in
London on 31 October 2013.
2. THE PREPARATION PROCESS OF ESTONIA'S ACTION PLAN
The preparation of Estonia's action plan for participating in the Open Government
Partnership started in January 2012. Coordinated by the Ministry of Foreign Affairs,
preliminary consultations concerning the activities and conditions of Estonia’s joining the
Partnership had been held beforehand with the representatives of civil society organisations
and the Steering Committee of the Open Government Partnership. Also, Estonian
4
5
http://valitsus.ee/en/government/engagement-practices
An overview of the People's Assembly can be found in Appendix 1.
4 representatives from the Government Office and the Ministry of Foreign Affairs had
participated in the international Open Government Partnership conference in Brazil on 7-8
December 2011, giving the overview of Estonia's plans in preparing the Action Plan related to
the goals of Open Government Partnership.
By mid-January 2012, a draft action plan had been prepared by the Government Office
and it was introduced to the Open Government Round Table, which comprises the
representatives of Estonia's civil society organisations. The representatives of the round table
presented their comments and proposals to the draft action plan by 31 January 2012. The
same time frame applied for collecting input from the ministries.
After incorporating the feedback from the Open Government Round Table and the ministries,
a new draft of the action plan was again presented to the Open Government Round Table for
input on 15 February 2012. Improved by the new proposals made by the Round Table, the
updated draft was then presented to the Round Table for another round of consultation on 28
February. Taking into account the proposals that had been submitted by 5 March, the
Government Office prepared an amended action plan draft that was presented for public
consultation for a two-week period.
Public consultation was held on 13-28 March 2012 on the public engagement website
osale.ee. The general public was informed of this process and its schedule through the media.
The opinions obtained in the course of public consultation together with the feedback from
the Government Office were published on the engagement website6.
In parallel with the public consultation, the activities in the action plan were coordinated with
the appropriate ministries. The action plan was completed by late March 2012 and it was
made publicly available in both Estonian and English7.
During the whole process of the action plan preparation, interested civil society
organisations were actively engaged through the Open Government Round Table, which
is a network open for everyone who would like to have a say in implementing the
principles of open government. The Round Table was established in autumn 2011 so that
the third sector could be a strong partner for the government in the Open Government
Partnership activities. The Round Table served as a contact point, collecting the proposals of
the citizens and acted as a dialogue partner. A representative of the government was present at
the meetings of the Round Table.
6
The documents are available at https://www.osale.ee/konsultatsioonid/index.php?page=consults&id=210 (in
Estonian).
7
https://valitsus.ee/UserFiles/valitsus/et/uudised/istungid/istungitepaevakorrad/AVP%20Eesti%20tegevuskava.pdf (in Estonian),
http://www.opengovpartnership.org/country/estonia/action-plan (in English).
5 3. IMPLEMENTING THE ACTION PLAN
In the first implementation period, the main focus was on two key areas of the Open
Government Partnership: the development of public services and addressing public
official ethics. A total of 15 activities were planned, which were divided into four fields of
activity: the development of public e-services; granting public use of the state’s information
assets; greater openness and predictability of policymaking; and, avoiding corruption and
conflicts of interest. The first three fields of activity contribute to the development of public
services, while the fourth is for addressing public official ethics. The activities are coordinated
by the Ministry of Justice, the Ministry of Economic Affairs and Communications, the
Ministry of Finance, the Ministry of the Interior and the Government Office.
During the report period, 9 activities were fully implemented, i.e. 75% of all activities
initially planned for this period, and 60% of all activities of the action plan. At present, 6
activities are being implemented; of those, 3 are being implemented according to the initial
schedule, while in the case of the other 3 the schedule has been updated. All planned activities
continue to be topical and meaningful, including the fully implemented activities – further
activities have been initiated.
Starting from next page, more detailed information is presented about each activity across key
areas and fields of activity, following the structure of the action plan. An overview of the
activities’ implementation statuses has been added to the structure.
6 The Structure of Estonia's Action Plan in Participating in the Open Government
Partnership
Key Area 1: Development of public services
Field of Activity A: Development of public e-services
Activity 1: Drawing up a green paper on organisation
of public services
Activity 2: Implementation of the eesti.ee action plan
Field of Activity B: Granting the public use of state
information assets
Activity 1: Drawing up a green paper on making
public data available in a machinereadable form
Activity 2: Creating a repository of public data
Activity 3: Launching pilot projects of public data
services based on the cloud technology
Field of Activity C: Greater openness and predictability of
policymaking
Activity 1: Interactive guidelines and training for
implementing the Good Practice of Public
Engagement
Activity 2: Launch of the impact assessment system
Activity 3: Overview of ministries’ work processes
Activity 4: Integration of impact assessment into the
process of public engagement
Fully implemented
In process, updated
schedule
In process, updated
schedule
Fully implemented
Fully implemented
In process, updated
schedule
Fully implemented
In process according to
the schedule
In process according to
the schedule
Key Area 2: Addressing public official ethics
Field of Activity: Prevention of corruption and conflicts
of interest
Activity 1: Creation of a database of declarations of
economic interests
Activity 2: Adjustment of the system of funding nonprofit organisations and establishment of a
disclosure system
Activity 3: Preparing the proposal for drawing up anticorruption strategy
Activity 4: Draft Anti-corruption Act
Activity 5: Establishment of the Public Ethics Council
Activity 6: Organisation of ethics training for
employees of various public sector
organisations (incl. public servants)
7 In process according to
the schedule
Fully implemented
Fully implemented
Fully implemented
Fully implemented
Fully implemented
Key Area 1: Development of public e-services
Field of Activity A: Development of public e-services
Activity 1: Drawing up a green paper on organisation of public services
Status: Fully implemented.
Purpose: Analysis of problems relating to the organisation of public services,
suggestion of possible solutions, setting the focus of development of
services and drawing up and discussing the further action plans for
resolution of main issues relating to the organisation of public services.
In charge: Ministry of Economic Affairs and Communications
Deadline: 2012
Expected result: The green paper on the organisation of public services has been drawn up
and prerequisites for drawing up the Action Plan for the resolution of
problems relating to the organisation of public services have been created.
Contents and By drawing up the green paper on the organisation of public services
schedule: (henceforth: GPOPS), the following was achieved:
• the concept of public services was verbalised,
• the problems of citizens and entrepreneurs utilising public services
and those of the state and local governments providing them were
gathered in a generalised form,
• possible solutions to the problems were presented,
• the measures for solutions were identified,
• the basic principles for developing the services in the future were set.
The first draft of the GPOPS was presented to almost 80 institutions and
interest groups for discussion in May 2012, and it was also discussed at
various round tables. After incorporating the input from the discussions, a
new version of the document was made public in the Draft Information
System and the public engagement website osale.ee in September 2012.
This version was also separately introduced to the Open Government
Round Table. The draft was improved based on the feedback received
from the consultation and various meetings.
At the same time, officials in charge of preparing the green paper were
also starting pilot projects developing the basic services in a new way
(e.g. the project of business processes analysis within the governing area
of the Ministry of Social Affairs) in order to test future development
directions and, based on that experience, to improve the content of the
GPOPS with good practices.
The government approved the GPOPS on 16 May 2013 and the GPOPS is
publicly available8.
Results and The goals were achieved: a common approach to the present situation was
impact: agreed upon together with the possible solutions and the preparation of a
further action plan. The focus for developing the services in the future was
set.
Additional Further pilot projects have grown out of the GPOPS preparation process,
8
http://www.mkm.ee/avalike-teenuste-roheline-raamat (in Estonian)
8 expected results
and plans for
their
implementation:
Risks:
Challenges:
Lessons
learned:
e.g. services’ redesign in the Estonian Road Administration. The solutions
identified in the GPOPS will be implemented in 2014-2015 in the
framework of the programme “Improvement of the Quality of Public
Services”, which is financed by EU structural means.
GPOPS is also direct input to the Estonian Information Society
Development Plan 2014-2020, which will form the basis for the
development of public e-services and e-state in general in the coming
years.
Implementation of the planned solutions: administrative capability and the
availability of sufficient resources.
Because of the complexity and the scope of the topic and the whole
subject area, there were many of the stakeholders with whom numerous
agreements had to be reached in substantial matters. This took longer than
expected as there was a need for more discussion and consultation on the
drafts.
• It is a good idea to start practical pilot projects in tandem with the
theoretical planning of policy: this is a source of valuable experience
that can be extended and passed on as a part of policy
recommendations.
• When dealing with complex topics, time should be allowed for
discussing and agreeing on basic principles even if this means not
meeting the activity deadline – the end result will be more solid.
• If the subject is too large initially (e.g. the development of public
services), it should be focused and narrowed down as necessary (e.g.
to a part of public services – in the case of GPOPS, the focus was set
on transactional services), so that the work could start from
somewhere instead of endless discussions with no action and no real
results.
Back to Action Plan structure
Activity 2: Implementation of the eesti.ee action plan9
Status: In process according to an updated schedule.
Purpose: The purpose is to improve the functionality and user friendliness of the
eesti.ee portal.
In charge: Ministry of Economic Affairs and Communications
Deadline: 2012
Expected result: a) By the end of 2012 Estonia’s information gateway eesti.ee will be a
secure, fast, high-quality and user view-oriented public sector service
and information portal that offers the citizen updated and relevant
public sector information and public services.
b) Eesti.ee is the common point of contact for Estonian and European
entrepreneurs / citizens in Estonia where one can get information
about services available to them and use services involving simpler
information obligations.
c) Eesti.ee is ready to render authenticated electronic services to
entrepreneurs / citizens of 11 EU Member States and allow
9
The story of development of the eesti.ee portal has been submitted as an inspiring example of Open
Government Partnership. See Appendix 3.
9 entrepreneurs / citizens of 9 EU Member States also to sign
documents in addition to authentication.
d) Eesti.ee is the main channel through which the citizen can subscribe to
notifications to be sent to their e-mail and mobile phone.
Contents and The main projects completed so far:
schedule: • In August 2013, a new "My Things" view was opened at eesti.ee that
lets the user see information and services relevant to her/him
specifically when entering the portal, i.e. eesti.ee has become more
personal;
• The notification module has been developed further and notification
services have been added (e.g. notification about the expiry of a driver's
license);
• Citizens / entrepreneurs of 11 EU member states can log in to eesti.ee
with their eID – the required interfaces have been developed.
Results and
impact:
Additional
expected results
and plans for
their
implementation:
Risks:
Challenges:
Lessons
learned:
Additionally, a widespread eesti.ee campaign was carried out in 2012 to
increase the number of people using the portal and to better acquaint the
present users of eesti.ee with its features.
The number of users of eesti.ee has grown. A more significant orientation
of eesti.ee on the user view has been achieved which is expected to make
the portal much easier to use. The entrepreneurs / citizens of 11 foreign
countries can be authenticated and use Estonian e-services.
The goal for the first half of 2014 is to finish the major developments that
have been planned so far. The following developments are under way:
• The development of the mobile version of eesti.ee (work in process, the
aim is to come up with at least a beta version by the end of 2013 – for
increasing the usage, which will be a result of increased ease of access
due to the possibility of using the portal on mobile devices);
• Adding notification services in cooperation with various institutions,
and informing users of this service;
• Expanding entrepreneur-orientated functionality.
With these developments and marketing activities carried out in 2014 and
beyond, additional results are expected to be achieved, including
becoming the common contact point for entrepreneurs and achieving an
increase in the number of users of notification services.
Delays and growing expenses of IT development. Low user awareness of
the features offered by eesti.ee.
• Determining the owners of services: eesti.ee is only a channel where
the owners of various services from various institutions can offer their
services. Today, the owners of services in institutions (responsible
officials) have often not been determined, which causes deficiencies in
the development and the quality of the services (e.g. not all individual
services within eesti.ee are easy to use).
• Finding the resources required for development – this, together with
procurement procedures, is the reason for not meeting activity
deadlines; the solution was found in redirecting the means within IT
investment measures.
In order to achieve the expected results, not only the development should
be concentrated upon, but also the “recruitment” of new users and
10 informing the existing users of the new services. It is very important to
ask users for feedback as this helps the development of better solutions
and services, e.g. the personal view of eesti.ee "My Things" was
significantly improved as a result of direct feedback received from test
users.
Back to Action Plan structure
Field of Activity B. Granting the public use of state information assets
Activity 1: Drawing up a green paper on making public data available in machinereadable form
Status: In process according to an updated schedule.
Purpose: The goal is to map the starting position and possibilities of making
Estonia’s public data available in machine-readable form and to develop
and discuss with stakeholders the conceptual solution of proceeding with
making public data available in Estonia.
In charge: Ministry of Economic Affairs and Communications
Deadline: 2012
Expected result: The green paper on making public data available in machine-readable
form has been drawn up and specific activities for making public data
accessible have been developed.
Contents and In December 2012 a partial draft of the green paper was prepared on the
schedule: basis of existing research and initial discussions; the draft mostly
contained guidelines for state institutions on starting the process of
making data publicly available.
Additional
expected results
and plans for
their
implementation:
After that, the scope was widened from being just the green paper: in
2012 a draft for changing the Public Information Act was started. The
main aim of it was to adopt the provisions of the EU Directive about the
re-use of public sector information, as there was a threat of infringement
proceedings being started against Estonia. With the same draft, the
government also proposed making data publicly available in machinereadable form. The law was passed in the Parliament on 5 December
2012, setting the deadline for data making the data publicly available by 1
January 2015.
The work on the preparation of the green paper will continue in 2013 so
that its contents will be in accordance with the law: the paper should
support the implementation of Public Information Act with the relevant
workflow organisation and recommended actions. The aim is to present
the green paper to the government in early 2014.
The green paper should offer the conceptual solution for moving forward
with making public data available in Estonia, including the fulfilment of
the obligation to make all databases freely available by 1 January 2015 –
the solution that was initially sought after.
Risks: Continued lack of administrative capability, i.e. delays in recruiting new
specialists.
Challenges: • Reaching agreements on the best policy steps – the idea that open data
is necessary and valuable is not shared within all state institutions:
there is a need to increase awareness and allow time for discussions.
11 • The completion of the activity has been somewhat delayed by the
departure of specialists who were leading this topic in the Ministry of
Economic Affairs and Communications.
Lessons The movement towards open data is not accepted by default: economic
learned: approach or some priority-grounded approach is needed, as various
administrators of databases have opposed interests on the basis of
practices deployed so far (e.g. requiring a fee for making data available).
Back to Action Plan structure
Activity 2: Creating a repository of public data
Status: Fully implemented.
Purpose: To create a single window for citizens and entrepreneurs to access public
machine-readable data.
In charge: Ministry of Economic Affairs and Communications
Deadline: 2012
Expected result: A single window for accessing public data in machine-readable form has
been created and it also works as a channel for exchanging information
and allowing citizens and entrepreneurs to make proposals for opening
new data or developing new services.
Contents and As a first step in encouraging access to public data in machine-readable
schedule: form, a common window, the web-based repository opendata.riik.ee was
opened in January 2012 in cooperation between the Ministry of Economic
Affairs and Communications and the researchers of Tallinn University of
Technology. This is a beta version that has all the basic functionalities for
making the data available.
Results and To date, five data collections have been referenced and shared through the
impact: repository, including data that was shared in pilot projects. In addition to
the repository, the website also includes guidelines for making databases
available in machine-readable form, entrepreneurs and citizens can make
proposals, the initial applications that have been created on the basis of
open data are referenced and a forum is open for users. This has created
the basic functionality for easy access via a common web window to open
data and also to the applications that have been developed based on it.
Additional Growth in the number of users of the repository and securing the addition
expected results of available databases. For 2014, a renewal of the repository is also
and plans for considered – for making it more user-friendly (including the design of a
their new user interface).
implementation:
Risks: • The solution is not user-friendly enough, i.e. it is not easy to use and it
is not visually attractive.
• The sharers of data and potential users will not reach the repository, i.e.
the solution will not become a comprehensive repository.
Challenges: Creating a solution that is as simple as possible, so that adding and finding
datasets would be as convenient as possible. Researchers’ help was used
for this, following best practices and examples from other countries.
Lessons Putting up beta versions of technical solutions is a good idea; this will
learned: allow their gradual development, and not remaining waiting for major
(political) steps which may take time.
Back to Action Plan structure
12 Activity 3: Launching pilot projects of public data services based on the cloud
technology
Status: Fully implemented.
Purpose: To lower the barriers of access to public data as much as possible using
new technologies and launch specific pilot projects.
In charge: Ministry of Economic Affairs and Communications
Deadline: 2012
Expected result: Specific services based on public data have been launched as pilot projects
– the monitoring of navigation marks, planning public transport routes
and an innovative query system of the construction works register being
first in line.
Contents and Four pilot projects were started in 2011 to try out different solutions for
schedule: opening the data and making it publicly available, and for trying out
different technical solutions for developing the services on their basis (e.g.
data formats, cloud solutions, etc.).
The pilot projects included the following data:
• Public transport routes,
• Database of the construction works register,
• Financial data of local governments,
• Markings of water routes and ports.
Results and
impact:
Risks:
Challenges:
Lessons
learned:
All four pilot projects were completed in 2012, reaching the stage of
publication of data and starting services. Most attention was attracted by
the publication of local governments' financial data in September 2012 in
cooperation with the telecom company Elion. In the course of the project,
the website www.riigipilv.ee was launched as well as the application LEO
(Läbipaistev Eesti Omavalitsus - Transparent Estonian Local
Government) based on it, which offers substantial visual overview of the
financial status of various local governments, including their expenses.
All four pilot projects were launched. They have been the expected source
of knowledge and experience regarding barriers (incl. legal and technical)
that hinder the process of making public data accessible, as well as
solutions (incl. formats, organisational structure, etc.). This knowledge
will be used in the future when preparing the green paper of making
public data accessible in a machine-readable form, notably when
developing guidelines and policy actions.
Unsustainability of services born as pilot projects, i.e. not finding
resources for maintaining them.
Certain experiments had to be made in the case of each pilot project, and a
learning curve was gone through, as these were innovative initiatives in
Estonia. It took somewhat longer than expected.
• It may be necessary to change legal acts regulating data collections to
facilitate the process of making public data accessible in required
volumes and ways.
• The awareness of data collection administrators needs to be increased
as well as the capability to move towards open data.
• As demonstrated by the publication of the financial data of local
governments, which was met with significant public interest, there may
still not be a sustainable business model behind the publication of data
13 of interest. Therefore, the state will have to finance the publication of
important data, at least in the initial stage of the project.
Back to Action Plan structure
Field of Activity C. Greater openness and predictability of policymaking
Activity 1: Interactive guidelines and training for implementing the Good Practice of
Public Engagement
Status: In process according to an updated schedule.
Purpose: Smooth implementation of the Good Practice of Public Engagement
approved by the Government of the Republic in 2011.
In charge: Government Office
Deadline: 2012
Expected result: Online guidelines on the use of the document of Good Practice of Public
Engagement have been drawn up and relevant training has been carried
out.
Contents and The purpose of the trainings is to give officials practical experience for
schedule: increasing participation in their institution.
Results and
impact:
The trainings started in March 2013. There is a plan to train 300 officials.
By May 2013, the number of people who had passed the training was 115.
It is too early to assess the impact of this measure, but the trainings on
public engagement have been met with enthusiasm. The number of
targeted participants for the training is approximately 15% of the whole
workforce of the ministries.
The engagement handbook is being updated and will be ready by early
October 2013. The preparation of interactive guidelines has been delayed
because of the delays in preparing the handbook.
Additional
expected results
and plans for
their
implementation: A new website of the government will be launched in November 2013,
which entails the unification of the content of the webpages of ministries.
In the course of that, engagement will become one of the 5 main menu
topics, so that information about engagement possibilities will be more
accessible.
Risks:
Challenges:
Lessons
learned:
For the evaluation of the state of public engagement, a survey is planned
for 2014 and a thorough overview of engagement will be based on that
survey.
The number of officials going through the trainings is not sufficient for
the critical effect; the time frame for them to obtain the necessary skills
and get acquainted with the system is too short.
Lack of suitable trainers hinders organising training courses in the
required volumes.
The need for training is greater and sometimes more specific than planned
initially. The readiness to react quickly and flexibly to arisen needs is
required. Therefore, trainings have also been carried out by officials of the
Government Office instead of relying on outsourced trainings only.
Back to Action Plan structure
14 Activity 2: Launch of the impact assessment system
Status: Fully implemented.
Purpose: To initiate the impact assessment co-financing programme which supports
the application of the impact assessment methodology (as part of the
Smart Decisions Fund) – through which the assessment of the impact of
strategies, legislation and Estonia's positions in the European Union.
In charge: Government Office
Deadline: 2012
Expected result: Impact assessment of the major effect of strategies, EU positions and
legislation is carried out.
Contents and Starting from 2013, an initial impact analysis is required for all EU
schedule: matters, for subject area development programmes as well as for 50% of
legislation drafts and drafts of secondary legislation based on them.
Results and To date, the system has kicked off more actively with EU-related matters,
impact: less with the strategy documents and legislation drafts. Initial impact
assessments are carried out in all EU-related matters every week, which is
also where the initial (best) practice is being developed.
The understanding of the necessity of impact assessment has increased
among officials and initial skills to implement it are developing.
Assessment of the functioning of the impact assessment system is planned
for 2015.
In recent years, the government has approved the need to perform a more
thorough impact analysis in most important policy matters; the analyses
are partially funded from central funds. Financing decisions have been
made in four cases so far, and there is the experience with all three kinds
of impact analysis (EU-related matters, strategy documents, draft
legislation).
Additional In 2014, the system will be implemented in full, which means that no
expected results important legislation draft can be passed to the government for discussion
and plans for unless impact analysis has been performed.
their
implementation: Government regulations will also be added to the list of things for which
impact assessment is required, and the impact assessment requirements
will apply 100% to the preparation of legislation and drafts of secondary
legislation.
Risks: The main risk is the chance that impact assessment will devalue, i.e. that
too little added value is seen in impact assessment compared to the
relatively large volume of work it requires.
Challenges: • The need for training is remarkable and it is difficult to supply it
quickly. There are still many officials who are not acquainted with the
requirement of impact assessment.
• Change in the organisation of work in ministries so that the capability
of analysis would increase considerably (e.g. collaboration between
policy departments and analysis units, increase in analytic skills etc.).
• Change of culture in the public sector towards more open public
discussion and analysis of impact.
Lessons The need for training and dissemination of information is significant in
15 learned: the starting phase of the system; satisfying this need should have begun
earlier and the readiness to provide support should have been bigger
(including initial feedback, e.g. in the form of good practices, guidelines
and examples for working with templates etc.).
Back to Action Plan structure
Activity 3: Overview of ministries’ work processes
Status: In process according to the schedule.
Purpose: Smooth implementation of the Good Practice of Public Engagement
approved by the government in 2011.
In charge: Government Office
Deadline: 2014
Expected result: The legislative drafting process of the ministries can be monitored at an
earlier stage and at a larger scale.
Contents and The minimum requirement: making sure public e-consultation of the
schedule: drafts is always carried out in cases where it is required.
Through the public engagement contact persons inside ministries and
through trainings10, the message that the requirements of The Good
Practice of Public Engagement must be fulfilled has been constantly
promoted. This will continue to be the case in the coming period.
Results and In 2013 in the ministries’ public engagement related self-assessment it
impact: became clear that in general the ministries have become used to planning
public engagement consciously in case of the drafts that presume or
require it – it is considered, who, why and when should be involved. This
proves that participation has become more systematic. As a rule, clear
objectives are set in the course of public engagement planning, but it is
rather rare that the required public engagement plan is prepared.
The Government Office is ready to start stopping drafts and not passing
them on to the Government of the Republic if the public engagement
requirement has not been fulfilled.
There is a plan to discuss with the ministries’ public engagement contact
persons about how the effective practices of public engagement could be
transferred to other ministries as well. It is also a question how to have
more homogeneous public engagement practices within ministries.
Additional
expected results
and plans for
their
implementation:
Risks: Top-level administration will not see the need to reorganise work and to
change the work planning processes towards being more open.
Challenges: Raising the awareness among stakeholders outside the public sector about
the benefits of a more open planning process.
Lessons More time should be planned for carrying out major changes and change
learned: agents found from inside as well as outside of the public sector.
Back to Action Plan structure
Activity 4: Integration of impact assessment into the process of public engagement
Status: In process according to the schedule.
10
More information can be found on public engagement trainings at Key Area 1, Field of Activity C, Activity 1:
Interactive guidelines and training for implementing the Good Practice of Public Engagement.
16 Purpose: To integrate public engagement and the impact assessment methodology
that was approved by the government in 2012.
In charge: Government Office
Deadline: 2014
Expected result: Through impact assessment, the society and the stakeholders have better
opportunities to assess whether the decisions of the government are
reasoned.
Contents and Impact analysis reports have become a part of public consultation
schedule: materials. At the same time as there are practically no reports to this date,
there is also no immediate experience as to how they should be presented
in the course of a public consultation and what role do they play in the
explanation of a draft act.
Results and The Good Practice of Public Engagement refers to the Impact Assessment
impact: Methodology and vice versa, creating the basis for integrating these
processes. Whenever there is a chance to convey messages (e.g. trainings,
presentations), the Government Office always refers to them together.
As there are generally different officials in a ministry who are in charge of
the two different processes, the processes do not yet work together
smoothly.
The awareness of ministries about each of the processes separately has
improved. In practice, this means that when drafts are prepared, the need
to plan time for both impact analysis and public engagement is
recognised, but there are not enough skills yet to combine the two.
Additional There are no additional expected results.
expected results
and plans for
their
implementation:
Risks: If the awareness of the necessity of impact assessment and public
engagement (as well as the development of relevant skills) does not reach
each and every official in departments overseeing policies, there is a
danger of having these processes being completed with either insufficient
quality or in a hurry. The risks and challenges related to these topics have
been highlighted earlier.11
Challenges: Continuous need to raise awareness on all levels.
Lessons It is too early to point out.
learned:
Back to Action Plan structure
Key Area 2: Addressing public official ethics
Field of Activity: Prevention of corruption and conflicts of interest
11
More information can be found on public engagement risks and challenges at Key Area 1, Field of Activity C,
Activity 1: Interactive guidelines and training for implementing the Good Practice of Public Engagement; more
information can be found on impact assessment risks and challenges at Key Area 1, Field of Activity C, Activity
2: Launch of the impact assessment system.
17 Activity 1: Creation of a database of declarations of economic interests
Status: In process according to the schedule.
Purpose: Prevention of conflicts of interests and strengthening the anti-corruption
attitude of public sector employees; further cultivation of ethical behaviour.
In charge: Ministry of Justice
Deadline: 2014
Expected result: The created database contributes to the prevention of conflicts of interest
and corruption in the public sector.
Contents and The Anti-Corruption Strategy was passed on 6 June 2012 and it became
schedule: effective on 1 April 2013. Section 13, subsection 4 of the law, which will be
the basis for establishing a registry of economic interests by the
Government of the Republic, will become effective on 1 January 2014.
On 12 December 2013, a lead group of the development of the registry of
interests was established on the basis of a directive of the Minister of
Justice, with participating officials from the Ministry of Justice, the
Ministry of Finance, the Tax and Customs Board, the Centre of Registers
and Information Systems and the Information Technology Centre of the
Ministry of Finance.
Results and
impact:
To date, the vision and functionality of the electronic declaration of
economic interests have been developed as well as a substantial description
of the form of declaration of interests. There was a public tender for the
organisation of the electronic declarations. The deadline of the tender was
30 September 2013.
Declaring interests will become significantly easier and quicker for officials
with the creation of the new registry of interests; at the same time, it allows
for much quicker and more efficient monitoring.
By the end of October 2013, the statutes and the form of the registry will be
developed. Until the opening of the registry of economic interests in April
2014, technical development works will be taking place. The first round of
declaring economic interests will be completed by 31 May 2014.
Additional
expected results
and plans for
their
implementation:
Risks: Not adhering to the schedule because of a heightened need for coordination
between the two ministries and various agencies.
Challenges: The effective and fruitful organisation of work.
Lessons It is too early to point out.
learned:
Back to Action Plan structure
Activity 2: Adjustment of the system of funding non-profit organisations and
establishment of a disclosure system
Status: Fully implemented.
Purpose: Prevention of corruption in the private sector and non-profit sector.
In charge: Ministry of the Interior
Deadline: 2013
Expected result: A system of disclosure of non-profit organisations’ funding from the state
budget and from the budgets of local authorities has been created inside the
concept of the development of a common system for funding non-profit
18 organisations from the state budget (the public has an overview of allocated
support).
Contents and The aim of the activity is to create a consistent system of state financing for
schedule: non-profit organisations on state as well as local government level,
strengthening the civil society and contributing to the sustainability and the
growth of the institutional capabilities of the non-profit organisations.
For the creation of a consistent financing system, common financing
principles were established by spring 2012, and by 31 March 2013,
financing guidelines were prepared along with sample documents. In
between, the guidelines were tested in late 2012 in the Ministry of the
Interior and three local government units and the guidelines were improved
based on the feedback from the test participants. The guidelines are publicly
available12.
To apply the guidelines, a total of 18 trainings were organised in the period
from 8 November 2012 to 27 March 2013 in towns of various counties, with
the total of 379 people participating from ministries, local governments and
non-profit organisations. Also, a consulting service was offered regarding
the guidelines in December 2012 and January 2013. Also, a financingrelated public debate was held with the representatives of public sector and
civil society organisations in January 2013 and Frequently Asked Questions
was drawn up along with the answers.
Results and
impact:
Additional
expected results
and plans for
their
implementation:
The development and the implementation of the guidelines was supported
by marketing activities that had been planned so that they would attract as
much attention as possible in the local and national media.
Guidelines’ implementation monitoring will be carried out in 2014 to
evaluate the impact. To date, some ministries and institutions have already
redesigned or adjusted their financing systems for non-profit organisations
in accordance with the guidelines.
In order to ensure that all parties will start following the principles in the
guidelines which are not required, but “recommended”, and that the
practices of financing non-profit organisations would become
homogeneous, follow-up activities are planned in the Civil Society
Development Programme 2011-2014 implementation plan for 2013-2014.
The monitoring, mentioned in the previous subsection, will be carried out in
order to get an overview of the present state and the potential barriers in the
implementation process of the guidelines. The everyday work of the
cooperation network of financers will also continue as well as the fostering
of cooperation of the units who provide state budget financing for nonprofit organisations – in order to improve the financing procedures of the
projects. There is a plan to organise experience-sharing round tables for the
representatives of local governments.
In 2014, additional trainings will take place. The trainings are designed for
the officials of ministries and local governments who work with non-profit
12
https://www.siseministeerium.ee/public/juhendmaterjal13032013.pdf (in Estonian)
19 organisatsions and allocate funds to them.
Risks: Application of the recommended guidelines is a long-term process that may
show real results in a couple of years' time only. The nature of the
guidelines, being “recommended” may impede their implementation.
Challenges: Hosting the processes of engagement and giving and collecting feedback:
the guidelines have been worked out through the cooperation of
approximately 300 people.
The guidelines need implementation. The closer the financing of non-profit
organisations is to the processes and examples described in the guidelines,
the more certain the financer can be that the financing is following the
principles of good financing practice.
Lessons • No period of time was planned for practical application of the guidelines
learned:
in the programme framework, but it would have been valuable.
• The implementation of the guidelines must be strongly lead by the
Ministry of the Interior and more public debate is needed.
Back to Action Plan structure
Activity 3: Preparing the proposal for drawing up anti-corruption strategy
Status: Fully implemented.
Purpose: To analyse the performance of the effective anti-corruption strategy and lay
down the objectives and courses of action of the new strategy that would
best contribute to a decrease the corruption to a maximum extent possible in
both the private and public sector.
In charge: Ministry of Justice
Deadline: 2012
Expected result: The objectives and courses of action of the new strategy have been widely
debated and approved by the government; the drafting process of the new
strategy has started.
Contents and Although the current activity foresaw the preparation of the proposal for the
schedule: Anti-Corruption Strategy 2013-2020, by the time of the current reporting it
is also possible to give an overview of the preparation of the strategy that
followed the proposal. The proposal was completed as of 3 January 2013.
More than 100 people from approximately 60 organisations (including the
Chamber of Commerce and Industry, the Association of Estonian Cities, the
Association of Municipalities of Estonia, Network of Estonian Non-profit
Organisations, Estonian Qualifications Authority, Estonian Service Industry
Association, NGO Transparency Estonia etc.) participated in the preparation
of the new strategy.
Both the proposal for the preparation of the new strategy as well as the
strategy itself went through public consultations, the consultation
documents are available13. The Anti-Corruption Strategy 2013-2020 was
sent out for approval to the relevant authorities in May 2013 and was
submitted to the government in September 2013. While preparing the
strategy, the implemented and not implemented actions of the previous anticorruption strategy were analysed and, alongside the new activities,
13
http://www.korruptsioon.ee/58421 (in Estonian)
20 attention was given to the issues in the previous strategy.
The Anti-Corruption Strategy 2013-2020 focuses on three main objectives:
• Promoting awareness of corruption,
• Increasing the transparency of decisions and actions,
• Developing the investigating capabilities of investigation institutions and
to prevent corruption that would threaten security.
To achieve the objectives, approximately 70 actions have been agreed upon.
Results and The impact of the anti-corruption strategy can be assessed over a longer
impact: period of time, primarily based on studies and international evaluations as
well as recommendations given to Estonia. Criminal statistics are also
analysed.
Additional Actions in the anti-corruption strategy are aimed at the following measures:
expected results • Raising people’s awareness of corruption and shaping their attitudes,
and plans for • Shaping attitudes towards corruption and raising awareness in the public
their
sector,
implementation: • Raising awareness in the private sector and drawing attention to
corruption prevention related issues,
• Increasing the transparency of the legislative process and political
decision making,
• Increasing the transparency of municipal financial transactions and
procedures,
• Increasing the transparency of public authorities and endorsing the
culture of corruption prevention,
• Corruption prevention and increasing the transparency of public
procurements,
• Increasing the transparency of financial allocation decisions,
• Preventing corruption and biased decisions in law enforcement
authorities and courts,
• Increasing the transparency in healthcare,
• Enhancing the analytical capacity for investigating corruption related
crime.
Risks: Potential risks may arise from the failure by the responsible authorities to
carry out activities. To avoid that, the new anti-corruption strategy
implementation foresees designating a person responsible for the
coordination of corruption prevention in every ministry.
Challenges: • As the strategy combines the authorities of different ministries, ensuring
smooth cooperation between the ministries.
• In ministries anti-corruption activities are considered the responsibility of
the police and public prosecutor’s office and therefore they fail to realise
the importance of their own actions in corruption prevention.
• As the strategy is a government level development plan, the anticorruption strategy cannot impose obligations or activities on the
parliament.
Lessons It is too early to point out.
learned:
Back to the structure of the action plane
Activity 4: Draft Anti-corruption Act
21 Status: Fully implemented.
Purpose: For the purpose of improving prevention of corruption, the restrictions and
duties of officials are clarified, the system of declaration of interests is made
more efficient and liability arising from violation of law is stipulated. The
draft Act decreases the administrative burden, increases transparency in the
public sector and raises Anti-corruption awareness in society.
In charge: Ministry of Justice
Deadline: 2012
Expected result: The system of the restrictions and duties of officials has been clarified and
the system of declaration of interests has been made more efficient for
the prevention of corruption.
Contents and The Draft Anti-Corruption Act was sent for consultation on 16 May 2011.
schedule: On 7 November, the bill was sent for a second round of consultation.
Results and
impact:
Additional
expected results
and plans for
their
implementation:
The bill was sent to the government on 8 February 2012, and the Parliament
started hearing the matter on 8 March; the Act was adopted on 6 June 2012
and took effect on 1 April 2013.
The new Anti-Corruption Act allows for using arrangements corresponding
to the nature of the functions and the corruption risk in a public entity, and
does not aim to impose uniform restrictions. In practice, this may lead to a
certain rise in administrative burden because corruption risks have to be
analysed and appropriate legal tools must be identified to mitigate these
risks. The public entity also has to ensure that public officials are aware of
corruption threats and legal obligations.
The Ministry of Justice leads the implementation and drafting of anticorruption policy, and will make amendments the Act when necessary.
Risks: • Problems may arise from implementing the Act due to lack of
implementing practice.
• As the new Act imposes the absolute obligation to declare one’s interests
in a register on a certain number of people, it will be a challenge to
implement the system in such a way that other officials would be subject
to declaring their interests only if there are no other efficient tools for
preventing the corruption risk. The implementation of such a system
requires careful analysis and implementation anti-corruption measures.
Challenges: It is too early to point out.
Lessons It is too early to point out.
learned:
Back to the structure of the action plane
Activity 5: Establishment of the Public Ethics Council
Status: Fully implemented.
Purpose: To create an independent Ethics Council with the aim of strengthening the
core values and ethics of public official’s tenure.
In charge: Ministry of Finance
Deadline: 2013
22 Expected result: The Ethics Council has been founded and it operates on a regular basis. The
Ethics Council gives advice to authorities and public officials in public
service ethics matters and delivers opinions on the compatibility of
behaviour with applicable public official’s ethics requirements.
Content and The founding of the Ethics Council was prescribed in the Public Service Act
time frame: that took effect on 1 April 2013. The Public Service Ethics Council was
established by the Government regulation no 294 on 27 June 2013. The
Ethics Council has nine members with the majority comprised of active
public officials. The first meeting of the Ethics Council where the time
frame for future actions of the Ethics Council will be set is to take place in
autumn 2013.
Results and The founding of the Public Service Ethics Council enables the preparation
impact: of the new code of ethics of public servants, which the Ethics Council will
approve and support its uniform application.
Expected It is important to ensure regular operation of the Ethics Council, the
supplementary engagement of public authorities in the activities of the Ethics Council and
results and the communication of the opinions of the Ethics Council to public
plans for authorities and to the society.
implementation:
Risks: • Considering the limited availability of time of the members of the Ethics
Council, ensuring the regular operation of the Ethics Council is critical.
• It is impossible to predict the number of requests that the Ethics Council
will receive.
Challenges: The negations over the composition of the Ethics Council took longer than
expected.
Lessons It is too early to point out.
learned:
Back to the structure of the action plane
Activity 6: Organisation of ethics training for employees of various public sector
organisations (incl. public servants)
Status: Fully implemented.
Purpose: Increasing the awareness of the public sector target groups of the main
values of the public sector and the development of skills of ethical
resolution of problematic situations.
In charge: Ministry of Finance
Deadline: 2012
Expected result: The target group of public ethics training has been extended to cover all
public sector employees. Regular trainings are carried out under the Central
training programme.
Content and 18 trainings were planned for public servants and 10 to more wide ranging
time frame: target groups from the public sector under the Central trainings 2012-2013
programme. The trainings received €33,909.18 of financing with 85% of the
sum covered by the European Social Fund. The trainings are organised by
the Estonian Academy of Security Sciences Public Service Development
and Training Centre.
Results and The trainings took place as planned. In addition to public service target
impact: groups, the programme covers the members of municipal governments and
councils and the employees of partially government or municipally owned
enterprises, foundations, non-profit organisations and bodies under their
23 administration.
In relation to the new Public Service Act and Anti-Corruption Strategy
taking effect, the training programmes were updated in 2013 to increase the
emphasis on explaining the operational and procedural restrictions that
come along with the new legislation.
Expected The need for continuation of ethics trainings is foreseen for 2014. Since no
supplementary resources have yet been allocated, actions are planned for raising the
results and necessary resources.
plans for
implementation:
Risks: As of 2014, there is a risk of not finding resources for financing the
activities since the current programme ends and the financing principles of
the new programme may change.
Challenges: To ensure the continuation of public service and public sector ethics
trainings in 2014.
Lessons With the new Public Service Act taking effect, changes had to be made to
learned: the content and target groups of the training programmes. As the employees
of public authorities do not fall under the code of ethics of public servants,
they were redirected to the public sector ethics training programme. This
change needed further clarification in the months after the Public Service
Act took effect.
Back to the structure of the action plane
4. SUMMARY
Estonia is committed to implementing the principles of Open Government Partnership and
continues to pursue the originally set objective of drawing the attention of the government and
the society to the quality of governance, learning from other countries’ experience and sharing
Estonia’s experience with other partnering countries.
The biggest challenge lies in establishing a more open culture of governance, which presumes
high expectations on the part of the society towards the political elite and civil servants. The
shaping of civil servants’ attitudes and skills as well as designing new technological solutions
to support a more engaging policy-making will takes place in that context. The support of the
political elite is an additional resource for more effective fulfilment of the set commitments.
One of the most important lessons learned from the reporting period is that besides the usual
ways of engagement (including voting, making proposals to the government and expressing
one’s opinions about bills) people can constructively convene to express their dissatisfaction
and to make suggestions regarding better governance as proven by the example of the
People’s Assembly. In such cases the sensible reaction of the government is to support the
citizens’ initiative and to create conditions for taking the feedback on board. The strength of
the People’s Assembly process was achieved through cooperation between the leaders of civil
society and public institutions (the President, the Parliament). All parties contributed to
creating an appropriate environment for channelling dissatisfaction into constructive value
24 adding proposals to the Parliament as the highest representative body, offering everyone the
possibility to participate in the process. It is too early to assess the long-term impact of the
People’s Assembly, but the suggestion of creating a legal basis for such a process shows the
high level of confidence in the setup among the participants.
From the very beginning, we have believed here in Estonia that in order to successfully
participate in Open Government Partnership we need to integrate domestic endeavours with
international objectives and principles. Through that, we are able to ensure that the set
objectives are relevant and realistic and the progress towards their achievement is monitored
and reported. The cooperation between the Ministry of Foreign Affairs and the Government
Office, with the Government Office coordinating the work of ministries contributing to the
Open Government Partnership action plan, and the Ministry of Foreign Affairs representing
the Open Government Partnership initiative as a whole, can be considered rather productive,
but the lack of a clear and visible leader has had a somewhat holding back effect in terms of
the perception of the importance of the Open Government Partnership among both the closer
circle of participants and the broader society.
For the Open Government round table and the representatives of the public sector, the first
year of participation in the Open Government Partnership has been a time to get to know each
other. The round table has the task of generating new ideas and monitoring government
actions, which has occasionally also meant expressing dissatisfaction with the relative
slowness or low ambition of the developments. Constraints and opportunities related to the
planning and implementation of government actions are closely linked to the provisions of the
Action Programme of the government.
The above-mentioned aspects should be taken into account when preparing the next action
plan for Open Government Partnership participation. The levels of ambition, the willingness
among parties to take responsibility and available resources should be aligned. It is time to
suggest new activities; the selection of the most viable and feasible will follow in the
upcoming months when the action plan will be revised. None of the actions in Estonia’s first
Open Government Partnership Action Plan has lost its relevance and will continue to be
implemented over the new period. We are also eager to learn from international practice and
are willing to share our experience in order to globally promote open governance values.
25 Appendix 1. Open government round table: People’s Assembly in Estonia – crowdsourcing solutions for complex problems
A former Estonian MP, member of the ruling Reform Party, announced in 2012 that the
party’s officials gave him 7600 euros of unknown origin that he then had to donate to the
party. He claimed that dozens of members had donated funds to the party this way, including
MPs.
Although the party rejected the accusations and the subsequent investigation was ended due to
a lack of hard evidence, the public did not find party’s denials convincing. Widespread protest
yielded to the street demonstrations and petitions in autumn, demanding more transparency in
party funding as well as more dialogue and openness in the political system.
How to turn this wave of activism into something constructive? Civil society activists
proposed crowdsourcing as a method for finding solutions to these complex problems.
A working group of CSO and political parties’ representatives gathered in November, 2012.
Five weeks later a website was opened where everyone could propose ideas for improving the
situation in the areas such as elections, public participation, political parties and their funding.
Within three weeks, it gained 60’000 visitors; 1’800 registered users posted nearly 6’000
ideas and comments. All these were grouped and provided with impact analysis by scholars
and practitioners. These were sent to the Deliberation Day on 6th of April, where a
representative sample of 314 people discussed the pros and cons of ideas and casted then their
preferences. The outcomes were presented to the Parliament who has then set a timetable
when these legislative changes will be discussed in the formal procedures.
The impact of this process, called People’s Assembly, is yet too early to summarize. None of
the legislative changes has been done so far, but they are in the agenda. The process clearly
proved that if good conditions are created, people are willing and capable to participate in the
policy making. Crowd-sourcing mechanisms can provide a valuable tool for implementing the
principles of open government and bridging the gap between government and the public. 26 Appendix 2. Open Government Partnership case study from
Estonia – the development of the government portal eesti.ee
A strong focus of the Estonian Open Government Partnership Action Plan is to develop public
e-services. This means various structural changes in the administrative processes that will
result in the improvement of the availability and user-centeredness of public services. A key
commitment in this area is to improve the state portal eesti.ee in terms of functionality and
user-friendliness. The aim is to build it into the primary e-service and government information
gateway for Estonian residents and entrepreneurs – thereby making access to government
easy and accessible for everybody.
There are several developments ongoing with eesti.ee in this aim, but one truly key step was
the creation of personal data and service view. It was launched in August 2013, although
some beta versions had been out already since the beginning of the year.
The idea of personal view is that after the user logs in securely with Estonian national eID
(either ID-card or mobile ID)14, he/she will be able to view all of his/her core data and service
statuses on one web-page. Each line of information also comes with links to related e-services
in order to easily take the user to further data viewing or applications or other transactions
within the portal.
For example, up-to-date information bits will be listed about the person’s family, real estate or
business matters; notifications about his/her documents’ validity and various due deadlines
(e.g. taxes or applications); basic health insurance related information; etc. In this way there is
no need for him/her to waste time on searching and navigating the portal any longer for core
services, allowing desired services to be reached faster and more conveniently.
After the launch of personal view, the feedback from users has been very positive as they
have longed for such easy access to core data and services – most users have very basic
service needs only, so they want to get things done fast.
People are especially appreciating the newly added notifications service. Only very few of
us regularly check and remember whether our driver’s license is about to expire or when our
pet should get the next annual vaccine or when the next tax declaration is due. In all these
cases, the duty to perform some steps lies with the individual. At the same time, the
government does know via various e-services which deadlines are coming up and when. Thus,
the government might as well take a step towards the users and provide this information as a
notification service. Then it will be easier for people to avoid getting into trouble with
deadlines, while legal compliance also rises and this benefits the government.
The motivation behind the initiative was that a) people expect a rising level of userfriendliness from government e-services, b) private sector online services have offered similar
possibilities for some time already (e.g. banks). Thus, user expectations and needs were the
driving force. The initiative arose bottom-up from the state portal development team like is
the case with most Estonian e-governance innovations.
14
See http://e-estonia.com/components/electronic-id-card and http://e-estonia.com/components/mobile-id for
more info on Estonian nation-wide eID system.
27 Building of the personal view page that combines data from a big variety of governmental
databases and services was possible because of X-road: the data exchange system that
Estonia has been using since 200115. X-road is the interoperability solution that carries highly
secure Internet-based data exchange between all governmental as well as some private
information systems. It enables connecting of any independent datasets and systems into
comprehensive e-services like the personal view page – and to do all this in a simple, uniform
and cost-efficient manner. At the same time there are very high levels of accountability.
Anyone accessing the system leaves a record, something that is viewable by the citizen.
There is still much to do to make this personal view of state portal services even more
personalized. For example, we can offer customized page views based on smart analytics on a
person’s activities in the portal and other data known to service provider. Also, we are
currently preparing to take the state portal to a mobile platform. This will make the personal
data and service view even more conveniently accessible for all users.
It’s things like these that often make a difference. They might not seem too big-of-a-deal at
first glance. Yet, in the end they contribute much to the e-service user experience and thereby
help to bring government closer to people.
More information: Siim Sikkut, Government Office of Estonia, siim.sikkut@riigikantselei.ee
15
See for more information: https://ria.ee/x-road/
28 Estonian Informatics Centre
eGovernment in Estonia: Best
Practices
Ahto Kalja1, Aleksander Reitsakas2, Niilo Saard2
1Inst. of Cybernetics at Tallinn Univ. of Technology,
Akadeemia 21, 12618 Tallinn, Estonia
2Cell Network Ltd., Toompuiestee 5, 10142 Tallinn, Estonia
ahto@cs.ioc.ee, aleksander.reitsakas@cellnetwork.com,
niilo.saard@cellnetwork.com
PICMET´05
1
Estonian Informatics Centre
Content
I Introduction
II The general architecture of eGovernment
environment in Estonia
III Results of Estonian eGovernment projects
IV Special citizens web portal with db-services
V Estonian ID card and PKI infrastructure
VI eServices
VII A new generation eService “Parental benefit” in
Internet
VIII Statistics
IX Conclusions
PICMET´05
2
Estonian Informatics Centre
I Introduction
eGovernment in Estonia got started by developing a functional
architecture that includes:
-  secure data transport backbone X-Road,
-  distributed information systems functionality and
-  different hardware and software components like portals,
elements of public key infrastructure (PKI), governmental
databases and information systems.
This is the very basis of hundreds of services that have been
created today. The recent success with eGoverment services
and the common architecture of eGovernment will be given in our
presentation.
PICMET´05
3
Estonian Informatics Centre
II The general architecture of eGovernment
environment in Estonia
The architecture of eGovernment was developed in the framework of the
X-Road project.
X-Road project was preliminarily initiated for interconnecting Estonian
governmental databases to the common data resource accessible over
the Internet.
After the successful start of sending database queries and answers over
the Internet, the X-Road environment was expanded to send all kinds of
XML-format electronic documents securely over the Internet.
At the same time the X-Road started to become a skeleton of all the
eGovernment services.
PICMET´05
4
Information systems
IS of
Estonian
Tax and
Customs
Board
Population
Register
CA of X-road
Estonian
Motor
Vechicle
Registration
Centre
x5
…
other IS
for ex.
MISP II
Services
Services
Estonian
Informatics Centre
X-road
centre
Banks
Hansa bank
Union bank.
Kreditb.
Sampo bank.
Nordea bank
HELPDESK
Monitoring
a) authent.
b) payment
c) services
Centr.server II
Services
(Elion)
AS
AS
AS
AS
AS
SS
SS
SS
SS
SS
Centr.server I
X-road
Information portal
http://www.eesti.ee
SS
Internet
Information portal
for enterpreneurs
SS
Central
register
of DBs
Riik.ee
(for civil servants)
SS
SS
ID-card
KIT
EIT
AIT
(Citizens’ portal)
(Enterpreneurs’ portal)
(Civil servants’ portal)
PICMET´05
Environments developed by government
CA
5
Certification agency
Estonian Informatics Centre
3-layers architecture I
Services
Data transport
X-road
Databases
PICMET´05
6
3-layers architecture II
Technology
Estonian Informatics Centre
Components
III layer
WSDL
UDDI
II layer
SOAP
XML RPC
LDAP
…
I layer
Oracle
Progres
MySQL
…
Services
Data traffic
X-road
Databases
PICMET´05
Parential benefit
My vehicles
My penalties
…
Security server
Central server
MISP
Citizen portal
…
Traffic register
Population register
Passports register
…
7
Estonian Informatics Centre
III Results of Estonian eGovernment projects
ring the last 3-4 years we have finished different IT projects for implementing
overnment architecture in the public sector of Estonia. As the result of the
ntioned projects, the following service portals, environments and frameworks
now available in Estonia:
• 
Special citizens web portal with db-services. Portal has won an award
Finalist with Honourable Mentions of the eEurope awards for
eGovernment 2003. The portals eServices will step-by-step be added
to the citizen portal (KIT) in the nearest future;
• 
Framework of the facilities for using Estonian ID-card (over 50% of
Estonian population has already an electronic ID-card) with PKI technology
for identification, authorization and digital signature operations;
• 
Citizens, civil servants and entrepreneurs web portals with almost 500
different eServices from different Estonian central and local governments.
er we will describe some of these environments projects more precisely.
PICMET´05
8
Estonian Informatics Centre
IV Special citizens web portal with db-services
All services available through the citizen's portal have a common user
interface, which is not dependent on a database management system for
back office.
A standard authentication system for all citizens has been developed as well.
The set of standard services available include typical queries, such as:
"give me my data" from the population register;
"give me my data" from the motor vehicles register.
PICMET´05
9
Estonian Informatics Centre
Authentication
Users
CA of
servers
CA of
citizens
Portal
Citizen
Central
Central
server
server
Adapterserver
Database
Security
Security
server
server
Internet
SSL channels,
Security
Security
digitaly signed
server
server
encrypted messages
Civil
servant
Central
monitoring
Local
monitoring
MISP
Local
monitoring
IS of an
organizat.
Database
processors
Functional scheme
PICMET´05
10
Estonian Informatics Centre
V Estonian ID card and PKI infrastructure
The purpose of Estonian ID-card project was to use nation-wide electronic
identity and develop a new personal identification card that would be
a generally acceptable identification document and contain both visually and
electronically accessible information.
On December 18, 2001 the parliament established ID-card as a compulsory
identity document and the Estonian passport is thus only a travel document to
travel abroad. On January 28, 2002 the first ID-cards were issued to Estonian
citizens. Today (25.7.2005) over 50% (803 000 people) of the Estonian
population (1.4 million) has an ID-card.
There exists a lot of similar projects in other countries (Belgium, Finland,
Italy etc.), but using of ID-card services at large you can find in Estonia as
in pilot country.
PICMET´05
11
Estonian Informatics Centre
Estonian ID card and PKI infrastructure II
The Estonian ID-card project is focused on the digital signature, which is
equivalent to the ordinary signature on paper. To achieve this aim the
Identity Documents Act as well as the Digital Signatures Act were adjusted,
which resulted in the following:
•  The certificate inserted in the ID-card includes the personal identification
code, which enables to identify the individual at once.
•  A certificate, which enables to sign documents according to the Digital
Signatures Act, is inserted in the ID-card chip.
•  Certificates inserted in the ID-card lack field of use restrictions and
therefore it can be applied in the public as well as private sector,
and also in any kind of mutual relations between individuals.
PICMET´05
12
Estonian Informatics Centre
Estonian ID card
PICMET´05
13
Estonian Informatics Centre
Estonian ID card
PICMET´05
14
Estonian Informatics Centre
VI eServices
The set of facilities for the IS, which are joined to the X-Road environment:
• Authentication (ID-card + 5 Internet bank services);
• Authorization;
• MISP (Mini Info System Portal) portal services;
• Simple queries to Estonian national databases;
• The facilities for developing complex business model
queries (queries to different databases and registers);
• The writing operation into databases;
• The facility to send large amount of data (over 10Mb) from database
to database over the Internet;
• Secure data exchange, logs storing;
• Queries surveillance possibility;
• The integration with citizen portal for adding new services;
• The integration with entrepreneurs portal for adding new services;
• Central and local monitoring;
• The special database for storing services WSDL descriptions.
PICMET´05
15
Estonian Informatics Centre
VII Best practice
•  Parential benefit in Internet
• 
5 information systems interact the data
–  Citizens’ portal
–  Register of Social Insurance Board (+MISP)
–  Population register
–  IS of Health Insurance Fund
–  IS of Tax and Customs Office
PICMET´05
16
Estonian Informatics Centre
DBs
Users
Register of Social
Insurance Board
Citizens’
portal
Citizen
Population register
X-road
MISP
IS of Health
Insurance Fund
Civil servant
IS of Tax and
Customs Office
Parential benefit in Internet
PICMET´05
17
Estonian Informatics Centre
Best practice for citizen
•  Citizen can give applications over the Internet
•  Citizen does not give data, which the IS knows anyway about the
citizen
•  Citizen does not fill long application documents and run from door to
door
•  A good example how the state has simplified the payment system
PICMET´05
18
Estonian Informatics Centre
Best practice for civil servant
• 
• 
• 
• 
Civil servant is free from revising mountains of paper documents (7)
Civil servant is free from inputting the data from paper documents
Civil servant is free from checking data in different databases
Civil servant can start the process by inputting only the personal
code of client
•  There does not exist any paper applications at all
PICMET´05
19
Estonian Informatics Centre
VIII Statistics
At the moment we have following clients:
•  Organizations: Number of agreements – ~350
Databases/Service providers:
•  All service providers: 34
Security servers:
•  Number of agreements for SS: 76
MISP servers:
•  Number of agreements for MISPs: 41
PICMET´05
20
Estonian Informatics Centre
Statistics
Services:
•  The number services from all the X-road service providers ~500
The statistics of usage:
•  During the year 2003, the total number of X-road queries was:
590 000.
•  Number of queries made via thr X-road in 2004: over 7.75 million
•  Daily record of queries in 2004: 118 000 queries per day
PICMET´05
21
Estonian Informatics Centre
IX Conclusions
We are sure that our projects for eGovernment framework development
and portals are making significant contributions to the process of moving
towards the information society. Our environment represents Estonian
and European best practice in the application and usage of new
technologies in order to provide eServices to citizens, to civil servants
and to entrepreneurs.
PICMET´05
22
Estonian Informatics Centre
PICMET´05
23
Estonian Informatics Centre
PICMET´05
24
Estonian Informatics Centre
PICMET´05
25
Estonian Informatics Centre
PICMET´05
26
Estonian Informatics Centre
PICMET´05
27
Estonian Informatics Centre
Thank you!
PICMET´05
28
The Estonian ID Card and
Digital Signature Concept
Principles and Solutions
Ver 20030307
Contents
Contents .........................................................................................................................2
Status of the document...............................................................................................3
Introduction................................................................................................................3
Intended audience ......................................................................................................3
Current project status .................................................................................................3
Principles........................................................................................................................4
Digital signature regulation........................................................................................4
Digital signature concept .......................................................................................4
Certification Service Providers (CSP-s) ................................................................4
Time-stamping Service Providers (TSP-s) ............................................................4
Supervision – Registry and Ministry .....................................................................5
Foreign Certificates................................................................................................5
Identity Document Regulation...................................................................................5
Mandatory document .............................................................................................5
Card appearance and layout ...................................................................................5
Electronic data on card...........................................................................................6
Certificates .............................................................................................................7
E-mail address........................................................................................................7
Data protection.......................................................................................................7
Organizational structure, card issuing and operation.............................................8
Solutions ......................................................................................................................10
Certificate profiles and e-mail addresses .................................................................10
Certificate validity verification methods .................................................................10
OCSP, time-stamping and evidentiary value of digital signatures ..........................10
Document format and DigiDoc................................................................................11
Roles, authorizations and organizations' validations ...............................................12
New ideas: replacement and alternative cards .........................................................13
2
Status of the document
This document is prepared by AS Sertifitseerimiskeskus (www.sk.ee). You may
freely distribute it in original verbatim form (without making any changes). The
Estonian ID card project information, including the newest version of this whitepaper,
is available online at http://www.id.ee. You may contact us at info@id.ee.
Introduction
Estonia has implemented ID card as the primary document for identifying its citizens
and alien residents living within the country. The card, besides being a physical
identification document, has advanced electronic functions that facilitate secure
authentication and legally binding digital signature, in connection with nationwide
online services.
This whitepaper gives an overview of the principles behind the project and explains
the choices and decisions made while carrying out the card project. It also presents an
overview of how the associated services and applications are implemented.
Intended audience
The first part of the whitepaper, "Principles", is written for decision-makers and
potential common users from a legal and economic perspective. The second part,
"Solutions", is for implementers and assumes knowledge about basic PKI concepts.
Current project status
The first Estonian ID cards were issued in January 2002. In one year, more than 130
000 cards have been issued, and the total figure is expected to grow to more than 350
000 by the end of 2003 (about 25% of the whole population).
The card is meant to be universal and its functions are to be used in any form of
business, governmental or private communications. It is already helping people to
make everyday communications more convenient. You can find more details about
the implementation and applications below.
3
Principles
Digital signature regulation
Estonian parliament (Riigikogu) passed the Digital Signature Act (hereinafter DSA)
on March 8, 2000, and it entered into force on December 15, 2000. The law regulates
issues that are essential for implementing a nationwide PKI and digital signature
infrastructure. The law is available online at
http://www.legaltext.ee/text/en/X30081K3.htm.
Digital signature concept
According to the Estonian DSA, digital signatures are equivalent to handwritten ones,
provided that they are compliant with the requirements set forth in DSA and if other
laws do not regulate otherwise. Thus as a rule, digital and handwritten signatures
should be equivalent in document management in both public and private sectors.
DSA also states that public sector organizations must accept digitally signed
documents.
The requirements set forth in DSA to digital signatures state that digital signature
must uniquely identify the signatory, be bound to the signed data in such a way that
makes changing the data after signing impossible without invalidating the signature,
and identify the time of signing (assuming the use of time-stamping or equivalent
time establishment technology).
In the terms of EC directive 1999/93/EC, DSA only regulates advanced electronic
signatures. Other types of electronic signatures can of course be used, but DSA does
not give them legal power.
Certification Service Providers (CSP-s)
DSA regulates the work of CSP-s in Estonia, setting forth requirements to them and
regulating their operation and supervision. CSP-s may only be legal entities with a
regulated minimum share capital, they must be entered in the National Certificate
Service Provider Registry (see below) and must carry out an annual audit to ensure
organization and system reliability. CSP-s must also have liability insurance to
safeguard against compensating faults made while providing the service.
It is important to note that according to DSA, CSP-s certify only real persons
identifiable by name and ID code – issuing certificates to pseudonyms is not currently
covered by DSA. It was discussed in the parliament during the law adoption process,
but was considered to be an additional unnecessary risk and so far, no need for this
has been seen.
Time-stamping Service Providers (TSP-s)
DSA also regulates the work of TSP-s and the comparison of time stamps between
TSP-s. The requirements to service providers are generally the same as those to CSP4
s. According to DSA, a time stamp is simply a data unit that proves that certain data
existed at a certain moment. DSA does not define time stamps in more detail, but
states that they must be bound to the timestamped data and issued in such a way that it
would be impossible to change the timestamped data without invalidating the
timestamp.
Supervision – Registry and Ministry
The National Registry of Certification Service Providers contains data about all
Estonian CSP-s and TSP-s. Although it confirms the public keys of CSP-s, it is
technically not a root CA in Estonia. Instead, it functions as a supervisory authority,
confirming the results of service providers’ annual audits among other things. The
Ministry of Economy and Communications, in whose administration area the registry
works, has the right to verify audit results and inspect the service providers’ premises
and relevant information.
Foreign Certificates
DSA regulates the recognition of foreign certificates, stating that in order for them to
be recognized equivalent to those issued by Estonian CSP-s, they must be either
confirmed by a registered CSP, be explicitly compliant with DSA requirements or
covered by an international agreement.
Identity Document Regulation
Identity documents in Estonia are regulated by the Identity Documents Act. The law
is available online at http://www.legaltext.ee/text/en/X30039K7.htm.
Mandatory document
According to the Act, possessing an ID card is mandatory for all Estonian residents
and also for all aliens who reside permanently in Estonia on the basis of a valid
residence permit with a period of validity of at least one year. There are no sanctions
for not having a card, but it is expected that as the first Estonian passports were issued
in 1992 with validity period of 10 years and they are expiring, most people will apply
for either only ID card, or ID card together with passport when renewing their
documents in the period 2002-2006. By the end of 2006, one million cards will have
been issued.
There is only one version of the document: there are no different optional features that
users can opt out of or choose to (not) have. All documents are equipped with a chip
containing electronic data and certificates (see below). It is understood that some
users may have doubts or fears about electronic use of the card, but remedies are
provided for that: if users do not wish to use the electronic functions of their cards,
they can suspend the validity of their certificates, thus making it impossible to use the
card electronically. Certificate suspending or revoking also removes user's data from
public certificate directory.
Card appearance and layout
The card looks as follows.
5
Front side of the Estonian ID card.
Back side of the Estonian ID card.
The front side of the card contains the card holder's signature and photo, and also the
following data:
• name of card holder
• personal code (national ID code) of card holder
• card holder birth time
• card holder sex
• card holder citizenship
• residence permit details and other information (if applicable)
• card number
• card validity end
The back side contains the following data:
• card holder birth place
• card issuing date
• card and holder data in machine-readable (ICAO) format
Electronic data on card
Each ID card contains various pieces of data. All the above data except photo and
handwritten signature are also present on the card in electronic form, in a special
publicly readable data file. In addition, the card contains two certificates and their
associated private keys protected with PIN codes. The certificates contain only the
holder's name and personal code (national ID code). In addition, the authentication
6
certificate contains the holder's unique e-mail address. Read more about certificates
and e-mail address below.
Certificates
Each issued ID card contains two certificates: one for authentication and one for
digital signing. There are also two associated private keys, protected by two separate
PIN codes, on the card. The certificates contain no restrictions of use: they are by
nature universal and meant to be used in any form of communications, whether
between private persons, organizations or the card holder and government. They
contain no roles or authorizations: those most come using some out-of-band method
(also see below, "Roles, authorizations and organizations' validations").
The certificates contain the card holder's name and national ID code. It is agreed in
Estonia that this data is public by nature. The certificates identify the card holder
uniquely because even though there may be name overlaps, the national ID code is
unique. In addition, the authentication certificate contains the card holder's e-mail
address.
E-mail address
The authentication certificate on each ID card contains the card holder's governmentassigned e-mail address in the format firstname.lastname_NNNN@eesti.ee, where
NNNN are four random numbers. The random numbers are necessary to provide
unique e-mail addresses even to persons with the same name. The address does not
change with subsequent certificate or card issuing – it is guaranteed to be a person's
"lifetime" address.
There is no real e-mail service associated with the address. It is a merely a relay
address which forwards e-mails to users' "real" addresses (e-mail accounts). Each user
must configure the forwarding addresses using an online service made available for
this purpose, and may reconfigure the addresses as often as he or she pleases. Up to
five forwarding addresses can be specified.
The address is supposed to be used in communications from government to the
person, but it can also be used in communications between persons and companies
and private persons themselves. The addresses are available online to anyone through
CSP-s certificate directory.
The address can be used as a simple e-mail address, but using the address and the
authentication certificate on the card, users can also digitally sign and encrypt their email. The digital e-mail signature is not legally binding and not covered by DSA, but
it provides receivers additional confirmation of sender authenticity. E-mail encryption
and signing using certificates on smart card is a standard function of various e-mail
applications.
Anti-spam measures are implemented in the forwarding server. In addition, spamming
is illegal in Estonia and spammers will be prosecuted accordingly.
Data protection
The data protection question is not very relevant in the context of Estonian ID card
because there is very little private data involved in the card issuing and further
7
utilization process. There is a broad Personal Data Protection Act in effect in Estonia
which regulates the use of personal data and databases containing personal data by
public authorities and private entities, and Estonian Data Protection Inspection is the
government body overseeing that the requirements of the act are met and enforcing
compliance if necessary.
The certificates on the card are available publicly in a directory service and contain
only the card holder's name and personal ID code, which are considered public data
by nature in Estonia. In addition, e-mail addresses in authentication certificates are
also available in the directory. The directory contains only valid (active) certificates:
if a person suspends or revokes his certificate, it is also removed from the directory
and the data are no longer available.
The public data file is not published anywhere online. The personal data on the card in
visual and electronic format are accessible only to those persons to who the card
holder physically presents the card.
The general stance to ID card and data protection in Estonia is that the card should
contain as little private data as possible. Instead, the data should be kept in databases
at relevant authorities, and a person can use the card as key (authorization method) to
access his or her data in the database.
Organizational structure, card issuing and operation
The card issuing as well as its further operation is done in close public private
partnership. There are three main organizations who are associated with issuing and
operating the ID card and the associated infrastructure.
Estonian Citizenship and Migration Board (hereinafter CMB) is the government
organization responsible for issuing identification documents to Estonian citizens and
alien residents, as required in the Identity Documents Act. CMB is in the supervision
area of Estonian Ministry of the Interior. CMB receives the card application from
citizens.
AS Sertifitseerimiskeskus ("certificate centre", hereinafter SK), founded by two
major Estonian banks Hansapank and Eesti Ühispank and two telecom companies
Eesti Telefon and EMT, functions as CA, maintains the electronic infrastructure
necessary for issuing and using the card, and develops the associated services and
software. SK also takes care of delivering the card to its holder through Hansapank
and Eesti Ühispank bank offices.
TRÜB Baltic AS, subsidiary of Swiss TRÜB AG, is the company that personalizes
the card.
The card issuing process consists of the following steps.
1.
person fills in application for the card, indicating the bank branch office where
he or she would like to receive the card
2.
CMB receives application from person
3.
CMB stores the application and forwards its data to TRÜB
4.
TRÜB personalizes the card
8
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
TRÜB gives the card the order of generating private keys (internal function of
the card, the keys will never leave the card) and prepares the secure PIN
envelopes
TRÜB formulates certificate requests (2 per card) and forwards them to SK
SK issues the certificates, stores them in its directory and returns the
certificates to TRÜB
TRÜB stores the certificates and personal data file on the card chip
TRÜB prepares the final delivery envelope, enclosing the card, secure PIN
envelope and an introductory brochure
TRÜB hands the final delivery envelope over to CMB
CMB hands the final delivery envelope over to SK (CMB has outsourced the
card delivery to SK)
SK sends delivery envelope to the bank branch specified in the original
application (done using security couriers)
person receives the delivery (containing card and PIN codes in separate
envelopes) from the bank branch office
upon receipt of the card, certificates are activated and published in directory
For further operation of the card, SK maintains the associated electronic services
including an LDAP directory service, OCSP validation service and other necessary
services for online validity and digital signature confirmations. SK also provides the
software to anyone interested in creating applications to the card and digital signature,
and provides a readymade client and web portal for giving and verifying digital
signatures (see below, "Document format and DigiDoc"). In addition, SK maintains a
24-hour telephone hotline which can be used for immediately suspending the validity
of certificates in case of card loss or theft.
9
Solutions
Following are a number of issues and questions that have been solved when
implementing the Estonian ID card and digital signature infrastructure.
Certificate profiles and e-mail addresses
The certificates on Estonian ID cards are standard X509v3 certificates. The
authentication certificate contains the card holder's e-mail address. The certificate
profile is available in a separate document.
Certificate validity verification methods
According to Estonian DSA, CSP-s must provide "a method of verifying certificate
validity online". SK as the issuer of certificates to ID cards provides users three ways
of checking certificate validity.
CRL-s are provided, containing the list of suspended and revoked certificates. CRL-s
are standard but outdated method, because as of January 2003, CRL size has grown to
over 1 MB in one year and it is not very convenient to use. CRL-s are mainly
provided for backwards compatibility and standards compliance. SK updates its CRL
twice a day. Delta CRL-s are not provided.
The second method is an LDAP directory, containing all valid certificates. The
directory is updated in real time – if a certificate is activated, it is uploaded to the
directory, and if it is suspended or revoked, it is removed from there. Among other
things, this provides everyone a chance of finding the e-mail address of any ID card
holder. Restrictions are in effect as to the maximum number of responses returned to
one LDAP query to protect against server overload.
The most convenient method of verifying certificate validity is SK-s OCSP service. It
can be used for simple certificate validity confirmations, but also for validity
confirmations ("notary confirmations") to digital signatures. SK provides a standard
OCSP service compliant with RFC 2560. An important detail is that according to the
RFC, OCSP responses are supposed to be based on CRL-s and therefore may not
necessarily reflect the actual certificate status. In contrast, SK has implemented its
OCSP service in such a way that it operates directly off its master CA certificate
database and does not use CRL-s. Thus, SK-s OCSP responses reflect actual (realtime) certificate status. In terms of the RFC, the response's thisUpdate and
producedAt fields are equivalent.
OCSP, time-stamping and evidentiary value of digital
signatures
For legally binding digital signatures, time is an extremely important factor.
According to the Estonian DSA as well as common sense, only signatures given using
a valid certificate are to be considered valid. On the other hand, to provide remedy to
the risk that the signing device (ID card) may be stolen together with PIN-s and
digital signatures could be given on behalf of the user by someone else, users have the
chance of suspending their certificate validity using a 24-hour telephone hotline
operated by SK. With these two concepts combined, users must be able to clearly
10
differentiate the signatures given using a valid certificate from those given using a
suspended or revoked certificate. Thus, there is a need for a time-stamping and
validity confirmation service which binds the signature, time and certificate validity.
Another important concept concerning signature validity is that the signature must be
valid also when the certificate has already expired or been revoked. If a certificate is
suspended by the card holder or anyone else, the card holder can reactivate it at a
bank office.
A number of experimental time-stamping protocols and technologies have been
proposed, but no common understanding or agreements of time-stamping is present,
the experimental technologies are under constant development and not in mass use.
Thus, an innovative approach was needed. SK chose to base its time-stamping
implementation on standard OCSP. The protocol contains a Nonce field, which
protects against replay attacks. Instead of cryptographically random data, the Nonce
field is set to contain the hash of the data to be signed, because it can also be
interpreted as just a random number. According to the RFC, the OCSP responder
signs its response which in SK-s case, contains the original nonce (document hash),
response providing/signing time and ID of the certificate used to give the signature,
binding the three pieces of data together and providing the validity confirmation for
the digital signature. SK stores the signed response in its log as evidence material.
SK has implemented all of the above, including both client and server parts, in its
DigiDoc digital signature architecture.
Document format and DigiDoc
In order to bring digital signatures into everyday life, common understanding and
signature handling practices are required. In addition, software and technology must
be available for anyone interested, in order to create compatible applications. After
all, the key to unleashing potential digital signature benefits lies in communication
between organizations, not within one organization. Therefore, it is vital that all
organizations in a given community interpret and understand digital signatures the
same way. In case of Estonia, the community is the whole country.
A number of digital signature implementations and applications are available on the
market, all claiming to be suitable for specific purposes. However, no known
application or implementation of the latest standards was found which would suit the
needs of the Estonian project, and reliance on foreign software providers guaranteeing
the functioning of a country's everyday life relying on digital signatures can also be
seen as a strategic risk. Therefore, a whole new approach – and a whole new software
architecture – was needed.
In 2002, SK together with its partners created an all-around digital signature
architecture dubbed DigiDoc. As the name suggests, DigiDoc aims to meet all the
needs users might have about digital signature creation, handling and verification.
On the server side, DigiDoc provides an RFC2560-compliant OCSP server, operating
directly off the CA master certificate database and providing validity confirmations to
certificates and signatures. On the client side, it provides a number of components.
11
The most important component is digital document format, which is key to common
digital signature implementation and practice. As of 2002, a number of standards have
been adopted or are in preparation. SK based the DigiDoc document format on XMLDSIG standard. However, it has several shortcomings such as allowing only one
signature per document, and in February 2002, ETSI published its extensions to
XML-DSIG as ETSI TS 101 903, also known as XAdES. DigiDoc document format
is a profile of XAdES, containing a subset of its proposed extensions. The DigiDoc
format is described in a specification document.
Based on the document format, a library was developed in C language which binds
together the following:
• DigiDoc document format
• SK-s OCSP validation service
• Interfacing with the user's ID card using Windows' native CSP interface or
cross-platform PKCS#11
The DigiDoc library provides easy-to-use interfaces to all of the above and there is no
need for application developers to know OCSP protocol specifics or DigiDoc
(XAdES, XML-DSIG) format internals. It can be embedded in any application and on
top of it, a COM interface has been implemented, making it easy to add DigiDoc
support to any Windows application supporting COM technology. A Java
implementation is also provided.
However, providing the libraries and formats was not enough because these do not
add value to end users without real applications. Although it is expected that DigiDoc
support will eventually be present in most Estonian document management systems,
web sites dealing with documents etc, a number of example or "reference"
applications are also provided. DigiDoc Client is a Windows application that lets
users simply sign and verify documents, and DigiDoc portal is an application that lets
users do the same online without the need to install any stand-alone software.
Naturally, both are based on the same DigiDoc library and thus fully compatible –
signatures given in Client can be verified in portal and vice versa.
The libraries, specifications and applications are provided to Estonian public free of
charge, and it is expected that digital signature usage in common life and everyday
business and government practices will grow significantly already in 2003. The first
official digital signatures in Estonia were given using DigiDoc Client only on October
7, 2002, and implementing the digital signature on a national scale naturally takes
some time.
Roles, authorizations and organizations' validations
In connection with implementing PKI and digital signatures, the question of roles and
authorizations has arisen in various projects. It is assumed that certificates for digital
signing may be issued for specific purposes only, and that a person's roles can be
embedded in role certificates that are then used for authenticating the certificate
holder into different systems and giving digital signatures in different roles. Thus, a
person needs additional role and signature certificates for each different role he or she
has, and the number of certificates grows, creating substantial interoperability and
scalability issues.
12
The Estonian approach states (as also said in the Estonian DSA) that a digital
signature given using a digital signing certificate is no different than a handwritten
one. A person's handwritten signature does not contain his or her role – the role and
authorization are established using some out-of-band method (out-of-band in the
context of certificates). The same approach also goes for authorization while
authenticating – a person's certificate should not contain his or her authorization
credentials. Instead, everyone has a similar universal key (authentication certificate),
and the person's role and authorization can be determined using some other method
(e.g. an online database) based on that key.
An exception to the above is organization's validation. Digital documents sometimes
need to be validated by organizations, so that other organizations can be sure of the
identity of the organization where the document originated. This is useful for e.g.
signing pieces of databases (e.g. bank statements) online, to be presented to other
organizations. For this, SK issues certificates to organizations that can be used to sign
documents digitally. Technically, they are equivalent to personal signing certificates
on everyone's ID card, but legally, they are not viewed as signatures and need not be
covered by law, because according to the Estonian law, only real persons can give
signatures. The "organizations' signatures" must therefore be viewed simply as
additional tools for proving information authenticity (that it really originated from a
specific organization) which may or may not be accompanied by a digital signature of
a real person working in that organization. Still, the PKI complexity stops here, and
besides personal and organizational signature certificates, there is no need for
personal role certificates or anything else more complex.
New ideas: replacement and alternative cards
As of the beginning of 2003, a number of ideas are being discussed for improving the
availability and usability of digital signatures in Estonia. One of them is the
"replacement ID card", or backup card. The main concern here is that the card issuing
process described above is quite complex and according to current regulations, it may
take up to 30 days for a person from the moment of presenting the application to
receiving the card. If a card is lost or damaged and a person needs to get a new one,
this may mean that he or she may not be able to give digital signatures for 30 days
which may not be acceptable in some high-stake business environments. Therefore, a
possibility could be established that current ID card holders might get a "backup card"
to minimize the extent of the above problem. However, this is currently not
implemented, and another remedy for the problem is that the above organizations will
just implement an "express service" which would be more expensive but quicker
method of getting an ID card in the "normal" way.
Another idea is that of "alternative card". National ID card need not be the only
carrier of digital signing certificates. Some large companies are already using smart
cards for their internal services, and would like to have digital signing certificates
issued by SK to be added to their internal cards. The company itself would then act as
Registration Authority, and SK would be responsible for issuing certificates in
response to certificate requests, as is also the case with regular ID cards. Still, this
"alternative card" will remain a niche solution and for the general public, the Estonian
national ID card is the universal signing tool for whatever role a person may be acting
in.
13