Estonian Electronic Identity Card and its Security Challenges

all right so as it's currently said my name is anis parchos and i am a recent phd graduate from the university of tartu and in this talk in this presentation i will share with you uh some of the findings from my phd research about the estonian electronic identity card and its security challenges now um i think i have spent last perhaps eight years studying researching this topic so there are really a lot of findings a lot of details for this specific presentation i have cherry picked some um some key things which i hope that you will find interesting so let's uh jump into the topic uh right away so let me start by introducing the stone

and electronic identity card um so um the estonian electronic identity card our id card is an identity document that is issued by estonian state and why it is interesting to us is because of this smart card chip here which is basically a small computer that is capable to generate cryptographic keys and perform cryptographic operations with these keys so basically it is a hardware security module which guarantees that the private key exists only in one copy in the cardholder's id card so the private key is generated inside the chip and if something needs to be signed the data is sent to the chip chip performs a cryptographic signature makes the signature and returns it back to the

terminal as soon as you see at least in theory it provides pretty good security features so to say so in case of restoring an id card it contains two asymmetric keys with the corresponding certificates and the certificate here is a digitally signed statement which attests that this particular public key belongs to this particular person so that we could later link digital signature to the person who created it okay so the first key is the authentication key which is used for authentication to e-services and document decryption and the second key is digital signature key which is used to give legally binding digital signatures now the reason why stand and id card is such interesting topic to study is

because it is a nationwide electronic identity scheme which was introduced already in 2002 and it is actually used in practice now as you may know uh today there are many countries in the world who have similar schemes introduced but as far as i know in none of these countries the id card is used as much as it is used in estonia and therefore i think there is a lot to learn from the estonian experience and also including the security issues and the other problems it has faced over these uh 18 years right so but anyhow whenever we talk about id card security we have to realize that this is about much more than just the security of the ship and

how secure the keys are stored there right because there is this um supporting public infrastructure there is software that implements these protocols there is a legal framework and much more right so the id card security has to be then analyzed in a much broader context and all these things we kind of can i can describe by the term id card ecosystem right all right so um let's just have a quick overview on the id card manufacturing and issuance process so this is how it looks so here we have an id card holder the person who wants to obtain the id card to get an id card the person visits the document issuer in this case police

estonian police and border cardboard the documentation themselves do not manufacture the cards this is outsourced the the cards are manufactured by the id card manufacturer for the first 15 years it was gemalto for the latest generation id card it is a company called edemia uh now dedicated manufacturer also doesn't actually produce the microcontrollers themselves so these security chips are produced by a huge semiconductor companies uh infineon which was used for the first cards and then for the latest generation card company nxp but still the id card manufacturer here is in a very important position it is a very important task because this is the id card manufacturer who initiates key generation inside the card so this

is super important that this procedure is strictly followed because otherwise the id card manufacturer could get hold of the id card private keys right which which wouldn't be good now and then there is a certificate authority which is a private estonian company skid solutions which issues certificates for the id card and here the id card manufacturer here is fully trusted by the certificate authority at any time id card manufacturer can connect to the cd authority and ask please give me a certificate with this public key and this personal data and server authority will digitally send the certificate send it back to the id card manufacturer that you can manufacture will write it into the card the card together with

pink pin envelope will be passed to the document issuer which will then pass it to the corresponding cardholder and it's also important is that to get an id guard the terms and conditions have to be signed and now these terms and conditions is illegally binding contract between the certificate authority and the id card holder so there is no way for you to obtain id card without signing these terms and conditions if you want to get id card you have to enter into these contractual relationships with the certificate authority and if you read actually these terms and conditions you will see that the certificate authority doesn't take any responsibility for the security of these generated keys so it's

all the id card holder who's responsible so anyhow so this is how the adequate manufacturing and issuance process works now over the years the electronic functionality of the id card has been implemented using different id card chip platforms by two platform i mean different hardware and software components which are running inside the card and figuring out which components exactly have been used in the id card turned out to be a quite challenging task because this information is not too well publicly documented but anyhow so here you can see the image the figure where you can see what platforms have been in used over the years and you can also see for which types of identity documents

