• Save
Secured Credential management system for Grid Computing Using Smart Cards
Upcoming SlideShare
Loading in...5
×
 

Secured Credential management system for Grid Computing Using Smart Cards

on

  • 770 views

Smart Card - One Card To Rule Them All

Smart Card - One Card To Rule Them All

Statistics

Views

Total Views
770
Views on SlideShare
770
Embed Views
0

Actions

Likes
2
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Secured Credential management system for Grid Computing Using Smart Cards Document Transcript

  • 1. USING SMART CARDS INGRID COMPUTINGA DissertationSubmitted In Partial Fulfilment OfThe Requirements For The Degree OfMASTER OF SCIENCEInNETWORK AND E-BUSINESS CENTRED COMPUTING,SCHOOL OF SYSTEMS ENGINEERINGUNIVERSITY OF READINGbyMr. Anind Duttaroy28thApril, 2008
  • 2. iiAcknowledgementsFirst and foremost of all, I wish to express my sincere thanks and heartfelt gratitude formy respected tutor and professor, Prof. Vassil Alexandrov, and my supervisor, Mr.David Johnson, for their immense assistance and support and constant motivation,without which, this project would not have been possible. This project is based on newconcepts and without their constant mental support and morale boosting and everypossible help, it would have been very hard for me to sustain the pressures of the project.I would also like to express deep appreciation and thanks for Mrs. Nia Alexandrov forher assistance and support throughout this programme. I would also take this opportunityto thank Mrs. Nellie Round for her administrative support. I express my deep gratitudeand my respects for everyone, named and unnamed, whose work and achievementshighly inspired me to undertake this project. Last, but not the least, I thank all the otherswho were very supportive of me throughout this work.
  • 3. 3AbstractThe bottom line of this research project is to examine a way to improve the Credentialmanagement system of Grid computing and in effect move the responsibilities ofcredential storage towards a better hardware and software platform. Storing of X.509 PKI(Public Key Infrastructure) credentials like, public and private keys, digital certificatesand/or proxy certificates etc., in the smart card is possible and would provide a betterauthentication process. This would be safer and secure than the present day systems like,Kerberos and MyProxy or any dedicated server acting as credential repository. Currently,a smart card is one of the major hardware components that provide the highest securitylevel and almost hack-proof. Plus, its self-destructing capabilities ensure that, the privatekeys of PKI and other confidential credentials stored in the smart card do not fall into thehands of malicious entities. Majority of smart cards today use the Java card technology bySun Microsystems Inc.The project aimed at creating a vendor-independent, platform -independent java card or smart card solution to implement in grid computing. Hence, thedesign and development was attempted on the Java Card development Kit version2.2.2, bySun Microsystems. The application development on this kit proved to be very limited innature. There were serious problems in installation and loading of applets by both themodels of communication - message passing model and the JCRMI model. The appletswere not being loaded, on and off, and there were loads of environment settings‟ problemsand problems in the configuration of the supplied tools and in their execution. Due toinnumerable technical hitches and time constraints the application development could notbe carried out to reach the expected target and had to be terminated midway. It reinforcesthe requirement of a developed IDE (Integrated Development Environment), preferably, afreeware, for the convenience of independent researchers and groups. Though the fulldesign could not be realized, yet, the methodologies and the processes followed and thedesign principles and programming procedures observed were in accordance with theJava card development framework guidelines, specifications and practices. In future, ifthe remaining steps of implementation can be carried out; there would be chances of highsuccess, to have a safer and secure Credential repository and authentication process inGrid computing.
  • 4. 4Table of Contents _ Using Smart Cards in Grid ComputingTable of ContentsAcknowledgements..............................................................................................................iiAbstract..............................................................................................................................iiiTable of Contents ...............................................................................................................ivTable of Figures................................................................................................................viiiList of tables .......................................................................................................................ixList of Abbreviations...........................................................................................................x1. Introduction and Background ........................................................................................ 11.1 What is it all about....................................................................................................11.1.1 Grid Computing........................................................................................................21.1.2 Smart cards............................................................................................................... 31.1.3 Java cards.................................................................................................................. 41.2 Overview of the scope and challenges.......................................................................52. Preliminary System Design............................................................................................. 82.1 Grid computing security........................................................................................... 82.1.1 Symmetric Encryption............................................................................................ 102.1.1.1 DES cryptosystem........................................................................................ 112.1.1.2 AES cryptosystem........................................................................................ 112.1.2 Asymmetric Encryption.......................................................................................... 122.1.2.1 RSA algorithm ............................................................................................. 132.1.2.2 DSA cryptosystem........................................................................................ 132.1.2.3 Elliptic Curve cryptosystem ........................................................................132.1.3 Certificate Authority .............................................................................................. 142.1.4. Digital certificates..................................................................................................152.1.5 Grid Security Management and Infrastructure ....................................................162.2 Authentication mechanisms................................................................................ 182.2.1 Shared secret based authentication........................................................................182.2.2 Public key based authentication.............................................................................182.2.3 Third party authentication..................................................................................... 192.2.3.1 Certificate based authentication..................................................................192.2.3.2 Kerberos.......................................................................................................20
  • 5. 5Table of Contents _ Using Smart Cards in Grid Computing2.3 Credential management systems........................................................................222.3.1 File system repository............................................................................................. 252.3.2 MyProxy.................................................................................................................. 262.3.3 KX.509..................................................................................................................... 272.4 Smart Cards.............................................................................................................282.4.1 Physical characteristics.......................................................................................... 282.4.2 Software characteristics......................................................................................... 312.4.3 Limitations, weaknesses and measures .................................................................332.4.3.1 Physical Attacks........................................................................................... 332.4.3.2 Weakness in the system................................................................................ 342.4.3.3 Limitations...................................................................................................352.5 Smart card enabled credential repository and authentication.............................. 362.5.1 Weakness in present day systems........................................................................... 362.5.2 Advantages of the smart card system.....................................................................362.5.3 The credential store and authentication mechanism............................................. 372.5.3.1 Functional requirements specification........................................................ 392.5.3.2 Usability issues............................................................................................. 402.6 Comparison of smart card system with others ...................................................... 413. Implementation Strategy .............................................................................................. 443.1 Smart card application development features ........................................................ 443.2 Java card technology............................................................................................... 453.2.1 The Application framework ................................................................................... 463.2.2 The java card API structure...................................................................................513.2.3 The development process........................................................................................ 524. Detailed Software Design and Implementation............................................................ 574.1 Detailed design description..................................................................................... 574.1.1 Multi-Tier architecture/N-Tier architecture ......................................................... 574.1.2 Java card three-tier architecture ........................................................................... 584.1.3 Grid Portal - Presentation Tier .............................................................................. 614.1.3.1 Grid portal requirements ............................................................................614.1.3.2 Grid portal design........................................................................................ 614.1.4 Smart card reader applications..............................................................................624.1.4.1 Card reader grid interfacing application.................................................... 62
  • 6. 6Table of Contents _ Using Smart Cards in Grid Computing4.1.4.2 Java card client application.........................................................................644.2 Implementation Steps .............................................................................................. 664.2.1 Java card client-server design based on JCRMI ................................................... 674.2.2 Platform Setup, File Conversions, Development ................................................... 694.2.2.1 Setting up the Java card platform............................................................... 694.2.2.2 APDU communication development, compilation, execution .................... 704.2.3 Java Card Remote Method Invocation development ............................................764.3 Difficulties faced, Efforts made and Way forward................................................. 824.3.1 Difficulties faced......................................................................................................824.3.1.1 Mostly vendor-specific development kit and tools......................................834.3.1.2 Lack of extensive documentation ................................................................ 844.3.1.3 Deficiency in collaboration and networking ............................................... 844.3.1.4 Complexity in the technology – not purely object-oriented........................ 844.3.2 Efforts made............................................................................................................854.3.3 The way forward.....................................................................................................855. Conclusion..................................................................................................................... 866. References and Bibliography........................................................................................ 88
  • 7. 8Table of Figures _ Using Smart Cards in Grid ComputingTable of FiguresFig. 2.1: Grid security model .............................................................................................. 9Fig. 2.1.1: Symmetric encryption...................................................................................... 10Fig. 2.1.1.1: DES algorithm............................................................................................... 11Fig. 2.1.2: Asymmetric encryption.................................................................................... 12Fig. 2.1.5a: Grid security management system ................................................................ 16Fig. 2.1.5b: Single Sign-on in grid..................................................................................... 17Fig. 2.2.3.1: Certificate based authentication...................................................................20Fig. 2.2.3.2: Kerberos authentication system ...................................................................21Fig. 2.3.2: MyProxy system view ...................................................................................... 26Fig. 2.4.1a: Physical parts of the smart card....................................................................28Fig. 2.4.1b: A typical smart card structure......................................................................30Fig. 2.4.2: The smart card file structure...........................................................................32Fig. 2.5.3: Physical view of the smart card authentication system..................................38Fig. 3.1.1: Smart card communication (Message passing)...............................................47Fig. 3.2.1a: Command APDU structure...........................................................................48Fig. 3.2.1b: Response APDU structure.............................................................................48Fig. 3.2.3a: The directory structure of the java card development tool.......................... 53Fig. 3.2.3b: The Java card development process.............................................................. 54Fig. 3.2.3c: The JCRMI framework ................................................................................. 55Fig. 3.2.3d: State diagrams of smart card (java card) and its reader ............................. 56Fig. 4.1.2: Architecture of Credential storage and Authentication system of Grid........ 60Fig. 4.1.3.2: Grid portal – Presentation Tier....................................................................61Fig. 4.1.4.1: Activity diagram of the grid interfacing application ...................................64Fig. 4.1.4.2: Activity diagram of the card client application............................................ 65Fig. 4.2: Activity diagram of Authentication of Grid user............................................... 66Fig. 4.2.1a: Class diagram of smart card client standalone class....................................68Fig. 4.2.1b: UML diagram of the java card application .................................................. 69Fig 4.2.2.2a: Printscreen image of applet compilation error. ..........................................71Fig 4.2.2.2b: Printscreen image of file conversion steps. ................................................. 74Fig 4.2.2.2c: Create Applet command structure explained. ............................................ 75Fig 4.2.2.2d: Create applet command structure for the rmi applet. ............................... 81
  • 8. 9List of Tables _ Using Smart Cards in Grid ComputingList of tablesTable 2.6: Table of Comparison among different Credential repositories.................... 42Table 2.6(Contd.): Table of Comparison among different Credential repositories......43Table 3.2.1a: Valid CLA values for APDU (ISO 7816 specified)...................................49Table 3.2.1b: Valid INS values for APDU (ISO 7816 specified)....................................50Table 3.2.1c: Status Codes of the Response APDU ........................................................ 50}
  • 9. 10List of Abbreviations Using Smart Cards in Grid ComputingList of AbbreviationsADMAESALWAPDUAPDUIOAPIASATRCACADCAPCBCCHV1CHV2CLACLICPUDBMSDESDFDSAECCEEPROMEFEMVEPROMG3SGGFGSI-----------------------------AdministrativeAdvanced Encryption StandardAlwaysApplication Protocol Data UnitAPDU input/outputApplication Programming InterfaceAuthentication ServerAnswer-to resetCertificate AuthorityCard Acceptance DeviceConverted AppletCipher Block ChainingCard holder verification 1Card holder verification 2Class of InstructionComand Line InterfaceCentral Processing UnitDatabase Management systemsData Encryption StandardDedicated FileDigital Signature AlgorithmElliptic Curve CryptosystemElectrically Erasable Programmable Read Only MemoryElementary FileEuropay MasterCard VISAErasable Programmable Read Only MemoryGrid Security Services SimulatorGlobal Grid ForumGrid Security Infrastructure
  • 10. 11List of Abbreviations Using Smart Cards in Grid ComputingGSMGUIICICCIDEIECIETFINSISOJCDKJCREJCRMIJCVMJTC1KCAKDCMFNEVPKIPROMRAMRFCROMRSASATSASIMTCGTDESTGSTGTTLSTPM--------------------------------Global System for Mobile communicationGraphical User InterfaceIntegrated CircuitIntegrated Circuit(s) CardIntegrated Development EnvironmentInternational Electronic CommitteeInternet Engineering Work ForceInstruction SetInternational Standards OrganizationJava Card Development KitJava Card Runtime EnvironmentJava Card Remote Method InvocationJava Card Virtual MachineJoint Technical Committee 1Kerberized Certificate AuthorityKey Distribution CentreMaster FileNeverPublic Key InfrastructureProgrammable Read Only MemoryRandom Access MemoryRequest For CommentsRead Only MemoryRivest Shamir AdlemanSecurity and Trust Services APISubscriber Identification ModuleTrusted Computing GroupTriple Data Encryption StandardTicket Granting ServerTicket Granting TicketTransport Layer SecurityTrusted Platform Module
  • 11. xiiList of Abbreviations Using Smart Cards in Grid ComputingUIVCManVO---User InterfaceVirtualized Credential ManagerVirtual Organization
  • 12. 1Chapter 1 – Introduction and Background _1. Introduction and Background1.1 What is it all aboutThe scope of this research project aims to explore the possibilities of the usage of smartcard security, its standards and its principles, in Grid Computing. This project is a novelendeavour to study the application of Smart Cards, its security framework and incorporatethem in the emerging Grid computing field [1]. This field of computing, that is, GridComputing, is growing rapidly in the last few years, and is taking the world of technologyby storm. Grid Computing is not a new invention, rather an innovation – usage of differenttechnologies in a very useful way. It is one of the most important innovations among thepresent day technological innovations going on.Like the Internet, hopefully, it would spread soon and dominate theworld. Grid Computing, is, basically, a sharing of resources. It comprises of a wide rangeof hardware and software, and this wide variety and range of hardware and softwarewould go on increasing, in days to come, starting with Desktops, Laptops, Servers, PDAs,mobile phones, etc. Grid computing, can be seen as a way of exploiting or rather usingunder-utilized computing resources. So, applications requiring large computations can berun on a wide network of computing resources, which are idle. Grid computing was beingused and still being used for computation for, among others, the Human Genome Project,AIDS research, encryption challenging, molecular structure determination, pharmaceuticaldrug design, stock market prediction, multimedia content distribution, climate modellingfor weather forecasts, remote Health Services, and even in the present Banking andFinance world etc. With the passing of time, grid computing has ventured into other areasof computing, as well as, has welcomed the use of various technologies within itself. Thus,has emerged, the use of Smart Cards in grids.This research project was inspired by numerous fresh and very recentwork and developments and projects taking place all over the world. This includes and isnot confined to, “The Mobile Java Card Grid” project [2] [3] in LaBRI, LaboratoireBordelais de Recherche en Informatique, Université Bordeaux 1, France, and, the recentdevelopment of the concept of Trusted Platform Module (TPM) [4] by the Trusted
  • 13. 2Chapter 1 – Introduction and Background _Computing Group (TCG) [TCG [5] is a non-profit organization established in 2003 byAMD, Hewlett-Packard, IBM, Intel, and Microsoft and also having as promoters SunMicrosystems, Lenovo and Infineon Technologies], and, the works by NTT DoCoMo [6],the famous telecommunications company in Japan, launching mobile phones embeddedwith contactless smart cards - the mobile phones being used to make credit card purchases.A grid network of different resources, like desktops, laptops, servers,mobile phones, PDAs etc. and being geographically dispersed gives rise to a number ofvery, very important issues. Grid Management is such a subject which deals with theadministration of the Grid, looking after its security, the principles followed, the wayresources are assigned for an application to run on them, management of data etc. – insummary, a huge range of issues.This project deals with one such issue or factor – Grid security. Gridsecurity management is a very important factor in the proper operation of a grid. Theproject aims to use smart cards to improvise the present Grid security.1.1.1 Grid ComputingGrid computing involves and requires technologies that provide supportfor execution of programs on variety of platforms, secure infrastructure, data managementincluding secure data movement/replication etc., resource management including resourcediscovery and utilization. Grid computing has evolved over the last decades and is nowmore than a technology to be used only for high performance computing. It can be safelyconsidered as a mature instance of the Service-oriented architecture. The grid environmentdeals with a term or concept called the Virtual Organization (VO). The concept of Virtualorganization involves dynamic bodies of organizations, or individuals who are in aposition to set rules and define policies for resource sharing on grid [7]. They also takepart in grid management. Thus, the grid spans over networks of multiple organizations andcontains a number of administrative domains within it. Each of them will have its own setof rules and business requirements and policies. The grid management has to deal withinter-domain relationship, transactions, and of course, security. The security infrastructureof the grid, or grid infrastructure security maintains inter-operability among variousdomains and transparency and clear separation of the security mechanisms and policies
  • 14. 3Chapter 1 – Introduction and Background _enforced by both real and virtual organizations. The basic security requirements of thegrid infrastructure include authentication, authorization and confidential communicationamong grid resources. The grid user requires authentication to log into the grid and use theresources, according to the right or authorization level the grid user has. Thecommunication among the different grid resources and the data exchanged is secured bydifferent encryption systems. The grid infrastructure security is based or built upondifferent security principles and policies. One among them is the PKI or Public KeyInfrastructure. It involves keys, public or private keys and digital certificates, all of themare also known as credentials. It is to be noted that, the security of any system depends onencryption algorithms, among many other factors. It is also to be noted that, other than thequality of encryption algorithms, any security system also depends on the credentialmanagement.The Credential management system has the Credential repository issuesand credential federation systems within it. In the present day, the credentials or simplyput, keys, certificates etc. are being stored on dedicated machines. The bottom line of thisresearch project is thus to examine a way to improve the Credential management systemof Grid computing and in effect move the responsibilities of credential storage towards abetter hardware and software platform. Storing of X.509 PKI credentials (which is beingused by Grid security) [8] like, public and private keys, digital certificates and/or proxycertificates etc., in the smart card would highly affect the way Grid security is now today.1.1.2 Smart cardsA Smart Card, chip card [9], or Integrated Circuit(s) Card (ICC), is basically embeddedintegrated circuits – a silicon chip, and which comes in two varieties. They are Memorycards and Microprocessor cards. Memory cards have non-volatile memory storagecomponents, and optionally, some specific security logic. Microprocessor cards containmemory and microprocessor components, having both data and security application. Theinterfaces provided by the Smart cards are categorized in two – Contact cards andContactless Cards. Contact Cards are inserted into a Card reader, or, put in some form ofcontact with the Card reader. The reader, coming in contact with the electrical connectorsof the chip, is able to pass data in and out of the chip. Contactless cards are just kept in
  • 15. 4Chapter 1 – Introduction and Background _proximity or passed in front of the card reader. The chip having an in-built antennacommunicates with the card reader through RFID induction technology. However, a thirdcategory is also in vogue, which has, dual interfaces, both contact and contactless. Mostsmart cards have proprietary operating systems.In the wireless scenario, smart cards provide improved network securitythrough user identification, stores user data, and provide a mechanism for recordingvarious service data events. These capabilities lead to improved service customization andportability in a secure environment. This is especially suitable for various transactionbased services. There have been many improvements so far and there are ongoing andever-increasing improvements in smart card technology. Currently, a smart card is one ofthe major hardware components that provide the highest security level. This highest levelof rich security features can be exploited to the utmost to improve grid computing security[10]. To have a better understanding of the usefulness of smart cards in grids, first of all,we need to understand both the technologies better (as would be explained in the nextchapters).3. Java cardsNow, the time has come to extend our discussion to the realm of Java Cardtechnology, the almost ubiquitous platform for smart cards. Sun Microsystems‟ Java Cardtechnology has been licensed to 90% of the smart card manufacturing companies. Thistechnology enables the card to be loaded with multiple applications, even frommultiple vendors. Most of the prevalent smart cards benefit from and use the Java Cardtechnology.This includes the cards used for,1. financial transactions, like bankcards.2. cards used for mass transit like the Oyster card (a contactless smart card), used inLondon transport systems, by passengers.3. identity cards and cards used for security access [11].4. SIM cards, cards used in mobiles and on most wireless networks.Java card is basically a subset of the core java technology. However, depending on thecard manufacturer, there are wrappers for the Java card APIs, implemented by theindividual card manufacturers for their cards and owned exclusively by them. These
  • 16. 5Chapter 1 – Introduction and Background _wrapper classes and APIs make life easier for the software developers of the respectivecard manufacturing companies to implement new functionalities and modify the existingones for the cards.Java Card Platform, Version 2.2.2 [12], developed by SunMicrosystems, is a binary development toolkit which includes a software bundle thatincludes the binaries, the Java card APIs, the relevant documentation, and a simulator forthe java card/smart card. However, this simulator is not a full-blown simulator and is verybasic in nature, with certain flaws of its own. This package lacks a standard debugger andis not GUI (Graphical User Interface) based and is a much minimized development kitcompared to the standard kits for all other platforms, whether it be Microsoft VisualStudio or Sun Microsystems‟ core Java platform or any other. This is, thus, a majorhindrance for software developers accustomed to development in a common, standard IDE(Integrated Development Environment), and GUI, with all supporting tools for softwaredevelopment, including a debugger, stack tracer etc. The simulator/emulator whichemulates the smart card, has command line functionalities and is again very basic, withvery limited features and no user interface. On the java card platform, multipleapplications from different vendors can co-exist securely. Here, the platform used is theJava Card Platform, Version 2.2.2, by Sun Microsystems. In this report, hence forth theterms „smart card‟ and „java card‟ will be used synonymously.1.2 Overview of the scope and challengesThe merging of different technologies in Grid Computing has been making it better andbetter and also is indirectly being conducive to its widespread growth. The concept of theuse of smart cards in Grid Computing to boost its security maybe, is a very small step inthis present age of emerging technologies and advanced computing, but, it is definitely astep towards the future. It is one of the highly innovative thoughts of today.This research project is a project involving highly ambitious thinking –the concept of merging two huge technologies together. This requires lot of future work. Itpromises to be a field of lot of further scientific research and huge financial investments.It definitely has potential for huge growth. However, there are scopes of huge fallback too,
  • 17. 6Chapter 1 – Introduction and Background _in this type of project, since there are lot of uncertainties in this field and everyone is sounsure about everything regarding this.However, this field of research tends to be a “high risk, high gain” field.There is a high possibility of the development of TCP/IP Smart Cards, in the next 2 years,which would help in discarding the need for Card readers, and thus greatly boosting its usein Grid Computing. This is one of the factors/uncertainties which would decide the fate ofsmart cards in Grid Computing.There are areas of major weaknesses here. One important problem ofJava card technology is that the tools for simulation or emulation of smart cards or Javacards are very vendor-specific, which highly narrows downs its scope. For example, in avery simple case, the tools provided by Sun Microsystems uses shell script file for Solarisand Linux platforms and batch files for Windows. So, any program with an intention torun any of these tools has to check the type of OS first. Also, there is an immense lack offreeware tools and utilities in the smart card sector. There is lack of standardsimulators/emulators, in the freeware market and the ones that are available are vendor-specific. So, a CAP (Converted Applet) file, for a Java card (Smart card) might be verifiedby one tool with no errors, and will show errors, while being verified by a tool of adifferent vendor. Smart Card standards are yet to evolve fully and almost the entire smartcard field is dominated by industry leaders and thus smart card research and developmentis highly vendor-specific. This is a very important obstacle to projects of such nature.causing lot of inconvenience and time wasters for independent researchers and developers,to make some meaningful contribution to this field.There are commercial Java Card development kits, for instance Odysseylab from Bull, Cyber ex from Schlumberger, GemXpresso RAD from Gemplus,Sm@rtCaf e Professional from Gieseke & Devrient, GalatIC from Oberthur Card Systems.These kits contain a card reader, cards, and software tools (a converter, a loader, a tool totest applets on the card, and some times a simulator). The programming environmentwhich provides the best coding support for smart cards, is GemXpresso. It offers a wizardto help developers in creating Java Card applications which takes care of low-level issuessuch as handling APDUs. For testing and debugging, Sm@rtCafe, currently, being theonly environment offering a Java Card specific simulator-debugger, has the edge. An idealJava Card special simulator-debugger should be able to give information about the stack
  • 18. 7Chapter 1 – Introduction and Background _and the storage, to handle atomic operations when card withdrawals or power failures aresimulated and to inspect the JCRE contents.However, here, sophisticated card-specific simulators, emulators andcard development tools have not been used. Here, as mentioned before in the previoussection, the platform used is Java Card Platform, Version 2.2.2, by Sun Microsystems.However, whatever be the problems and obstacles, Grid computing andSmart cards are here to stay and evolve over time to better and efficient technologies andbe more useful to the variety of application usages they are serving now.
  • 19. 8Chapter 2 – Preliminary System Design _2. Preliminary System DesignThe system design aims to improve the grid security system by improvising the gridcredential management system and also implement a better authentication for the grid useror resource. In a nutshell, the purpose is to use smart cards as a safe and secure repositoryof important grid credentials, like private keys, of a public-private key pair, digitalcertificates etc. and also act as a system of authentication, by which grid users can provetheir identity and get access to the grid and its resources. Analysis of different facts of gridhas led to the proposed method of security implementation. The following sections wouldbe helpful in understanding the facts.1. Grid computing securityAs the grid expands and more and more hardware and software joins it, security becomesa headache. The basic points of Grid Security can be summarized as;1. Authentication.2. Authorization.3. Confidentiality of communication, data, and resources.There are other issues of grid security, worth considering too, such as, infrastructure isrequired to comply with local domain level security policies and VO defined policies. Thegrid security infrastructure (GSI) requires clear separation of security policies as well asmaintains interoperability among them. In a summary, there needs to be Interoperability,Integration and Trust relationship. As per the IBM RedBooks paper (2005) [7], thesecurity challenges and requirements in the grid infrastructure can be summarized in thefollowing points, Authentication, Authorization, Privacy, Confidentiality, Secure LoginDelegation, Single logon, Credential life span and renewal, Message Integrity, PolicyExchange, Assurance, Manageability, Firewall Traversal, Securing the OGSAInfrastructure. The security fundamentals incorporate three main features, Authentication,Authorization and Encryption. A grid resource or a grid user needs to be authenticatedbefore it is allowed access in the grid. The sharing and access policies need to be checked,so that, proper level of access is granted to the user/resource. The next step involvesproper encryption of the data/software/resource etc., so that it is not hacked into, or, any
  • 20. Chapter 2 – Preliminary System Design _damage done. If we divide the security concerns into two broad categories, then, the gridresource needs to be protected from an erring application, and the executing applicationneeds to be protected from the grid resource or other erring applications on that particularresource or elsewhere in the grid. The above two broad categorization of security concernscan be explained as, say, an erring application can easily utilize hardware errors in aparticular grid resource and can corrode it – for example put virus into the system, corruptthe OS or other applications in the hardware and do all sorts of other malicious operations.Any application can try to be a Trojan Horse. On the other hand, in the grid resource onwhich a particular application is run to do some huge computations, anybody can dumpthe memory where it has been loaded to work out what it is doing, or even trace theinstructions executed by the processor. Some malicious applications can corrupt the dataof this application and pose some other security concerns. We can have the high level gridsecurity model in the figure, as follows, Fig. 2.1., which covers the fields likeauthentication, authorization and confidentiality. We are going to concentrate soon on thekey/credential management part of the grid security model (as shown circled in the figurebelow).Fig. 2.1: Grid security model9
  • 21. Chapter 2 – Preliminary System Design _One of the important things that Grid security infrastructure uses is thePKI model. As a note, I would like to mention that the Globus Toolkit, which is a verypopular open source software toolkit for building grid applications and systems, uses thegrid security infrastructure. PKI is based on a private-public key pair and is also known asAsymmetric cryptography. Before we talk further about keys and certificates andcertificate authority (CA) and their handling, let us first understand some of theseimportant security terms and concepts.1. Symmetric EncryptionSymmetric encryption involves encryption of any message or data with only common key.The key is secret but is shared. The data is encrypted and decrypted by the same key, andis sent to the other party who decrypts the message. The communication should be secureonce again; otherwise if the key becomes accessible to any third party, the data can bedecrypted. Symmetric encryption is efficient in terms of performance; it is faster than theasymmetric encryption. The common algorithms used are DES (Data EncryptionStandard), AES (Advanced Encryption Standard), Triple-DES etc. The java cardtechnology for smart cards has support for the symmetric encryption algorithms, AES andDES.The key sizes of TDES are,1. 112 bit key and 16 parity bits2. 168 bit key and 24 parity bits.Fig. 2.1.1: Symmetric encryption10
  • 22. Chapter 2 – Preliminary System Design _2.1.1.1 DES cryptosystemDES, after many levels of transpositon and substitution encrypts 64-bit data blocks, using56-bit encryption key. The size of the key is 56 bits plus 8 parity bits. It is a very oldalgorithm, created by Horst Feistel. In this algorithm, 64 bits of data blocks each, plaintext,are encrypted for 16 rounds or iterations, to produce the ciphertext. Before the iterations,the block is divided into 32-bit halves and processed alternately. By an algorithm knownas key schedule, the sixteen 48-bit subkeys are derived from the main key and one key isused in one iteration. The figure below, shows the 16 interation steps on the left and thedetails of an iteration on the right. Within each iteration, there are 4 steps, Expansion, KeyMixing, Substituion and Permutation.Fig. 2.1.1.1: DES algorithm2.1.1.2 AES cryptosystemAES is commonly also known as Rijndael in the cryptography field. It uses cryptographickeys of 128, 192, and 256 bits to encrypt and decrypt data in blocks of 128 bits. It is asymmetric block cipher and is much faster than Triple-DES.11
  • 23. Chapter 2 – Preliminary System Design _2.1.2 Asymmetric EncryptionIn this form of cryptographic procedure or encryption, a set of keys are generated unlike inSymmetric encryption. The basis of this is, the key that is used for encryption is differentfrom that used for decryption. Normally the public key is in the digital certificate issuedby the Certificate authority. The private key of the owner is very important and should bekept secure. Any message to be encrypted is encrypted with one key and decrypted withthe other key of the key pair. The same key cannot be used to encrypt or decrypt the data.A message encrypted with the public key can be decrypted by the private key and vice-versa. Also, generally for secure communication, a message is often encrypted by thesender‟s private key first and then encrypted again with the receiver‟s public key. Then thereceiver on receiving the doubly encrypted message, decrypts it with its own private keyfirst and then by the sender‟s public key. The asymmetric encryption algorithmscommonly used are, the RSA (Rivest, Shamir, Adleman), DSA, ECC, Rabin, ElGamal,etc.Most common is the RSA algorithm. The java card technology for smart cards hassupport for the encryption algorithms like, DSA, RSA and ECC.Fig. 2.1.2: Asymmetric encryption12
  • 24. 13Chapter 2 – Preliminary System Design _2.1.2.1 RSA algorithmThe asymmetric encryption method based on the RSA algorithm is based on generation ofkey pairs from the product of very large prime numbers.For example, the RSA algorithm roughly follows the steps mentioned below,1. Get two prime numbers, a, and b.2. Their product, c = a x b.3. Compute, f(c) = (a – 1) x (b -1).4. Select e to be coprime to f(c) and be less than c (<c).5. Determine h such that, h x e = 1 mod f(c).6. The key pairs are {e, c} and {h, c}.7. For encoding message, P, A = Pemod c.8. For decoding message, Ahmod c = P.The typical length of the RSA key is 1024 bits. Due to its complexity, using this form ofencryption, we have to compromise with the performance. To alleviate the problem, oftena message is encrypted with the symmetric encryption algorithm key and then the key isagain encrypted with the public key pair.2. DSA cryptosystemDSA (Digital Signature algorithm) was proposed by the National Institute of Standardsand Technology in August 19991. Here, the private key operates on the message hashgenerated by SHA-1, to verify a signature, one recomputes the hash of the message, usesthe public key to decrypt the signature and then compare the results. The size of the keyvaries from 51 to 1024 bits.3. Elliptic Curve cryptosystemOther than the two renowned algorithms for public key cryptography, RSA and DSA,there is another algorithm, useful for digital signatures and key exchanges, and used in thesmart card field. This is the ECC (Elliptic Curve Cryptosystem), and is supported by javacard technology. It is based on elliptic curves, which are defined by the followingequation, Y2= x3+ ax + b . This is in a finite three-dimensional space and no point ispermitted to be singularity. For this cryptographic system, the finite spaces are used, the
  • 25. 14Chapter 2 – Preliminary System Design _finite spaces are, GF(p), GF(2n), GF(pn), where p is a prime number and n is a positiveinteger greater than 1. This cryptographic algorithm uses very low computing powercompared to RSA and DSA. The key sizes are also comparatively much smaller. The ECCalgorithm keys of sizes 126, 256, and 320-bits correspond to keys of sizes 1024, 2048 and5120 bits respectively, of the RSA algorithm. So, it would be very useful to use this systemin smart cards as they require much less processing power.3. Certificate AuthorityThe CA is responsible for issuing digital certificates to the requesting entities. However,before a Certificate Authority issues a certificate to the requesting entity, it has to performsome important work related to itself, which actually proves its own identity. They are:-1. It creates or generates its own private-public key pair.2. It creates its own digital certificate.3. Its signs its own digital certificate by its private key.4. It stores its private key securely.All grid resources need a digital certificate which proves its identity. So, a grid resourcesends its request to the CA. It sends its own unsigned digital certificate to the CA, forsignature by the CA, which would prove the grid resources‟ identity. The CA verifies bydifferent means, the genuineness of the grid resource and then signs the receivedcertificate with its private key and sends it back to the resource. Thus, the CA‟s privatekey is of utmost importance in the grid security infrastructure. Anyone who can get accessto the CA‟s private key can impersonate the CA and thus might achieve control over thegrid by signing the digital certificates of unwanted or criminal resources and prove themas authentic entities of the grid. The private key of the CA is usually stored in dedicatedservers in locked rooms. Also, the CAs of different sub-domains and VOs again have totrust each other.
  • 26. 15Chapter 2 – Preliminary System Design _2.1.4. Digital certificatesDigital certificates are, in essence, data structures containing the public key of anasymmetric key pair and other details of the owner. They can associate a grid resourcewith its public key. The Certificate Authority certifies that the enclosed public key belongsto the owner listed in the certificate. A digital certificate is created by its owner, say, a gridresource, and then sent to the CA for signing. So, CA certified digital certificate provesthe identity of the owner, in this case, the grid resource. The digital certificates are alsoknown as X.509 certificates, where X.509 is a standard defined for Public KeyInfrastructure and Privilege Management Infrastructure (PMI). The digital certificatecontains the owner‟s public key and since it is signed by the CA, it proves that the publickey in the certificate belongs to that respective owner. Thus, when a communication isbeing established between two grid resources or entities, the recipient gets the certificatefrom the sender, checks it to see whether it has been signed by a trusted CA, and if it isokay, then initiates communication. The recipient use the public key in the certificate(which is the sender‟s public key) to decrypt the messages encrypted by the sender with itsprivate key. The digital certificate is in essence, an Identity credential for the grid resourceor grid user. There are two types of certificates; one is for the user, to identify oneself inthe grid. This identifies the username in the grid. The other is for the server, whichregisters the fully qualified domain name of the server.
  • 27. Chapter 2 – Preliminary System Design _2.1.5 Grid Security Management and InfrastructureGrid security management can be roughly divided into three main categories, management,architecture and infrastructure, in Fig. 2.1.5a [7].Fig. 2.1.5a: Grid security management systemArchitecture management deals with the entire grid system architecture and involves andis not limited to user and resource authorization, security of information, and the entireservices which the grid offers. The infrastructure management system deals with and isnot limited to the network structure, the host, the resources and their underlying networkissues. The Management issues can be further classified into Credential managementsystems, Trust management systems, and Monitoring systems. Also, an important point tonote is that, all of these issues are often overlapped and inter-dependent.The standardization of grid security design and principles, has led to thedevelopment of the GSI. The standardization efforts were mostly by the Global GridForum (GGF), which is a community behind these standardization efforts. However, now,the GG has merged with the Enterprise Grid Alliance and formed the Open Grid Forum.The grid security infrastructure covers the following requirements for the security.1. Authentication2. Authorization.3. Confidentiality.4. Integrity.5. Single Sign on.6. Delegation.16
  • 28. Chapter 2 – Preliminary System Design _A grid consists of heterogeneous systems and domains and organizations includinguniversities, research institutes, commercial organizations etc. These different types oforganizations often come together and form a group and follow a defined set of rules andpolicies. This is known as virtual organizations. It has already been explained before. Agrid user trying to access resources under different security domains, then they wouldneed a single sign-on or single log-in. We can visualize the system when a grid user triesto access the grid in such a scenario (Fig.2.1.5b), as per Chakrabarti [8].1. Authentication – There are different authenticating mechanisms for the grid users toget access to the grid. The main ones are described in a later section.2. Authorization – defines the level of access for the grid user.3. Confidentiality – This requirement applies to the confidentiality of data and messagessent over the grid, that is secure communication.Fig. 2.1.5b: Single Sign-on in grid4. Integrity – This applies to message integrity, any changes made to the messages ordocuments can be identified by receiver.5. Single sign on – When a grid user needs to have access through different securitydomains.6. Delegation - Sometimes, there are needs of delegating authority to a different entity,and the generation of proxy credentials is required. This is delegation.17
  • 29. 18Chapter 2 – Preliminary System Design _2.2 Authentication mechanisms.There are different authentication schemes for grid users and resources in the grid. Theyhave different levels of security and performance. The most common mechanisms [8] usedare the Shared secret based authentication, public key based authentication (or, the PKI),and the Third Party authentication (also based on PKI).2.2.1 Shared secret based authenticationHere, the system is based on sharing some secret data like the password. The administratoror the system responsible for authentication, the authenticator, asks for the password fromthe grid user. Generally, the hash of the password, stored in some server is used forchecking the password supplied by the user. This has can be retrieved by hacking into theserver. Also, the password is vulnerable to attacks like sniffing and others. The passwordcan be easily retrieved when it passes through the network. There is another way of usingshared secret mechanism, by the challenge method, where the authenticator challenges theuser by asking to encrypt a message by a shared secret key. The shared secret key ischanged often for security purposes. This mechanism is often used along with othermechanisms. The shared key is again stored in the client machine or a grid host machine,which is again vulnerable.2.2.2 Public key based authenticationThis is, as the name suggests, is a PKI-based mechanism. The grid user, who needs to beauthenticated to log-in the grid, sends a message encrypted with his private key. Theauthenticator, who has the grid user‟s public key, would decrypt the message with thepublic key and thus, the authenticity of the grid user is proved. This is very secure methodof authentication, but has problems while being adopted on a large scale. There arescalability issues involved. This is eased when the grid user uses a smart card where theuser‟s keys are stored. Thus the smart card, on this account acts as a very secure storage
  • 30. 19Chapter 2 – Preliminary System Design _for the keys (or, credentials, as they are known in a much formal way), plus, they providemobility for the grid user and solves lot of scalability and usability issues.2.2.3 Third party authenticationThis mechanism is based on authentication by a third party, for example, the KeyDistribution Centre (KDC) of Kerberos. Another very popular example of third partauthentication is the Certificate based authentication. It is used in Grid Securityinfrastructure, or GSI, based grids, such as, in the Globus toolkit. The grid user has adigital certificate, signed by a trusted certificate authority. The authenticator knows thisCA and its public key, and hence, the grid user‟s credibility is proved and gets access tothe grid.2.2.3.1 Certificate based authenticationThe trusted third party in this case is the certificate authority. Among other information,the GSI certificate, signed by the CA, has the following important information:1. The name of the owner of the certificate, in this case, the grid user or resource.2. The owner‟s public key.3. The CA‟s public key.4. The digital signature of the CA.The steps followed in the authentication process, are,1. The grid host obtains the public key of the CA, to later verify the signed certificate bythe CA.2. The grid host then generates its own key pair – a public-private key pair and thencreates a certificate request and sends it to the CA.3. The CA verifies the information of the owner and then signs it and sends the certificateto the grid user on the grid host machine.4. Now, the certificate and keys are stored on secure places in the grid host machine, or,maybe some other machine.
  • 31. Chapter 2 – Preliminary System Design _Fig. 2.2.3.1: Certificate based authenticationSo, the grid host machine now has the following important credentials stored in it.1. The grid user‟s private key.2. The CA‟s public key.3. The grid user‟s digital certificate, signed by the CA (this contains the user‟s public keytoo).The keys and certificates can also be stored in the online credential repository system,MyProxy [14]. When stored in host machine or the like, generally, some extra layer ofsecurity are added to keep the user‟s private key and certificate safe, by using passwords.Also, the grid host‟s private key is protected by the local operating system privilegeswithin the grid server. However, this system has a weak point in that, the grid hostmachine or the grid server would be exposed to hacking and other attacks.2.2.3.2 KerberosKerberos is a very common network authentication protocol, which is based on the sharedsecret key authentication mechanism and follows a client-server model. The protocol isbased on the Needham-Schroeder protocol, provides mutual authentication and requires atrusted third party. So, it is also a variation of the third party authentication scheme. It usesa KDC (this is the trusted third party), and it runs on a secure node in the network. It hastwo parts, the Ticket Granting Server (TGS) and an Authentication server (AS).20
  • 32. Chapter 2 – Preliminary System Design _1. The client logs in the AS and request for access to the TGS. The client generally entersa username and password on the client machine, and a hash is performed on thepassword, and it becomes the client‟s secret key. The request sent by the client to theAS is simply a clear text message.2. The AS checks for the client details on its database and then sends the client, the TGSsession key encrypted with the client‟s secret key (shared with the AS), and the TGSticket encrypted with the TGS‟ public key.3. The client decrypts the TGS session key with its shared secret key and then startscommunication with the TGS.The main and single point of failure in the Kerberos system of authentication in grid is thecentral server, where all the secret keys are stored. Kerberos requires continuousavailability of the server, so, a power shutdown means nobody can log in. This can bemitigated by multiple servers, but the problem of the servers being hacked still remains.Fig. 2.2.3.2: Kerberos authentication system21
  • 33. 22Chapter 2 – Preliminary System Design _3. Credential management systemsWhat is a credential? According to the dictionary, it is the proof of ability ortrustworthiness of an individual or an attestation of qualification, competence, or authorityof an individual or identity. So, as per the definitions, the public and private keys and thedigital certificates signed by the CA, all fall under the term „credential‟. The schemes ofproper storage and handling of important credentials like, the private keys, the digitalcertificates etc. gives rise to the Credential management systems. Grid securitymanagement systems, as mentioned before (please refer to Fig.1.1.1), has credentialmanagement system in one of its sub-division level. Credential management system is avery important part of the grid security infrastructure. The main functionalities of theCredential Management System of the grid are initiation, renew, secure and safe storage,translation, delegation and control. The credentials maybe classified as,1. Identity credentials.2. Authentication Credentials.3. Authorization Credentials.Credential management systems can generally be divided in two heads,Credential repository or, in plain language, storage systems, and Credential federationsystems or credential sharing systems.The different credentials mentioned here, can be comprehended whenexplained with the help of an analogy. Let us consider the case of a person (a student,perhaps), who wants to enter the United Kingdom. He/she requires a Passport to provehis/her identity first. The student and the student‟s passport is a perfect analogy to a gridresource user and its Identity credential. The student now applies for visa to gain entry tothe United Kingdom. At the British embassy, the visa is stamped on the student‟s passport.The student now has legal permission to enter the United Kingdom with a valid passportand a valid visa. The British student visa is thus, an analogy to Authentication credential.An authentication credential is of lesser longevity and system specific with local/temporalpolicies attached to them, like a visa is of shorter duration and country specific. A visa isgranted, if and only if, you have a valid passport. Similarly, the authentication credential isgranted only after the identity credential is checked. The Authorization credential isauthorization to use a particular resource and have a certain level of rights on it and
  • 34. 23Chapter 2 – Preliminary System Design _similar issues. An analogy to this is the authorization to work for 20 hours term-time, inthe United Kingdom, after you get British student visa, or the right to buy a flight ticketfrom the student‟s home country, once the student has the valid passport and the valid visa.So, often, you get the authorization credential after you get the first two, that is, theidentity credential and the authentication credential.It is to be noted here, that the identity credential is issued by a third party,which is trusted. For example, in the analogy mentioned above, the passport is theauthentication credential, which is issued by the respective government. Here thegovernment of that country is a third party and trusted. Similarly, in the grid computingscenario, the CA is a trusted third party. A brief look into the different functionalities ofthe Credential management system shows „Initiation‟ as involvement of authentication ofuser and grant of the required credential to the user. „Secure storage‟ need not bementioned again. After the credentials expire, there is the need to „renew‟ them. This isone important functionality which is facilitated by the system. „Translation‟ of credentialsfrom one domain to the other is another functionality. Plus, there is „Delegation‟,„Revocation‟ etc.The Credential repository looks into the following matters:-1. Securely storing credentials.2. Generating new credentials on demand.3. Generating proxy credentials on users behalf for Delegation purposes.Proxy credentials are basically, „short-term credentials‟ or „temporarycredentials‟, like temporary private keys, temporary certificates, all signed by the user‟slong-time credential, stored unencrypted on local file system, to be used for days or hours.Currently, credentials are stored on dedicated machines, which are quite vulnerable. Inaddition, there is the use of online credential repository systems, like MyProxy. TheInternet Engineering Work Force (IETF) has a working group called the „Secure AvailableCredential‟ group, who raises concerns and looks after the issues pertaining to themanagement and secure usage of the credentials, explained before, in desktop/mobileenvironment. Certain RFCs (Request for Comments) has been published regarding thecredential management. This has three main requirements, according to Chakrabarti,Anirban (2007), in „Grid Computing Security‟ [8]:-1. Credential transmission.2. Credential storage.
  • 35. 24Chapter 2 – Preliminary System Design _3. Credential heterogeneity.The first point requires that all credentials are safely and securelytransmitted over the network and also, are authenticated in some way. The secondrequirement, as per Chakrabarti, Anirban (2007), in „Grid Computing Security‟ [8], statesthat, “The RFC mandates that the credentials should not be in the clear when stored. Thecredentials should be defined as an opaque data object that can be used by the networkdevice. Clients should be able to recover the credentials from the opaque objects. Thecredential format should provide a privacy and integrity protection.” The third pointcovers the heterogeneity issue. Since, grid computing has different systems and differentprotocols incorporated in it, it states the fact that, the different credential types like theX.509, PGP etc. must be supported and the use of varied cryptographic protocols must bepermitted and encouraged.The desired characteristics of credential management systems, accordingto Chakrabarti, Anirban (2007), in „Grid Computing Security‟ [8], can be summarized asfollows:-1. Initiation.2. Secure storage.3. Accessibility.4. Renewal.5. Translation.6. Delegation.7. Control.8. Revocation.The characteristics can be explained in brief as follows;1.Initiation - This process basically describe, the authentication of the usersbefore they are supplied with the required credentials. The credential management systemstakes care of the initial authentication procedure, which can involve the use of passwords,biometric authentication or an extra set of asymmetric encryption keys. This last set ofauthentication procedures would involve two layers of authentication.2.Secure storage - This is the credential repository system, one of the main parts ofthe credential management system, and the requirement is that it would provide the bestpossible security for storing the long term credentials, that is, the private keys only or both
  • 36. 25Chapter 2 – Preliminary System Design _the public and private keys of the long term key pairs, or, the digital certificates. Thisfeature can be improved highly by storing the credentials in smart cards kept with the user,or, in smart cards as part of an existing grid resource like, the desktop, laptop, any servermachine, mobile phone, PDA etc.3. Accessibilityby the user, when needed.4. Renewal- The secured credentials should be properly accessible- After the expiry date of the credentials, they must beproperly renewed, the storage area and access mechanisms and other environmentalfactors without being affected.5.Translation - If multiple domains are using similar credentials, thenthe credentials used in a particular domain needs to be translated properly to that ofanother domain, so that their usability is nor affected.6.Delegation - The delegation of rights and permissions must beproperly taken care of by the credential management system.7. Control8. Revocation--Audits and monitoring again must be properly handled.In case of user compromise, there must be arrangementsso that the credentials are revoked.The credential repository system of the credential management system requires a betterhardware and software system to provide „secure storage‟ at the highest level. Here, therobustness of smart cards comes into being. At the hardware level, the cards areappreciatively resistive to physical attacks. The smart cards are tamper-resistant cards [15].They are quite secure both at the hardware level as well as the software level [16]. In thehardware level, they are built such that, any external physical attack or attacks to getaccess to its data is resisted and the data in it (be it authentication data, keys or other data)is destroyed automatically. Before going into the use of smart cards as credentialrepository, let us check some of the common repositories. Generally, repositories can beclassified as “software-based” and “hardware-based”.2.3.1 File system repositoryThe most common credential repository is the general file system. Generally, and in mostcases, the private keys and the digital certificates are stored in the local computer‟s file
  • 37. Chapter 2 – Preliminary System Design _system. Mostly, the encryption here is password-protection. This computer again maybeconnected to the grid and act as the grid host or the grid server. Thus, the key files areopen to hacking of the machine from the network and other cases of attack. This is themajor weakness in the system.2.3.2 MyProxyMyProxy is a very popular online credential repository system and isbased on the client-server technology. At the initiation phase, the long term credentials arestored in the MyProxy repository. These credentials usually have a very wide range of lifeterm, from weeks to years. These credentials are kept in the repository, usually encryptedby passwords. When a grid user requires some credentials, usually, by starting themyproxy-init client program, it establishes a TCP connection to the server and initiates theTransport layer Security (TLS) handshake protocol. The server and client authenticateseach other with their own set of credentials and then the server would provide the proxycredentials of the user, which has been derived from the long-term credentials of the user.Fig. 2.3.2: MyProxy system viewThe original credentials never leave the repository, but every time, a userrequests a credential, MyProxy provides proxy credentials, which are short life-termcredentials. This allows Delegation possible in grid computing. The client (the grid user orany grid resource), sometimes delegate authority to another user or resource. Then the26
  • 38. 27Chapter 2 – Preliminary System Design _proxy credentials are obtained from MyProxy and passed to the other user or resource.The actual long-term credentials are stored in the MyProxy repository, encrypted with theuser password by TDES (Triple Data Encryption Standard) in CBC (Cipher BlockChaining) mode. The user can update the credentials in the repository. The user also canalso destroy or delete the credentials in the repository. The repository is basically,dedicated servers. The one weakness which this system has is the same as the previousone, that is, the machine on which the repository is mounted, will always be prone tomalicious attacks for possession of the credentials.Before we go to proposing our own system, we must take a peek intosome smart card details so that its usability is better understood and adapted in the gridsystem.3. KX.509The KX.509 is a protocol which defines the inter-operability between X.509 certificatesand the Kerberos protocol. This system allows the grid users to access any grid resource orany grid application that uses X.509 certificates, using the Kerberos system. The grid userlogs into the local system using password, obtains the Ticket granting ticket (TGT) fromthe Kerberos server. Once the TGT is obtained, the KX.509 protocol starts. The KX.509follows the processes in order:1. KX.509 generates the public/private key.2. The KX.509 gets the service ticket for the Kerberized Certificate Authority (KCA) andsends the public key.3. The KCA decrypts the service ticket and then the session key is used to send a short-term life certificate. This certificate is used to access the resources requiring the X.509certificate.
  • 39. Chapter 2 – Preliminary System Design _2.4 Smart CardsSmart cards are one of the greatest pieces of hardware available, in such a small size. It isto be noted that, the SIM card (of mobiles) are the oldest smart cards.2.4.1 Physical characteristicsThe card is basically an embedded Integrated circuit (IC), embedded in a plastic card. Thesize of the plastic card varies depending on the requirements [17], generally, a standardsize is that of a bank card, however, the SIM card (the oldest and the first smart card), ofmobiles phones is small. A well-defined industry standard exists for the smart cardtechnology – it is standardized by the Joint Technical Committee 1 (JTC1) of theInternational Standards Organization (ISO) and the International Electronic Committee(IEC). These organizations control the smart card standards. The series of internationalstandards, ISO/IEC 7816, covers all the features and factors of a smart card, which ispossible, for example, the physical features, physical contacts, electronic signals andtransmission protocols, commands, security architecture, application identifiers, andcommon data elements. The smart card, unlike normal computers, does not have astandard output interface, like a display, or a standard input interface like, a keyboard ormouse, or a standard USB port. All the interactions to and form the card is done throughthe card reader, to which the smart card is connected directly - inserted or swiped through,or connected indirectly by RFID. The ISO 7816/1, ISO 7816/2 defines the physicalcharacteristics of a smart card. According to Vicente, Ortega Jose [9], the card generallyconsists of the following physical parts, as shown, below in Fig. 2.4.1a.Fig. 2.4.1a: Physical parts of the smart card28
  • 40. 29Chapter 2 – Preliminary System Design _The universally used plastic card has dimensions 85.6 mm x 53.98 mm x0.76 mm. This is the standard dimension, used in all bank cards, debit, credit cards, accesscards, ID cards etc. The cards come generally in two varieties, contact cards andcontactless cards. Contact Cards are inserted into a Card reader, or, put in some form ofcontact with the Card reader. The reader, coming in contact with the electrical connectorsof the chip, is able to pass data in and out of the chip. Contactless cards are just kept inproximity or passed in front of the card reader. The chip having an in-built antennacommunicates with the card reader through RFID induction technology. However, a thirdcategory is also in vogue, which has, dual interfaces, both contact and contactless. Thecontact cards can generally be identified by their gold connector plates. According to theISO 7816/2, the card ideally has 8 (eight) contacts, however, for all practical purposes,only 6 (six) contacts are used. The card generally consists of the CPU (central processingunit), the Security Logic (which has varied security functionality, like detecting abnormalconditions, like low voltage) the Serial I/O interface, the Test Logic (functionalities to testitself) and different types of memory. The different types of memory, present in a smartcard are:-1. RAM (Random Access Memory),2. ROM (Read Only Memory),3. PROM (Programmable Read Only Memory),4. EPROM (Erasable Programmable Read Only Memory),5. EEPROM (Electrically Erasable Programmable Read Only Memory).The most important memory, here, is the EEPROM. This memory isprogrammable and erasable by a user, and can be erased and used from 10, 000 to1,000,000 times, depending on the card type and vendor type. The EEPROM is non-volatile memory, that is, it retains its contents even after the power is removed.The RAM is of course, the example of volatile memory. The EEPROMis a very important part of the smart card. Since it is erasable and programmable, this partof the card actually hosts the smart card applets, which provides the differentfunctionalities of the smart card. The java card applets are stored here. The storagestructure of the EEPROM of a smart card follows a typical logical file structure, which isexplained in a later section. Another important part of the smart card is the CPU, basicallya micro-controller, or sometimes, a better processor. The card internal structure can be
  • 41. Chapter 2 – Preliminary System Design _viewed as under, according to Dr. Raúl V. Ramírez Velarde [24], and is shown below inFig. 2.4.1bFig. 2.4.1b: A typical smart card structureThe CPU is the logical brain behind the card, and the term “smart”started being used due to this logical centre or brain of the card. This part is responsiblefor many issues including the communication protocols, protection of memory againstattacks etc. There are also smart cards in the market having cryptographic co-processors,which provide support for the encryption algorithms like, RSA (used in PKI), and TDES.The Serial I/O interface gets connected to the card reader, for exchangeof data and commands. The serial transmission line here follows bi-directional method, orhalf-duplex mode of communication. This implies that, at any moment of time,communication is in one direction. Besides, the communication speed or the bit rate ismuch lower than normal. This low bit rate and the half-duplex mode of communicationhelps in preventing massive data attack on the card. The card follows two communicationprotocols, which are, T = 0 asynchronous half duplex character transmission, T = 1asynchronous half duplex block transmission.The card has the CPU/processor of the order of 8 or 16 bit processor,upto 1-4 kb RAM, upto 32-128 kb ROM, 8-64 kb EEPROM. The data holding capacity isvery less and the operations possible with the card would be very less in view of the smallsize processor. The smart card has its own OS.30
  • 42. 31Chapter 2 – Preliminary System Design _2. Software characteristicsThere are two primary types of smart card operating systems – Fixed File structure andDynamic Application system. Generally, all the cards available in the market haveproprietary OS, that is, the vendors supply their own OS. But the most common are JavaCard OS, Multos, and CardLogix M.O.S.T. The operating system of the card controls itssecurity logic. The two types of OS can be explained below,1. Fixed File structure – This approach treats the card as a secure computing device andsecure storage device. Files and permissions are set by the card issuer. The OSperforms set of instructions and applications such as authentication, encryption etc.2. Dynamic Application system – This follows a Disk drive approach to card OS. Thecard OS has active memory manager, can load applications with differentfunctionalities onto the card, and performs active file management and allocation.They may also be termed as multi-application OS. Examples of such are the Java Cardand Multos.Similar to the standard file structures, such as DOS, the card has one Master File (MF) atthe top, equivalent to a root directory, and then it has subdirectories, the Dedicated File(DF) and the Elementary File (EF). The smart card files structure shown in the followingfigure, in Fig. 2.4.2.The Elementary File is the last node in the structure. The MF containsheaders of the EFs, directly beneath it, and the headers of the DFs. It also contains data.Dedicated File contains the elementary files and also data. The elementary files simplycontain its header and the data in its body. The data is managed in different ways,depending on the different types of operating system available in the market. For example,in GSM (Global System for Mobile communication), the data is managed by organising infixed or variable lengths of the data records. In some cases, the data is managed simply byoffset and length.Smart cards do not possess batteries or its own power source, so it has todepend on an external power source, such as when it gets connected to the card reader. Onreceiving power, the card becomes active and the Master file is automatically selected. Inthe card, a file being selected implies opening the file. Also, an applet being selected onthe card means, it being instantiated and ready for receiving command from the card
  • 43. Chapter 2 – Preliminary System Design _reader. But more on that later. Once, the Master file is activated, the access or selectionmechanism can move around the tree, traversing the tree either in ascending order, or indescending order. Each file has in its header, its attributes, and also the access conditions.When a file is selected, the information contained in its header is retrieved. Thendepending on the access conditions, the file data (contained in its body) can be accessed.Thus it provides a logical security level of the card.Fig. 2.4.2: The smart card file structureProgrammatically, each file is referenced by two byte identifier.According to the paper by Vicente, Ortega Jose [9], the file access conditions in a smartcard can be characterised by five different levels. These are - Always (ALW), Card holderverification 1 (CHV1), Card holder verification 2 (CHV2), Administrative (ADM), Never(NEV). The “Always”, as its name implies, allows access to a file without any restrictions.The “Never”, as its name implies, allows no access to a file. The CHV1, and CHV2,allows access only when these values are correctly presented. For ADM, the accessrequirements are variable and depend on the respective controlling authority. In case offiles storing encryption keys, the files are mostly classified under ADM access conditions.Another enhancement in smart card security, is the use of Biometrics.Biometric data [18], such as, fingerprints, iris scans etc. are stored in the smart card, andafter the fingerprints and iris scans are read by some scanner or reader, it is passed to thecard, which then verifies it by matching with the stored template. On a proper match, thecard then provides an authenticated session answer to the calling user application. Thus,smart cards enabled with biometrics authentication mechanism would further enhancesecurity in a grid environment.32
  • 44. 33Chapter 2 – Preliminary System Design _The respective applet on the card verifies whether the pin, or password,or biometrics [19] are correct by comparing with stored data – in case of biometrics, bycomparing with the stored biometric template. Depending on matchedpin/password/biometrics, or unmatched, the applet returns the corresponding code. Ifmatching fails after pre-determined number of tries, the card is blocked and requires anunblocking pin/password/biometrics, and if this matching also fails after pre-determinednumber of tries, the card is blocked permanently. The self-destructive nature of the cardenables its maximum security characteristic. Any data stored in the card, is generallystored in two ways. One is that, it can be stored individually in a file, with accessconditions written in the file header, otherwise, it can be stored in a group of fileshierarchically set under one header file, and the access conditions written in its header.2.4.3 Limitations, weaknesses and measuresLike all technologies, being very practical, a smart card is also not 100% safe, though itprovides the highest level of security compared to any other technologies.2.4.3.1 Physical AttacksAn important vulnerability of the smart cards is being prone to direct physical attacks.There maybe,1. Internal attacks2. Logical attacks.3. Side Channel attacks.4. Non-invasive attacks.5. Invasive attacks.6. Reverse Engineering.7. Traditional Mathematical attacks8. Implementation attacks.The EEPROM can be erased or modified by supplying unusual voltage to it. Thecontroller can be heated to a high temperature and if UV light is focused on the EEPROM,the security lock is removed.
  • 45. 34Chapter 2 – Preliminary System Design _1.The internal attacks comprise of attacks on the internal structures using Focussed IonBeam system, Etching tools, Probe station, Laser cutters etc. Probe stations are used onthe bus connectors to read values. Focussed Ion Beam system modifies shielding or chip.However, there are counter measures for this, such as sensors, reduced feature size – 0.6micron technology, Multi-layer, Buried bus, the logic can be confused by Glue logic orredundant logic.2.The logical attacks comprise of attacking communication channels and informationstorage. It comprises of File System scanning, Command scanning, Cryptanalysis andprotocol abuse, and invalid/inopportune requests. The measures include and are notlimited to, restricting and verifying command coding for command scanning, restrictingfile access and testing file access mechanisms for file system scanning, excluding non-valid behaviour and verifying conformance for invalid/inopportune requests etc.3.The side channel attacks include attacking operation by-products, such as powerconsumption, electromagnetic emission etc. It includes varying the power supply the cardat different instances, such as when reading a memory cell. The counter measures can be,and not limited to, using sensors for supply voltage, light and temperature. reducingprocessor signal by equalising or balancing power, shielding emission, adding noise to theprocessor activity etc.However, most of these attacks are classified as Class 3 attacks, as perVicente, Ortega Jose [9], which implies that a huge cost factor is involved to carry outthese attacks on smart cards, that is, the system cost is much less than the cost of attackingand breaking the system. It also implies, it requires huge amount of computing power tobreak only one transaction.2.4.3.2 Weakness in the system.One of the greatest vulnerabilities of the smart card technology lies in the card reader itself.In all these transactions, the weakest link is in the password being received and sent by theservlet and it being received by the card application. Each of these points can be hackedinto, which will make the entire smart card system (end-to-end system) pointless, in termsof security. So, any data sent from the card or any data going into the card can be easilysniffed or corrupted. The data becomes accessible at this stage. This type of attack on asmart card falls under the Non-invasive attack category. However, with time, if the card
  • 46. 35Chapter 2 – Preliminary System Design _reader is made redundant and a smart card with USB connection facilitated somehow, asproposed by Ravishankar T., Tournierm F., Violleau T. (2006) [22], then the system canbecome highly secure. For the time being, we have to use the existing design of the system.2.4.3.3 LimitationsThe integration of smart cards in a distributed environment like a grid environment isquite difficult, since, there are some drawbacks in smart cards. Smart cards have fourmain problems to integrate them in a distributed or grid computing environment.First, their communication procedures take place through a card reader.Hence, this is an extra piece of hardware.Second, the cards are passive in nature, that is, they cannot initiatecommunication with the external world, whether it‟s some other smart card, otherprocessor, network etc. The card application (that is, the software application inside thecard) waits for a command from an external application (usually, called the hostapplication) to start executing.Third, the communication protocol between the card and the card readeruses a sequence/structure of bytes (APDU – Application Protocol Data Unit) which is notefficient enough. To develop any application for the smart card would involve lots ofdependencies on the APDUs. Being very complex in nature and not very efficient, theAPDUs make it difficult to maintain standard communication. There are possibilities ofdeveloping wrapper applications to sort this problem partially.Fourth, and finally, the smart cards are very short of memory. Hence,storage power, computing power and communication bandwidth is affected. However, allthese problems might also be solved soon, as there are chances of smart cards beingmanufactured, with 1 GB of memory and TCP/IP protocols. The production of these cardsmight be possible very soon, in a couple of years, maybe.
  • 47. 36Chapter 2 – Preliminary System Design _5. Smart card enabled credential repository and authenticationSmart cards will be able to provide both storage services and authentication services. Thestudy of present day commonly used systems points us to use more of smart cards.1. Weakness in present day systemsAll the above credential repositories studied so far, have one thing in common, they allstore the grid credentials in the dedicated server machines or workstations etc. A quick runthrough some of the common credential repositories yields,1. The Kerberos Key Distribution Centre is an attractive target for attacks and has highprobability of being attacked, as the keys are all kept unencrypted.2. The MyProxy server is also a similar target, even though the keys are encrypted withuser passwords, but, once a hacker gets hold of the encrypted keys, then there wouldbe dictionary attacks for breaking the passwords.3. Another common authentication system, the SPX, is similar to Kerberos, does notoperate on shared key mechanism, but on PKI. The SPX server faces similar problems.4. Any other store house of keys, like workstations, desktops, laptops etc. are prone toattacks from the network.2. Advantages of the smart card systemWhen smart cards are used as store house of secret keys, private keys and digitalcertificates in the grid, they will provide the following advantages,1. First of all, the smart card has very low probability of its contents being retrieved. Ifthe smart card gets lost, the card is self-destructive, on even being physically attacked,the keys are destroyed by the deletion of the key objects of the java card applets, so amalicious user cannot get access to the secret credentials and thus cannot impersonatea genuine grid user, and hence data remains safe and the grid remains safe.2. Smart cards provide mobility and better usability.3. Finally, they can provide Two-factor authentication or identification, which is highlysecure and safe. This includes, the user password, plus, the card itself.
  • 48. 37Chapter 2 – Preliminary System Design _4. As they are mobile, they have less probability of being attacked. In practice, an attackcannot be generated directly against a smart card, since it is passive and needs the cardreader application to make it active.2.5.3 The credential store and authentication mechanismThe keys stored in the java card would be generally RSA key pairs, butshared secret keys can also be stored. Generally, a typical smart-card has a storagecapacity of 16-32 KB which can store normally 3-5 key pairs and digital certificates. Keyobjects are created in the applet of the java card to store the keys and their correspondingindex. For every grid user and maybe, grid resource, a smart card should be issued whichwill contain the private key and also, maybe the certificate, with the public key. The usercan swipe in the card through some card reader attached to a terminal before gettingaccess to the grid. Biometrics can be added to the card for further security, which ensuresthat the same person use the card for whom it is intended.There would be possibilities of keys and certificates generation from twosources. Either they can be can be generated by some grid management or administrationapplication and then stored in the smart card, or, they can be generated by the smart carditself and stored within it. The decision as to who generates the credentials is being left tothe grid security policies and VO policies, and is not kept within the scope of this project.Here, I have stressed more on the storage security and the authentication mechanism. But,whatever is the decision of future grid policy makers, this system would have provisionsto cater to both the policies.Now, back to the card. The private key can be stored as a composite key,like the password or PIN to be given by the user to be part of the key. Also, any biometricscan also be combined with the private key and stored as a composite key. The storage ofthe key in the card can be for a particular lifetime, as decided by the CA, who issues thecertificate with the public key.So, when a user types in his password/pin, the request (in form of APDU– Application Protocol Data Unit – packets of data - the present form of communicationfor smart cards) is passed to the JCRE (Java Card Runtime Environment). From JCRE,this command APDU goes to the applet which checks whether the requester needs to login.
  • 49. Chapter 2 – Preliminary System Design _The command APDU contains the pin. Then the applet method matches the pin with thepin/password, and then sends the response APDU. If login attempts are more than aspecified number of times, it is blocked. There is an unblocking pin for the card. If that isalso given incorrectly, the card is blocked permanently. In reality, the applet then deletesthe file containing the keys. The physical view of the system is represented as in thediagram, Fig.2.5.3.Fig. 2.5.3: Physical view of the smart card authentication systemIn biometrics enabled card, there is no need of pin/password. Whenhe/she swipes in, the applet matches the biometrics from the reader with that stored on it,instead of matching pin/password. The card reader is generally connected to a desktopmachine or can exist individually. The user needs to provide his/her username andpassword in the Grid Portal, which is a web application in an application server, forexample, say, WebSphere Application server. The username and password, maybe, takenup by a servlet and passed to the card application, which, in turn, passes it to the applet inthe smart card, to match. The grid user once logged in the grid can then submit a job orcheck the status of an already running job. Also, there must be facilities such that, thecredentials can be retrieved from the card.The proposed smart card system thus enables asecure authentication system, as well as, provides secure storage of keys.38
  • 50. 39Chapter 2 – Preliminary System Design _2.5.3.1 Functional requirements specification1. The smart card or java card should store in it, the following credentials, one or more ofthem: –(i)(ii)(iii)(iv)Private key of the grid user or grid resource.Public-private key pair.Digital certificate.Shared secret key (in case of symmetric encryption).and one or more of them:-(i) Username/password combination.(ii) Biometric data.2. The private key or the shared secrety key or the private-public key pair can be storedin combination with the username/password or biometric data, like a composite key.For this, specific algorithms are available, but this is not the scope of this project.3. In the intial stage, a smart card is issued to a grid user by the grid administrator, withthe username/password/biometric data for authentication, and the generated privatekey/digital certificate stored in the card.4. The grid user can now log in as explained in the previous section.5. The keys/certificates should be retrievable from the card by the user and sign amessage or a new certificate request etc.6. Everytime, the card gets connected to the card reader; first the card reader applicationmust select a particular applet, which would do the initialization procedures of the javacard. This includes executing applet methods responsible for verifying the lifetime ofthe credentials stored it it. This means that, the applet must check whether thecredentials have expired or not.
  • 51. 40Chapter 2 – Preliminary System Design _7. In case of credential expiry,(i) In case of credentials being generated by an external application, external tothe java card, the card the card should send notification messages and requeststo the grid administrator, through the card reader application, for updates.(ii) In case of credentials being generated by the java card itself, the appropriatecard applets should generate new credentials and the card should update itself.8. In case, the credentials has not expired, then depending on the time of expiry, if theremaining time duration reaches a threshold value, then, depending on the source ofcredential generation,(i) In case of credentials being generated by an external application, external tothe java card, the card applet returns a request to the card reader application,which passes it again to the appropriate grid application for updates.(ii) In case of credentials being generated by the java card itself, the appropriatecard applets should generate new credentials and the card should update itself9. In other cases, on instructions from the grid administrator, the card should allow forupdates of the credentials and usernames/passwords/biometric data stored in it. So, itwill receive the updated data through the card application and update itself.10. Each time an update request and data is sent to the card, the card applet must verifywhether the request and data are sent from the genuine source, that is, the gridadministrator.11. In case of loss of card, all references to the card, like the hash values associated withcard and stored with the grid administrator, should be destroyed and procedures forgeneration of new keys, passwords etc. should be started.2.5.3.2 Usability issuesThe usability factors:-1. There is no User Interface specifically for the smart card or the java card. There wouldbe UI for the entire authentication system, but not directly for the card. The UI to be
  • 52. 41Chapter 2 – Preliminary System Design _used is the grid UI. The grid user accesses the grid through this UI and the UI shouldbe able to take in the user‟s username/password s and/or biometric data. All the dataflow to and from the card goes through the card application. The card applicationalways acts as the interface for the card.2. Mobility of the credential repository is a great advantage.3. Owing to this mobility, however, the grid user‟s habits need to change.2.6 Comparison of smart card system with othersA smart card enabled credential repository has a lot of advantages over other credentialrepositories, as mentioned and explained at various points in the previous sections. Thereare some disadvantages, as well, with the smart card system when used as a credentialrepository. One important factor is that, presently, smart cards cannot generate proxycredentials. The smart card application framework here - the java card technology, do nothave support for this. There are different important factors to be considered whencomparing a smart card authentication and repository system with other systems [8] [37].I have considered some important factors for comparing the different credential repositoryand authentication management systems. I have considered few of the most commonsystems available worldwide. They are:-1. MyProxy online credential repository system.2. Kerberos.3. KX.509.4. VCMan.5. Liberty Alliance.6. Shibboleth.7. NSD Security Practical PKI.The first three has been described before. A few lines about the last four systems.4. VCMan (Virtualized Credential Manager) – It is basically a federated credentialmanagement system, and it provides inter-domain virtualized credential and policymanagement.5. Liberty Alliance – It is also a federated credential management system framework,created by a consortium of 150 companies.
  • 53. 42Chapter 2 – Preliminary System Design _6. Shibboleth is another federated identity management system based on open sourcesoftware.7. NSD Security Practical PKI – It is a product of NSD Security Inc., a subsidiary ofNippon Systems Development Incorporated, and is an Identity Management systemthat provides the security of PKI alongwith the usability characteristics of passwords.The characteristics that we are going to match are:-1. Type of Credential management system – whether it is only a credential repository or acredential federation system.2. No. of IDs – It defines the type of credential repository that returns single or multiplecredentials, as required by the grid user.3. Type of the credential – It implies the type of credentials the user gets from therepository. It maybe the key or the certificate or a token. A token is a statement with ashort life-time.4. Platform of the client or user5. Credential generator – who generates keys - client or repository or both.6. Security status and comments – how secure it is and comments.SystemNameSmartCardsystemMyProxy Kerberos KX.509 NSDSecurityPracticalPKIRepositoryLiberty VC-Alliance ManType oftheCredenti-almgmt.systemNo. ofIDsRepository Repository Repository ProtocolforfederationFeder-ationFrame-workFeder-ationMech-anismSingle IDreturnedMultipleIDsreturnedKeysSingle X.509andKerberosTokensSingle Multiple Kerberos andX.509TokensCredenti-al TypePlatformOf theClient/UserKeys andcertificatesAnyToken Token andkeysWindows AnyMultipleAny Should beKerberosenabledShouldbeKerberosenabledAnyTable 2.6: Table of Comparison among different Credential repositories
  • 54. 43Chapter 2 – Preliminary System Design _ofsoftware,physicalattackspossiblebut muchless.Expensive.prone todictionaryattacksTable 2.6(Contd.): Table of Comparison among different Credential repositoriesThe comparison tables shown above clearly represent the fact that smart card system hasquite a good number of positive traits in terms of security and add to it, its mobility, thesecure software and hardware, and better manageability owing to its mobility, then itsurely establishes itself as aveuy secure system. Though it is expensive initially, but, whenimplemented on a wider scale, the economics might prove feasible.SystemNameSmartCardsystemMyProxy Kerberos KX.509 NSDSecurityPracticalPKILibertyAllianceVC-ManKey Optional Both Not Not Both Not appli NotGenera applicable applicabl e-cable appli-tor -cableSecur-ityStatus&Comm-entsVerysecure,Not proneto hackingacrossnetwork,not proneto hackingSecure,but theserver ispronetohackingandencryptedkeys areNot sosecure,all keysin onecentralserverSimilartoKerberos,sinceit‟s aprotocolusingKerberosSecure Secure Secure
  • 55. 44Chapter 3 – Implementation Strategy _3. Implementation StrategyThe smart card credential repository and authentication system needs to be implementedin the java card technology as it is the most prevalent technology today, despite itsshortcomings and drawbacks. Soon, with the advent of better hardware (i.e. the card itself)and better software framework (java card), the present day anomalies and inconveniencewill be removed.1. Smart card application development featuresThe use of smart cards in grid computing is quite a complex process. There are lot ofdetails to look into. For example, for communication with a smart card, a card reader isabsolutely necessary. So the card reader needs to be a part of the distributed system.Hence arise the requirements for developing proper software applications not only for thecard, but the card reader as well. The card reader applications need to communicate withthe card on one hand and the other grid applications on the other. The modes and levels ofcommunication vary on both sides. On the card side, there is generally low levelcommunication, because there is APDU communication involved. On the other side, highlevel communication is possible. In order to develop applications that make use of smartcards, there are four important features that has to be taken into consideration (in referenceto a previous section “Limitations”, 2.4.3.3) –1. High level of communication.2. Transparent service discovery.3. Proactivity.4. Extended memory resources.1. High level of communication – So far, in the present java card technology, there aretwo levels of communication used. One is the message passing model, which use rawAPDU data and is quite low level. The other is the Java card RMI, which provides awrapper for the former mode of communication. It would thus facilitate easiercommunication with the rest of the grid.
  • 56. 45Chapter 3 – Implementation Strategy _2. Transparent service discovery - A smart card is basically passive and do not announceits services on its own. Hence it is necessary to faciliate means for the card to exposeand describe its services, so that all the other components of the distributed system,discovers them and uses them. It would facilitate easir, faster and better integration ofsmart cards in the grid.3. Proactivity – To achieve co-operation, grid system components must communicatewith each other. Hence, a framework needs to be in place to take communicationinitiatives, thus, making the cards virtually active. This can be achieved by developingsophisticated card reader applications.4. Extended memory resources – Smart cards have limited memory, so providingmeaningful solutions is mandatory in new kinds of application domains.2. Java card technologyThe Java card development kit (JCDK) specifications of Sun Microsystems covers threemajor parts,1. Java card API (Application Programming Interface), which defines the coreframework and extension packages and classes for smart card applicationdevelopment.2. JCVM, a subset of the original Java virtual machine, for the smart card.3.JCRE, the runtime environment for the smart card.The main features of the Java card technology are,1. Interoperability.2. Security.3. Multi-application capability.4. Dynamic.5. Compatibility with existing standards.The first four terms are self-explanatory, the fifth one corresponds to thecompatibility of the card APIs with international standards for smart cards, such as,ISO7816, or EMV (standards for interoperability of smart cards, and started by Europay,MasterCard and VISA). One of the aims of the project is to create a platform-independent,vendor-independent smart card solution for grid computing. So, the JCDK of SunMicrosystems has been chosen.
  • 57. 46Chapter 3 – Implementation Strategy _3.2.1 The Application frameworkThe java card application from end-to-end, comprises of a back-end application, a cardreader side host application, a client application on the card reader and the actual cardapplication on the card. The smart card reader is also known as the Card AcceptanceDevice (CAD), and it is the interface between the other applications and the card (javacard or smart card, whatever you call it). The java card virtual machine [25] actually sitsin the card on top of the card operating system. The java card runtime environment [26]consists of the java card virtual machine, the java card framework and APIs and someextension APIs. The communication procedure in a smart card system, in between the cardreader and the card is basically a client-server model. The card is passive and the cardapplets act as server. They are instantiated when loaded on the card and even when thepower is switched off, they remain alive, and obviously, inactive. They however remaininactive even when the power is switched on, by connecting the card to the reader. Thecard applets become active when they are selected by sending APDU from the card reader[27]. The mode of communication between the cards reader and the card follows twomodels. One model of communication is the fundamental message passing model. Theother is the Java Card Remote Method Invocation (JCRMI) [28]. There are other modelstoo, but they depend basically on these two, rather on the first one. They contain APIswhich are mainly for writing client side applications, they are, Java Card RMI Client API,Security and Trust Services API (SATSA), and the Open Card framework.APDU is the heart or core of java card or smart card communication.The APDU is a logical data packet that is sent and received from and to the card. It is oftwo types, Command APDU, sent from the card reader to the card, and the ResponseAPDU, sent from the card to the reader. The Command APDU, as its name suggests sendsa command from the reader to the card, for example, for loading an applet, selecting anapplet, and host of other commands. They send data within it too, for example, thepassword or biometric data to the respective applet with the corresponding command ofmatching them with the stored template. The Response APDU, as its name suggest, sendthe corresponding response to the command, for example, password matching status –success or failure, applet selected, applet loaded, file selected, file read etc. They also senddata within it to the card reader, like sending back the stored digital certificate, the keys,etc. The APDUs are actually sent by the card reader to the JCRE and the JCRE sends it to
  • 58. Chapter 3 – Implementation Strategy _the card, and vice-versa. The communication process is based on any two link protocols,T=0 and T=1. T=0 is byte-oriented and is quite complex. T=1 is block-oriented. There areother protocols, like, T=USB and T=RF. The smart card communication system, based onmessage passing model, is viewed as under, in the figure, Fig. 3.1.1. It maybe mentionedhere, that, all models of smart card communication are basically, based on the messagepassing model using the Application Protocol Data Unit, and in reality, provides justwrappers over the APDU.Fig. 3.1.1: Smart card communication (Message passing)The APDU follows a specific structure. The command APDU has aheader and a body. The header is required and the body is optional. The header containsfour parts,1. CLA (Class of Instruction) – Its length is 1 byte. This field represents the type ofcommand, for example, SELECT Command. Its valid values are specified in theISO7816/4 specification.2. INS (Instruction Set) – specifies specific instructions depending on the CLA type.They are used for data access on the card. Both the INS and CLA can be user-defined.The INS length is 1 byte.3. P1 (Instruction parameter 1) – This value depends on the INS and supports it. Itslength is 1 byte.4. P2 (Instruction parameter 2) – This value also depends on the INS and supports it. Itslength is also 1 byte.47
  • 59. Chapter 3 – Implementation Strategy _The optional body contains three parts.1. Lc – Its length is 1 byte. This value represents the length of the data field.2. Data Field – This contains the actual data and may be of any length. This mightcontain any data.3. Le - Its length is 1 byte. This value represents the maximum length of the data field,to be obtained in the response APDU.The command APDU structure is shown as below, in the figure, Fig. 3.2.1a.Fig. 3.2.1a: Command APDU structureThe response has a body and a trailer part, which gives the status of thecommand, whether it was successful or not, and what the error was. The body is optionaland the trailer is required.1. Body – Its length is variable. It contains the data returned by the applet. The maximumlength is specified by the command APDU‟s Le field.2. SW1 – The required status field. Its length is 1 byte.3. SW2 – The required status field. Its length is 1 byte.Fig. 3.2.1b: Response APDU structure48
  • 60. Chapter 3 – Implementation Strategy _The CLA valid values of the command APDU as specified by ISO 7816,is shown in the table below, Table 3.1.1a, sourced from the Sun Microsystems report byOrtiz, C. Enrique (2003) [23].Table 3.2.1a: Valid CLA values for APDU (ISO 7816 specified)The INS valid values of the command APDU as specified by ISO 7816,is shown in the table in the next page, Table 3.2.1b, sourced from the Sun Microsystemsreport by Ortiz, C. Enrique (2003) [23].The response status of the response APDU are defined in the ISO 7816and some valid values have been defined. They are categorized into 4 (four) levels, asshown in the table, Table 3.2.1c, in next page. The XX implies values to be inserted here.The above described APDU structures form the basis of allcommunication in a smart card system. The smart card communication using the APDUstructures makes it quite complex compared to other standard forms of communication.However, the APDU does not directly go into the card from the card reader, rather it ispassed to the Java Card Runtime environment which passes it to the smart card. The JCREdoes not depend on any platform and is actually the provider of a platform independentinterface for all types of services provided by the smart card and its operating system. TheJCRE consists of the JCVM, the Java card APIs, third party extensions etc.The java card runtime environment specification has been set to define a wide of range ofissues including the java card applet life cycle, the java card virtual machine life cycle,selection and isolation of applets, object persistence, sharing, transactions etc. The Java49
  • 61. Chapter 3 – Implementation Strategy _card Virtual machine is implemented in two parts, one part external to the card and theother running on the card itself. The VM on the card interprets bytecode, manages classesTable 3.2.1b: Valid INS values for APDU (ISO 7816 specified)50Table 3.2.1c: Status Codes of the Response APDUand objects and so on. The external virtual machine is a development tool, also known asthe java card converter tool, which converts the class files into appropriate binary files,called the CAP file.The java card technology is a subset of the core java technology, sosome features are supported and some not. The supported features include,1. PackagesStatus of the Command Response Codes(SW1, SW2)Process Completed – Normal processing 61, XX or 90, 00Process Completed – Warning 62, XX or 63, XXProcess Interrupted – Execution Error 64, XX or 65, XXProcess Interrupted – Checking Error 67, XX to 6F, XX
  • 62. 51Chapter 3 – Implementation Strategy _2. Interfaces.3. Virtual methods.4. Dynamic object creation.5. Exceptions.The unsupported features include,1. Large data types.2. Dynamic class cloading.3. Multi-threading.4. Garbage collection.The java card development process [29] [30], in a nutshell, involvescreating java files, then corresponding class files, converting them to CAP files, then toscript files containing the APDU commands in hexadecimal format and the CAP files,then, installing or loading the applets on a real smart card or a simulated one, and finallyexecuting the client and passing commands and receiving them from the applets.2. The java card API structureThe java card application development framework has its own packages, some of whichare derived from the core java packages and classes. These packages eill be used for theproject. The API framework is smaller than J2ME‟s CLDC. The framework does notsupport Strings and there are no Class or System classes. The packages are the following:-1. java.io - It defines only the IOException class and does not include any othercore java i/o classes.2. java.lang - It defines only the Object class from which all the classes of thejava card framework are derived. It also defines the Exception class and some of itsderivatives.3. java.rmi - It defines the Remote interface and the RemoteException class.None of the othere java.rmi classes are there.4. javacard.framework - It defines interfaces, classes, exceptions which form thefoundation of this framework.It defines interfaces like PIN, classes like Applet, AIDetc.5. javacard.framework.service - This allows the java card applet to bedesigned as the aggregation of service components.
  • 63. 52Chapter 3 – Implementation Strategy _6. javacard.security - This package is a very important package of theframework and is used for implementing security and cryptography. It definesinterfaces and classes which are responsible for generating keys according to the mostcommon cryptographic algorithms. For example, it definesRSAPrivateKey, RSAPublicKey, ECPrivateKey, ECPublicKey etc.Plus, there are some standard extension packages:-AESKey, DESKey,1. javacardx.apdu.2. javacardx.biometry.3. javacardx.crypto.4. javacardx.external.5. javacardx.framework.math.6. javacardx.framework.tlv.7. javacardx.framework.util.8. javacardx.framework.util.intx.3.2.3 The development processThe java card development kit v2.2.2 is provided by Sun Microsystems and is a freewareand contains the basic tools needed for java card application development. However, asmentioned by Ortiz, C. Enrique (2003), in the Sun Microsystems report [23], “While theSun Java Card Development kit allows you to write and test Java Card applets, deployinga real end-to-end smart-card application requires tools not included in the developmentkit, for example the use of terminal-side APIs such as the OpenCard and Global PlatformAPIs. It may also require the use of tools such as Subscriber Identification Module (SIM)toolkits to help you manage the SIMs.” The toolkit by Sun Microsystems is a very basictool, without an IDE, debugger, GUI etc. This toolkit contains, the Java card verifier,converter tool, the APDU tool, the capdump tool, the scriptgen tool, supporting librariesetc. The directory structure, of this development tool, which is generally used fordevelopment purposes, is as shown here, in Fig. 3.2.3a, sourced from the SunMicrosystems report by Ortiz, C. Enrique (2003) [23].
  • 64. Chapter 3 – Implementation Strategy _Fig. 3.2.3a: The directory structure of the java card development toolThe main tools provided by the kit, in order of general usage, are,531. Converter2. Scriptgen3. apdutool4. cref----converts CLASS files to CAP files, JCA files and exp files.converts the above files to .scr (script) files.reads APDUs from script files and sends them to the JCRE. runsthe C-language java card runtime environment from thecommand line. It is actually a simulator that can be built with a ROM mask, similar to realjava card technology based implementation. It has the ability to simulate the persistentmemory of java card or smart card, that is, EEPROM, and then save and restore thecontents of EEPROM to and from disk files.5. JCWDE - emulates the JCRE. It simulates the running of java card appletas if it were masked in ROM.Both the tools above, cref and JCWDE do almost the same things. Either of them is usedto simulate a java card or smart card environment and install and load applets in the card.The steps involved in the the java card development process aresummarized in the diagram in the next page, in Fig. 3.2.3b, according to the SunMicrosystems report by Ortiz (2003) [23].The Java card RMI framework, is an object-oriented form of the smartcard application development framework, and in reality, provides an abstraction to theAPDU-based communication. However, the stages of installing and loading applets onthe card, does not change. They remain almost the same in format and complexity as themessage passing model. In this stage, one has to deal with APDU handling inhexadecimal forms, and the complex script files, as the former model of smart cardcommunication. The JCRMI framework is represented in the diagram, Fig. 3.2.3c.
  • 65. Chapter 3 – Implementation Strategy _Fig. 3.2.3b: The Java card development processHowever, for the main card client application, the card reader or moreformally, the Card Acceptance Device terminal, should support a J2SE or J2ME platform.The card client application is written in JCRMI (Java Card Remote Method Invocation). Itis a JCRMI client application which calls the smart card applets, which are JCRMI serverapplets executing on the smart card. The reference implementation of the Java card RMIclient-side API is based on APDU input output, as usual, for the card access mechanisms.The Java card RMI is just like a wrapper hiding the intricate details of the APDU accessmechanisms. So, in effect, underneath everything, underneath the JCRMI framework, thesame old APDU communication mechanism comes into play, with protocol negotiation,and Answer-to reset (ATR) etc.54
  • 66. Chapter 3 – Implementation Strategy _Fig. 3.2.3c: The JCRMI frameworkThe java card development process involves dealing with not only thejava files, which has the source code, but also, the batch files, Converted Applet files,script (.scr) files, the saved EEPROM image file etc. The state of the EEPROM contentscan be saved in a file and later invoked by the C-language java card Runtime Environment(or, C-JCRE provided by Sun Microsystems). It is to be noted that, unlike otherprogramming languages development cycle, in case of java card application development,the script (.scr) files, the CAP files etc. are sometimes more important than the class orsource files, mainly due to the fact, these files are the basis of APDU communication withthe smart card (be it a real one, or a simulated one), and problems in the communicationprocess between the card and card reader would make all the written source code for thecard client and the server (the applets) irrelevant. So, establishing communication andproper loading or installation of applets in the card is vital so that one can move forwardin writing more code to implement the required functionalities and design. So, the APDUsare of vital importance.Also, it is of vital importance to note that, though the proposedfunctional requirements define the complete smart card credential repository system, forall practical purposes, keeping in mind the time factor, initially, a smaller part of it will be55
  • 67. Chapter 3 – Implementation Strategy _designed and probably, a smaller part of it will be implemented. Then, depending on thesuccess/time factors, the design and implementation will expand.The java card state diagram and java card reader state diagram can bevisualized as below, in Fig. 3.2.3d, according to Shillington and Waker [34].Fig. 3.2.3d: State diagrams of smart card (java card) and its reader56
  • 68. 57Chapter 4 – Detailed Software Design and Implementation _4. Detailed Software Design and ImplementationThe system can be designed almost like a three-tier architecture having the grid client orthe grid user as the first tier, followed by the card reader applications, and finally the smartcard. The tiers are the physical and logical parts of a system architecture, separated asdifferent layers of the system. The tiers are generally modular in design, so each tier is aself-contained module. Here, in grid, practically speaking, the system must be an n-tierarchitecture, where grid applications of varied functionalities comprise of separate tiers.The system is designed keeping in mind the different steps involved in a smart card basedauthentication procedure. In the process, we should not forget the main criteria, that is, thecard also acts as the principal repository for the credentials, keys and certificates.1. Detailed design descriptionThe design here tries to strictly follow the popular three-tier architecture, consisting of,1. The Presentation Tier.2. The Application Tier (Business Logic/Logic Tier).3. The Data Tier.Before we move further, let us have a look at what the tiers implies. This way, it would beeasier to have a better design.1. Multi-Tier architecture/N-Tier architectureThe multi-tier architecture or n-tier architecture is the basis for almost the entire softwareindustry and software arhcitectures developed. It is a radically advanced version of thesimple client-server architecture. The „n‟ here implies any positive integer, to denote thenumber of tiers. It maybe 2, 3, or 4 or more.The tiers are explained here, for ease of understanding the design created for the project.1. The Presentation Tier – This is the tier that provides a User Interface (UI) to the userof any system. So, the Graphical User Interface forms a part of this layer. The user‟sworkstation, whether it is the desktop, laptop, PDA, mobile phone etc. has this front-
  • 69. 58Chapter 4 – Detailed Software Design and Implementation _end application, often the GUI or the CLI (Comand Line Interface) displaying to theuser. It contains application-specific entry forms or interactive windows etc. This tiercontains only a user interface sometimes, or sometimes some business logic is alsoembedded in it. Then it is also known as Presentation Logic Tier. In some cases, thereis clear separation between the Presentation UI and the Presntation Logic Tier. Somedata that is local or unique for the user is also sometimes kept on the local disk ormemory.2. The Application Tier (Business Logic/Logic Tier) – This is a very important part ofany system. This contains all the Business logic in it – the business rules, the datamanipulation/transformation logic etc. It acts as the server for the client requests fromthe UI and as the client for a different tier, such as the Data Tier or Data Access.3. The Data Access Tier – This tier contains generic methods to interface with the data.It creates connections with the database etc. It is actually an extra tier, positioned inbetween the business logic tier and the data tier. In some cases, this tier is not present.4. The Data Tier – This is where all the data belongs. It is the layer which stores andmanages the data. For general applications, it would be simple file systems containingdata or Database Management systems (DBMS). So, this layer can be quite simplelike with plain text files and engines for reading, sorting, searching, indexing the filesand data in the files and quite complex like data base management systems.2. Java card three-tier architectureThe tiers in the design described here, for all practical purposes, are roughly inter-mingled. This is not unusual for systems like this, and is quite often recurring in othersystems too. Practically, the functional steps followed, would be,1. A grid user logs in through the grid portal, then, the username/password or biometricdata is passed through it to the smart card reader.2. In the smart card reader, there are two applications. Everything which comes fromoutside – here, from all other applications interacts with the grid interfacing
  • 70. 59Chapter 4 – Detailed Software Design and Implementation _application. This application acts as the interface to all the grid applications, whether,it is the grid portal, or, they are grid administrator applications or any other gridapplications which generates key pairs and digital certificates and pass them forstorage in the card. The grid interfacing application, interact with the smart card clientapplication.3. The smart card client application interacts with its server, which are the smart card andthe java applets on the card. Here, in this project, an actual card was not used, but asimulator of the card, which means the Java card runtime enviornment is simulated bytools supplied by the Sun Microsystems‟ Java card v2.2.2 tool „cref‟ or „JCWDE‟.4. Whatever is the status of the transactions between the card applets and card clientapplication, the status and data, if any, are passed to the grid interfacing application.5. This grid interfacing application now has transactions once again with the grid portal,and/or grid admin etc.The system can be designed as in the following figure, in Figure 4.1.2, in the next page.The dotted lines roughly classify each of the sections as one layer or tier. Following thethree-tier sytem architecture principles, and the flow of processes described above, thetiers here would be roughly,1. Presentation Tier – The Grid portal comes into this. It is the GUI of the card system.2. Application Tier (Logic Tier) – The entire card reader comes into this, consisting ofthe grid interfacing application and the smart card client application. Considering thedefinition of this tier, all the business logic should be in it. The other grid applicationswould thus fall into it. However, in real-life grid applications, the system can be muchcomplex with multi-layers within this tier itself.3. Data Tier – This contains the java card or smart card applications on the card. This isbasically java card applets on the card.It is to be noted that, in this system design, there is, and would be, enveloping orintermingling of the Application Tier and the Data Tier. It is because the java card
  • 71. Chapter 4 – Detailed Software Design and Implementation _applets perform lot of functionalities which is common to the application tier. So, theapplication tier can extend to the java card. Also, the java card itself can have n-tierstructure within, since different applets have various functionalities, and differentapplications can be loaded in the card. So, one tier maybe responsible for managingdata, and another tier can interface with the card reader applications, and a third tiermight act like some sot of middleware.Fig. 4.1.2: Architecture of Credential storage and Authentication system of GridNow let us examine the different layers of proposed design, bit more, in the next sections.60
  • 72. Chapter 4 – Detailed Software Design and Implementation _4.1.3 Grid Portal - Presentation Tier4.1.3.1 Grid portal requirementsWe start from the grid portal application. The very basic requirements for a standard gridportal are:-1. First of all, it should be very user-friendly. Users should be able to log in the gridusing any standard web browser.2. Through the grid portal, the grid user should be able to carry on all his required jobsand should be able to use all the functionalities permitted by their credentials.4.1.3.2 Grid portal designThe grid portal application can be a simple web application or can run from anapplication server such as Websphere application server. The grid user can put hisusername and password through the Web page and the control passes to an applicationservlet with username and password as arguments, which again passes the control to theFig. 4.1.3.2: Grid portal – Presentation Tiergrid interfacing application with the same username and password as arguments again.The reason why the username/password combination is not passed directly to the grid61
  • 73. 62Chapter 4 – Detailed Software Design and Implementation _interfacing application on the card reader is that the purpose of application servlet is toget the status of authentication, and on success, start different jobs on the grid, dependingon the user‟s request. This involves submitting jobs on the grid, getting status of alreadyrunning jobs in the grid etc. In case of biomteric authentication, there will be separateapplications for capturing biometric data (from a suitable biometric device), and passingthe data to the application servlet. The servlet passes control to the grid interfacingapplication with the biometric data as arguments. However, it is to be noted that, this partof the design was intended to be implemented after completion of the main smart cardapplications.4.1.4 Smart card reader applicationsAny grid application, residing on the grid host or anywhere, for that matter, who actuallygenerates the key pair for the grid‟s Public Key Infrastructure based model, would pass theprivate key (encrypted, of course) to the grid interfacing application on the card reader.The card reader, hence, should be connected to the grid. For that matter, it can beconnected to a desktop, which is in the grid. The choice of application, resident on thecard reader can be customized, according to the requirements for that particular grid. Forexample, here, as shown in the figure Fig. 4.1.2, there are two applications resident on thecard reader.4.1.4.1 Card reader grid interfacing applicationThe first application is the grid interfacing application that provides general services toother grid applications, and acts as an interface for the smart card, to other gridapplications. Its functions include,1. Importing the key/key pairs/digital certificates etc. from the Grid application(s) andexporting it to the smart card reader application for storage in the card.2. For storage in the card, receving the password/biometric data (fingerprints, retina scanetc.), from the grid portal application (portal servelet) and corresponding driverapplications for reading biometrics (when the grid user enters it for the first time), and
  • 74. 63Chapter 4 – Detailed Software Design and Implementation _passing it to the smart card reader application for storage in the card.3. For authentication purposes, receiving the password/biometric data (fingerprints,retina scan etc.), from the portal servlet and corresponding driver applications forreading biometrics, and passing it to the smart card reader application forverification/matching with the stored template.4. Getting the status of authentication - success/failure from the smart card readerapplication and returning it to the grid portal application for display to the grid user.5. Importing the key/key pairs/digital certificates etc. from the Grid host application forupdating purposes and exporting it to the smart card reader application for storage inthe card.6. Receiving the password/biometric data (fingerprints, retina scan etc.), from the gridportal application and corresponding driver applications for reading biometrics, forupdating purposes, and passing it to the smart card reader application for storage inthe card.Basically, this application would act as a co-ordinator between the smartcard reader application and the grid or grid applications. However, the card reader canhave a single application that combines the functionalities of grid interfacing applicationand the actual card reader application. The activity diagram for this part of the system canbe summarized in the following page, Fig. 4.1.4.1. The activity diagram here shows onlythe import/export of the credentials and passwords for storage. The activity digram for theauthenticating processes would be the same.
  • 75. Chapter 4 – Detailed Software Design and Implementation _Fig. 4.1.4.1: Activity diagram of the grid interfacing application4.1.4.2 Java card client applicationThe actual smart card or java card client application, on the card reader,has the following functionalities,1. Importing the key/key pairs/digital certificates etc. from the grid interfacingapplication and passing it to the smart card‟s respective applet for storage in the card.2. For storage purposes, receive password/biometric data (fingerprints, retina scan etc.),from the grid interfacing application and pass it to the smart card‟s respective applet.3. To authenticate the grid user, receive the the password/biometric data, from the gridinterfacing application, and pass them to the java card.4. Getting the status of authentication - success/failure from the smart card readerapplication and returning it to the grid portal application for display to the grid user.64
  • 76. Chapter 4 – Detailed Software Design and Implementation _5. Import credentials for update in the java card.6. Get new username/password and biometric data for update.The activity diagram for the java card client application has been represented in the nextpage, Fig. 4.1.4.2. The activity diagram here shows only the import/export of thecredentials and passwords for storage. The activity digram for the authenticating processeswould be the same. It is always better to have two separate applications in the card readerfor purposes of modularity and better interaction with the grid.Fig. 4.1.4.2: Activity diagram of the card client application65
  • 77. Chapter 4 – Detailed Software Design and Implementation _4.2 Implementation StepsThe java card stores the keys and digital certificates for the grid user. The grid user usesthe card to authenticate himself while logging in the grid. The grid user can then accessthe grid and use a particular grid resource, depending on the level of authorization grantedto him, and submit his job in the grid, or check status of a previously submitted job. Theprivate key can also be retrieved from the card. Though it might not be a secure thing todo now, but, for the time being, the design is kept that way. The activity diagram for thedifferent processes occurring during authentication by smart card in the grid can bevisualized in the activity diagram, Fig. 4.2, in the next page.Fig. 4.2: Activity diagram of Authentication of Grid user.66
  • 78. 67Chapter 4 – Detailed Software Design and Implementation _1. Java card client-server design based on JCRMIIn continuation with the above design discussions, if we consider only the card reader andcard transactions, then they represent a client-server model, where the card readerapplication is the client and the card applets are the server components. I have worked onprogramming java card application based on both the modes of commuincation betweenthe card and the card reader – the message passing model and the JCRMI model. The RMImodel is a better programming model because it wraps some of the raw APDUcommunication details. But, still, there are some APDU communication procedures weneed to follow even here. This class design was started with the aim of first targeting onthe main part of the greater design, that is, the card and card applet. Then it might beexpanded covering the bigger picture.Here, in our design, we have the client application class,CardClientClass, Fig. 4.2.1, as a standalone class. The packages that has to be importedare,1. java.rmi - General RMI implementation of Java framework.2. javacard.framework - Framework classes for the java card.3. java.util.ResourceBundle.4. com.sun.javacard.clientlib - This implements the root or basic functionalitiesenabling exchanges of APDUs with smart card or its simulator/emulator. Animportant prerequisite for it is the inclusion of APDUIO (APDU input/output) libraryin the classpath.5. com.sun.javacard.rmiclientlib -RMI implementation of the Java card framework.6. com.sun.javacard.cardServerPkg.RemoteCardSrvr - It is the remote serverpackage, required for the server stub on the client.It is to be noted, that the directory structure of com.sun.javacard is animportant standard structure to be followed for a java card directory.
  • 79. Chapter 4 – Detailed Software Design and Implementation _Fig. 4.2.1a: Class diagram of smart card client standalone classThe JCRMI framework requires an Interface on the card which isexposed or publicized. This interface is implemented by the implementation class. Thejava card applet is the JCRMI server, as mentioned in a previous section. It basically, actsas an object container. Here, for our design, the UML diagram is as follows, in the nextpage, in Fig. 4.2.1b.68
  • 80. Chapter 4 – Detailed Software Design and Implementation _Fig. 4.2.1b: UML diagram of the java card application694.2.2 Platform Setup, File Conversions, Development4.2.2.1 Setting up the Java card platformThe steps followed in the java card development process are as,1. Check as a pre-requisite, the workstation on which development is done, should haveJava runtime installed, minimum requirement is jre1.3.2. Unzip and install the java card v2.2.2 development kit in a directory of your choice.
  • 81. 70Chapter 4 – Detailed Software Design and Implementation _3. On Windows system, add parameters to the environment variable.Right-click on, “My Computer”  Select “Properties” (The Properties dialog boxopens)  Go to “Advanced” tab page  Click on “Environment Variables” (TheEnvironment Variables dialog box opens)  Click on “New” button under the“System Variables” box  Add “Variable name” – JC_HOME  Give “Variablevalue” – the directory path of the java card folder, till the root folder. In my case, itis “C:java_card_kit-2_2_2”.4. Ensure that the system variable JAVA_HOME is set to the java root directory.Minimum requirement is jdk1.3.5. Under “Path” system variable, add the java card directory path till the „bin‟ folder.In my case, it is “C:java_card_kit-2_2_2bin”.6. In “CLASSPATH” system variable, add the path for the jar files of java cardframework. They are generally in the‟lib‟ directory of java card. Generally, we have toadd the following library files.“C:java_card_kit-2_2_2libapi.jar”.“C:java_card_kit-2_2_2libapi_16.jar”.“C:java_card_kit-2_2_2libjavacardframework.jar”.“C:java_card_kit-2_2_2libjcrmiclientframework.jar”.The main intention of creating the programs decsribed below was to merge the two. So,the card and client was created in JCRMI, to do the main functionalities, like receivingand sending private keys, and then the intended plan was to incorporate some of the codefor the biometric authentication in the JCRMI part and make it a full-fledged program.4.2.2.2 APDU communication development, compilation, execution1. Then we write the code in simple JAVA file, in any standard IDE, like Eclipse orNetBeans or JBuilder etc. It is best if the project directory is set within the java carddirectory. So, my project directory for this part of project development is,“C:java_card_kit-2_2_2samplesNewBioMetDevlop”.
  • 82. Chapter 4 – Detailed Software Design and Implementation _2. Compile the JAVA files to CLASS files, using any compiler. Here Eclipse platformversion 3.3.1.1 has been used.During this phase, often there is a problem during compilation of the java card appletclass derived from javacard.framework.Applet. It displays,“cannot access javacard.framework. Applet bad class file……class file has wrongversion 49.0, should be 47.0…..” The following printscrren image shows this. Theimage is of course, for a different class.Fig 4.2.2.2a: Printscreen image of applet compilation error.3. Run the „Converter‟ tool of Sun and convert the CLASS file to a CAP file and .expfile.This command is for converting the „BiometPassAppTest‟ CLASS file. This appletclass is responsible for receiving the biometric data and performing match on the card,with the existing stored template during the user authentication procedure. Forsimplicity, here the biometric data used is just the version number and length ofpassword. For practical, real-world applications, the data involves set of co-ordinatesfor finger prints, for example. (refer to source code listing in Appendix A.2.3)71
  • 83. 72Chapter 4 – Detailed Software Design and Implementation _This is the command given in the command line.C:java_card_kit-2_2_2samplesNewBioMetDevlop>converter -out CAP EXP -classdir %JC_HOME%samplesNewBioMetDevlopbin -applet 0xA0:0x00:0x00:0x00: 0x62:0x03:0x01: 0x0C:0x0f:0x02:0x01 BiometPassAppTest -debug -verbose com.sun.javacard.newBioMet0xA0:0x00:0x00:0x00:0x62:0x03:0x01:0x0C:0x0f:0x02 1.0This command is for converting the „BioMetServerTest‟ CLASS file. This applet classis responsible for enrolment of the Biometric data in the card, that is, stored astemplate for reference, during the user authentication procedure. (refer to source codelisting in Appendix A.2.2)This is the command given in the command line.C:java_card_kit-2_2_2samplesNewBioMetDevlop>converter -outBioMetDevlopbin0x0f:0x01:0x01CAP EXP -classdir %JC_HOME%samplesNew-applet 0xA0:0x00:0x00:0x00:0x62:0x03:0x01:0x0C:BioMetServerTest -debug –verbosecom.sun.javacard.newBioMetServer 0xA0:0x00:0x00:0x00: 0x62:0x03:0x01:0x0C:0x0f:0x01 1.0The conversion phase faces some other series of problems, one of themajor problem is “Unsupported File Format of version 50.0”. All these errors areremoved, if the JAVA files are compiled using jdk/ jre version 1.3. The converter tool inthe javacard development toolkit v2.2.2, does not support CLASS files created withother versions of jdk. (This was however not mentioned in any of the documentations).4. Use the „scriptgen‟ tool to convert the CAP file + .exp file to a script file (.scr).These are the commands given in the command line.C:java_card_kit-2_2_2samplesNewBioMetDevlop>scriptgen –o %JC_HOME%samplesNewBioMetDevlopbincomsunjavacardnewBioMetServer.scr %JC_HOME%samplesNewBioMetDevlopbincomsunjavacardnewBioMetServer.cap
  • 84. 73Chapter 4 – Detailed Software Design and Implementation _C:java_card_kit-2_2_2samplesNewBioMetDevlop>scriptgen –o %JC_HOME%samplesNewBioMetDevlopbincomsunjavacard newBioMet.scr %JC_HOME%samplesNewBioMetDevlopbincomsunjavacard newBioMet.capThe contents of the two files are then merged into a single file, newBioMetServer.scr.(Refer to code listing A.2.1), so the program can be run conveniently by submittingone script file.The steps described above can be seen from the printscreen imagegiven in the next page, in Fig. 4.2.2.2b (Though it was tried with a different java cardproject, but, the steps and commands are exactly the same). In the printscreen figure,the applet class is „MoneyWallet‟. It can also be seen that another command has beenrun, called „exp2text‟. This tool is used to view the export file, .exp in text format.5. Run the „cref‟ tool which runs the java card runtime environment (C-JCRE).6. Run the „apdutool‟ in another window, while the „cref‟ is running, with this command,C:java_card_kit-2_2_2samplesNewBioMetDevlop>apdutool newBioMetServer.scr > newBioMetServer.scr.cref.outThe first file is the input script file prepared before by scriptgen and next one is theoutput file (refer to code listing A.2.4).
  • 85. Chapter 4 – Detailed Software Design and Implementation _Fig 4.2.2.2b: Printscreen image of file conversion steps.Taking a look at the files mentioned above, in the .scr file, newBioMetServer.scr, theinstaller aplet is installed first, as can be seen from the command APDU values.// Select the installer applet0x00 0xA4 0x04 0x00 0x09 0xa0 0x00 0x00 0x00 0x62 0x03 0x01 0x08 0x01 0x7F;// 90 00 = SW_NO_ERROR74
  • 86. Chapter 4 – Detailed Software Design and Implementation _The first value, the CLA value, 0x00 is one of the reserved values according tospecifications (ISO 7816), and is described in a previous chapter, Chapter 3, and is usedfor installing the installer applet. The next value, the INS value, 0xA4 is for selecting file.This is also a reserved value. After installation of installer applet, the some systemcomponents are installed or loaded. Then the bioserver applet is created, the APDUcommand is,echo "BIOSERVER APPLET IS CREATED NOW.";//create bioserver applet with AID 0xA0 0x00 0x00 0x00 0x62 0x03 0x01 0x0C 0x0f 0x01 0x010x80 0xB8 0x00 0x00 0x0d 0x0b 0xA0 0x00 0x00 0x00 0x62 0x03 0x01 0x0C 0x0f 0x01 0x01 0x00 0x7f;The CLA value 0x80 is for application specific instructions, as defined by ISO/IEC 7816-4. The INS value, 0xB8 is given by me, it is user-defined code, and here corresponds tothe installation of the applet.Fig 4.2.2.2c: Create Applet command structure explained.The Create Applet command is of primary importance, since the fate ofwhether the applet is successfully loaded or not, depends on this APDU command type. Inthe figure above, Fig.4.2.2.2c, I have showed the Create Applet Command APDU formatand its corresponding values for the BioServer applet. The figure is self-explanatory. Theabove format of the command is followed always. Please note, the “Parameter Length”field and the following ones are all together after the AID field. It is one whole block.Here it is shown in two layers due to space constraint.75
  • 87. 76Chapter 4 – Detailed Software Design and Implementation _After creation, applet is selected, and some data is sent in the followingAPDU commands, one command for data storage and one command for data matching.Then the apdutool is given powerdown command. If the output file is checked,newBioMetServer.scr.cref.out, the response APDU commands are output as,THE INSTALLER APPLET IS BEING SELECTED NOW.CLA: 00, INS: a4, P1: 04, P2: 00, Lc: 09, a0, 00, 00, 00, 62, 03, 01, 08, 01, Le: 00, SW1: 90, SW2: 00The last two values indicate success, SW1 and SW2 should be 90 and 00 respectively.This means Installer applet is successfully installed and selected.BIOSERVER APPLET IS CREATED NOW.CLA: 80, INS: b8, P1: 00, P2: 00, Lc: 0d, 0b, a0, 00, 00, 00, 62, 03, 01, 0c, 0f, 01, 01, 00, Le: 0b, a0, 00,00, 00, 62, 03, 01, 0c, 0f, 01, 01, SW1: 90, SW2: 00THE APPLET IS BEING SELECTED NOW.CLA: 00, INS: a4, P1: 04, P2: 00, Lc: 0b, a0, 00, 00, 00, 62, 03, 01, 0c, 0f, 01, 01, Le: 00, SW1: 90, SW2:00Here, also, the last two values are SW1:90 and SW2:00 in both cases, which indicatesuccessful applet creation and selection.The BioMetServerTest and BiometPassAppTest classes, are all applet classes, derivedfrom the Applet class.4.2.3 Java Card Remote Method Invocation developmentBased on the design described in section 4.2.1, the implementation steps and details aredescribed. The class, RemoteCardSrvr (refer to source code listing in Appendix A.1.6), isthe remote interface which exposes the services the card applet will provide. It extends theRemote interface of the JCRMI framework.Since the JCRMI is a subset of the main Java RMI. the java rmi package has beenimported.package com.sun.javacard.cardServerPkg;import java.rmi.*;import javacard.framework.*;import javacard.security.*;public interface RemoteCardSrvr extends Remote{//exposed services this interface provides//get the RSA Key pair from the card client application and store in filepublic void GetRSAKeyPair() throws RemoteException, UserException;
  • 88. 77Chapter 4 – Detailed Software Design and Implementation _//get the RSA private key from the card client application and store in filepublic void GetRSAPvtKey() throws RemoteException, UserException;//get the RSA public key from the card client application and store in filepublic void GetRSAPublicKey() throws RemoteException, UserException;……………………………………………………..…………………………..The services or the methods in the interface are implemented in the implementation class,RemoteCardSrvrImpl, which actually extends the CardRemoteObject of the JCRMIframework, and implements the above interface, RemoteCardSrvr. TheRemoteCardSrvrApplet class is the applet class and the JCRMI server. It is the owner ofremote objects, which provide services to its clients, the card reader application. As usual,it is extended from the java card framework applet class.public class RemoteCardSrvrApplet extends javacard.framework.Applet{private Dispatcher dispCard;private RemoteService servCard;private Remote remoteCard;public RemoteCardSrvrApplet(){remoteCard = new RemoteCardSrvrImpl();dispCard = new Dispatcher((short)1);servCard = new RMIService(remoteCard);dispCard.addService(servCard, Dispatcher.PROCESS_COMMAND);……………………………………………………..…………………………..As can be seen from the code snippet, the java card applet creates instances of thedispatcher and the card RMI service. It contains the implementation object and providesreference of it to the client application. The CardClientClass (refer to source code listingin Appendix A.1.8) is the client class which talks to the server, the card. It is a standaloneclass, reads display messages from the properties file, displayMsgFile.properties (refer tosource code listing A.1.4) and displays status messages on each stage of its execution. Itimports the „clientlib‟ and „rmiclientlib‟ libraries, for the card access classes which arebasically wrappers for the APDU communication. See the code snippets below.
  • 89. 78Chapter 4 – Detailed Software Design and Implementation _………………………………..import java.util.ResourceBundle;import com.sun.javacard.clientlib.*;import com.sun.javacard.rmiclientlib.*;import com.sun.javacard.cardServerPkg.RemoteCardSrvr;…………………………………...…………………//CardAccessor interface used to communicate with the card.CardAccessor cardGate = null;try{//ApduIOCardAccessor implements the CardAccessor interfacecardGate = new ApduIOCardAccessor();//Initiates the Java card RMI sessionJCRMIConnect connectCardRMI = new JCRMIConnect(cardGate);System.out.print(displayMsg.getString("statusMsg01")+" ");………………………………………………………………………………ApduIOCardAccessor is the class accessing the card and doing the underlying functions ofmoving APDUs from and to the card or card simulator and it uses the ApduIO library ofthe javacard dev. kit. It requires parameters from the file, jcclient.properties file (refer tocode listing in Appendix A.1.2), and the file remains in a directory listed in CLASSPATHenvironment variable. The file contains parameters related to the type of protocol used,T=0, T=1, the no. of the port (here the default port is 9025). A connection is initiated withthe card, and the RMI connect instance is created. Then the card applet is selected. Thecard applet is the server and it provides the reference to the implementation class, asmentioned before. When this reference is cast to the corresponding interface type, then itcan be treated as a local object of the implementation class.…………………………//Referencing with class nameconnectCardRMI.selectApplet(CARD_SERVER_AID,JCRMIConnect.REF_WITH_CLASS_NAME);……………………………………………………
  • 90. 79Chapter 4 – Detailed Software Design and Implementation _//Now, getting the initial Interface reference from CardRemoteCardSrvr cardSrvrIntfc =(RemoteCardSrvr)connectCardRMI.getInitialReference();if(cardSrvrIntfc != null)……………………………………………………The steps to execute the entire program are,1. Compile the JAVA files to create CLASS files.2. Run the command rmic to create a stub file for the server implementation, for theclient to access locally. My project directory is,C:java_card_kit-2_2_2samplesNewCardSmartGrid.The command is,C:java_card_kit-2_2_2samplesNewCardSmartGridbinclassescard>rmic -v1.2 -d C:java_card_kit-2_2_2samplesNew CardSmartGridbinclassescard com.sun.javacard.RemoteCardSrvrImplIt is to be noted that, the above directory where the command is run, should be alwaysabove the comsunjavacard directory, so that when the stub file is created, it does notcreate an extra comsunjavacard directory.3. Create the jar file for the entire directoryThe command is,C:java_card_kit-2_2_2samplesNewCardSmartGridbinclassescard>jar –cf cardframeTest.jarcomsunjavacardcardClientPkg4. Put the jar file in the directory JC_HOMElibcomsunjavacardcardServerPkg5. Check the batch file created to run the client, RemoteCardClientBatch.bat (refer tocode listing in Appendix A.1.1). The batch file should contain the correct classpath forthe above jar file.set JC_RMICPATH=%JC_HOME%libbase-core.jar;%JC_HOME%libbase-opt.jar;%JC_HOME%libjcrmiclientframework.jar;%JC_HOME%libcardframeTest.jar;%JC_HOME%libapduio.jar;%JC_HOME%samplesNewCardSmartGridbinclassescard;%JC_HOME%samplesNewCardSmartGridsrc_cardclient
  • 91. 80Chapter 4 – Detailed Software Design and Implementation _%JAVA_HOME%binjava -classpath %JC_RMICPATH%;%CLASSPATH%com.sun.javacard.cardClientPkg.CardClientClass %16. Run the tool, cref (which runs the java card runtime environment) and save theEEPROM image of the simulated card in a output file.C:java_card_kit-2_2_2samplesNewCardSmartGridbin > cref -o eecardsave7. In another window, while the cref is running, run the following command to install theJCRMI applet on the card. The input file is the script file,RemoteCardSrvrAppScript.scr (refer to code listing in Appendix A.1.3). The outputfile is the file, RemoteCardSrvrAppScript.scr.cref.out (refer to code listing inAppendix A.1.7).C:java_card_kit-2_2_2samplesNewCardSmartGridbin>apdutool –nobanner -noatr RemoteCardSrvrAppScript.scr> RemoteCardSrvrAppScript.scr.cref.outAfter the script is run and the output saved, the „cref‟ tool is automatically powereddown by the powerdown command in the script file.8. In the next round, to start the RMI client-server interactions, start cref again with theinput saved file, eecardsave, which contains the EEPROM image of the previous run.This is because, since cref simulates the JCRE environment, starting the cref withsaved EEPROM image, simulates a card environment with the JCRMI applet loaded.Running the input batch file makes the applet active and the card and card clients startstalking to each other.C:java_card_kit-2_2_2samplesNewCardSmartGridbin > cref -i eecardsave9. C:java_card_kit-2_2_2samplesNewCardSmartGridbin>RemoteCardClientBatch.bat > RemoteCardClientBatch.scr.cref.out10. It is very important to note that, at step no. 7, is where all execution had to be stopped.The JCRMI applets were not loaded or installed. So, the next steps of no.s 8 and 9could not be followed. The execution was run a number of times. For the first fewtimes, it was okay, but finally there was error in applet loading and due to timeconstraints, the execution was terminated.
  • 92. Chapter 4 – Detailed Software Design and Implementation _Let us examine the input and out files. The input file is RemoteCardSrvrAppScript.scr(refer to code listing in Appendix A.1.3). The installer applet is installed as usual at thebeginning.echo "THE INSTALLER APPLET IS BEING SELECTED NOW.";// Select the installer applet0x00 0xA4 0x04 0x00 0x09 0xa0 0x00 0x00 0x00 0x62 0x03 0x01 0x08 0x01 0x7F;// 90 00 = SW_NO_ERRORThen after installation of system components, the JCRMI applet has to be loaded.The applet AID - 0x0b 0x00 0x00 0x00 0x62 0x04 0x01 0xc 0x8 0x01//create RemoteCardSrvrApplet0x80 0xB8 0x00 0x00 0x0c 0x0a 0x0b 0x00 0x00 0x00 0x62 0x04 0x01 0xc 0x8 0x01 0x00 0x7F;The create applet command in this particular case can again be better understood by thefigure below,Fig 4.2.2.2d: Create applet command structure for the rmi applet.If we study the output file, RemoteCardSrvrAppScript.scr.cref.out (refer to code listing inAppendix A.1.7),THE INSTALLER APPLET IS BEING SELECTED NOW.CLA: 00, INS: a4, P1: 04, P2: 00, Lc: 09, a0, 00, 00, 00, 62, 03, 01, 08, 01, Le: 00, SW1: 90, SW2: 0081
  • 93. 82Chapter 4 – Detailed Software Design and Implementation _The SW1 and SW2 values of 90 and 00, implies that the installer applet was loadedperfectly.REMOTECARDSRVRAPPLET APPLET IS CREATED NOW and BEING INSTALLED ON THECARD.CLA: 80, INS: b8, P1: 00, P2: 00, Lc: 0c, 0a, 0b, 00, 00, 00, 62, 04, 01, 0c, 08, 01, 00, Le: 00, SW1: 64,SW2: 43The SW1 and SW2 values of 64 and 43, implies that “applet not found for installation”.This became an intermittent failure initially, and then became acontinuous failure, and it is also a major failure. The executions were re-tried bymodifying the environment, re-installing java card platform, re-writing the code, but to noavail. Due to this reason, further code was not written for the JCRMI classes for the applet.Since, without the applet being loaded on the card and consequently, no communicationbetween the card and card client, there was no option of testing the code.It is to be noted that, in both the methods of communication, messagepassing model and JCRMI, there were quite an abundant number of problems, which hadto be solved on a case by case basis, and which were time-consuming, especially due tolack of exhaustive and comprehensive documentation for java card applicationdevelopment.4.3 Difficulties faced, Efforts made and Way forward4.3.1 Difficulties facedThe implementation of the card client application and the card applets was attempted injava card v2.2.2 development kit of Sun Microsystems. During the implementationprocess, there were certain difficulties, faced in the different steps of installation,configuration, running of different tools including the java runtime environment simulator.Some of the snags and technical hitches could be solved, but it was very time consuming,owing to the lack of sufficient resources in the java card application development field.The areas of difficulties are listed and explained in the following sections.
  • 94. 83Chapter 4 – Detailed Software Design and Implementation _4.3.1.1 Mostly vendor-specific development kit and toolsAs already mentioned number of times before, in the previous sections, the tools suppliedby Sun Microsystems has its own snags and hitches and there is no easily available properdevelopment toolkit. The toolkits that are available in the market are by specific vendorsand they generally target specific smart card platforms, which are again generallymanufactured by the same vendors or their partners. The most popular toolkits which weretried out were as follows:1. Developer Suite v3.0 by Gemalto (one of the largest smart card manufacturingcompanies) - The toolkit [38] targets the following types of smart cards, (given withtheir compatible java card versions in parantheses, USIM card R6 (Java card 2.2.1),USIM card R5 (Java card 2.2.1), Sim card R5 (Java card 2.1.1), Sim card R99 (Javacard 2.1.1), R-UIM card (2.2.1). The tool was evaluated and found that the free trialversion of the toolkit, does not support any card type except one, and that too, almostall its functionalities are disabled.2. Sm@rtCafe Professional edition 2.0 by Giesecke & Devrient GmbH (leading supplierof smart card solutions in Healthcare, Identification etc.) – The toolkit [39] simulates ageneral, platform-independent java card, however, its free trial version crashed quite anumber of times during its evaluation and hence had to be abandoned for further use.Both of them are expensive, in their market-ready versions, and hence could not bebrought under the scope of this project. Sun Microosystems‟ development kit does notcontain any user friendly tools to create the java card applications. In the commercialmarket, each vendor provides it own java card development environment and alsoproposes its own specific solutions for Java card [41]. Also, since the market for smartcards is still very small compared to other java technology markets, and also a closedmarket, it becomes increasingly difficult to find free alternatives for java carddevelopment tools [42].
  • 95. 84Chapter 4 – Detailed Software Design and Implementation _2. Lack of extensive documentationThough there are specifications‟ documentation available from Sun Microsystems, andtechnical discussions in Sun‟s Developer Forums, still the documentation is notcomprehensive and in some cases, quite sketchy. This is in far contrast with that availablefor Sun core Java, J2EE, J2ME, C, C++,Microsoft Visual C++, .Net, C#, COM, CORBAetc, or any other commonly used technologies, for that matter. Due to its vendor-specificnature, the java card programming in the professional world is mostly carried out usingtools and IDE specific to different vendors, so general documentation is comparativelyscarce.3. Deficiency in collaboration and networkingThe java card developer‟s forum is available only in Sun Microsystems‟ website. Thereare not any other popular and useful developer forums, specifically on java cards. There isserious shortage of collaboration and networking sites and blogs for java carddevelopment, much less compared to that available for other technologies. This restrictsthe problem solving capabilities of developers by networking and participating indeveloper forums and networking sites and blogs.4. Complexity in the technology – not purely object-orientedThe java card technology has some very important drawbacks – such as it is not purelyobject-oriented. The smart card communication is based on APDU, which are logicalpackets of data and are represented in hexadecimal format. It is quite complex andrequires meticulous checking of the script files that contain them, so that there is no errorin the communication between the card client and the card. Secondly, it is also not exactlyplatform independent. Third, the simulator and the tools are not easily configurable anduser-friendly.Due to all of these reasons, the java card application softwaredevelopment process faces bouts of time delays. A developer encounters a problem andhe/she does not know where to look for, since documentation and online resources arelimited. Sometimes, you get stuck by a snag, but, you have to spend weeks to solve it [43].Hence, sometimes, the development process gets tedious and frustrating. Taking all this
  • 96. 85Chapter 4 – Detailed Software Design and Implementation _into account it is clear that the development of java card applications needs to be uniform,platform independent, and should be done in a controlled, systematic, well defined,rigorous way.4.3.2 Efforts madeDuring the entire project, every effort was made to ensure that the applicationdevelopment follows clearly the designs made. However, due to the factors describedabove, all through the way, considerable numbers of problems were faced. Due to lack ofproper documentation, as described before, solving some of these problems and errorsconsumed a lot of time, and hence, during the application development process, theproject could not follow the stipulated milestones and deadlines.For example, one error worth mentioning here is the “Unsupported fileformat” error. This occurs when the CLASS files were being converted to CAP files byConverter. There is no mention of this error in any of the standard documentations.Finally, a solution was discovered, from one of the discussion topics in the Sun developer‟sforum.This can be solved only if the JAVA files are compiled using jdk/jre v1.3.4.3.3 The way forwardIn this project, the java card application development was attempted on SunMicrosystems‟ development kit to develop a platform independent application for gridcomputing. But, in the present stage of java card development, it can be safely assumedthat we need to be dependent on some of the existing smart card platforms (by differentvendors), to move forward. So, the way forward would be to use a standard simulator andIDE like, the Developer Suite [38], from Gemalto, possibly, the world‟s larget smart cardmanufacturer, or from Schlumberger smart card solutions, or from Motorola or Siemens.Also, there is the need to use real smart card hardware, for practical tests on the java cardapplication.
  • 97. 86Chapter 5 – Conclusion _5. ConclusionThe research project aimed in improving to a high extent the credential managementsystem, to be more specific, the credential repository of a grid computing system, byincorporating the smart card in the grid and thus in effect, creating an authenticationsystem too, for the grid user. The aim was to create a platform independent, vendor-independent, smart card or java card software solution for grid computing. Due to thepractical complexities involved in the development of java card application, which is quitecomplex compared to the other java technologies, a high number of constraints had to befaced, as described in the previous sections, and the experiments had to be terminatedmidway and the intended design and plans could not be implemented or carried out to thedesired extent. However, it would act as the stepping stone to a lot of future work.The Java card platform is both a hardware architecture and softwareplatform. The next generation java cards will provide hardware solutions. They will beusing a USB connection that suppresses the need for specific reader and supports highspeed communication. Second, very powerful processors with multithreaded OS areplanned. These cards will provide a TCP/IP stack that will make them directly accessibleon the network. These cards will also implement communication model in which cardswill be active, and everything would be object-oriented. So, it would be easier to carry theproject forward.In the search for better Grid security practices, the designs proposed herehave been created after carefully studying the existing technologies and their pros andcons and analysing the related research work the world over. This can pave the path forbigger projects, which would definitely be fields for high financial investments. Thepossibilities are endless. The future work involved would be,1. Using standard simulators and IDEs from different vendors and testing the applicationon a number of platforms, to make sure it maintains cross-platform operability,because the grid is essentially cross-platform.2. To verify the development phase on Sun Microsystems newly released Java card 3.0specification. It has been released, as of now, when the paper was being prepared.3. Verify it on the real smart card hardware of different vendors.
  • 98. 87Chapter 5 – Conclusion _4. Try to integrate the smart card application with the Grid Security Services Simulator(G3S) [36], or, any other standard grid simulator and also Globus and the like, toprove its portability in grid computing environment.If these future steps are carried out, there would be chances of highsuccess, to have a safer and secure Credential repository and authentication system in Gridcomputing.
  • 99. 88Appendix6. References and Bibliography1.GRID today (www.gridtoday.com www.gridtoday.com), “SMART CARDS: WILLTHE STANDARDSMAKE IT PART OF THE GRID?”, October 2002, Special Features, Vol.1, No.19.2. S. Chaumette, K. Markantonakis, K. Mayes, D. Sauveron, "The Mobile Java CardGrid Project", 2005, Proceedings of the 6th International Conference e-Smart05, Nice,France (2005) e-smart 2005 award for the best innovative technology.3. S. Chaumette, A. Karray, D. Sauveron, “The Software Infrastructure of A JavaCard based Security Platform for Distributed Applications”, 2006, Proceedingsof the 8th International Conference on Enterprise Information Systems (ICEIS 2006),4th International Workshop on Security in Information Systems: WOSIS 2006,Paphos, Cyprus (2006).4. S. Rau, “The Trusted Computing Platform Emerges as Industrys FirstComprehensive Approach to IT Security”, February 2006, IDC Executive Brief.Program Manager, Trusted Computing Group (TCG).5.https://www.trustedcomputinggroup.org/home/www.trustedcomputinggroup.org/hom e(retrieved in February 2008).6. M. Williams,“NTT DoCoMo to offer credit card payments by handset”, August2005, Network World, IDG News Service.7. IBM RedBooks Paper, “Introduction to Grid Computing”, 1st edition, December2005.8. Chakrabarti, A. (2007), Grid Computing Security, 1stEdition, Springer publications.9. Jose V. Ortega, Smart Card Security”, Texas Wesleyan University, USA.10. D. Kouril, L. Matyska, M. Prochazka, "Improving Security in Grids Using the SmartCard Technology", Sep 2006, 7th IEEE/ACM International Conference on GridComputing. CESNET, Czech Republic.11. L. A. Mohammed, A. R. Ramli, V. Prakash, Mohamed B. Daud, "Smart CardTechnology: Past, Present, and Future", April 2004, International Journal of TheComputer, the Internet and Management publication, Volume 12#112. Sun Microsystems, "Development Kit User‟s Guide, Java Card Platform, Version2.2.2", March 200613. IBM RedBooks Paper, “Enabling Applications for Grid Computing with Globus”,June 2003.
  • 100. 89Appendix14. J. Novotny, S. Tuecke, V. Welch, “An Online Credential Repository for theGrid: MyProxy”, 2001, Proceedings of the 10th IEEE Symposium on HighPerformance Distributed Computing, 2001.15. S. Chaumette, D. Sauveron, "A High Level Security Framework for the Grid:The Java Card Grid TestBed", May 2006, 20thEuropean Conference on Modellingand Simulation ECMS 2006, Bonn, Germany.16. S. Chaumette, P. Grange, A. Karray, D. Sauveron, P. Vignéras, "Secure distributedcomputing on a Java Card Grid", April 2005, Proceedings of Parallel and DistributedProcessing Symposium, 2005, 19th IEEE International.17. Smart Card Group Ltd., “Smart Card Tutorial”,(www.smartcard.co.uk/tutorialindex.htmlhttp://www.smartcard.co.uk/tutorialindex.html) (retrieved in January 2008).18. G. Bella, S. Bistarelli and F. Martinelli, “Biometrics to Enhance Smartcard Security”,Computer Laboratory, University of Cambridge, UK, Dipartimento di Matematica eInformatica, Universit`a di Catania, Italy, Dipartimento di Scienze, Universit`a “G.D‟annunzio” di Chieti-Pescara, Italy, Istituto di Informatica e Telematica, CNR, Pisa,Italy.19. L. Bechelli, S. Bistarelli, and A. Vaccarelli, “Biometrics authentication withsmartcard”, August 2002, Technical Report 08-2002, CNR, Istituto di Informatica eTelematica, Pisa, 2002. Istituto di Informatica e Telematica (IIT), CNR Pisa, Italy.Area della Ricerca di Pisa, Via G. Moruzzi 1, I-56124 Pisa, Italy.20. E. Atallahy, S. Chaumette, F. Darrigade, A. Karrayz, D. Sauveron, "A Grid of JavaCards to Deal with Security Demanding Application Domains", September 2005, 6thedition of e-Smart conference & demos, Sophia Antipolis, French Riviera – 2005.21. S. Chaumette, D. Sauveron, "An efficient and simple way to test the security of JavaCards", May 2005, Proceedings of the 3rd International Workshop on Security inInformation Systems, WOSIS 2005, in conjunction with ICEIS2005, Miami, USA.22. T. Ravishankar, F. Tournier, T. Violleau, "Java Card Platform Evolution: FutureDirections", 2006, JavaOneSM conference, Sun‟s 2006 Worldwide Java DeveloperConference.23. C. Enrique Ortiz, “An Introduction to Java Card Technology”, May 2003, SunDeveloper Network, Technical Articles.24. Dr. Raúl V. Ramírez Velarde, "Security and Smart Cards", June 2007, Lecture Notesat Universidad Carlos III Madrid, Spain.25. Sun Microsystems, "Virtual Machine Specification, Java Card Platform, Version2.2.2", March 2006.
  • 101. 90Appendix26. Sun Microsystems, "Runtime Environment Specification, Java Card Platform,Version 2.2.2", March 2006.27. Sun Microsystems, "Application Programming Notes, Java Card Platform, Version2.2.2", March 2006.28. Sun Microsystems, "RMI Client Application Programming Interface, Java CardPlatform, Version 2.2.2", March 2006.29. Ed Ort, “Developing a Java Card Applet”, Aug 2001, Sun Developer Network,Technical Articles.30. Ed Ort, “Writing a Java Card Applet”, Jan 2001, Sun Developer Network, TechnicalArticles.31. H. Yu, X. Niu, D. Ma, C. Shen, “Research on Applying Java Card to DatabaseEncryption Systems”, 2006, Proceedings of the 2006 International Conference onIntelligent Information Hiding and Multimedia Signal Processing, IEEE ComputerSociety.32. C. Mitchell, "Trusted Computing:Putting a security module on every desktop",March 2007, Seminar: New Zealand Information Security Forum, Auckland, NewZealand.33. A. Martina, P. Yaub, "Grid security: Next steps", January 2007, InformationSecurity Technical report, Volume 12, Issue 3.34. N. Shillington, T. Waker, "The Design of a Smart Card Interface Device",Data Network Architectures Laboratory, Department of Computer Science, Universityof Cape Town, South Africa.(www.cs.uct.ac.za/Research/DNA/SOCS/rchap4.html)www.cs.uct.ac.za/Research/DNA/SOCS/rchap4.html(retrieved in February 2008).35. T. Warmbier, “New generation Java smart cards”, March 2004, CardTechnology Today, ScienceDirect, Volume 16, Issue 3..36. S. Naqvi, M. Riguidel, "Grid Security Services Simulator (G3S) – ASimulation Tool for the Design and Analysis of Grid Security Solutions", December2005, Proceedings of the First International Conference on e-Science and GridComputing, 2005.37. J. Basney, W. Yurcik, R. Bonilla, A. Slagell, "Credential Wallets: A Classification ofCredential Repositories Highlighting MyProxy", August 2003, 31st ResearchConference on Communication, Information and Internet Policy (TPRC 2003),Arlington, Virginia, USA.38. Developer Suite documentation, "Developer Suite v3.0”, July 2007, Gemalto, CEDEX,France.
  • 102. 91Appendix39. Sm@rtCafe Documentation, “Getting started with Sm@rtCafe Professional Edition2.0” Giesecke & Devrient GmbH, Munich, Germany (www.gieseckedevrient.com).40. Dr. Monica Cortes, "Basic Security mechanisms and services”, May 2007, LectureNotes at Universidad Carlos III Madrid, Spain.41. Wojciech Mostowski, “Rigorous Development of JAVACARD Applications”, March2002, Rigorous Object Oriented Methods Workshop, London, U.K.42. Igor Medeiros, “Java Card Development Kit, Make your Choice”, Igor Medeirossblog,(http://weblogs.java.net/blog/igormedeiros/archive/2007/05/java_card_devel.html)(retrieved in March 2008).43. Sun Developer Network, “Consumer and Commerce - Java Card”, Developer‟s forum,(http://forum.java.sun.com/forum.jspa?forumID=23), (retrieved in March 2008)