Levels of Assurance. Tabea Born and Maxime Peyrard. TU Darmstadt

Transcription

1 Levels of Assurance Tabea Born and Maxime Peyrard TU Darmstadt Abstract. This paper deals with four levels of assurance (LoA), which have been defined by different standardization organizations and consortiums. These provide general recommendations for each level, how they should be implemented, and which requirements must be fulfilled. The definitions and recommendations of ISO/IEC, NIST, STORK, and Kantara will be presented, by giving a short summary of the LoAs defined by each consortium. After that, the differences in their approaches will be pointed out with respect to the chronological order of the publication dates. Keywords: levels of assurance, authentication, cryptography, eid, credential, token, identity check, security 1 Introduction Today, many applications of the real life are going online. This gives the user more comfort and makes it easier for him or her to get specific information he or she wants to have. Therefore many parts of the life of a person can be found online, which includes a very high amount of personal data. Because there are many different applications on the internet a person can use, including online games or online banking, different security levels are needed. While it is important to have a high security level for an online banking transaction, an online browser game may only need a low level security since it does not contain any valuable personal data. The levels of assurance (LoA) are one suggestion on how to secure sensible and personal data on the internet. They give a description of the authentication process and define security standards for each level which are to be met. On the authentication process, a user has to prove that he or she is the legitimate user to get access to some specific data or is allowed to conduct certain transactions, respectively. The above mentioned levels of assurance (LoAs), which describe different security levels for an authentication process, are introduced by the institutes ISO/IEC, NIST, IAWG/Kantara, and the consortium ENISA/STORK. They describe the lowest level (called LoA1) as the level, which has commonly no protection and can be used, when minimum risk is associated with erroneous authentication [1]. The second level (LoA2) has a minimal protection, where a user has to authenticate with a user name and a password, whereas the third level of assurance (LoA3) needs an additional factor, like a biometric or a special

2 2 Levels of Assurance card reader for online bank transactions. The fourth level (LoA4), which is the highest one, requires furthermore in-person identity proofing for human entities and the use of tamper-resistant hardware devices for the storage of all secret or private cryptographic keys [1]. Kantara justifies the selection of four levels by stating, that it is necessary to keep the complexity and the costs to maintain both the authentication information [...] and the underlying infrastructure manageable [2]. More levels would confuse the user and possibly decrease his confidence [...] in the authentication framework and the applications using it [2]. Less levels on the other hand would not fit the different requirements of the diverse applications. Some applications would be overly secured, while others might be not secure enough with a lower security level. 2 Overview In this paper, the discussion will be based on the work and the frameworks produced by ISO/IEC, NIST, STORK, and Kantara, which are shortly introduced below. 2.1 Description of the organizations IAWG/Kantara IAWG (Kantara Initiative Identity Assurance Work Group) is a non-profit association dedicated to work on technical and legal innovation of digital identity management. Kantara is not an official standardization institute but their publications are recommendations to other standards bodies such as IETF (Internet Engineering Task Force) or ISO. Their work on levels of assurance aims to promote uniformity and interoperability amongst identity service providers. ENISA/STORK ENISA (European Network and Information Security Agency) aims to address security issues of the European Union. In order to do so, the STORK QAA (Quality Authentication Assurance) project was created. (cf. [6]) STORK s challenge is to provide security standards in authentication process for European Citizens and ebusinesses. Their aim is to have a common framework and the provision of eid (European recognition of electronic IDs) interoperability. ENISA maps existing standards of each member state to the four levels defined by STORK in order to compare and evaluate each one. The approach is based on five key points, whereby the factor which gets the weakest score determines the level. Three of them are about the registration phase while the remaining two are technical factors about the electronic authentication phase. NIST (National Institute of Standards and Technology) is a measurement standards laboratory which belongs to the United States Department of Commerce. The document that describes standards for levels of assurance was