they have been used for and so largely in estonia there have been five major id card chip platforms in use over the years this is mikardo multos jtobsles66 jtobles78 and for the latest generation of id cards this they are provided by the idemia platform a few words about each platform so this mikado platform was introduced uh from in the beginning and it was used for more than nine years and now this in for this platform the function electronic functionality of the id card was implemented by configuring the micardo card operating system so it was possible to create their key objects pin objects and then configure the access rights for these objects then later in 2010 multis platform was

introduced now you need uh this platform is used exclusively for the digital uh first generation of digital identity cards and now this multiple platform was a fully programmable card so there the functionality was implemented using low level c language and so some some someone was paid to basically implement the same functionality the same card interface as was provided by the micarta platform uh for different marketing reasons multus platform was deprecated later and in 2011 the jtox 66 platform was introduced now this jtop 66 architecture is this java card platform meaning that this platform actually runs java applets or java card uplets which is a subset of java programming language again here's some estonian spades to

implement the same functionality in a java car doublet and the cards were shipped out to the to the car holders now in practice uh this didn't went so smooth as expected because at the end of 2011 it was discovered that this java card applet has an unnamed security flaw and all these cards issued in 2011 had to be recalled and the output had to be fixed now the next uh milestone was at the end of 2014 when the upgraded jtop 78 uh platform was introduced also java card which used a newer security microcontroller now as you may remember this is this notorious platform which was vulnerable to this infineon rsa key generation flaw rockef law which was the cause for the

um id card security crisis in 2017 which i think you all remember and which was fixed basically not by changing platforms but by switching from their sat generation to elliptic curve keys here and then finally at the end of 2018 uh the idemia platform was introduced and now this edema platform is also java card but here this card is not running some applet written by some estonian but it is it is it is running a fully security certified european citizen card update which is also used in the id cards of other countries and so what is important point to make here is that this edemia platform is the first id card platform which has actually passed full security

certification so for these previous platforms uh perhaps the chip or the operating system had a security certification but not the smart card applied which is which implements the electronic functionality of the card and so the reason why estonia moved to this fully certificate certified platform is because of the legal requirements so as you have heard the european union eids regulation requires qualified signature creation devices to be security certified now before eides there was the european union directive on electronic signatures it also recognized security certification but as an alternative the member states could do compliance security assessment themselves to verify that indeed the platforms comply to the security requirements of secure signature creation devices and as far as i can tell

apparently dystonian authorities didn't do this compliance assessment before introducing these platforms only in 2015 when the eides regulation was soon to be introduced only then uh the authorities realized that but this hasn't been done and actually we have to do this compliance assessment because otherwise these cards will not be recognized under eis as a qualified signature creation devices now the status of qualified signature creation device is prerequisite for the digital signature to have this handwritten signature status if the platform doesn't have the status of the signatures created with it also doing a hell handwritten signature studies right and so what was done was that in 2015 a committee was established from four state officials uh who then issued the

the compliance assistance protocol basically stating that yes these platforms comply to the security requirements of secure signature creation devices and as you may guess this kind of assessment was rather a formality because it's unlikely that these officials actually analyze the security of the source code or dedicated components now and even more it seems to me that for in some of the cases for them on which platforms the authorities may actually haven't found out what are the except except exact uh components that are used in the into the platform and as an example um um let me discuss this in character platform so uh while visually it seems that there was a single platform used for these

nine years while communicating with the card i got um suspicious that there have actually been three different chip platforms used over the years for this mikado platform and i was also able to obtain evidence for that and so what you see here you see here three id card chip samples for from the id card issued in different times and while you can see that the contact layout of the chip is the same for all these three cards if we turn the chips around and if you remove the epoxy layer and if you take a photo of the microcontroller we can clearly see that these microcontrollers uh these cards are using three different microcontrollers and the fun fact is

that only this microcontroller which was used in the id cards issued in 2002 was security certified to be used together with demi cardo operating system now i i don't know whether whether the whether the id card manufacturer informs the authorities about these changes but as far as i can tell there is no protocol that that would have assessed the compliance uh security compliance of these changes to the requirements of qualified signature creation devices and i mean from one from one side uh you can see the benefits of this approach because uh it's it's very easy to introduce new cheap platforms and uh you can skip the the lengthy and maybe time-consuming security assessment process on the other hand the this even formal

