[OT] DT-3500 Brainstorm UPDATED

This will be very geeky. Don't bother reading it unless you want to. Any actual useful releases etc will happen elsewhere. Here are my notes thus far (NOTE: I have very little actual experience with this at this point so take it with a grain of salt please):

Windows

Just need to get my hands on Visual Studio again so I can poke around. I haven't bothered yet. pcscd emulates the winscard API so we should be source compatible if we're careful.

Mac

Smart cards on the Mac are supported by pcscd, included in the install. MuscleCard can sit on top of pcscd and provide access to the card in a platform agnostic manner, but only if the card supports the MuscleCard applet (not likely).

There is a "mac" driver for the Mako Infineer DT-3500 here, but it seems to involve a kernel module for linux. Sources are also found on that website. Hopefully the pcscd that comes with OS X will simply recognize the reader. (it doesn't)

We will have to write our own driver for pcscd to deal with our cards. This is not as horrible and low level as it sounds. I'm currently USB bus snooping to see what the Respironics driver is doing with the card and reverse engineering its behavior. When I'm done, we should have an open source driver that compiles on both OS X (PPC + Intel) and Linux that allows the cards to be read using pcscd. Once we have that step accomplished, we can begin writing our code to interface with it.

pcscd is API compatible with the Windows PC/SC API, meaning the code for accessing the data on the card should be the same on all platforms if we're crafty! If not, it'll be really really close. :-) The driver I'm working on will allow us to get at it normally.

Linux

Access to the smart card will work exactly as it does in OS X, which is via pcscd. It appears at this point that we'll get Linux support "for free" as long as I'm relatively compiler agnostic. To install dev tools for pscsd on debian derivatives, "sudo apt-get install pscs-tools". The "Red Hat 9" driver on Mako's site is actually a pcsc bundle and could work on intel OS X at least as well with a little luck. Poking around the bundle yields an interesting copyright (Athena Smartcard Solutions).

-------------------------------

The Reader

The reader supports basically anything the smartcard wants to do. It's all going to depend on what is actually on the smart cards.

More info on the reader.

-------------------------------

Smart Cards in General

Many smart cards are not simply a store of data. The chip is actually a tiny computer that can perform operations (usually related to encryption). Information on interacting with this standard (ISO 7816-4) can be found here. Note that some cards do not support the full ISO standard.

Other smart cards are simply a disk.



Do be careful while playing with the cards:

MuscleCard Tutorial wrote:Upon receiving your smart card and reader it is important to first find your transport key. The transport key is a string of numbers used to lock the smart card during it's travel from the manufacturing site to the customer. The actual key itself is sent via other means such as mail so that if the truck is robbed during delivery the cards are worthless unless they have the transport key. You can try to randomize keys and verify them to the card but the cards will eventually destroy themselves after so many bad verifies. This is usually under twenty tries so good luck. Like a password you can change this key once you have verified the original transport key. This key is like a super user password. Functions like creating, deleting, or updating files cannot be done without this key.

(Not sure if we need the transport key to read the data from the card. Also, the machine may supply the transport key and unlock the card negating any concerns about this parcticular roadblock.)

Diagnostic tools:

• PCSC-tools

Filesystem



Master File is the root of the filesystem
Dedicated File is a directory
Elementary File can be one of four things, all of them being "actual data"

Goals

I think we should aim for having a tool that reads the card using pcscd or winscard depending on the system and outputs the data in a non-system-specific format. This format is up for debate. Any software that wants to access the SmartCard can then bundle a binary of this app and run it on the command line.

Likely format choices:

• - CSV file.
  - XML.
  - YAML.
  - An SQLite database (which would then be read from another program). Bonus here is programs like Encore Pro Analyzer would take a minimum amount of work to change their SQL syntax over. If they wanted to support directly accessing the card, they'd just call this code chunk from the command line and once it's done they can query the database as usual. If it were passed an SQLite database file that already contained data it would add to it, so the application wouldn't have to bother with merging or anything, it would just be running this tool pointing it at your database file and then querying to see the new data. According to jskinner, the database they're currently using to store the data is horribly designed, in which case we may want to start from scratch. SQLite still provides an easy way to perform queries on the data and means programs don't have to worry about parsing, byte order, etc.
  - MySql. I don't like this option because it means the users have to install MySql and something like SQLite would do just fine. We're not having 100 queries executing simultaneously or anything.
  - Support all of the above using command line switches.