3 Levels of Assurance 3 written by the ITL (Information Technology Laboratory). ITL develops tests and proof of concept. It provides guidelines in order to make the development and the use of information technology cost-effective, secure and coherent with other standards. NIST SP (Electronic Authentication Guideline)[5] establishes technical guidelines for implementing authentication mechanisms for government and electronic commerce. While these recommendations are specific for the US, they are broadly applicable to any environment that requires the authentication of entities. ISO/IEC (International Organization for Standardization/International Electrotechnical Commission) is a groupment of two worldwide standardization institutes. They provide state of the art specifications for products, services and good practices, helping to make industry more efficient and effective. The consensus aims to break down barriers to international trade. Technical committees lead to the development of international standards which are then bring to national bodies for voting. The standard on electronic authentication establishes four levels of assurance for entities, stipulating the criteria and guidelines of implementation for each level. Doing that, it just gives general advices on what the different levels are about. 2.2 History of the publication dates of their approaches Fig. 1: Hierarchical relationships between different standards OMB (Office of Management and Budget) is under the US government and provided some guidelines for E-authentication with levels of assurance in 2003

4 4 Levels of Assurance [3]. IDABC stands for Interoperable Delivery of European egovernment Services to public Administrations, Businesses and Citizens. It is an European program that aims to exploit the opportunities offered by technologies of communication in order to improve collaboration between European public administrations. The graph shown in figure 1 represents the year of publication and the interdependencies of the approaches treated in this paper. Apart from these examined approaches of the main standardization institutions, there are far more recommendations for the levels of assurance, which will not be further looked at and do not appear in the graph. As it can be seen in figure 1, the similarities between the recommendations is due to the fact that they have all the same influences and they are close to each other in this relationship tree. There seems to be a common ancestor for all the standard, which is OMB M (2003)[3] that inspired the special publication of NIST in All the other publications of the different organizations seems to be directly or indirectly inspired by these two first standards. This tree will help to understand the similarities we will find in the following description of the LoAs. 3 Evaluation In this section, the four levels of assurance (LoAs) will be roughly explained at the beginning of each subsection. After that, the different approaches of the organizations ISO/IEC, NIST, ENISA/STORK and IAWG/Kantara will be illustrated. Finally, the differences in their approaches considering their backgrounds described in section 2 will be pointed out. In the last subsection, the limitations of the approaches will be explained. A summary of the different approaches from the organizations for each level can also be found by taking a look at the tables 1, 2, 3, and 4 in the appendix. 3.1 Level 1 LoA1 provides the lowest security confidence and does not need strong authentication technologies. The standards agree on the fact that this level is the one with the lowest consequences if an erroneous authentication occurs. This is the minimal assurance associated with minimum risk. In this level, the standards do not require any identity proofing like ID (proof of Identity checkable against official or governmental institutions), personal information, or physical presence, but the confidence that the entity is the same over consecutive authentication. Therefore there is a need of an identifier for every user, which must not necessarily be unique or private. A factor like PIN is well suited, but since the requirements are not really strong, there is a wide range of factors that can be used at this level. There is no need for cryptographic methods at this level. The standards allow that any of the token methods from the above levels can be used. NIST is the organisation that differs from the others because it provides some