compliance assessment is a prerequisite for the digital signatures created using these cards to help this handwritten signature status so you could say that strictly speaking uh we could challenge the validity of any digital signature which was given using these uh these platforms right but anyhow so let's say step it a bit and uh maybe maybe you're wondering how did i manage to make a photos of these microcontrollers and indeed this wasn't actually quite trivial to us to do so the first challenge was how to remove the epoxy layer from from from the chips without damaging the microcontroller and this is where the fellow phd chemistry student came in to help and what you see here is

sulfuric acid heated to 200 degrees and when this is done then the um okay um apparently one slide is missing so when it is done basically the epoxy layer um is dissolved and we can get get get hold of the plane microcontroller now the next challenge of course was how to make a high-resolution picture of that microcontroller and so first i got in touch with the university of tartu institute of technology to perhaps use their expensive microscopes but then my colleague although pets he suggested to try out this cheap usb microscope from aliexpress which you can buy for some 20 25 and indeed this this cheap device actually worked like a charm and here you can see the results

so actually order two of them one with thousand times magnification another is thousand six hundred and here we can see the results now this here is this estonian poem which is printed in a microprint on the previous generation file card so you can see actually that the zoom factor is quite nice here all right let's uh switch the topic a bit so in the context of my phd research i have also done a few studies which focus on a specific security aspect of the id card infrastructure or ecosystem and the first uh which i would like to mention you here is the research titled practical issues with steele's client server authentication which was about the use case where the

id card is used to authenticate to e-services and here you see how it looks from the user's perspective let's say i want to authenticate to the online bank i choose a student id card authentication option the certificate pop-up window is shown i click ok and then on the handshake level a signature is sent to the server proving that i have access to the corresponding private key right so in the context of this study we proposed different tests how to test the security of id card authentication implementations on the server side so we run different tests we try to submit certificates which are expired revoked and then see whether they are accepted the the most critical finding that we

found in the in the in the in the context of this research was that the two biggest banks in estonia uh said bank and swedbank that their implementations failed to verify whether this certificate is actually issued by the trusted certificate authority which basically meant that it was possible to create fake certificates and essentially bypass the id card authentication process now at the end of uh last year uh computer science bachelor student simeon kravchenko uh he repeated this experiment and he found a few more e-service e-services where the same type of adequate authentication flow is present and these were coop bank elisa printing city and the arved now this rv dot t was a somewhat special case because it took uh

for them more than months to to fix this issue uh because apparently they wanted to ship some also functionality improvements together with the security fix the the the other case which is a noteworthy i think is the scoop bank case uh and why because uh bank compared to other banks in estonia they are fully relying on the id card authentication so who bank doesn't use any semi secret user identifier such as username or user id as in case of other banks so what it meant in this case is that the mass exploitation was possible right so it was possible to just take the list of all identity codes go over them see who has the

bank account in the coop bank and then log into their accounts what made the matters worse here was that kubank is a provider of banklink authentication service which then meant that by exploiting this flaw uh the the person could be impersonated also in other public and private uh e-services right so you see that actually it may be a good idea to to to introduce some kind of user identifier because in this case in case of these these faults the mass exploitation could be at least slowed down in this case if you're from estonia and you are then you probably also have heard about this latest incident where the hacker downloaded close to 300 000 id guard

photos from the servers of information system authority and as far as i understand actually the the a very similar id card authentication a bypass flow was exploited in this case and unfortunately this e-service of id photo downloading was not in the list of e-services which we tested so we were not able to discover this flow before before others uh discovered um now the second paper which i would like to mention is about using the stone and electronic identity card for authentication to a machine and this was co-work with danielle morgan and now this study concerned the use case where the id card is used in terminals to authenticate the cardholder now for example you see here example

from the prisma shopping terminal where the card is inserted for the car holder to obtain loyal customer benefits right now what is super important to note here is that this use case doesn't involve any cryptography so what is done here is the terminal simply reads the personal identity code from the public personal data file which is stored in the chip and here the question was how hard it would be to build a fake id card an id card emulator where we could specify arbitrary data in this personal data file and so what we did is that we took a programmable java card we took a code from martin paliak and we extended it in a way also that

this emulator it logged the commands that were received from the terminal so this way later we could see exactly which entries from the personal data file the terminal retrieved right and it's okay so this project was a success the id card emulator was accepted as the authentic card in any terminal we tested and unfortunately we also observed that most of the terminals in shops they read the entire personal data file although only maybe the personal identity id code would be necessary to identify the person right and of course we don't know whether this data is used somewhere or or it's just that the api reads their own personal data file and the systems throw away everything except that eco anyhow