(@jskinner, your thoughts on moving EPA to SQLite as the datastore?)
-------------------------------

This main post will be updated as I investigate more or as others make discoveries.

Worst case scenario is that Respironics wrote a custom OS that they're running on the smart cards. In which case we play with it and see what it has to tell us. Again, most likely, any data stored on the card will be accessible for reading using the standard SmartCard filesystem techniques and we can bypass the entire mess of dealing with the proprietary-ness because we're not interested in writing to the card.

CURRENT STATUS: I'm attempting to get the reader working on Linux since there is a linux driver for it. Currently not having any success. Once I get it working on Linux and talking to the card, then I need to compile the driver on OS X.

UPDATE: The reason this wasn't working is because we need to write our own driver for the reader because the Respironics smart cards are "special". That's my current project.

the key I was thinking about in the other post was the transport key.

Upon receiving your smart card and reader it is important to first find your transport key. The transport key is a string of numbers used to lock the smart card during it's travel from the manufacturing site to the customer. The actual key itself is sent via other means such as mail so that if the truck is robbed during delivery the cards are worthless unless they have the transport key. You can try to randomize keys and verify them to the card but the cards will eventually destroy themselves after so many bad verifies. This is usually under twenty tries so good luck. Like a password you can change this key once you have verified the original transport key. This key is like a super user password. Functions like creating, deleting, or updating files cannot be done without this key.

Yeah. The transport key is probably included in plain text in the respironics driver install or provided by the machine and/or driver the first time it's initialized. I'm not even going to begin researching how to write to the card because people should just be masking up anyway. If the key is only needed to write/modify, then we don't care. I don't even plan to support wiping the card, at least for now.

Remember, the harder they make it to access the card, the smarter their CPAPs have to be to write the data out. That gets expensive.

I can get my hands on a pc/sc Lite driver specifically for the USB Infineer DT-3500 for linux. With full source code if that will help you.

Also... if you haven't already seen it, there's this resource...

http://www.linuxnet.com/index.html

Lots of smart card tools there.

blarg, I think you need to do some more research on the different types of Smart Cards that exist. Not all of them contain a micro.

I don't care what types are out there except the one we care about. My software comes today so I should be able to poke around tonight. There's some weirdness going on somewhere because they made a custom driver. It could be that they just wanted to use their own interface to the card. We'll see.

Status:

We get to write a driver. It's not very bad with PC/SC helping us out, so I'm going for it. My project last night was getting dumps of the usb bus traffic to see how the reader is communicating with Windows.

I used Windows running in an instance of VMWare on top of Linux, and I grabbed the events using debugfs and usbmon in Linux. To do this, I enabled debugfs in my kernel (recompile), modprobe usbmon, mount the debugfs and cat out the events.

Windows is polling the device, so you'll see a lot of events that happen in a pattern and then one oddball message and response. That's what we really care about. For more info on the format of the dumps, check the Linux Kernel Docs on usbmon here. If someone has the time to write a script to parse these into something a little happier, I wouldn't be offended. lol.

Where does this get us? Well, the driver I'm writing has to send these control messages just like the windows driver does. So, knowing what you have to say helps. Next step is to play with the code for the already-written-but-doesn't-work-and-we-don't-know-why driver for the DT-3500 in Linux and see which functions are getting called when, and making sure we're sending the right messages over the usb bus.

Available Dumps:
Plugging in the reader
Plugging in a card to an already initialized reader
Removing the card
Removing the reader

Once we get PC/SC to send the right messages to the reader and it thinks it's successfully initialized, I'll start trying to get the green light to come on. Then we can worry about trying to communicate with the silly thing. The way I'll be writing the driver means this will work on OS X as well as Linux when I'm done.

Blarg,

I'm not a programmer, so about all I can offer is encouragement. I also have a Mac, and Windows computers with Vista, and XP Pro running, if you need help testing things.

Rick