We, the team of Project eID, just made this video documentary to help anyone gain a brief idea about our project. We have included many basic details about our project that could serve as a starting point to anyone who is interested in our project.
Its a 13 minutes video, but we urge you to watch the 13th minute…
We would like to thank Dr. Chandana Gamage, our project advisor, for his valuable inputs to this documentary. Also we would like to thank Mr. Thiyagaraja Dinesh for helping us in the making of this documentary.
I have just finished adding the svn:externals property to our SVN repository at university, to enable pulling the commits from our Project eID repository.
We were recently given a Subversion repository for project purposes at our university which is at http://repos.cse.mrt.ac.lk/05/cnwisg2/. But as we are already having setup our Project eID repository at http://svn.project-eid.org/eid/ I thought of using svn:externals at the CSE repository, thanks to Senaka for proposing the idea.
I used TortoiseSVN to do this, though this can be done with any SVN client (including the geekey command line client). Thanks to this and this, now things are working fine.
Just for the information I used the following properties with svn:externals
After the meeting with our project supervisor yesterday, we decided to review the two architectures for online authentication mechanism. I’d like to present some of our findings and thoughts on these two in this post.
The first architecture is the one that we already had. In that model eID systems stays in the middle in the authentication processs between the eID Card Holder and the Relying Party. The system will be using a Java Applet to perform authentication with the eID Card Holder.
The second architecture that we proposed at yesterdays meeting. It keeps the eID Holder in the middle of the process, giving more control over what is happening. In this model the communication between the Relying Party and the eID System happens solely through the eID Card Holder. But for this to work we might have to use a local application or a browser plugin to perform many of the actions.
After some long discussions within the group members, we thought we should stick with the first design than the second one. I’d like to point out some of the points which led us to this decision.
Problems identified in the first design:
Session handling method
Tie up message flow
Possible DoS attacks
How those could be solved:
We can use session tokens accross a transaction, which could solve session handling and tie up message flow
To prevent DoS attacks, there are many standard procedures. Using CAPTCHAs could be a very basic but an effective method in this. Also there are other measures that could be taken to prevent DoS attacks at system level.
Problems identified in the second design:
Complexity on the Relying Party interms of Signing and Verifying Signs. This is a problems as we cannot expect every system developer how wants to use eID System to know and implement these complex tasks.
Communication from the local application/plug-in will be a problem, unless we use HTTP. Also this needs certain installation and permission at user computer.
Also there is one important reason for deciding not to use the second design. The second design is very much identical to the Card Space specification. And these is already an implemention of this as WSO2 Identity Solution. Though there are significant differences from this and Project eID, following the same basic design would be like a duplication of systems.
So we have currently decided to use the our earliear design, but we can use any good features in the later design. I hope we could finalize on this by today evening. I’ll try to post an update on this by today night.
The select method tells the JCRE if the applet is ready to process requests, by returning a true value. If the applet is not ready to accept processing requests, the select method returns a false value.
If an applet is selected and you want to select an applet with a different AID, the JCRE calls the currently selected applet’s deselect method.
Once an applet is selected all communications between the applet and the client application are sent to the process method
This method accepts an APDU object as a parameter. The APDU is sent from the client application to the java card applet, the client application then waits for a response APDU in return. For security reasons references to an APDU object are only allowed within a method, so an APDU must be passed in as a parameter to the method or stored in a local variable. This is to protect against the possibility of one Java Card applet accessing APDU data that belongs to another Java Card applet.
I found a good Network authentication protocol which can be helpful for our project. Kerberos is a protocol and it has it’s own Architecture. And it is mainly designed to provide strong authentication for client/server applications by using secret-key cryptography. A free implementation of this protocol is available from the Massachusetts Institute of Technology. Kerberos is available in many commercial products as well.