Hardware Security

[ main | schedule | cases | smartcard practicalities | project work | side-channel lab ]

Group project: JavaCard smartcard development

Groups spring 2018

Preliminary steps

Once you have the hardware, make sure you can get the reader working, and that you can get an applet installed on the smartcard. As a first step you can try out the Chipknip terminal, on your own bank card, to see if the card reader works. Then install the Calculator applet on the smartcard and try this out with the Calculator terminal (see the smartcard practicalities subpage). Necessary links for software (the JCOP Eclipse plugin and a VM image with Eclipse with that plugin installed) will be emailed. Email Niels Samwel to confirm that you have this working!

First phase: Design phase

First step in the project: think about

• Use cases (options);
• Assets and stakeholders involved;
• Security requirements this results in, in terms of confidentiality, integrity, authentication (mutual or one-way), non-repudation, availability;
• Threats and abuse cases;
• Attacker model & Trusted Computing Base (TCB): describe what you assume attackers can do, ie. what are their capabilities and to which parts of the system do they have access. Also describe what you assume attackers cannot do, and which (parts of) systems, persons or organisations are in the TCB.
• High level design - incl. use of passwords, PIN codes, crypto (key management and security protocols) to meet the security requirements.

Email the report to Erik Poll and Niels Samwel by Feb 27. Include your group number both in the filename and the document itself, and all your names and which university you are from.

• Don't forget that in addition to the obvious terminal applications that are needed for each project (eg. cash register, petrol pump, etc.), you will need additional functionality to "personalise" the cards, which typically involves uploading/generating keys, setting card numbers, etc. For this you will need a personalisation terminal, which is used by the card issuer prior to handing out cards to the users (aka the card holders).
• The smartcards we use can do standard (a)symmetric crypto (DES, triple DES, AES, RSA) and hashing algorithms (MD5, SHA1), but don't get distracted by such details too soon.
• Before giving security protocols in all their detail, give concise descriptions of their goals, for example
  • authentication of card by terminal,
  • mutual authentication between card and terminal,
  • proving authenticity (integrity) of some data,
  • ensuring confidentiality of some data, etc.
  After stating the goals of protocol, before you come with detailed description of the protocol with message-sequence charts or in Alice-Bob style, you may still be able to give a more abstract characterisation of (parts of) it, eg.
  • a challenge-response protocol to prove knowledge of key K,
  • a key-exchange to establish a shared secret key S, etc.
• Your design document should be such that security expert (like one of your fellow students) can quickly convince him- or herself of the soundness of your design. No need to include any `sales pitch' advocating the use of smartcards as e-purse, car key, loyalty card, etc.
• Explicitly state any assumptions that you make, for instance on any component of the system (eg. petrol pumps, point-of-sale terminals, or cars).

Second phase: Building phase

Keep track of any design decisions you make along the way, and record where you deviate from the original high level design. This may happen because of technical restrictions, because you run out of time, or because you thought of better ways to do things.

Implementing the crypto can be time-consuming, and the nastiest to debug, so it may be wise to make a first implementation without (m)any of the cryptographic checks in place.

• Deadline for the source code: June 12
  Email a tar.gz or zip to Niels. Include your group number in the filename and use the following as the subject of the mail: [HWSec] Code - Group <group number>

• Deadline for the report: June 12
  Email a pdf (no .doc!!) to Erik. Include your group number both in the filename and in the document itself. Use the following as the subject of the mail: [HWSec] Report - Group <group number>

  The final report should be the first design document, updated to take into account my earlier feedback and any changes that happened along the way: i.e. mention any some shortcuts you took in the implementation - because of technical problems or simply meeting the deadline - and any further improvements you thought of only later or didn't have time to implement in the end.

  Keep the report short and to the point: 10 pages max or 8 pages if you use 2-column style. To get in the right frame of mind when writing the document, maybe it is useful to imagine you're trying to present your application to a technical expert working for the company or government that commisioned the application, and that you have 10 pages to explain the security requirements you identified and to explain how implementation in the end ensures these. Be frank about any limitations and shortcomings of your solution!