smartcard practicalities |
project work |
Group project: JavaCard smartcard development
Groups spring 2017
||Reader & card
||1st version report
||2nd version report
||Joost van Dijk,
| - & B1,3
|R4,H8 & B2,4
Javier Gil Pascual
|R3,H9 & A11,12
Wouter van der Linde
|R2,H1 & A10, J2
Finn de Ridder
|R1,H7 & A8,7
Amber van der Heijden,
|R9,H2 & A5,6
Jose Luis Torre Arce
|R8,H10 & A3,4
|R7,H5 & A1,2
|R10,H17 & J3,6
|R5,H16 & JD5,8
Form a group of 4 people from one university, pick one of the cases as your group project. Inform us of your group by email and obtain a smartcard and reader for your group.
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
We have written up a document about the JavaCard project [PDF]
with hints and tips, esp. about documenting your design.
It is based on the experiences of previous years when we taught
the same course. Read it carefully and check it regularly during
the project, and use it as a checklist for the project reports
before handing them in.
First step in the project: think about
and write this up in a few pages (8 pages max, but you should manage in less).
N.B. an important challenge is in writing this up as clearly
and concisely as you possibly can.
- Use cases (options);
- Assets and stakeholders involved;
- Security requirements this results in, in terms of
confidentiality, integrity, authentication (mutual or one-way),
- 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
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.
- authentication of card by terminal,
- mutual authentication between card and terminal,
- proving authenticity (integrity) of some data,
- ensuring confidentiality of some data, etc.
- 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
Go ahead and build it.
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!