(Peter Teufl)
Will discuss planned E-ID solutions for Austria compared to current solution. Focus on security - mobile security specifically, authentication and perspective on the overall security. The company I am representing is working with the government, the ministry of interior and the ministry of digital and economic affairs, universities etc.
Current Solutions: · De-central solution · Authentication - qualified signatures (2 options: Chip cards or mobile phone signature)
Attributes - minimum dataset, stored on the Chip card/ and or mobile phone signature; Web-only solutions
Registration: multiple passes, registration offices, online through the ministry of finance
E- ID 2020
There are multiple ways to do it but the ministry has decided
Q: What was the reason for re-enrollment? A: Something you need to ask the Ministry of Interior. Q: Which level of assurance are you going for? A: High Q: Do you plan to also have a specific identifier for the academic sector? A: If you go to the private sector, this is also sector-specific, so there shouldn’t be a problem to have a sector-specific ID for academia. The idea is that your identification number is not the same for every sector. Q: Who is creating the sectors? A: The public sector is created by the public authorities aka the government, but the private sector is based on the companies’ IDs.
IDP is separated into 2 parts - · For the user there’s going to be a service that if you lose your phone, you can still get it on a new device · qualified signature provider
TIME frame: · Pilot operation is going to start very soon · gradual shift for the service providers · DIGItale AMt app - all of the authentication parts will take place in the app
mobile phone signature – based on a qualified signature · for the mobile part - 3 factors (knowledge-password, possession-authentication key, inherence-finger print/face ID) · for face-ID - biggest problems with android providers, as they don’t adhere to the rules google has created
Q: How does this concept security-wise relate to the old qualified signature concept of the (sic) synchronized control of the product key? Specifically, asking about TRUST on iPhones and other platforms? Is it something that can compare to Smart card? A: If you look at the current prices and you have a patched phone. It’s not as secure as Smart card. It depends on the phone. It’s a very common problem with the android phones as there are so many old phones out there, regardless of the state of the Trust, they have many vulnerabilities out there. One thing that is definitely the case here, is that you have better protection than just storing the key in the settings of the app. There have been some incident management system testing that has already been proved to work. For example, there was this incident with Nokia 9 and the same problem with Samsung s10, where you can unlock the phone with a chewing gum. For any kind of incident, you should have a very good incident management process, because it’s not going to be secure for all purposes.
Q: How does the SP know what kind of factors are used by the IDP and when? Is it using standard methods? How does the SP make a decision based on the factors used by the IDP? A: The policy is defined by the SP. The application register needs to be secure; The SP doesn’t request the information. IDP is policy enforcement, it’s static for the URL profiles.
Q: Can you enforce more policies on the admin side? A: The SP can steer this in terms of this timeframe, but the rest is done by the security because the IDP knows what kind of smart phone signature has been used 10 hours ago and then the decision by the IDP is made to provide the security level. It can decide on different URLs.
Q: From a user experience perspective if you have a 15-20 min time out, you just have to use the fingerprint again? A: We need to make a difference here; this is for mobile use cases. If you do it in the mobile browser that’s a different story, but you have the possibility to use OIDC in the app, so you get engaged in an OIDC protocol and then you’re using this frame but if you just go to the mobile phone browser and use it like in the web, you just have the standard system.
Q: Is this standard based? A: The remote signature resolution is provided by E-Trust.
Q: So, you use the signatures as proof of authentication? A: Yes, if the IDP validates this qualified signature because it’s trusted, then you provide the means of authentication against the IDP and those 3 factors here are used to creating the signature in the first place, to authenticate via the Trust provider. I think this use case (qualified signature) is mostly used in Austria, I don’t know if it’s used anywhere else.
Security - presentation
Q: Have you done some scalability testing on this? A: Several approaches. 1st you need some keys like SAML keys… we can take the numbers that are already known on big servers and we will know how many operations we will need per second. What still needs to be decided on the security perspective - using HML keys for internal protection and HSM because they have to be generated every hour.
· we use all the current technologies out there · we check the root protection capabilities, but it comes with continuous challenges · if you have a fingerprint, you get a dialogue which is now broken on phones like One+ · we are testing on the google cloud, but when it comes to fingerprint testing, that’s down to testing each device which costs a lot of resources · with every major release, we experience a challenge when it comes to security
Q: Is this back-end system something you acquired? A: The backend is custom, based on the Austrian registry that provides the attributes. The backend has app register (data protection policies, metadata etc.). Assigning the attributes is custom.
Q: Basic premises are that you rely on everyone having a relatively modern smartphone, but what happens to people that don’t want to have/use a smartphone? A: There are currently discussions on how to provide it for users who don’t have a phone. There has been the option to use an SMS, but that depends on the different providers (roaming, etc.). On iPhone every iPhone starting from iPhone 5 has the capabilities and android starting from android 6 a lot of phones can use the app. The mobile app is primarily for the mobile use cases and if you go to the web, if the SMS is allowed then it will be fine, but all of this is under discussion.
Q: Could you summarize the smart card solutions? A: Regarding the chip cards, in the previous solution they have been used for the key signature and the attributes. The release of the attributes is not supported by the new system but there will be places where you would be able to use the key signature for authenticating against the services. In this case, chip card is still around but not in the role of providing the attributes. The attributes will be revoked when the new legislation is out.
Q: To use the chip card do you need an NFC reader? A: A lot of those chip cards don’t have an NFC reader. NFC is not required but a card reader in some way. The chip card is not the primary use case. NFC was never a focus. Using NFC is a limiting factor for users.
The session is extended: Q: What happens if you have 2 mobile phones, can I use both? A: Yes Q: And if I lose one? A: You can imagine it being the same as on Google. If you log into the system (my EID part) and then you see a list of devices and you can decide whether to throw them out or add them. This is the problem of the recovery procedure, if you have lost all the phones, you need to make sure you have some authentication left to go to the right page and in this case let’s put security aside, SMS would be perfect. If you lose the phone with the SIM card, it will be a problem. The worst case is if you have a new phone or you wipe the app, you would have to go to the passport office again. This is a big challenge because you have security and how to avoid going to the passport office.
Q: What about multiple accounts on one phone? A: nice idea, but not a primary focus currently. Q: What about tablets? A: Tablets haven’t been addressed yet.
Q: The mobile authenticator, authenticate app that’s provided by the EID system or you also have an IDP or client line that can be embedded if you’re building your own app? A: The app is provided by the system, it’s already in place. The clients currently need to do a SAML or OIDC and they are reconnected to the right part, that’s quite easy. The mobile part it’s a lot more complicated because you still have a lot of URLs that go over to the other app but you need to be careful to do it the right way. It’s not vital that you get an initial token and then you reenroll this token again. We don’t do this because the SPs need to have all those technologies and they don’t.
A: We have the app switch; we can’t embed it in the standard authentication workflows because that doesn’t meet the requirements of the mobile phone signature because you don’t have that many options in the browser. But that’s a big gap, because we can do it for every country with the app provider. In the web case, it doesn’t work like that, you lack information about a lot of things like who has it installed etc.
Q: Is there a mechanism to direct to the app store on iOS? A: Yes.
Q: What is the technical interface E-ID app? A: Standard OIDC, not going to be SAML.
Q: Does the app have a local refresh token? Outside the E-ID? A: Yes, depends on the SP. OIDC – refresh times which need to be decided soon…there will be policies.
Q: Concerning the 3-factor authentication, I think the problematic part is the requirement for a fingerprint or face ID because in some cases you don’t need it. If the fingerprint of my phone doesn’t comply with your regulations for the authentication… I think the inherence factor is problematic, as it’s not confidential and the other part is that there could be security breaches and leaks. But you have the fallback to the password? A: Think about the signature authentication, you need ALL 3 factors. If one of the 3 factors is lost, you will be required to fulfill all 3 factors. You need to bind your phone with the recovery system. You won’t be able to change between methods.
Q: What is inherence? A: It’s a biometric property. Whenever you create a key in the Trust, you can tell your iPhone or Android to use the fingerprint of the face ID.
· Pilot is going to start in May, but I don’t want to comment much on this as it’s not my area of expertise. We’re hoping to have the app running by the end of the year, but it will be challenging for the SPs.
