Of JavaCard 3.0 and things to come

Heuze's blog on smart card tech (especially development and standardisation) has a post discussing JavaCard 3.0. Among other things, he suggests that multithreading in smart cards might be useful, but I'm not sure that multithreading is a desirable (if even workable) feature for a smart card OS. Smart cards are currently only required to cheaply and securely store data, and this functionality determines the on-card resources and application environment. If new technology came out which allowed very inexpensive extension of card resources (e.g. 20+ MHz CPU, 500+ KB RAM) then a whole range of new options would appear.

A killer app would be where the smart card serves as the consumer's PC-in-a-wallet, carrying all their personal details, their cryptographic identification data (logon and authentication) as well as personal preferences and settings for configuring client services (web sites, etc). This data would be accessable via a standardised framework, independent of the system or service used by the client. Of course, this raises the spectre of standardisation again...

Extending this idea to m-commerce follows naturally: secure, transparent, over-the-air/contactless access to your securely stored personal data in your mobile device is something that would be attractive to consumers.

Windows Secure Logon with Smart Card

In my work I use an Omnikey (Gemalto now) 5321 Contact/Contactless smart card reader, and noticed that Windows XP automatically detects it as a secure logon device. This got me wondering how to deploy a Windows driver and user application which would communicate with the smart card whenever it's inserted. The first questions coming up in my mind are:

1. Does Windows even allow a custom, unsigned user application to be registered to handle a smart card? Surely this would compromise the logon system's security...
2. If it doesn't, what are the options? Microsoft's proprietary smart card applet and logon infrastructure?
   

Answers:

Google right away gave hits from Windows Hardware Developer Central where I found the answers to the above questions. Smart Card and Biometric Devices – Architecture and Driver Support:

To work with the smart card support in Microsoft Windows operating systems, smart card readers and cards should be compatible with Interoperability Specification for ICCs and Personal Computer Systems. Smart card readers and device drivers should also be Plug and Play compliant.

Microsoft Smart Card Minidriver specification v6.2:

Smart card vendors can write card minidrivers to present a consistent interface to their smart card type to the Microsoft Smart Card Base Cryptographic Service Provider (CSP) or Crypto Next Generation (CNG) Key Storage Provider (KSP) and to the Smart Card Management Interface. These card minidrivers plug in to Windows operating system code. The functionality in a card minidriver is narrowly scoped and carefully defined so that the card-dependent code is simple to implement and easy to verify functionally.

More information was forthcoming about Smart Card Drivers from Windows Embedded Developer Library and Smart Cards from MSDN. (Edit: I also found a general overview of MS smart card integration and various subsystems.) This private blog about Smart Card infrastructure in Windows provides useful tips and addenda which might not be easily accessable otherwise. However, I think I'll start with these cookbooks from Microsoft TechNet on integrating smart cards as authentication devices.

Edit: info about the MS authentication function library.

On matters Java Card

Vetilles' blog on Java Card, smart card and privacy related topics is very useful for both novices and experts in the field.

GNU C extensions

GNU C has many extensions which make the programmer's life easier-... or not. But the resulting code is more efficient! One of these extensions is the compiler attribute preceding a function header specifying certain function behaviour. For example, a function can be forced to always be compiled inline with __attribute__((always_inline)). More than one attribute specifier can be used within the parentheses; full attribute syntax can be found here. Attributes can also specify the way the compiler treats types and variables.

Contiki employs attributes in its protothreading system (see core/sys/pt.h) for specifying return addresses via labels (core/sys/lc-addrlabels.h). The preferred alternative is a coroutine-based method (/core/sys/lc-switch.h) using switch-case control structures and the __LINE__ C macro.

Least I Could Do

RFID firewall

A quick description of RFID Guardian, a firewall for RFID tags. Development was done using the Triton PXA270 (Intel Xscale) devkit. Homepage of the project is here.

LayerOne 2007

Instructive and funny video from LayerOne 2007 about commonly used physical access control technologies. The Wiegand, proximity and RFID protocols are covered, with the focus being on hacking a common Wiegand implementation (28:50). An honourable mention must be made of the concealed bar-code card as being one of the most "embarrassing" attempts at security through obscurity. (As the presenter said: "If you ever find out someone working for you implemented such a system, fire them. Then shoot them so they don't infect the rest of us.")

More good talks focussing on privacy matters: RFIDiots and Anti-Forensics.

Linux talks

Videos from the Embedded Linux Conference, Mountain View, USA, Apr. 2008 are now available. There is a vast array of topics, including "Every Microamp is Sacred - A Dynamic Voltage and Current Control Interface for the Linux Kernel", "Using a JTAG for Linux Driver Debugging", and "UME - Ubuntu Mobile and Embedded". Site seems to be slashdotted for now, but hopefully it'll get back to its feet soon.

The cruise starts

One of my projects involve dynamic updating of kernel code on sensors running the Contiki OS. It seems there are many ways to do this, as shown in this presentation and supporting .pdf by Adam Dunkels et al. The Contiki layers and linking relationships are explained in detail in this and this document.

Wikipedia has a good overview of ELF, a very popular structure for dynamically linked modules. A hallo-world example from LinuxJournal (1995) is also a good starting point. This excellent tutorial shows how to use ELF when compiling really small ASM files (includes a specification of ELF), while this site explains in detail how the ELF structure is implemented using C libraries.