5 Levels of Assurance 5 advices on technological aspects of the first level. The token can be a user chosen string of six or more characters, a randomly generated PIN of four digits, or a secret with equivalent entropy. Files of shared secrets (credentials) should be protected by access control and tokens should not be in plaintext but stored as a hash value. Furthermore the verifier shall implement a mechanism that limits the number of failed authentication attempts for a subscriber. 3.2 Level 2 The second level of assurance (LoA2) defines an authentication process, where a failure or a hacked account causes only little harm to the account owner. Therefore the methods, which are provided by this security level, are at a minimum, forcing the user to authenticate himself with a user name and a corresponding password. It is up to the user to choose a secure password, which cannot be compromised in an ease way. ISO/IEC states that the LoA2 should be used when moderate risk is associated with erroneous authentication [1]. They explain, that it is sufficient to use single-factor authentication. This describes the commonly used authentication process, where the user has to provide a user-name and a password (cf. [4]). It is needed, that a user prove through a secure authentication protocol, that he or she possesses the above mentioned credentials. The operator of the application on the other hand has to provide control, which reduce the effectiveness of eavesdropper and online guessing attacks [1]. Furthermore the stored credentials have to be protected against attacks, too. NIST gives a summary of the technical requirements for the LoA2 and explains that this level provides single factor remote network authentication [5]. They define some single-factor authentication tools and permit the use of tokens for LoA3 and LoA4. For a successful authentication, the user has to prove through a secure authentication protocol that he or she controls the token [5]. This is a identity proofing requirement, where the user has to present some identifying material or information only he or she has (cf. [5]). The application, where the user wants to authenticate himself, should be secured against attacks like online guessing, replay, session hijacking, and eavesdropping and the used protocol has to be at least weakly resistant to man-in-the-middle-attacks [5]. Besides that the owner of the application should secure, that long-term authentication secrets [...] are never revealed to any other party except verifiers operated by the Credential Service Provider (CSP) [5], which is described as a trusted entity that issues or register subcriber tokens and issues electronic credentials to subsribers [5]. Temporary shared secrets on the other hand can also be provided to verifiers, which are independent of the CSP (cf. [5]). An assertion, which is a statement from a verifier to a Relying Party (RP) that contains identity information about a subscriber [5], should be protected against disclosure, rediction, capture and substitution attacks, as well as manufacture/modification and reuse attacks, which are restricted in LoA1. For these assertion protocols,

6 6 Levels of Assurance approved cryptographic techniques are needed. STORK defines that the second level is used by services where damage from a misappropriation of a real-word identity has a low impact [6]. While a physical presence of the user is not required, their real-word identities must be validated [6]. The user name and password, which are required at single-factor authentication, are sent to the user by two separate mailings. Moreover, the chosen password has to conform common guidelines for strong passwords or PINs and should not be vulnerable to guessing or dictionary attacks. During the electronic authentication phase the use of adequately robust protocols is required (cf. [6]), because the accuracy and security has to be guaranteed for delivered identity tokens. Additionally the authentication process has to provide some protection against guessing, eavesdropping, hijacking, replay, and man-in-themiddle attacks [6]. Kantara specifies their LoA2 similar as it described in the section of ISO/IEC above. The second level shall be used, when moderate risk is associated with erroneous authentication [2], whereas single-factor remote network authentication [2] is required. For a successful authentication, a user has to prove that he possesses a certain token through a secure authentication protocol and attacks, like eavesdropper, replay, and online guessing attacks, should be prevented (cf. [2]). The identity proofing requirements has to be more binding and the authentication mechanisms have to be more secure (cf. [2]) compared with the requirements Kantara has defined for LoA1. The descriptions above show, that the approaches from the different organizations are quite similar, but also differ from each other. While ISO/IEC, STORK, and Kantara give only a rough overview on how the second level should look like, NIST describes the second level from a technical point of view and gives more restrictions on how the level should be implemented. Additionly, NIST is the only organization which describes how stored credentials or assertions, respecively, have to be treated and which threats have to be prevented. STORK on the other hand, draw up guidelines on the robustness of the credentials and demand them to be conform to common guidelines. As mentioned above, the description of the second level of Kantara and ISO/IEC are quite similar. This is because the ISO/IEC description is based upon the publications of Kantara and the special publication of NIST in 2006 to provide an international standard. All in all the different definitions of the LoA2 have some points in common. First of all, single-factor authentication has to be used and there must be some confidence in the claimed or asserted identity. Also the authentication protocols have to be sufficiently secured, which implies protection against eavesdropping and online guessing attacks at this level for all organizations.

