Novay's NFC Passport Reader

At Novay, as part of a project for EIT ICT Labs on Mobile Security & Privacy, we have been working hard on an Android app, based on JMRTD, to demonstrate how passports (and identity cards) and the passport holder can be validated. The first version of our efforts is now available from the Play Store.

Now the underlying ePassport Java library JMRTD was ported to Android almost two years ago in a proof-of-concept app. The new Novay app focuses on two new features. First, it makes the passport reading experience as user friendly as possible. The UI is up to 4.x standards, and has been better thought out. We're looking at showing the information as soon as possible as it comes in over the (awfully slow) NFC connection, while at the same time making sure that the user understands that the document needs to held in proximity to the device for the couple of seconds that it takes to read all of the information.

Second, and more importantly, the new app uses the security mechanisms of the chip embedded in a passport to their full potential. This means that the authenticity of the contents and of the chip are actually checked, and the results are displayed to the user.

We're working on a next version this app in a second phase of this project. We still see plenty of possibilities to improve the usability. 

People at Novay involved are: Peter Ebben, Ruud Kosman, and myself. Thanks to Atlantic Zeiser for providing the sample document that was used in the screenshots above and in the Play Store.

Step-up authentication as-a-service for SURFnet

Two-factor authentication used to be the domain of secret services and the military. The enterprise and consumer e-Banking and e-Government domains have since embraced two-factor (or: step-up) authentication. More recently social network sites such as Facebook and Google have started offering two-factor to protect their (free) services. Federations of higher education and research (operated by the NRENs) are still largely basing their authentication on username/password.

A parallel development is that service providers in federations for higher education and research are starting to offer services that deal with highly sensitive information; for instance privacy sensitive administrative, research, or medical data. This is both a consequence of the success story of federations as well as the "move to the cloud" where traditional in-house applications like accounting systems are increasingly being outsourced to cloud providers. Because of the sensitive nature of the data in such systems, stronger forms of authentication are necessary.

NRENs such as SURFnet have noticed these trends, and the discussion of how to best approach two-factor within a federated setting is now in full progress. An Identity Provider (IdP) within a federation is ultimately responsible for providing the identity of its users. This includes authentication and the IdP can make authentication as strong as it wishes, of course. The case for two-factor in a true federation is, however, significantly more complex than rolling out two-factor in a situation where Identity Provider and Service Provider coincide (such as in e-Banking or the enterprise), as information about the Level of Assurance is shared with and interpreted by Service Providers in the federation. Introducing multi-factor authentication within a federation is really only sensible if registration (enrollment of an authentication token) procedures also warrant a strict higher level of assurance.

Novay, in close collaboration with SURFnet, has made an initial design for a service to assist Identity Providers in the introduction of two-factor authentication solutions that can be used across the SURFconext federation. The report describing the design is available for download from the SURFnet website. The report describes both the technical (architecture, standards) and the procedural (registration, logging, de-registration) challenges.

Architecture

The two main architectural challenges to focus on are:

• the best location for a multi-factor-authentication service, such that it can support multiple Identity Providers;
• which standards (and what choices within those standards) should be used for uniformly signaling the level of assurance from Identity Providers to Service Providers.

As for the location of the service: in a SAML based hub-and-spoke federation (such as SURFconext) it makes sense to base (the initial version of) the service as a transparent proxy on the Service Provider bound exit of the hub (as shown above). This separates the service from the hub. It also means that the Identity Providers and Service Providers can remain unchanged, except for Service Providers that need to deal with higher levels of authentication. The paper builds a case for this simple architecture.

As for the standards to use: there are many variations on levels of assurance frameworks. To name  just a few: NIST SP800-63 for the US and STORK for the EU. The best option, at this moment, would be to standardize on the upcoming ISO/IEC 29115 standard which will unify some of these standards. SAML 2.0 has had support for signaling details about the authentication process (and related processes) since its inception in the form of the so-called Authentication Context. This concept, however, leaves a lot of implementation freedom (and therefore interpretation freedom) for Identity Providers and Service Providers. Attempts to merge the Authentication Context concept with ISO 29115-style levels of assurance are relatively recent, and also appear in other authentication protocols such as OpenID Connect. The paper will give recommendations for how to best apply these standards.

Registration process

The level of assurance of an authentication token is not only determined by characteristics of the token itself, but also by the process by which the token is bound to an individual user by the Identity  Provider. The paper recommends appointing a Registration Authority within the institute of higher education or research and making that person responsible for binding authentication tokens to users  (staff, students) of the institute. The paper gives precise guidelines for setting up a Registration Authority. The most important recommendation is that individual users should visit the Registration Authority in person for face-to-face binding to the authentication token. The user should bring the token and a valid passport or identity card. The Registration Authority will check that these match with the user and with the attributes as issued by the Identity Provider. The Registration Authority also oversees an authentication attempt (with the second factor only) to make sure the user actually  controls the token.

The registration process is supported by an online service hosted by the federation operator. The service contains both a self-service user interface for end-users (so that most of the administrative process can be dealt with before the user actually visits the Registration Authority) as well as a user  interface for the Registration Authority. The paper shows mock-ups for both user-interfaces.

It is highly likely that the service proposed in the paper has broader applications beyond the boundaries of SURFconext. The architecture was described with portability in mind, such that the service can be re-used in other federations. Although the paper makes some concrete choices (to make it relatively easy to actually start building such a service) these choices are documented in the  paper.

Acknowledgements

The authors would like to acknowledge Ruud Kosman of Novay for designing the mock-ups and other colleagues from SURFnet and Novay for reviewing early drafts of the paper.

Context-enhanced Authorization

Context information can make authorization management more flexible and more secure. Knowing when and where users are, and what they are up to helps in determining which access rules to apply. We recently did a project with Rabobank and IBM where we ask (and answer) questions such as: 

• What authorization related use-cases could benefit from context information?
• Which context-sources are relevant, mature enough, secure enough to be used today (or in the very near future)?
• How to deal with the (lack of) quality and authenticity of context?
• How does context information interact with authorization standards such as XACML and today's implementations of those standards? (See my previous posts for more technical details on the hands-on XACML work that we did in that project.)

The main lessons learned (the answers to the above questions) are:

• Typical use-cases can be found in the area of the mobile workforce ("nomadic working", etc.). As organizations introduce these new ways of working, traditional security policies that are only based on (authenticated) identity and static roles and entitlements are too strict and too coarse-grained. Context can make a difference here and allows finer-grained access so that, for example, medium level security tasks can be performed from home if the context allows this.
• A model for context-information can be constructed around different context-types, some traditional (location, time, ...), some more exotic (physiological, mental, social, ...). The above use-cases can already be adressed with the more traditional context-sources: location, time, proximity, device id, network id. These basic context-sources are readily available, and are under control of the organization.
• The easiest way to deal with authenticity and quality of context is to rely on trusted context-sources that are under control of the organization.
• Externalization of authorization, such as propagated by the Attribute Based Access Control (ABAC) paradigm (and facilitated by standards such as XACML) works well in practice when combined with context information. In a demonstrator (see video above) we showed that adding context to authorization policies managed by Tivoli Security Policy Manager (a XACML IBM product) comes down to adding a policy information point. Relying applications only need to understand XACML in order to become context-enabled.

Obviously, there are questions left for future research. How to deal with privacy issues is one of them. Complexity of policies and other scalability and performance issues form another. Want to read more? Go check out the project page or read the white paper.