Category Archives: eIDAS

GSMA published requirements for SAM

The GSM Association (GSMA) has released a new requirement specification focusing on Secured Applications for Mobile (SAM). In this specification the capability allowing cellular connected devices (e.g. smartphones) to use a wide range of secured applets within an eUICC (embedded universal integrated circuit card) is described. Applets specified here can be managed by a service provider and are cooperating with applications running in the device itself. The focus of the specification is on the eUICC where the secured applets will operate independently and outside of any eUICC profile.

GSMA Logo

The requirement specification with the title SAM.01 is published on the GSMA website in the following link: https://www.gsma.com/newsroom/resources/sam-01-secured-applications-for-mobile-requirements

Use case: mobile eID as a secured applications for mobile

The usage of mobile devices for mobile services is one of the dominant trends we can see worldwide. Mobile devices replace the personal computer at home or at office. For access to online services the mobile device is getting more and more important. New applications are often only offered for mobile devices (mobile first). Based on this trend the mobile device is becoming the most common interface between the customer and the service providers.

For the digitalization of business process, the secure identification and authentication of end customers is a key requirement. The eIDAS regulation No 910/2014 of the EU is defining three levels of assurance (LoA) for electronic identification. The two highest levels “high” and “substantial” are demanding the usage of secure elements (see BSI Technical Guideline TR-03159 Mobile Identities). To achieve these levels the usage of an secure hardware token is essential. One of these token could be an eUICC and the usage is specified in SAM.

This secure hardware token is a central element for several mobile identities that are currently under development, like ICAO Digital Travel Credentials (DTC), mobile Driving License (mDL) specified in ISO/IEC 18013-5 or in general building blocks for mobile ID (ISO/IEC 23220). Last but not least the German identity card (ePA) will be derived to a smartphone to use the online identification directly on the device.

You can find a description of current mobile ID projects and standardisation work in my article “Digital and mobile identities” which was published in the context of Open Identity Summit 2020.

As soon as the eUICC is a well-specified secure platform, it is the perfect platform for hosting mobile ID applications which are offering high security for the service provider and also for the end user.

Architecture of SAM

The following figure describes the architecture of Secured Applications for Mobile (SAM) as specified by GSMA:

Architecture of Secured Applications for Mobile (SAM)
Architecture of Secured Applications for Mobile (SAM) (Source: GSMA SAM.01 v1.0)

On the left side you can find the service manager (SAM SM), which acts on behalf of the Application Service Provider (ASP) and is in charge of managing SAM Applets through SAM Commands. On the device itself you can see the device application (e.g. provided in an app store by the ASP), the local applet assistant (LAA) and – of course – the eUICC. The eUICC offers a security domain (SAM SD, also known as common security domain (CSD)) including an ASP SD where the SAM applets are located. The SAM applet can be used to assure the security of the device application by storing keys or holder data, performing encryption, signing etc.

Next steps

The work has not finished with the release of the requirement specification. All the requirements must be incorporated into a technical specification where all details are described on the level of bits and bytes. To assure that current developments in other working groups are also involved (and to assure that the wheel is not reinvented a second time) GSMA is working with external organizations like GlobalPlatform or ETSI. On this way we will see several interoperable applets running on eUICC allowing high security in the near future.

BSI released version 1.2 of TR-03105 Part 3.3

The German BSI has released a new version 1.2 of TR-03105 Part 3.3 for eIDAS token. This test specification for chip assures conformity and interoperability of eIDAS token like eID cards or residence permits. TR-03105 Part 3.3 contains tests for protocols that are summarized under EACv2 and corresponding data groups.

Front page of German ID card (Personalauswweis) compliant to TR-03105 Part 3.3
Front page of German ID card (Source: Wikipedia)

In TR-03105 Part 3.3 Version 1.2 new test cases are added to verify and assure the correct handling of authorization extensions. Authorization extensions are specified in TR-03110 and they are a special type of certificate extensions. These extensions convey authorizations additional to those in the Certificate Holder Authorization Template (CHAT) contained in the certificate. Additionally, authorization extensions contain exactly one discretionary data object that encodes the relative authorization. The main changes of version 1.2 are:

  • Test cases to verify correct handling of authorization extensions
  • New certificates to perform test cases with authorization extensions
  • The tests for command COMAPRE can now be performed in a more detailed way (see new table in ICS in annex A.1)
  • A new test case to verify the TA migration according to the manufacturer’s implementation conformance statement where the AT trust point are replaced
  • Some minor editorial changes and clarifications