7 Levels of Assurance Level 3 In LoA3 there is a need for high confidence, because substantial risks are associated with an erroneous authentication and the system may suffer substantial damages. ISO/IEC requires the use of a multi-factor (cf. [1])(which is at least two distinct authentication factors). This is a security process in which a user provides two means of identification, one of which is typically a physical token, such as a card, and the other of which is typically something memorized, such as a security code [7]. For example a bank card is a two factor authentication, where the card is the physical token and the PIN is the memorized token. Every secret information related to the authentication should be cryptographically protected even if there is no need in of a cryptographic-based challenge-response protocol (cf. [1]). There are no particular requirements in the generation or storage of credentials [1]. NIST provides multi-factor remote network authentication [5], which means that there is a need for at least two-factors. The identity proofing of the claimant requires verification of identifying materials and information (cf. [5]). The authentication is based on proof of possession of the allowed types of tokens through a cryptographic protocol [5]. Because no information about the primary authentication token is allowed to be exchanged in plaintext over the network, the authentication procedure must be cryptographically protected (cf. [5]). The claimant can prove that he controls the token by unlocking the token with a password, a biometric, or by using a secure multi-token authentication protocol. Long-term shared authentication secrets [...] are never revealed to any party except the Claimant and Verifiers operated directly by the CSP [5]. STORK describes two ways to achieve the security needed in its definition of LoA3. In the first one, there is the need of the physical presence of the claimant at least once during the registration phase (cf. [6]). There have to be multiple assertions about the identity of the claimant, which must be unique for him or her (cf. [6]). The validation of an assertation need to be signed with a nonqualified digital signature [6]. In the second way, the physical presence of the claimant is not required, but the assertions about him or her must be related to a unique piece of information that only the claimant knows (cf. [6]). Furthermore, that information must be checkable against official identity. The validation of an assertion requires the exhibition of a physical and an official document (such as an ID) with at least a photo and a signature (cf. [6]). No matters which way, the authentication mechanism must be secure and has to offer protection against guessing, eavesdropping, hijacking and man-in-the-middle attacks (cf. [6]). Kantara recommends a multifactor remote network authentication [2] with a verification of identifying material and information [2] related to the claimant. There is the need to prove the possession of a token through a cryptographic se-

8 8 Levels of Assurance cured protocol (cf. [2]). This token is allowed to be a soft, hard, or one-time password device tokens [2]. ISO/IEC and NIST have the same point of view regarding to authentication procedure and identity proofing. Their difference come from the credentials management. While there is no requirement in ISO/IEC, NIST specifies that credentials must be available only to the Verifiers operated directly by the CSP [5]. STORK differs because there is a way of implementing the authentication mechanism at LoA3 that requires the physical presence of the claimant during the registration phase. The identity proofing relies on the government accreditation or supervision (not applicable for private business). 3.4 Level 4 The fourth level of assurance (LoA4) has the highest security level. It is only used, when a failure in the authentication process implies enormous risks for the user. Because of the high risk involved, in-person identity proofing and a multi-factor authentication with hard tokens is required. ISO/IEC states that this level is only used when high risk is associated with an erroneous authentication [1]. The confidence in the claimed or asserted identity has to be very high (cf. [1]) and therefore not only in-person identity proofing, but also multi-factor authentication for human entities is required. Furthermore, all secret or private cryptographic keys have to be stored at temper-resistant hardware devices (cf. [1]). It is needed, that every personal identifiable information included in the authentication process, which could be a name or a fingerprint, has to be cryptographically protected in transit and at rest (cf. [1]). Also nonperson entities, like laptops or mobile phones, may be authenticated through digital certificates. The fourth level of assurance is intended by NIST to provide the highest practical remote network authentication assurance [5]. To answer that claim some additions to the LoA3 requirements are made. First of all in-person identity proofing is obligatory and additionally only hard tokens are allowed in the authentication process (cf. [5]). The particular demands of NIST can be met by using a PIV (Personal Identity Verification) authentication key of a FIPS 201 compliant PIV Card (cf. [5]). Furthermore it is needed, that all communicating parties and all sensitive data transfers between them are authenticated with strong cryptographic methods like public key or symmetric key technology, respectively (cf. [5]). Threats on the protocol, which are in particular all threats from LoA3 and man-in-the-middle attacks, have to be prevented. At last all stored assertions have to be cryptographically protected as in LoA3, whereas the used keys have to be bound to the authentication process (cf. [5]). These authentication secrets are never revealed to any party except the Claimant and Verifiers operated directly by the CSP [5].

