Hardware and Operating Systems Security, autumn 2011

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

Groups

First step

• Use cases;
• 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: ie. who might attack the system, what would they want to achieve, and what are your assumptions about what they can or cannot do.
• High level design - incl. use of passwords, PIN codes, crypto (key management and security protocols) to meet the security requirements.

Hints:

• Don't forget that in addition to the obvious terminal applications that are needed and are mentioned for each project (eg. cash register, petrol pump, ...) , there will be additional functionality needed to "personalise" the cards, which typically involves uploading/generating keys. For this you may need some personalisation terminal, which is used by the card issuer prior to handing out cards.
• 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 boring detail, give concise descriptions of their goals (eg. challenge-response protocol to prove knowledge of key X, some key-exchange to establish a shared secret key X.)

On September 26 each group presents this high-level design and we discuss these. We have 15 minutes per group incl. discussion so aim for a lot less, say 10 minutes presentation max. Your presentation should at least explain who has which keys and how these are used in the central use cases. Possible set-up for you presentation

• list the main "use cases" (eg charging, buying, paying, pumping, driving, renting, returning ... depending on the project) and the stakeholders/parties (eg customer, card, bank/government, ...) involved - just to fix terminology and make sure we all have a similar understanding of what the project is about.
• give overview of the key set-up and distribution of keys across the various parties, incl. the smartcard (ie. who knows which keys?).
• give an overview of the information stored on the smartcard
• for at least one of the use cases (or more, if you think you have time) sketch how all this comes together in the protocol for that use case, and how this achieves the important security requirements (wrt. authentication, confidentiality, integrity, etc.)
• maybe mention any important assumptions that you made.

On October 3 each group hands in their written analysis and high-level design, to give another week for some tweaking in response to the discussions. Don't make this any longer than it needs to be.

Second assignment (per group) - delivering the project

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 think of better ways to do things.

• Deadline for the source code: December 5. (TO BE CONFIRMED)
  Email a tar.gz or zip to Joeri de Ruiter.

• Deadline for the report: December 12. (TO BE CONFIRMED)
  Email a pdf (no .doc !!) to Erik Poll and Joeri de Ruiter.

  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: ie. 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!

Third assignment