ISLOG Development

Versioning and other things

2011-10-08T02:07:00.000-07:00

I like to see versioning as the project's foundation.

Whereas good versioning doesn't mean good development process, you can be sure that bad versioning means bad development process. Product version history can give you a good idea about a software development company quality and I thing it should be an important criteria if you're looking for outsourcing.

As an example, I will describe how we manage versions at ISLOG. Which I truly believe is far from perfect as we make improvement every month.

Most of our projects code is stored on SubVersion respositories. Those projects use the following version description:

[MAJOR].[MINOR].[SCM REVISION].[BUILD NUMBER]

Recently, we start to migrate projects to Git repositories that required changes to the version description (because of the Git distributed orientation):

[MAJOR].[MINOR].[MMDD].[BUILD NUMBER]

Where MAJOR number change rarely and MINOR number is incremented on each release.

Of course, as soon that a release is done, the SCM repository is tagged with that version to facilitate code browsing between versions when required.

The current development version is continuously built and tested thanks to continuous integration servers (Jenkins) which looks on code changes. Some native projects are multi-platform and have to pass successfully jobs on Windows CIS and Linux CIS before any release authorization.

Binaries files generated for tagged and development versions are stored on artifacts servers to be reuse independently on other projects. We mainly develop in .NET (C#) and C++ technologies. Maven is use for native projects, with Archiva as the repositories server. NuGet is use for .NET projects, but we have to do a lot of tricks to have snapshot repository equivalence (our hope is on the coming versions).

Every binary has a generated symbol file (pdb file).

That file is linked to the SCM revision and stored on a local Microsoft Symbols Server. Thus, if a project use an artifact as dependency and the developer want to debug the dependency code, symbol is retrieve automatically from the Symbols Server, code source revision retrieved from the SCM, and then displayed to the developer.

And the version regulate all this stuff.

New reader support: STid and Elatec

2011-03-07T00:27:00.000-08:00

Two new RFID readers are now supported into the development snapshot of our products.

- STid STR reader
A French RFID reader with nice cryptographic functionalities.

- Elatec TWN3 reader
Popular mainly into the German market, this reader exists for various RFID technologies.

DESFire EV1 support

2011-01-25T05:21:00.000-08:00

Oh god, it should be on the road-map since two years. I breathed deeply when I changed the ticket status to "fixed".

We always knew how the chip worked, but never had the time to implement it to the software. You could imagine how frustrating it was.

The RFID Suite 2011 version will support Mifare DESFire EV1, just like any other chip.

Windows Phone 7 and NFC

2010-10-19T08:39:00.000-07:00

I'm just back from a Microsoft Days event, with of course the current main Microsoft product at the top: Windows Phone 7. This event was technical and I could discuss shortly with one speaker.

The operating system looks great, performs, with good features. Nothing really new except good integration with other Microsoft product. Which it by itself already a big value.
You can quickly throw four limitation:
- Material is almost imposed by Microsoft. Due to performance.
- You can't create application running as "service", not shown => no code executed
- You can't develop outside DotNet with Silverlight and XNA. No native development, no other runtime or graphical engine.
- You can only deploy the application using the marketplace.

That means company deployment is not possible at this time.
That means innovation will evolve with Microsoft. Hope your physical and system component is already integrated, or even planned. Otherwise you're really stuck. NFC compability is not here, neither planned.

Nokia do research and works on it since more than two years, with already few available phone, Apple just released a NFC reader for iPhone and Google implements NFC technologies into the software through OpenNFC for Android system. Microsoft doesn't event think about it for the latest mobile operating system on the market... And the business can't do it by itself.
I don't know if this eight month old OpenNFC WM7 compability new is still true now. Seems difficult.

End-user is clearly targeted by Windows Phone 7, not the corporate user, and things will probably be unlocked later in the time when feedbacks will come. But time go fast and innovation doesn't wait.

Update January 07, 2011:

Other people can enable NFC on Windows Mobile 6.5 using a NFC sticker which communicate with the phone on bluetooth, see TwinLinx.

For important project under Windows Phone 7, nothing stop you to directly work with the phone manufacturer to add NFC hardware and specific native application. Only available for a minority, but better than nothing :)

Update June 01, 2011:

Windows Phone 7.5 "Mango" Updates should bring NFC support to Windows Phone. Let me see it.

Update October 08, 2011:

And it comes with Windows Phone 8... finally !

Custom format and new reader support: Prox'N'Roll and LGM5600

2010-10-18T08:31:00.000-07:00

Compatibility with two new readers:
- Prox'N'Roll reader: look pretty, and I really enjoy to develop on it. It is also the key to make our application Calypso compliant. (more info here)
- LGM 5600 reader: the main feature is the IP connection directly available through the reader. (more info here)

The big new for Arnaud and me, is the Custom Format availability (finally !).
You can create your own Access Control format without any additional development from our side.

More freedom is always better in this world :).