9 Levels of Assurance 9 STORK addresses with its definition of the fourth level of assurance services where demage caused by an identity misuse might have a heavy impact [6]. To prove the identity of a user, his or her physical presence or a physical meeting with him or her is required. If the registration has to be online, the identity of the user is validated by using trusted e-signatures, whereas the details of the validation of the identity is left to national law (cf. [6]). At this level, the most robust and secure authentication mechanisms are used which offer protection against guessing, eavesdropping, hijacking, replay, and man-in-the-middle attacks (cf. [6]). Kantara declares its LoA4 to be appropriate for transactions requiring very high confidence in an asserted identity [2]. At this level the best practical remotenetwork authentication assurance is provided. This is based on the proof through a secure, cryptographic authentication protocol, that a user possesses a specific key. The authentication mechanisms are similar to LoA3, but at this level only hard cryptographic tokens are allowed [2]. Additionally the authentication of all sensitive data transfers have to be cryptographically secured with keys, which are bound to the authentication process (cf. [2]). The fourth level is intended by the standardization organizations to provide the highest security level for an authentiation mechanism. Therefore the asserted claims are the highest, which are possible today. To achieve this, the authentication mechanism requires in-person identity proofing and a cryptographically authentication protocol. This has to be secured against all threats from lower LoAs as well as man-in-the-middle attacks. Also in this level the differences in the approaches from the organizations can be seen. NIST takes the technological point of view and focusses on the authentication process and on the safety of the stored data. They set up concrete requirements on the authentication process and demand that a token has to be a hardware cryptographic module validated at FIPS Level 2 or higher with at least FIPS Level 3 physical security [5]. But also STORK has special requirements, which include, that the used credentials have to be qualified hard certificates according to Annex I of Directive 1999/93/EC [6]. Only ISO/IEC and Kantara provide a definition for the fourth level which gives the authentication mechanism a wide scope. 3.5 Limitations Although the standards provide state-of-the-art recommendations on how to implement and define the security levels in an electronic application, there are still some limitations that make those standards less powerful. First of all, the considered standards are just recommentations. Many application do not follow them due to a lack of rigor in the development of the application or because they cannot afford the technology required by the level they have to implement. For example, LoA3 and LoA4 may require the physical presence of the claimant, which means you need to be able to meet all the claimants at least once in a

10 10 Levels of Assurance secure office. The standards have the problem of the validity in time of their technological recommendation. Technology, especially electronic and Internet ones are growing really fast and security recommendations may be outdated in a very short period of time. The publications of the standards must be reviewed really frequently in order to keep being state-of-the-art. Finally there is the limitation on the applicability of these standards. There is one which aims to be followed in Europe (ENISA/STORK) another one which is provided for USA (NIST). Even if they have a lot in common and they are inspired by each other, there are some difference and it implies that there is no global coherence and reference. Another limitation could be, that the organizations STORK and NIST have bound their requirements of the authentication mechanism to the institutions FIPS or Annex, respectively. This states a problem, because the requirements defined by these institutions could change be out of date sometimes. If this happens, the authentication mechanism is no longer secure. On the other hand, the definitions of ISO/IEC and Kantara are so widely defined, that a bad implementation of the authentication process is possible, which could lead to identity misuse. 4 Conclusion In this paper, the differences in the approaches of the organizations ISO/IEC, NIST, STORK, and Kantara for the four levels of assurance were pointed out. It became clear, that the organizations NIST and STORK want to create technical standards for the USA or Europe, respectively, while ISO/IEC and Kantara strive to create international accepted standards. The history of the release date of the publications (cf. figure 1) reveals, that the first approach for the four levels of assurance was made by the executive office of the president in 2003 [3]. In this publication rough basics of the levels of assurance and some basic guidelines for the definition of them are set. That is the main reason wherefore the approaches from the standardization organizations are this similar, but quite different. As it can be seen in the tables 1, 2, 3, and 4 in the appendix, NIST is the only organization, which defines the storage of its assertions for every single level. They also permit the usage of token methods of higher levels for every level and urge the use of a secure authentication protocol for each level. STORK on the other hand, is the only institution, which make detailed demands on the robustness of the credential. As it can be seen in table 1, the security of the password or the PIN is up to the user, whereas in the fourth level Qualified Hard certificates according to Annex I of Directive 1999/93/EC [6] are required. Furthermore, the validation of the identity is defined explecitely and from the second level upwards at least a governmental validation is necessary. The standardization organizations ISO/IEC and Kantara provide both similar definitions for the four levels, which are inexhaustive. Both want to provide a international standard and because of that, detailed definitions are not possible. Their def-