so another interesting finding here was that it turned out that it is quite trivial to transplant the fake chip to the authentic id card and here we can see the example uh this is the authentic id card and this is authentic id card with a fake chip blue glued on it and also i was surprised that actually the process was quite trivial and in this process no physical security elements of the authentic id card were damaged right so to remove the chip from the fake card it was only necessary to hold a lighter a few seconds behind the card and the chip would simply fell off now to remove the the original chip from the id card you would

have to make a cut somewhere here with a paper knife and then just remove by force of the chip and remove the glue residues which which were around there and then glue the fake chip so as you see in this process uh it's actually possible to create a authentic id card with a fake chip that's visually indistinguishable from from the from the from the authentic card now i mean in this case you can see the different differences the cheap contact layouts but actually today it's also possible to buy the cheap programmable java card chip which has exactly the same contact layout as as in the authentic card all right so the next thing which i cannot skip in the

tile in the talk title as it is is this 2017 id card crisis and i think so i have written about it quite a lot others have written i think it's well known what happened there and uh today i will not go into it but i will just remind you that this was the case which resulted in a legal dispute against the id card manufacturer gemalto because apparently gemalto knew about the flaw earlier but did not inform the authorities in a timely manner right now what i want to focus in the rest of my presentation is on some of the findings which maybe are not so well publicly known and to set a stage for that let me

introduce the id guard certificate repository now as you may know all currently valid id card certificates are published in a public ldap certificate repository and the purpose of this repository is to make the public keys available in case someone would want to make some create some encrypted file to the card holder to the recipient so over over the years time to time i have been collecting these certificates which are published in this repository and by analyzing these certificates i was able to discover some anomalies which signaled about the serious security flaws in the key management of the id card and uh so these findings have been published in detail in the the user next 2020 paper called the standard

electronic identity card security flaws in key management and i'll just go very briefly over them and and bring down the key key find findings so the first observation to mention was that there were certificates with corrupted rsa public keys and here we can see the full list of certificates now the corrupted there is a public key here means that these public key modules could be divided by small prime factors three five seven and so on now as maybe you know in rsa the public key modulus is constructed by multiplying two huge prime numbers together right so if the public key can be divided by small factors something is uh really really wrong with the key and eventually

we came to the conclusion that most likely the corruption happened on the id card production line where the public keys retrieved from freshly generated public keys retrieved from the card maybe on the electric communication line and some bits got flipped and when even if a single bit is flipped for the rsa key then it basically becomes in a way a random number right so now this seemingly purely a quality issue actually turned out to have a quite critical security consequences because if the public key becomes random number then the mathematical properties of the key are lost which means that if we could somehow recover all the prime factors that make up the corrupted public key we could also then

construct the corresponding private key right and in the case of one corrupted public key in case of svetlana's public key we actually managed to to fully factor all the factors and here you can see the process so we use the gmp elliptic core method for factorization so this is this corrupted public key modulus and here we can see that the first prime factors are found already in first few seconds then the next one and then finally here we can see the full full list of the prime factors and it took us this amount of seconds which is around 60 hours in total um so yeah we were lucky of course this is this process is uh probabilistic so

it's not guaranteed that you uh basically there is a bit of luck involved here so i guess we were very lucky here now once we have the all the prime factors we can construct the rsa private key file and then using the private key file we can sign something and see whether it works and in this case we see that indeed no surprise the digital client recognizes the signature as valid very good so point proven now a more interesting finding among the certificates where certificates with dublicate rsa public keys so what it means is that there are several pairs of certificates where the public key and certificate issued to one person matched the public key

from the certificate issue to another person and this one pair a pair issued to belonging to toeivo and we decided to investigate it further so here we can see the authentication certificate of toivo and here we can see the digital signature certificate of ullen and as i'm switching between these certificates you can see that actually the uh public key modulus is the same here and what you can also observe is that not before time that these certificates have been issued with a few second difference right now the question of course is how it could possibly happen maybe it is some flaw in the certifications process for instance the public key by a mistake was included twice in two different

certificates right now an alternative explanation is that the certificates are actually correct but the corresponding id cards uh contain the same private keys and okay today i know that these cards actually contained the same private keys but at that time that had to be established so but okay in case in case in case the private keys are the same for these cards do you see the security impact of this so what it basically means is that the ulla can create using their digital signature key she can authenticate and then torivo using his authentication keeper then can forge digital signatures in the name of ulla right uh so to test out this uh i got in touch

