1. I guess it should be common knowledge by now that password authentication is not very secure.

2. The main cause for that are the famous phishing attacks, in which the attacker directs users to a fake web page identical to another one and steals the user's passwords. But this is not the only problem with passwords.

3. The Internet is getting so wide and there are so many relevant web services that people have to remember an obscene amount of passwords. It is well known that people don't have the capacity to remember on average more than 6 different passwords.

4. This leads them to resort to insecure solutions such as writing down passwords or reusing them countless times. Some mechanisms were created to face these issues.

5. Single Sign-On
(SSO)
One of them is Single Sign-On or SSO. SSO systems allow a user to login only one time to access several web services. Examples of such systems are OpenID and Shibboleth. These systems still normally use passwords. Although passwords are still quite useful web authentication, they are no longer useful for services with higher levels of risk, such as online banking services.

6. Single Sign-On (SSO) Strong Authentication
For this last case there is strong authentication. Strong authentication is not a well defined term. However, it is commonly interpreted as authentication that uses one or more of the following factors:

7. Single Sign-On (SSO) Strong Authentication
KNOW
*******
Something you know, such as passwords or PIN codes.

8. Single Sign-On (SSO) Strong Authentication
KNOW
*******
HAVE
Something you have, such as an ATM card or a SIM smart card

9. Single Sign-On (SSO) Strong Authentication
KNOW
*******
HAVE
And something you are, or in other words, something that characterizes you uniquely such as a fingerprint or an iris used in biometric authentication.
ARE

10. Single Sign-On (SSO) Strong Authentication
KNOW
*******
HAVE
Most solutions use the first two factors, probably because biometric information is still quite hard to handle in a network environment. The problem with something you have is that its either based on something that’s cheap but easy to copy like a one time password list as Nordea uses, or its secure but expensive such as custom built security tokens.

11. Single Sign-On (SSO) Strong Authentication
KNOW
*******
HAVE
This is why the mobile phone is considered as the best option to fulfill that role. Most people have one and they normally take it everywhere with them.
So, by combining these two mechanisms, i.e. SSO and Strong mobile authentication, we can obtain a secure and usable authentication solution.

12. Strong Mobile Authentication in Single Sign-On Systems
So finally hello, my name is André Andrade and I’m going to present the results of my thesis entitled Strong Mobile authentication in SSO systems
André Andrade

13. Overview Objectives Protocol arquitecture and description
Prototype overview
Demo
Conclusion
Ill start by presenting my objectives in the thesis, then describe a strong authentication protocol we created. Third, Ill show how a protocol implementation prototype we developed works and actually demonstrate it. Then Ill shortly analyze both my results, the protocol and the prototype and present some insights about the work.
Finally Ill conclude the presentation.
André Andrade

14. Objectives
Strong Authentication protocol for SSO systems using the mobile phone as a security token
Security, usability, flexibility, cost-efficiency
Implmentation prototype
Proof-of-concept
Usable strong authentication method using the mobile phone as an alternative in SSO authentication
Lets now see our objectives. Our main objective was to create a protocol for strong authentication in SSO systems using the mobile phone as a security token. We figured that a protocol gives developers the freedom to make some different decisions while still having a good platform to start on. So our protocol is focused on creating systems that are first of all secure, as to protect from the most relevant and known threats existent. Also focused on usability to provide a good user-experience as compared to other common solutions. Flexible as to allow the implementation with different tools and systems. And inexpensive to implement and deploy.
I also created an implementation prototype to prove that the concept of the protocol is applicable and to demonstrate the possibility of creating a usable strong authentication method using the mobile phone integrated in an SSO system as an alternative to service providers
André Andrade

15. Protocol - Arquitecture
We start by going through the architecture of the protocol. As we can see in the figure, our protocol is built on top of the common SSO platform architecture with the service provider that has the web services, the user agent that tries to access those services and the identity provider that provides authentication and identity management. We just included the mobile phone to the architecture. As you may notice, there is no direct connection between user devices! We chose not to rely on that connection because it may not often exist. For example, when you access a public library computer, it is improbable that it has a bluetooth connection or even that it is completely secure to connect the phone to it.
André Andrade

16. Protocol - Arquitecture
In the flow of our protocol we don’t include the SP because it is not directly involved in how the authentication method works. So besides the user agent that requests authentication and the authentication service that processes it in the IdP, the mobile phone has two components: the authentication client application which is the client interface, and the credential manager which manages the user’s private credentials. We rely on the existence of a credential manager that stores the user credentials safely and processes them in an isolated environment. There are two mechanisms in the phone that make this possible: the SIM and OnBoard credentials from Nokia. In our implementation we use onbard credentials as we will demonstrate shortly.
André Andrade

17. Protocol - Description
The protocol focuses on two main aspects:
The first is to guarantee that the authentication service ensures that the same user controls both devices during the authentication. And second is the unequivocal identification of the user with his credentials.
I’ll now explain each step of the protocol. The UA starts by creating a TLS connection with the AuS. Then …
As we saw the protocol is divided into two main parts: the authentication session enforces that the same user controls both devices and the user identification. And then the actual authentication of the user composed by both authentication factors: the PIN authentication to control the access to the credentials and the digital signatures in the challenge response method to actually prove the user’s identity to the authentication service.
André Andrade

18. Prototype - Overview
I developed an implementation prototype of the protocol to prove its concept. The prototype was built on top of the Shibboleth SSO system and OnBoard credentials as the credential manager. Onboard credentials uses general purpose secure hardware on the phone to manage the credentials safely.
The most significant detail to mention in the prototype is that it uses cookies as the session management as a consequence of using HTTP. Cookies have several vulnerabilities that are outside the context of the protocol so we had to investigate and solve them.
André Andrade

19. Prototype - Demo Credential db: /etc/sauth/db/
Sealed credentials are unsealed by the credential manager when used
Seal is an encryption of the private key and PIN using the embedded platform key
- Browser starts → Mobile follows
- Mobile starts → Browser follows
- Two browsers → Mobile follows
- PIN wrong 3 times
- Session Expiration in browser or in phone
André Andrade

20. Conclusion SSO and strong authentication complement each other
Mobile phone is a beneficial option as a security token and there are secure mechanisms that enhance it
Protocol enables the creation of secure, usable, flexible and cost-efficient strong authentication methods
Implementation prototype
André Andrade

21. Questions? I’ll be glad to answer any questions you may have.
André Andrade