After the exam, we had gathered two meeting with our supervisor Dr. Chandana Gamage. After our discussions with the supervisor, we had to change the system architecture. According to our previous architecture we planned to have the eID system in between the Reliant Party (RP) and the clients. For that architecture we identified there is the problem in the client authentication was services. We needed to redirect the request to the client to get his authentication details. So we identified that there is problem in the request redirection part because it is impossible to redirect the request in the web services.
There for I planned to develop a layer in between the Reliant party and the eID services. That layer help to redirect the request and get the client authentication details from the client.
But after the discussion with the supervisor, he didn’t suggest us to maintain that kind of architecture in the eID system. Then we planned another flexible architecture.
Then I started to find out the way to handle the message passing mechanism in between the client and eID card and the eID server. Then finally I found a solution to overcome that problem through the Java Applet. Through the Java Applet client and the eID server can communicate by using HTTP requests.
So finally we all are re planning the system architecture.
Monthly Archives: October 2008
R8: Think about New Architecture
Filed under Reports
R8: Vacation during Project
Its Vacation during Project, not Project during Vacation 
I started back working on the project couple of days after the exam. The first thing we had to do was to finalize the architecture in the online authentication and web services part. Malalasena and Shayanthan who were working on the WS part encountered some problems that required us review back the system design for changes. We had couple of meetings to discuss on these matters. After this we came up with changes and proceed on to development.
On the other had I worked on the project web site mainly. Though we had the documentation site at http://codex.project-eid.org/ we felt it could be better to have a blog to update our latest developments then and there. So I setup a blog using WordPress at http://blog.project-eid.org/ I also crearted usernames for each users, so that all of us can post independently. We then migrated mostly all the reports and posts from Moodle and some from our Google Docs to this blog, as appropriate.
I also did some tweeks in MediaWiki on which Codex site is running to suite more to our requirements. I also installed a custom made theme for the Codex site. (I’m thinking of porting the same theme for the blog as well in future.)
Then I setup the SVN code repocitory for the project at our site. But that is currently closed for public access due to some problems, and I’m trying to solve those currently.
Finally I also designed a nice index page for the project web site which is pure HTML and CSS, and it will be the home at http://www.project-eid.org/
We are into serious work after the vacation, and I hope things will go on smoothly in days to come.
Filed under Reports
R8: Messing around with Java card
Just after the first semester exams finished, I started the reading and implementation works in a smart card environment according to the decision made in the meeting with our project superviser. First I had to learn about the smart card basics, programming techniques and then set up the development environment. I went through several hardships in finding solutions in this phase, so I got many helps from many online forums.
After a lot of reading I decided to use Java card technology. It was not so familiar for me to work with that platform. Setting up the environment for the first time took me about a week. Presently I’m supposed to use the simulater available in JCDK (Java Card Development Kit). And also we are in the process of buying a USB smart stick or Smart card and reader from Singapore.
Presently I’m in the process of developing an applet to be used in the smart card. So I’ve identified the functions to be performed by the applet and designing the class architecture.
After the exams we had a group meeting for discussing issues with the web service development. We redesigned the architecture to overcome the problems. During this period we had several teleconferencings and discussed the issues. However we got some problems that had to be discussed with our superviser. So we decided to meet him when the semester starts.
We implemented a blog to our project website and I was working on migrating the old reports to that blog. We found that having this sort of blog will greately help us in the future. We decided to post a copy of all our weekly reports and other reports to this blog in the future.
Filed under Reports
Meeting with Project Supervisor (24-10-2008)
We had a meeting with our project supervisor Dr.Chandana Gamage today from 1.30pm to 2.15pm.
After yesterday’s meeting we had a brainstorming session with all group members and discussed about the options we have for the system architecture of the eID system. So we arrange today’s meeting to discuss further on this and finalize the design. Today’s discussions lead us to a redesign of our architecture. We found that there were some flaws in our earlier architecture, in which the eID WS was sitting on the middle, which could easily lead to problems in terms of load as well as attack prone.
Changes in Design
Some points that were highlighted at the meetings.
- Moving load away from central eID WS server
- One time signed polycies for the relying parties
- Complex functionalities implemented at the WS end
- Mostly all network enabled application are now on web, so better to have a browser plugin
So we decided to make the end-user to be at the end and include one more application to our deliverables list that would be a browser plugin. This plugin will now at as the center point which will handle the message flow from relying party, web service and the eID card.
Read-only memory eID
Also we decided to add one more deliverable to our project in the form of an alternative eID card to smart card based one, using a read-only memory stick. Though this would miss some security advantages, this could give some advantage interms of cost of the device. We will have to explore into this further to get more possible implementation options. We will have to try and find ways to make a normal USB memory stick to a secure one, or else we should find some other alternative that could work for our needs.
Offline Authentication Application
We also discussed about the Offline Authentication Application and how it would work in a practical situation. We discussed to have the following two in this application and to discuss further on this to add any other as needed.
- Signed Photo Verification (Signed by Issuing Authority, updated regularly)
- PoI (Persons of Interest) Checking System
Deliverables
We also finalized our list of final project deliverables with our supervisor as follows.
- eID card
- Smart card based
- Read-only memory based
- Online Authentication Web Service
- Browser Plugin for online authentication
- Offline Authentication Application
- Card Issuing/Updating Application
- 2 Research Papers (3rd one if time permits)
Filed under Meetings
Options for architecture. Which we select?
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.
Filed under Articles
Meeting with Project Supervisor (23-10-2008)
We had a meeting with our project supervisor Dr.Chandana Gamage today from 11.45am to 12.45am.
Today’s meeting was very important as we were able to identify many issues and problems to be considered in our project. I think this is due to the shortcomings in our initial design phase, but at least we found this at this point. We identified that the architecture we were working on has some problems and needs some changes. Due to this some of the earlier code of some modules need to be changed significantly. But I think that the way things work…!
Problems we found:
- Session handling through browser (This was misinterpreted at the meeting, hope what we were thinking was OK)
- How we tie up the message flow? – How the transaction is handled among Relying Party, eID Holder, and eID System
- Protecting Privacy in transaction – This will be one big concern, but we need to decide to what level we can do this.
- Possible DoS attacks
Possible solutions:
- A model similar to the Card Space specification (I don’t think this alone will solve our problems)
- But we could adapt something from here to our system
- Changing the message flow,, having user in the middle instead of the eID System in the middle (?)
Java Card:
Discussed about the progress on the eID Card development. As we wanted to use Java Card, decided to order and buy a Java Card and Reader for this purpose. We will have to decide on a suitable card soon and buy as it could help us progress faster. We will have to find a way to get it from Singapore or some place.
Read Only USB Token:
Even though we are doing main development using Java Card, project supervisor suggested us to have another option also with Read-only USB tokens as it could add value to the project. We will have to look into this too.
Admin Matters:
- Need to update the project web site regularly (Seems missing a lot lately)
- Having regular meetings with project supervisor, as it would help us greatly to identify flaws and issues in the project progress.
- We need to speed up thing a little more as we have a lot more to do
Filed under Meetings
Functions of Java Card Applet
Select method
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.
Deselect method
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.
Process 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.
Other specific methods
Writing Data
- setPersonalData()
- setPublicPrivateKeys()
- setBiometrics() – If needed
Reading Data
- verifyPin()
- validateSignature()
Filed under Articles
R8: Problems, me and web services
After the exam, I resume development of the web service. That was my first experience with web service development. So, I developed the web service while learning the web service development with apache Axis2, WSAS (WSO2 Web Service Application Server) and eclipse IDE. While developing the web service I figured out some problems with our system architecture.
According to previous system architecture;
In online authentication, First user will try to login to Reliant Parties (RP) web site. At that time RP will send a request to eID web service, asking authenticate the user (card holder). Then web service will be prompt a applet in the card holder web browser. Using that applet we service will access the USB smart card based eID and authenticate user and redirect user to the RP web site again.
But finally I figured out that is not possible in web service because, in web service all the executions are happened in server side and browser redirections are not possible in web services. (We were very new to web services to understand that before)
Then I informed about that problem to the group members and we discussed about that. Finally we come up with a solution that having a separate layer (ie- web page) in front of the web service and then RP will redirect to the card holder to that layer and using that layer web service can access to the eID card without redirect user inside web service.
But after sometimes we figure out that not providing the optimal solution for the eID system. So we decided to have meeting with the Dr. Chandana Gamage after the vacation.
Then I started struggling with web services again.
Filed under Reports