ALUCID feature analysis

7. ALUCID feature analysis

ALUCID feature analysis is similar to the analysis of PKI features.

7.1 ALUCID in peer-to-peer environment

The use of ALUCID in peer-to-peer communication is partially similar to the use of PKI in this environment. RP can manage personal data collected from its users in a way that is similar to the way certificate authorities manage it.

ALUCID offers simplification and requires a different way of thinking about eID from the RP staff point of view. The most interesting difference is probably the opposite sequence of activities related to personal data management.

This feature enables to use different methods of personal data verification and enables use of personified electronic communication to support personal data verification.

7.2 ALUCID in cross-border and cross-sector environment

The complex cross-border and cross-sector environment creates additional place to use infrastructural features and advantages of ALUCID network topology design (see Figure 2). Sharing thousands of eIDs needed to support communication with thousands of RPs is done automatically by PEIG. The user can only have one PEIG. The topology and relationships between players in the complex environment are simpler due to missing third parties. The basic relationship is the direct relationship between RP and its customers, i.e., direct relationship between a citizen and an electronic service provider (government organization).

The situation can be moreover simplified by trust between RPs. ALUCID supports trust relationships in any topology. The trust between RPs enables to share verified personal data between RPs linked to eID in a secure way. The use of anonymous random numbers is the same in any language. The link between authentication and user’s database record is thus not language dependent. The interoperability of direct communication between RPs used for exchanging personal data in the case of trust relationship can be solved by standard methods and tools used in other areas of data exchange in e-government (Neumann, 2006).

Only peer-to-peer translation is needed (if any translation is needed at all).

Anonymous electronic identity in cross-border and cross-sector environment

Figure 2 Identity triangle principle in a cross-border environment

In a cross-border and cross-sector environment, we can find the following consequences: (1) Communication with any party only when needed by the citizen; (2) Every RP should have a minimal specific set of personal information reflecting its specific needs and law

regulations; (3) Every piece of personal information can be protected by access management with clear responsibility in particular law conditions.

7.3 Trends

If we analyze trends, we can find that with the increasing number of RPs using ALUCID: (1) The complexity of the personal data verification process is the same, independent of the number of other

RPs; (2) The amount of personal information stored in one RP database is not changing and the level of privacy stays the same; (3) The eID change is independent of personal data changes and other RPs; (4) The risk of semantic and format incompatibility is independent of other RPs; (5) The risk of user’s refusal to do complex verification of a lot of personal information is independent of the

number of RPs; the amount of repeated verification of the same personal information can be decreased by trust between RPs;

(6) The compatibility of the personal data verification process with privacy protection is specific to the RP and to the trust relationship between RPs; it can be solved individually, it does not depend on other RPs; (7) The quality of verified information does not depend on other RPs (excluding if there is trust between RPs); (8) The risk related to incompatibility of the culture environment and law system does not exist in eID; it

Anonymous electronic identity in cross-border and cross-sector environment

does exist in the personal data verification process; (9) No language translation is needed in eID; it is a peer-to-peer issue in the personal data verification process; (10) The risk of identity theft does not depend on the number of RPs; it is controlled by eID security management independently of other RPs; eID used by one RP does not depend on eID used by any other RP, and the risk of personal data abuse from eID is theoretically zero.

From the other point of view, in the case of wide use of ALUCID, the complexity should decrease for users and RPs. The probability that the citizen will have his/her own PEIG grow and so will the probability of using PEIG to communicate with a new service.

7.4 ALUCID specific topics

The question how to verify personal information and link it reliably to anonymous eID might be also interesting. The following text tries to provide a basic answer. EID is created automatically and it is without any relationship to users’ personal information. The eID infrastructure is able to distinguish between users by use of anonymous eID, but there is no relationship with personal data.

If RP needs personal data to support the electronic service, the account activation procedure including personal data verification is necessary. The starting access rights will be different from the target access rights. The access rights will be changed to the target ones when the procedure is successfully finished. The starting access rights should be set up in order for the procedure to be executed.