with toy war uh taiwa agreed to participate in the experiment so what i did is that i sent an executable to to toyo he had to run it on his computer enter uh pin one here and some signature bytes were printed out now so he sent me back this screenshot of this output i wrote down bytes from the signature i pasted them into a digital signature container and indeed this provided a proof that toy was card contains the corresponding private key and it can be used to forge digital signatures in the name of ullen all right later i also got in touch with ulla and found out that her card also contains the same private key

but then the question the million dollar question is how is it possible right because if the if the if the key is generated inside the card it should be unique for for for each card however if the key is generated outside and then copied to the card then in case of some software flaw the same private key can be imported in two different cards which which actually was the case here right and this is when we come to the finding the evidence that actually for some certain set of id cards the private keys were generated outside the id card and to make a long story short so what we did is that we generated millions of

keys using the actual id card platforms and then compared whether the properties in the public keys obtained in this process match the properties of the public keys that are inside the certificates and they should match if the same key generation agreement was used right but for a particular set of certificates they did not match and here you can see the example so this is the distribution of most significant byte of the modulus for keys generated by the platform and this is the distribution from the public keys in the certificate as you see the distributions are different which means that these keys were actually generated by some different rsa key generation algorithm than the one which is implemented by the card

now the set of these certificates belong to specific set of id cards which were renewed in a police customer service point to fix the flaw in the id cards that were issued in 2011. um so what is meant is that the the the first the person got the id card is a some unnamed four and then when they went to upgrade or fix it they actually got the copy of private key injected in their card um not very successful fixing of the issue i would say right what's also super important to note here is that um this practice of of of generating uh these keys outside the card was present for five year period this was done over five year period and

in this time none of the audits of the certified authority neither internal nor external found these non-compliance which basically questions the scope and and the quality of of or the benefits provided by these type of security audits anyhow so um after we disclosed uh these findings to the authorities soon after uh ppa announced um the replacement of the affected id cards under warranty and at that time uh from more than 74 000 id cards which are renewed in customer search points only 12 000 were still valid and then soon after also the ppa brought gemalto to court demanding a contractual penalty of 152 million euro for the breach of contract because apparently the contract required

the educate manufacturer to generate the keys inside the car yeah so this was breached now in their public communication uh gemalto denied any wrongdoing they said that it's a surprise that the ppas announcements are a surprise and that they have done everything as agreed upon and now the latest news which are from the february this year is that ppa and gemalto reached a compromise agreement with gemalto agreeing to pay the state 2.0 million euro in compensation so 152 were asked 2.2 were renegotiated agreed and if we read the the the press release which is published on friday after working hours then we can see that it states that the agreement has been signed to close the

claims on the potential vulnerability to the estonian id card which occurred in 2017. so as you see this press statement mentions only the rocket case not the not the key generation outside the card i approached the ppa and they confirmed actually that actually this settlement covers all the disputes between the state and the id card manufacturer and so you can only only wonder why these press release mentions only the rocker case in 2017. but all right so with this peculiar note i end my presentation and thank you for your attention

i believe citizens have a lot of questions regarding their id card so no i actually have a question about the slide 17 uh you said that you generated keys on the actual light cards right how did you do that very good question um and there is a special story how i did on these particular cards actually my cardo cards if you recognize these are the first generation cards which are which are used from 2002 to 2009. so in case of these particular cards it turned out that this micart operating system was hit the security flow in their configuration which meant that i mean i i i found it only after the last id card was already expired so this

is an issue right but if if if this was found like then 10 years ago then this would be issue because what it meant is that by knowing pin two code of the card it was possible to override the card management keys which are used to personalize the card so basically i could just take a real cards and create my own configuration and generate the keys export them even the previous private keys export and and and and collect the cards now for the other platforms um now i got the samples for other cards for the java card platforms uh for the multus platform remember the multis platform which was which had this applet programmed in in

low level c i mean i could get a blank blank uh multi-card and i actually acquired it but the problem is that the key generation algorithm was implemented inside the applet so for for this and for java card platforms key generation was operating system feature so there was no way for the manufacturer by writing an applet modified but for multi-platform of course it depended on this particular application which is not open source so i couldn't get it and couldn't see actually what what what is the key generation organ which is used for multiple cards only by absurd i could so what i could do i could um actually just generate this plot but i didn't have a reference data to see