New reader support: Deister and RFIDeas

2010-05-07T01:30:00.000-07:00

One part of our job is to be compliant with majority of readers and chips on the market. We just end up Deister reader integration, from the German company, and RFIDeas reader integration, from the US company. We are glad to have those companies as new partner for our product today.

To refresh the list, here is what our products support (and is tested with) in the current development phase:

RFID readers:

Omnikey (5321, 5325, 6321, ...)
Cherry
SCM
HID SmartID
ELA
Deister
RFIDeas
All PC/SC readers

RFID chips:

Mifare Classic 1k/4k
Mifare DESFire
HID iClass (and so PicoPass)
HID Prox
Tag-It
iCode
Deister
EM4001
EM4002
EM4100
EM4102
EM4135
Indala
All ISO 15693 chips

I don't talk only about chip identification, but high level chip functionalities too.

There is convenient identification and secure identification

2010-04-26T00:42:00.000-07:00

Guess what? RFID is about identification. And yes it's in the name, even if some people who don't use RFID only for identification (vending ...) would like to change the acronym.
We identify object, animals and people with this technology since decades now. Where the business goes wrong is when it identifies human being in the same way than a cow. A livestock chip is used for logistic and traceability; a cow will not hijack your system to give you less milk. A smart card chip is used for access and traceability which engage responsibility. We talk about security here, and new rules must apply.

If you are in this page, maybe you already know these points and will find it trivial, but it’s the main things we have to explain to customers (even to big company):

Proprietary solution sucks: just because you don’t know how it’s working should show you a big red flag. People explain things which make them good, and hide the bad ones. Moreover you will be stuck with the product company owner.

Card Serial Number identification doesn’t mean secure identification: the CSN was created to manage collision, and in extension for poor identification. Anyone can capture and reproduce it with the appropriate tool.

Use encoded number: it’s a secure way to process (I will talk about asymmetric RFID system in another post); only you can create and read this number to identify people. It’s flexible; you can create / remove a card by yourself, and with the number of your choice.
Be up to date: chips look like software and most software need update to be efficient in time. 10 years old technologies are cracked now, the manufacturer already created the new chip generation.

Windows 7 and native 64-bit compatibility

2009-12-29T02:40:00.000-08:00

It's the kind of post I would like to do more often, and I think a good way to finish this year.
We worked hard to make the full ISLOG RFID Suite 2010 compatible with Windows 7 and associated User Access Control. Rights are checked now and even a limited user can use ReadCard software for exemple. Windows 7 try to find a driver for every card insertion, whereas that kind of stuff doesn't exist in RFID (thank to the contact smartcard world inheritance), an error message occures each time and it becomes quickly noisy. There is a temporary solution do disable this behavior on Microsoft website :

To disable Smart Card Plug and Play in local Group Policy, follow these steps:

Click Start, type gpedit.msc in the Search programs and files box, and then press ENTER.
In the console tree under Computer Configuration, click Administrative Templates.
In the details pane, double-click Windows Components, and then double-click Smart Card.
Right-click Turn on Smart Card Plug and Play service, and then click Edit.
Click Disabled, and then click OK.

The significant other change is native 64-bit support. All software are installed natively in 32-bit or 64-bit depending your operating system. It was a challenge for us and took a lot more time that what we thinked at the begining. But at the end, all readers (Omnikey, Cherry, SCM, ...) and all chips (HID iClass, Mifare Classic, Mifare DESFire, Tag-It, ...) supported in 32-bit are supported in 64-bit too. It worth it.

Dell embedded reader

2009-12-29T01:20:00.000-08:00

I will continue today about contactless reader topic.

It take a while now we have some interests on the embedded rfid reader available in Dell E-Family laptops. It was a huge evolution because now people own RFID reader by default just like wifi or bluetooth, without knowing what is it sometimes.
Thanks to HID Global, Broadcom and Dell companies, RFID software can be democratized.

After testing, the story was less funny: the reader doesn't work like standard PC/SC reader and it seems difficult to use it without proprietary SDK.
In fact the reader run in two modes which can be turn on/off to support PC/SC or not. Special thanks to Ridrix for his discovery.
Once you enable normal radio mode, you're on familiar ground and the good new is ISLOG RFID Suite already works with Dell embedded reader for Mifare Classic and Mifare DESFire chips too. We're currently unable to support HID iClass card on this reader without the SDK, will should be released soon I hope.

Cherry and SCM SDI010 readers

2009-12-28T15:44:00.000-08:00

Time is passing by so fast... already 4 months since the last post.

All our products just passed few tests, and are compatible with Cherry RFID readers and SCM SDI010 reader for Mifare Classic and Mifare DESFire chips. In fact we support those chips with all fully compliant PC/SC RFID readers which support ISO 14443 A and ISO 7816 (like Omnikey 5321, 6321, ... of course).
It seems trivial but it's a big design change, that almost guarantee you that any desktop RFID reader you plug on your computer will work with ISLOG software.
Again, standards have won.

