Author: Robert Leslie, CEO, Sedicii Innovations Ltd With growing concerns about data protection and privacy in the press in recent times, we still regularly read reports about how we are exposing our personal information and not protecting ourselves properly when we go online. We use simple passwords and then reuse those same passwords on multiple websites, significantly increasing the possibility of the theft of our private data. Why do we do this, when we know what the possible consequences might be? Do we really not care what happens to our identity? Yes, we do. However, in some cases, we are not aware of the best ways of protecting ourselves. In others instances, when it comes down to it, we automatically choose convenience over security when presented with a choice between them. The information we provide to websites about our identity can be broadly broken into three categories. (i)            That which is public – generally, this would be more likely to be content rather than specific identity attribute data e.g. content you post on Facebook or Twitter; (ii)          That which is private – content that you have put restrictions on as to who can see it, when they can see and where they can see it. In other words, you have placed bounded controls around it; (iii)        That which is confidential – this is information that you never, ever want appearing in public in any form, other than for your own consumption, as it is completely personal to you. However, it may be held in digital form in banks, insurance companies, healthcare providers, government agencies and companies you have relationships with. There is an automatic and justified expectation that this data will be held securely and in a form such that it cannot be reused if stolen or compromised in some way. How we provide, use and consume personal information into the future is a topic that should concern all of us. Given this context, we began thinking about ways to try to solve some of the challenges relating to how we use information. In particular, what if we could ‘consume’ private or confidential information without having to expose it? Could I authenticate you without requiring you to give me your password? Or, could I process your credit card payment without requiring you to share with me your credit or debit card details? These are the real world problems that we sought to address. AUTHENTICATION TECHNOLOGY Sedicii is a patented authentication technology, developed in the Digital Enterprise Research Institute, in National University of Ireland, Galway. It eliminates the need to transmit or store private information (e.g. passwords, credit card details or a passport number) during the process of authenticating. In the growing digital economy, this capability is important, as it provides a very secure way of confirming that a person’s private information is true without it ever being exposed. Sedicii is based on the Zero Knowledge Proof (ZKP) protocol, which is an authentication protocol used in cryptographic systems to allow a party to prove that they know something (e.g. a credential), without having to expose what it is they know. There are two parties involved in ZKP, the prover and the verifier. ZKP allows a prover to show that they have the information (for example, a credit card number or password), without having to give the verifier the details of the information. Sedicii is based on an isomorphic graph implementation of ZKP. When used in a pure authentication context, it provides secure authentication without the need to transmit the password, or a hash of the password, over the network. Sedicii also eliminates the need to store password hashes in a database. Thus, if a hacker is able to obtain access to the credential database, they will still not be able to determine what the passwords are. AUTHENTICATION SCENARIO Here is how the Sedicii ZKP protocol works in an authentication scenario. The user initially needs to be registered on the system. Once registered, they can they authenticate whenever they choose. Registration process:

1. The user (prover) inputs a username and password;
2. The user’s browser, via a downloaded javascript, hashes the username and password with a hash function and generates a permutation, referred to as the 'private permutation';
3. The server then generates a random graph G1 and sends it to the user’s browser via a javascript. G1 is then stored on the server;
4. The user’s browser then computes a second graph G2, which is G1 transformed by the permutation created in step two;
5. The user sends the username and G2 to a server, where they are stored in a database.

Authentication process: The verifier (the Authentication Server) knows G1, G2. It does not know the password. The user knows the password. A javascript downloaded to the user’s browser converts (via hashing) the user’s password into a permutation, referred to as the 'private permutation'. We now want to prove that the user (the prover) knows the password. The authentication process works as follows:

1. The verifier has G1, G2 and it also creates a series of random graphs G_R, which are created by applying a random permutation to G1. These random graphs will be used as a series of ‘challenges’ that forms a key part of the ZKP protocol;
2. The verifier then sends G1 and the random permutationto the user’s browser;
3. If the user is honest, then they know private permutation (derived from the hashed password),the browser should be able to calculate G2 by applying the private permutation to G1. (NOTE: the verifier never sends G2 to the user)’;
4. The verifier generates a random permutationand calculates a random graph G_R, which is G1 with the random permutation applied to it;
5. The verifier sends the random permutationto the user’s browser;
6. The user’s browser then generates a response permutation, i.e. a ‘response’ to the ‘challenge’, by calculating the product of the inverse of the private permutation and the random permutation. The browser then sends this valid response permutation, the ‘response’, back to the verifier;
7. The verifier can now apply the response permutationto the stored G2 to see if he gets back to the random graph G_R that was originally created in step four;
8. If the result of applying the response permutation to G2 is in fact G_R, then the verifier can conclude that the user knows the password.

Why? Because the response permutation is the product of the random permutation and the inverse of the private permutation. The user could not supply the verifier with the correct response permutationif he did not know the private permutation to start with and the user could not generate the private permutation if he didn't have the password. PROTECTING PRIVATE PERMUTATIONS At no point, does the user send the private permutation to the verifier. He sends the response permutation instead. This means that the verifier never knows and never stores the private permutation. This matters because storing the password, or a representation of the password (which is what the private permutation is), would mean Sedicii is no different from all the other authentication systems out there that transmit and store passwords. The above steps are just a single iteration through the authentication process. In the full implementation, the process is carried out 20, 30 or more times. Note that different G_Rs are used in each iteration. This introduces a massive level of randomness into the whole authentication process to make life even harder for an attacker. In the Sedicii implementation, timers are used to ensure that the attacker would not have time to brute force the calculations. In addition, the private permutation is actually created by hashing the password using a salt to add complication. So in step two of the algorithm above, the user is actually sent three things: a random graph G1, a salt and a random permutation_. It should be noted that all the complex calculations described above are occurring inside the browser and are completely invisible to the user. All the user has to do is enter a username and password exactly as they do today – nothing changes. The many vulnerabilities and attack vectors for web-based applications include both web-specific (e.g. cross-site scripting) and generic (e.g. password sniffing) ones. Such issues can expose users to identity theft and loss of their personal, financial and other valuable data. Whilst relying on service based security solutions, such as SSL certificates, to protect applications and with the introduction of cloud computing and the growing complexity of attack vectors, it will no longer be acceptable, feasible or even viable to maintain such security by just adding more firewalls and SSL certificates. The transformation of user engagement with digital services in recent years has created significant vulnerabilities in the security and management of users’ private information online. The traditional ways of authenticating a user have highlighted much vulnerability where a user’s private information can be stolen and exploited, creating significant inconvenience for the user and serious financial and reputational consequences for the holders of this data. Sedicii is building on the capabilities of greater processing power, greater bandwidth and more robust cryptography methods to provide a safer way to protect private user information in an ever threatening online world. Rob Leslie is the CEO and founder of Sedicii. He has held senior management/director positions with Datacraft Japan, PTS Ltd, eSafe Japan and Dell Japan, where he was part of the initial management team that launched Dell into the Japanese market. He subsequently became a partner in PTS, a niche technology services company that was acquired in 2000 by Datacraft Asia as part of its entry strategy into the Japanese market for a significant sum. Leslie is also co-founder of Global Business Register, which specialises in identity and compliance solutions for banks and other companies with anti-money laundering and ‘know your customer’ regulatory needs. Since 2011, he has been actively working on the Sedicii project. He is also a mentor with Enterprise Ireland, providing advice to its high-potential startup companies and is an investor in a number of technology and biomed startups.