what type of properties were generated by the actual card so multi about multiple about multiple platform i cannot make any claims whether the keys were generated inside or outside uh but for all other platforms there is a quite strong evidence that for all others except these seventy four thousand cards which are in ppa these keys have been generated actually inside the card but here's again the question that um how much can you trust the id card manufacturer because to implement this key import feature the applet actually had to modify to to supply this functionality right so and the same way the id card manufacturer could help modify the applet to export the private keys after they are

generated right so this really doesn't tell us whether there are copies of the private keys somewhere or not that this is a trust issue here next question uh hey uh you mentioned doing research with like coup bank and arvad and trying to kind of submit uh authentication material that maybe wasn't valid so to say uh how did you feel during this research legally speaking did you gather consent before or were you protected under something or did you just yell it um no legal con no consent from the parties involved uh so what was basically done is that the the fake certificate is generated and we just try to click on the button log in with eddy card and see whether we are

letting and now the question is whether uh this type of testing requires the the consent but uh this is a discretable object here and i'm very much like should i like to discuss these things but in this case new uh we just went and tested it out with the service providers we considered uh important to be test ticket against this fall so i'm wondering from the human side that toivo you mentioned like what was his first reaction when you reached out to him was he like what kind of hacker are you what are you doing or did he understand did he have any background in i.t right so the case we stole was that of course when i approached him first

time i approached him over email and i explained to some level the that i'm doing this research and that it would be very great if he could participate in experiment now i didn't disclose to him that we will be forging a digital signature in the name of fool but i but i assured him that this experiment doesn't involve any damaging consequences for for his security uh because okay so if i actually did tell him that you know your id card can be used to forge other person's signature maybe that wouldn't be uh the right thing to do right um but yeah of course i i will approach him with also the same credentials i said that i'm a

phd student researching this topic and apparently he deemed me [Music] trustable enough to to run this executable of this computer but all to be honest we're running executables provided by different entities all the time right and then uh yeah so maybe i'm not so real party to not run this yeah a follow-up question uh also about this certificate collision because all those public certificates are associated with a personal id and they are published in the central registry what is the probabilistic theory says if you generate a certificate in chip what is the what is the what the theory says how uh is it possible to generate again two uh uh similar uh certificates but now that

reside on different ships right right very good point so there has been a case in the history this was about taiwanese uh identity cards where the chips actually had a faulty random number generator and indeed there was a case that different cards contained not exactly the same keys but one of the one of the prime numbers was the same for these cards and indeed uh this this hypothesis was not uh disregarded uh from the outset that indeed it could have been that the the the the there's always a coincidence that two random numbers are the same right but of course if the run if the numbers are large enough uh and that they're indeed random then this probably should be

negligible that's it as negligible actually being able to just guess these prime numbers right so uh but that what was of course very specific here is that these certificates were generated in a very close a few second difference from each other and as we later established that these are actually this the common thing about this certificate is that they were obtained in the id card renewal process then i pretty much pointed the the finger that most likely these keys haven't been generated inside the chip right so that would be too much of a coincidence and generally cannot rule it out indeed and but of course well no in in some sense we have a security certification for random number

generators that are being used on the cards right and and stuff but in the time in each case this actually didn't help so yeah in general it cannot be rolled out but it's there that this is the reason why there had to be some some additional evidence found determined proof that the keys were actually generated outside the card right so we couldn't just uh kick uh open the doors of the edicar manufacturer and inspect the source code of the live system what it is actually doing although maybe to some extent we should have done it i mean not we but someone should have done it right so all we could do we could uh obtain some

evidence using the public information which actually was the case in this case

thank you so much for being a watch talk on the sterling government and like technical agencies for like years and years now and i also say that you are like a prime example of how mathematics can be used to actually keep watch of the organizations but i have a question uh estonian united cards were one of them may be the first but now there are many countries who are doing similar projects what do you think what is like the technical control level of those countries do they have like their own ordinances who are keeping tabs on what they do right and i think this is really a really good point and i mean in comparison with id schemes in other