11 Levels of Assurance 11 inition have to leave the countries or association of states free to define their own details for each requirement they deliver. Although the definitions of the organizations are quite different, it becomes clear, that their purpose is fulfilled. NIST provides a definition of the four levels of assurance for the United States of America, fitting their requirements, while STORK satisfies the claims of the European Union. The attempt of ISO/IEC and Kantara to define an international standard is based on the publication of NIST in 2006 and is therefore rather a trimmed version of that than an independent work on a new international standard. Up to this point the four levels were described without bringing the number of them into question. In their publication Kantara states, that more than four levels would confuse the user and there is some possibility, that his or her confidence in the authentification framework could be decreased (cf. [2]). Because the internet has many different applications and most of whom have different requirements, one can argue that more levels could be appropriate. On the other hand, it might be possible that only one assurance level (LoA4) would be enough to secure any data. Both argumentations have their weaknesses. The first approach would result in overfitting, because hundreds of different assurance levels would be defined. The second approach on the other hand, would not reflect the reality, because some applications are needed to be more secured than others. For example, an online bank account must be more secure, than an account for a browser game. Moreover the security measures taken into account on the fourth level are more expensive and costlier than a simple application would require. Therefore a small number of well defined assurance levels would be more efficient. A look on the definition of the different levels shows, that they are well defined. For really simple applications, the first level provides a low security level, because it is just needed, that the user is the same as in former sessions. The second level is the one, which is used at most. A user is free to choose a user name and a password, with which he can authenticate himself through a secure protocol. The third level is used, when there can be done harm to the user, if his account is compromised, like in online banking authentification. The fourth level is just needed, when a misuse implies high risks to the user. The main problem of this approach is, that the four levels of assurance are just a proposal. There are no direct standards which have to be achieved. The operator of an application can choose if he want to meet the requirements and how he wants to do that. Also, he is free to choose which security level he wants to implement. It is possible for him to choose a lower security level than that one which would be suitable to reduce his cost. For example an online shopping application is usualy based on the second level of assurance. But this can lead to a huge financial harm of the user who ownes this account as there is often stored a direct debit function. The levels of assurance do not give any advice on how to handle such a special case. It has to be reconsidered if generalities should be given for applications where an user provides personal data and is generally not aware of identity theft or financial harm.

12 12 Levels of Assurance References 1. ISO/IEC: Information technology - Security techniques - Entity authentication assurance framework (2012) 2. Kantara: Identity Assurance Framework: 4 Assurance Levels (2010) 3. Bolten, J.B.: MEMORANDUM TO THE HEADS OF ALL DEPARTMENTS AND AGENCIES (2003) 4. Rouse, M.: single-factor authentication (sfa) (2007) 5. NIST: Electronic Authentication Guideline, Special Publication (2011) 6. STORK: D2.3 - Quality authenticator scheme (2009) 7. Rouse, M.: two-factor authentication (2005)