These are examples of possible account activation and personal information verification scenarios: (1) Personal presence—the user will bring his/her PEIG and visit the RP’s contact point. In this case, the

standard physical identity verification can be done together with the use of PEIG. The physical presence of PEIG can

be used to link the verified identity to anonymous eID, and the account can be activated with target access rights;

(2) Activation key (one-time password)—the standard identity verification process can be executed. When finished, RP generates a specific activation key which is then transferred to the citizen. This activation key is linked to the verified personal information. The user opens the electronic service with his/her PEIG and enters the activation key. The key is linked to the session and the session is linked to the anonymous eID (PEIG), i.e., the verified personal information is linked to the eID;

(3) Signed form—the user opens RP’s electronic service as a new user with his/her PEIG. The RP’s information system displays a form with unique form ID (the form number). The user fills in the requested personal information, prints the form out and signs it (by hand). The signed form can be sent as a standard letter. The RP verifies the personal information included in the signed form by a standard “paper” identity verification procedure and then the RP uses the form ID (linked to anonymous eID in the information system) to activate the account;

(4) Sharing between RPs—one RP trusts the personal information verification process of another RP, the specific service of ALUCID (identity triangle) can be used to transfer specific verified personal information between RPs without sharing eID;

(5) Identity authority—when an RP is generally trusted as the personal identity information authority (like a specific government office issuing passports), it can work as an “identity authority” and transfer verified personal information to many other RPs (of course, with respect to the laws).

In the case of cross-border and cross-sector environment, direct peer-to-peer user communication can be used in various forms, such as classical “paper based” or “personal communication” based procedures supported by the

Anonymous electronic identity in cross-border and cross-sector environment

existing law system, verification procedures and trained staff. The second option, which is more ICT technology based, is about sharing personal information between RPs. The idea of “identity authority” can be very advantageous in e-government. The trust related to the personal information about citizens existing in governments (e.g., in the case of issuing citizens cards, passports, driving licenses and health insurance) can be used for electronic personal data exchange linked to eID.

7.5 Real life experience

ALUCID has been verified by pilot deployment in 2 applications of Ministry of Culture from August, 2009 (http://www.kultura-evropa.eu/, http://www.norskefondy.cz/). Many partial issues have to be solved during pilot planning phase such as distribution of PEIGs, ALUCID integration with Microsoft SharePoint Portal, interconnection of AIM with the application in hosted virtualized environment, account activation and linking of ALUCID account with previously created account, services supervision and management, authentication security management etc.

All issues have been solved successfully; ALUCID features (e.g., AIM network interfaces) have been used in many cases as advantage. PEIG have been distributed using an installer (a program used for installation of regular software) located on

a USB flash disk. The possibility to use network distribution of PEIG was verified as well. The installer supports PEIG installation in 3 PEIG use scenarios (PC based and 2 scenarios of USB token based PEIG). The modification of “activation key” scenario has been used for account activation and link of ALUCID accounts. Old account user name and password are used. Microsoft SharePoint Portal supports external authentication systems. ALUCID has a defined network interface. Therefore the integration was relatively simple and quick. The real operation has shown functionality and stability of ALUCID and MS SharePoint Portal integration module implementation. Only one functionality blackout has occurred since the start of operation until this text writing.

The use of ALUCID is voluntary; any user can use classical user name and password authentication supporting password memorizing in browser if he does not want to use ALUCID. The current security policy does not need forcing of password strength control or periodical change of password.

ALUCID uses authentication based on 18 byte pseudorandom identifier 30 byte authentication random challenges and 1024 bit RSA key with MD5 hash. ALUCID has been tested by about 7% of users and it is regularly used by about 5% of users. The pilot deployment has brought real life experiences. They will be used in future ALUCID development.

Currently, another pilot deployment is prepared. The environment will need higher level of privacy protection.