Modified test cases in version 1.2

  • EAC2_7816_L_36: Clarification in Purpose
  • EAC2_7816_N_1: Clarification in purpose
  • EAC2_7816_P_8: Added missing tag ‘7C’ in commands
  • EAC2_ISO7816_P9: Removed tag ‘97’ that is not necessary in command RESET RETRY COUNTER (step 6)
  • EAC2_7816_P_14: Added missing tag ‘7C’ in commands
  • EAC2_7816_P_14: Added missing tag ‘7C’ in commands
  • EAC2_7816_U_13: Expected results: Accept also a checking error in step 3 of preconditions
  • EAC2_7816_U_14: Expected results: Accept also a checking error in step 3 of preconditions
  • EAC2_DATA_B_11: Check a whitelist of SecurityInfos (PACEInfo, PACEDomainParameterInfo, PasswordInfo, ChipAuthenticationInfo, ChipAuthenticationDomainParameterInfo, PSAInfo, TerminalAuthenticationInfo, PSMInfo, CardInfo) and ignore PrivilegedTerminalInfos
  • EAC2_DATA_C_12: Editorial correction in Test-ID
  • EAC2_EIDDATA_B_6: Renamed data type ArtisticName by NomDePlume according to TR-03110

New test cases in version 1.2

  • EAC2_7816_L_38: Positive test with a valid terminal authentication process. The DV certificate and the terminal certificate grant access to an eID access function that is reserved for future use (RFU).
  • EAC2_7816_L_39: Positive test with a valid terminal authentication process. The DV certificate and the terminal certificate grant access to an eID special function that is reserved for future use (RFU).
  • EAC2_7816_L_40: Positive test with a valid terminal authentication process. The DV certificate and the terminal certificate contain a certificate extension (authentication terminals) extended by two empty bytes. The authorization extension in both certificates are extended with leading ‘00 00’ (56 bit instead of 40 bit).
  • EAC2_7816_L_41: Positive test with a valid terminal authentication process. The DV certificate and the terminal certificate contain a certificate extension (eID functions) extended by two empty bytes.
  • EAC2_7816_L_42: Positive test with a valid terminal authentication process. The DV certificate and the terminal certificate contain a certificate extension (special functions) extended by two empty bytes.
  • EAC2_7816_L_43: Positive test with a valid terminal authentication process. The DV certificate and the terminal certificate contain an unknown OID in CHA.
  • EAC2_7816_L_44: Positive test with a valid terminal authentication process. The DV certificate and the terminal certificate contain an unknown authorization extension OID in for eID access.
  • EAC2_7816_L_45: Positive test with a valid terminal authentication process. The DV certificate and the terminal certificate contain an unknown authorization extension OID in for special functions.
  • EAC2_ISO7816_M_9: Positive test to verify that a link certificate can activate a feature of the eID card. In this test case the right to read DG1 is used to verify that the eID card supports activation of features by link certificates.
  • EAC2_ISO7816_M_10: Positive test to verify that a link certificate can deactivate a feature of the eID card. In this test case the right to read DG1 is used to verify that the eID card supports deactivation of features by link certificates.
  • EAC2_ISO7816_M_11: Positive test to verify that rights are granted by the last link certificate and not a combination of all rights in the whole certificate chain. In this test case the right to read DG1 is used.
  • EAC2_ISO7816_M_12: Positive test to verify that a link certificate can activate a feature of the eID card. In this test case the right to compare DG8 is used to verify that the eID card supports activation of eID Access features by link certificates.
  • EAC2_ISO7816_M_13:  Positive test to verify that a link certificate can deactivate a feature of the eID card. In this test case the right to compare DG8 is used to verify that the eID card supports deactivation of eID Access features by link certificates.
  • EAC2_ISO7816_M_14: Positive test to verify that eID Access rights are granted by the last link certificate and not a combination of all rights in the whole certificate chain. In this test case the right to compare DG8 is used.
  • EAC2_7816_N_2: Positive test case to verify the TA mechanism migration according to the manufacturer’s implementation statement (replacement of the AT trust point)

As mentioned in my previous blog post describing latest version of TR-03105 Part 5.1, I’ve extended the focus of my blog from ePassports towards eID and eIDAS token. You can find a list of current test specifications here.

Focus extension of this blog to eIDAS token

Until today the focus of this blog was limited to ePassports or eMRTDs specified by BSI and ICAO. From now on this focus will be extended also to eIDAS token.

eIDAS Logo

An eIDAS token is specified also in BSI TR-03110. The technical guideline specifies a set of different algorithms and protocols that can be used in the area of identification and authorisation. One representative for a token like this is for example the German ID card (Personalausweis).

Additionally, a first prototype of an eIDAS token was implemented during a project called PersoSim on behalf of BSI. Goal of this project was to implement the functionality of a German ID card in a simulator including a virtual smart card reader.

Protocols specified in TR-03110 beyond eMRTD are:

  • Restricted Identification (RI)
  • Pseudonymous Signatures (PS)
  • Chip Authentication Version 2
  • Chip Authentication Version 3
  • Terminal Authentication Version 3
  • Enhanced Role Authentication (ERA)
  • Authorization Extension for additional attributes

From now on you can find test specifications for eIDAS token at the overview of test specifications. There are more and more eID documents using the protocols specified in in TR-03110 (e.g. Authorization Extension for LDS2 where entry and exit stamps are stored on the chip) and at the end of the day the corresponding test specifications are getting more and more important. That’s the reason why I decided to blog also about eIDAS token at this blog from now on.