countries it might as well be the fact that about the developments in other deployments in other countries we simply don't know that where these keys are collected and stored right but in the case of estonian id card there is some evidence that actually the trust model that we fully trust the id card manufacturer that we but we enforce the security through contractual clauses because they promise to provide the security this is our security guarantee uh this that this actually may not work always right in practice and what i also was telling that i mean when i started actually this research and i started off the questions how are the keys generated what are the practical security measures in place to

prevent the id card manufacturer for collecting the private keys of all estonians then pretty much the answer was i got was first answer was there are security audits done right and the second answer was that uh this is the business of trust right so these id card manufacturers are huge companies with a billion whatever dollar revenues and and they most likely would never risk with their reputation doing something like this right and these both things uh turned out to not hold in practice here right so indeed if to answer about the the developments in other countries we simply we simply don't know but i think this is a good lesson also to learn for the sake of deployments in other

countries about these trust issues and how much can you trust the id card manufacturer regarding the process as actually the state must be in governance of the process how do you feel is and state government like been improved uh can you see some improvements uh regarding uh uh monitoring the security audits performing the security audits as needed and so on what what what is your feeling about this right so now first of all i think it's actually a good uh thing in a way that for example this edema platform uh which the latest platform has passed a formal and not so formal security assessment right so that's actually a good thing although even with that platform there were some

non-compliances that that showed up um now has there anything changed uh based on these findings i unfortunately i don't i don't see any fundamental changes in organization of the of the um of these processes i mean but but you can ask what the state could do right uh could there be a policeman with a dog uh like observing this process or or or this task has been outsourced to the private entity and also the security in that sense has been outsourced to them right and no of course the the thing which i'm advocating for is to change the design or architecture of the solution in a way that the uh the the let's say using threshold

cryptography as it's done in smart id when the key is shared between the the server and the the the user's mobile phone right so there can be a cryptographic solutions to decrease the trust level required for this and i think this is the correct uh way to deliver to the research further but of course this is not an easy like uh switching the flag and and and running these requires for the research and there has to be also you know political and non-political motivation to to to try to improve this i don't know maybe [Music] yeah i mean the very really really good question you can ask each of you can ask yourself what would you do if you were

in the in the shoes of the of state authorities how to ensure it and what i have actually in this research i have i got the feeling that the authorities actually do not want to even know what's how these sausages are made because by by this knowledge they would be liable to act somehow and therefore it's actually very nice that oh this risk has been what is risk transferred yeah this risk has been transferred we have solved the the the risk right so that's that's how i see it all right thank you martin yes yes yeah thank you yeah i'll hand it over here i have a really easy question which agency in the estonian government

is responsible to ensure that those things are correct uh from the outset it seems to be estonian information system authority uh i mean the responsibility for the for the id card uh electronic chip of id card and this is somewhere written in the in the government regulation yeah but of course i would say actually that this is uh i mean this personally i think that that that the the fact that the private key copies perhaps are stored somewhere in some backend servers this is i would say the state security issue yeah well after all we are voting with these cards right so with this private key so um yeah that's that's that's that's would be my answer

i let's ask one question you were already commenting on how the things are done in other countries and said that probably nobody knows but has there been interest for your work so is there a line of uh different eu countries waiting for thing in the line right yeah no but i think that's also understandable uh the less the less focus uh the less probability to find something ugly there right so um and yes of course i have dedicated a significant part of my life actually to research the estonian id card ecosystem and the solutions used here and i would even say that i'm not actually interested to to to switch and look uh for the the the security research

outside estonia at least currently okay any more questions we can probably have one small short question yeah there is on the back i don't care there

hi hi i have a question regarding this radical transparency by estonian authorities so uh your expert opinion on is it possible to create cover identities with this scheme when all the certificates are made public um now indeed if you look at the estonian uh example you can see that they're all public basically that the population register is public of estonia right in a way and any if you see in some other countries like germany where they are talking about these authentication schemes which would just disclose some properties about you whether you are adult or minor you know and there is a there is a big contrast here indeed uh whether i would uh [Music] be advocating for these type of privacy

pursuing authentication schemes most likely not because they are quite complicated and what i also see from this research of course the complexities is not always the friend of the security so even if they provide maybe some nice security features unfortunately unfortunately i think that the biggest privacy risk is what we what we heard in the first session today is that actually our data is stored in the servers which are not well protected that that i see the much bigger privacy issue than passing around your personal identity code in authentication tokens you