13 Levels of Assurance 13 A Summary of the four LoAs ISO/IEC NIST ENISA/STORK IAWG Kantara Confidence in the claimed or asserted identity Authentication method Robustness of the credential Authentication protocol Attacks, which have to be prevented Security of the stored credentials / assertions Usage of the level Minimum risk caused by erroneous authentication Minimal; user should be the same No specific requirement; minimal assurance; no cryptographic methods Some assurance, that a user is the same as in former sessions User has to prove, that he possesses and controls the token Erroneous authentication has a very low or negligible impact Minimal or none; verification of a given address; no government agreement needed No guidelines for strong passwords or PINs are given Secure authentication protocol None Little or no protection Protection against manufacture / modification and reuse attacks Erroneous authentication causes no negative consequences Minimal Some assurance; no cryptographic methods Table 1: Summary of LoA1

14 14 Levels of Assurance ISO/IEC NIST ENISA/STORK IAWG Kantara Confidence in the claimed or asserted identity Authentication method Robustness of the credential Authentication protocol Attacks, which have to be prevented Security of the stored credentials / assertions Usage of the level Moderate risk caused by erroneous authentication Single-factor authentication Some Presentation of identifying materials or information Single-factor remote network authentication Eavesdropping, online guessing attacks Must be protected against attacks Secure Secure; weakly resistant against MITM attacks; Approved cryptographic methods required Online guessing, replay, session hijacking, eavesdropping Resistant to disclosure, redirection, capture, substitution attacks + LoA1 requirements Identity misuse has low impact Identity has to be validated with governmental agreement Single-factor authentication Must conform common guidelines for strong passwords and PINs Has to be sufficiently robust Some protection [6] against guessing, eavesdropping, hijacking, replay, and MITM Moderate risk caused by erroneous authentication Confidence, that the asserted identity is accurate Single-factor remote network authentication Secure Eavesdropping, replay and online guessing attacks Table 2: Summary of LoA2

15 Levels of Assurance 15 ISO/IEC NIST ENISA/STORK IAWG Kantara Usage of the level Substanital risk is caused by erroneous Confidence in the claimed or asserted identity Authentication method Robustness of the credential Authentication protocol Attacks, which have to be prevented Security of the stored credentials / assertions authentication High Verification of identifying materials and information Multifactor authentication Multi-factor remote network authentication Cryptographically protected Cryptographically secured Verifier impersonation attacks + LoA2 requirements; Cryptographic strength mechanisms required No requirements Protected against repudiation by Verifier + LoA2 requirements Identity misuse causes substantial damage Unambiguous identification of a user; supervised or accredited by the government Robust authentication methods Soft or hard certificates or one-time device tokens Protection against guessing, eavesdropping, hijacking, replay, and MITM Substantial risk is caused by erroneous authentication High confidence; verification of identifying materials and information Multi-factor remote network authentication Soft, hard or one-time password device tokens Cryptographically secured Table 3: Summary of LoA3

16 16 Levels of Assurance ISO/IEC NIST ENISA/STORK IAWG Kantara Confidence in the claimed or asserted identity Authentication method Robustness of the credential Authentication protocol Attacks, which have to be prevented Security of the stored credentials / assertions Usage of the level High risk is caused by erronerous authentication High; in-person identity proofing Multi-factor authentication Cryptographically protected Temper-resistant hardware devices In-person identity proofing Multi-factor authentication; personal authentication key Only hard cryptographic tokens allowed Strong cryptographic authentication; public or symmetric key technology Strongly resistant against MITM attacks + LoA3 requirements Cryptographic protection; keys bound to authentication process Identity misuse has a heavy impact Physical presence or a physical meeting; identity verification according to national law Most robust authentication mechanism Qualified hard certificates Protection against guessing, eavesdropping, hijacking, replay, and MITM Very high Multi-factor authentication Only hard cryptographic tokens allowed Cryptographically secured by keys bound to the authentication process Table 4: Summary of LoA4