Walkthrough on configuration card

2009-08-23T00:21:00.000-07:00

To not say "there are two kinds of people in this world", I will say that according to your job you see RFID system in different ways.
If you come from Access Control industry, for you the reader with the firmware do all the work. It establishes connection to the card, does the authentication, retrieves the identification number, and transmits this information to the access control system which decides if you have access or not. The first time you used a computer with a desktop reader, you attempted to find this same behavior, but it's not the same, intelligence is now on the software not on the reader.
If you come from Software industry, you live in a LEGO world where the OSI model is the old good king. For you the software do all the work. The first time you used an access control system (AC), you attempted that the reader was managed by the AC.

Anyway, in both cases, RFID software and access control, you meet the same problematic: how to manage sensitive configuration ? On a secure and private RFID environment, you have to deal with data location on the card and access key. Those information are critical.
For software, if someone else than the administrator use it, you can't just store information into a database or configuration file, an insider attacker would quickly break you down. You can't neither impose the configuration on code, it's too rigid and just a time's question before reverse engineering gets all your secrets ; even if sometimes at this day you don't really have the choice depending of your application purpose. Sure, you can let the user enter the configuration each time he wants to use your application, but it's a heavy process, and maybe your customer doesn't want that everybody know the security configuration... Moreover it sounds like "okay, I don't know how to manage this stuff, so let the user decide. If he write keys on a piece of paper I don't care, at least it's not my fault".
For AC, because readers are rarely managed by the AC unit, you can't make your configuration on the AC user interface. Most readers are only unidirectional, you have to set your configuration directly into the reader. Well, if you can only update the reader through connection cables with the appropriate tools, the customer must share his security decision with another company (the AC installer or the reader manufacturer). Because it's a heavy process too, you will think twice before updating a deployed facility.

One solution is to use configuration card.
Configuration card is loaded at the software starting up, it's a secure storage place and nobody could get sensitive information without physically own the card. It's flexible, the same application can use different configuration card. The customer control his security decision alone and updating readers is easy: you just put the configuration card at the front of the reader.
Because you use the configuration card without knowing what is on it, different people can create the card, and using it, you can delegate without breaking the security. You could also add PIN code to configuration card to ensure that only few restricted users can use it.
Some readers with configuration card support have a "reader configuration key" used to authenticate configuration card. That key must be changed before deployment, to be safe against malicious reader reconfiguration.

The bad new is there is no standard about configuration card. If you want to support a configuration card type, you have to contact the company who created it. Thus you can also create your own... whereas each configuration card type contains fundamentally the same informations. Interoperability ?

We develop, really

2009-08-17T13:34:00.000-07:00

Sometimes, people think we only use a SDK provided by the reader manufacturer and they can do all the work themselves. Of course they can it's not magic, but it will take longer (and cost more) that they think. I don't blame them, it's never fully wrote in some sentences, only the transmission protocol explains clearly the actors, or you have to read several hundred of pages. I want to clarify the architecture in a single short post.

First, you have the reader (the PCD). It support some ISO specification (ISO 15693, ISO 14443) at the transmission protocol, or a specific one. It also provide a way for developers to access this reader, through PC/SC, or specific API for example.

What you get when you buy a reader, is only the way to access this reader. Sometime you don't even have a document for PC/SC compliant reader, just go to the Microsoft website. But at this stage you can't do so much yet. Sometimes you have to implement yourself the transmission protocol.

You have to communicate with the card now (the PICC). The chip on the card also support some ISO specification for the communication level. The same one that the PCD and they can communicate between them. You need the chip command set to be able to do something on the card. Sometimes you can only do that through the specific reader API. Sometimes the chip allow different ways for the same behavior: specific command set for the chip, and ISO 7816-4 or ISO 15693-3 (with optional commands) compliant commands.

For example, internally we draw the full architecture for DESFire chip and associated reader like this schematic. Each block represents an implementation. This give us modularity and flexibility.

We spent months on reader and chip integration. We spent weeks on user interface creation.

Welcome back commander

2009-08-17T07:21:00.000-07:00

The company evolves, our products evolve, our strategy evolves. Now we think it's time to be more transparent. This blog is part of this vision.
The RFID industry don't talk so much with a software point of view except about ISO specification and few forums for non-professionals. We use access control system, biometric/rfid readers and cards every days, and now, you can fallow us.
Our customers, maybe you, have the right to know how we do our products, and most importantly, why we did it in that way.
Because what we do after all, it's software development.

Currently we are three writers on this blog: Arnaud H., Julien K., and myself (Maxime C.).

What we will discuss:

ISLOG's products functionalities
Access control, biometric and RFID subjects
Business stories
Pure technical development sessions with pieces of code

What we will not discuss:

Commercial topics, contact ISLOG by phone or email for that.
Daily mood

In other words: Welcome to this blog. Hope it will be useful for you.