I am looking for some libraries in delphi to programming and reading from RFID cards. today I use normal Mifare 1k cards, and use a simple library to read the cards UID, but I would like to do more with these cards, like storing and reading from theire memory.
today my development uses PCSCconnector.pas library in delphi (PC/SC Interface component)
I am not sure if this is capable of doing anything more advanced other than just send code to return the UID number of my cards ?
if not, what else is there out there who can be used?
in a second note, can someone push me in the right direction on how to identify card types?. what kind of RFID card I am holding, what are the parameters, mifare 1k. 5k? java card etc etc ?
This doesn't exactly answer your question, but a few notes and hints:
The problem with Mifare 1k (all Mifare Classic cards, not DESFire, Ultralight etc.) is that they are proprietary. Reading the UID is a standard function, supported by all ISO14443-compliant readers. To read/write data, you need to have a reader with Mifare (classic) support.
This raises the question on what kind of reader you are using?
The protocol and algorithms were reverse-engineered, but NXP does not license the crypto algorithm (crypto-1) - means any open source library doing so (there might be some) is probably not legal.
Documentation for all other NXP Mifare cards is only available under NDA.
EDIT:
SpringCard does have a lot of diagnostic software tools available on their website as well as a lot of other PC/SC-related resources. I think it is mainly C++/C#-focused.
http://www.springcard.com/solutions/pcsc.html
PC/SC Diag for example is quite handy for some quick tests on a card.
Related
Which of MIFARE cards support a single block that can be programmed to require a password for writing, but is available to everyone for reading its data? And is such standard eligible on all platforms, specifically iOS. Can it use its NFC chip for doing both mentioned operations on such card?
There are quite a few products in the MIFARE product family1 that would allow write-protecting information with an authentication key/password (while at the same time having that information freely readable):
MIFARE Ultralight EV1: 32 bit clear-text password verification, password can be used as a write password (free read, "authenticated" write) or as read/write password (only "authenticated" read/write). The password cannot be set for a single block through, it's only possible to set one passwords for all blocks starting at a specific offset. Note that many of NXP's NTAG products also feature these capabilities.
MIFARE Ultralight C: Similar capabilities to the above, but with a stronger authentication mechanism using 2-key-TDES.
MIFARE Classic: Each sector can have separate keys. You always need keys for reading and writing.
MIFARE DESFire EV1: Not organized in blocks but in files. Each file can have multiple keys set for read protection and/or write protection. Hence, you could have a file that's freely readable but requires a key for writing.
Your second requirement, "is such standard eligible on all platforms, specifically iOS", is a bit more complex to answer: First of all, writing to NFC tags is not possible in iOS (except with some jailbreak?) Hence, I would interpret that as: What tags support write-protection and can be read with an iOS device?
iOS devices can only read from NFC Forum tags that already contain an NDEF message. Moreover, since the NFC Forum tag specifications do not (yet?) define a way to have authentication for accessing NDEF data, all data needs to be freely readable.
Hence, all of the above, except probably for MIFARE Classic, can be used. You will need to format the tags to contain an NDEF message.
For instance, you could use a Ultralight C/EV1 tag, store an NDEF message onto it and then set write-protection for the area where the NDEF data is stored (i.e. all pages >= 3). However, only adding write-protection for a specific block won't work. You may be able to craft your NDEF message in a way that the write-protected part sits at the end of the NDEF message at a block boundary of the Ultrlaight tag. Then you could add write protection for only that specific block (and all higher, but unused, blocks). Unfortunately, this opens up for potential manipulations on the size fields for the NDEF message (chopping off that write protected block from the data). Hence, partial write protection of the NDEF message might not be a good idea from a security perspective.
Similarly to the above, you could also use DESFire EV1. When used as an NFC Forum tag, the NDEF message is stored in a single file. Therefore, you could restrict writing to that file with an authentication key.
As iOS can't write to the tags, you will probably use another platform to write updates to the tags. Android, for instance, is capable of sending the low-level commands necessary for authentication to any of the above tags. Similarly, many PC based readers support this (though DESFire usually has better support there).
1) Note that there is other products (even from other manufacturers) as well that provide similar capabilities.
Have anyone worked with Zebra ZXP printers ?
I need to access the printer from Delphi, Feed one card to Contact reader, do some stuff with the smart card, then access the contactless chip, again do some stuff and, if everything is OK then do some printing, if there was an error with smart card the eject it without printing anything.
Some delphi wrapper for ZmotifPrinter.dll would be very nice :)
The ZMotif SDK can be used in Delphi: http://www.zebra.com/us/en/products-services/software/developer-tools/zmotif-sdk-zxp-series-8.html. Their SDK doesn't provide direct smart-card encoding functionality; rather, it allows you to position the card to the reader at which point the smart card encoder (which is PC/SC compliant) can be controlled from any other applicable library as if it were a standalone reader. Here is an example integrating their SDK with WinSCard.dll: https://km.zebra.com/kb/index?page=answeropen&type=open&searchid=1371214373330&answerid=16777228&iqaction=5&url=https%3A%2F%2Fkm.zebra.com%2Fkb%2Findex%3Fpage%3Dcontent%26id%3DSA280%26actp%3Dsearch%26viewlocale%3Den_US&highlightinfo=4194565,308,322#. Otherwise, their SDK does let you control printing functionality.
While this may be a poor answer for the StackOverflow format, you can definitely contact zebra's technical support for sample applications. They will almost certainly have sample applications for you in Delphi. You can reach them at card_sdk_questions#zebra.com.
This is a followup question to my earlier question: Read and Write Card Details using a Smart Card Reader
I have got the SDK and gone through the reference manual and sample code. But the SDK mentions very low level details like turning light on or off, sending APDU commands, etc.
My requirement is to read the card data like member name, membership no., etc. which is stored inside the card.
My client has arranged the SDK from the vendor, but I am still no better at reading the data inside the card. Can anyone suggest what should I do next?
Also, how to find out the type of the card, i.e. whether its a MiFare card, or other PICC Card? There is nothing on the card to suggest this way or that way.
Thanks.
Apparently the SDK concerns the reader. However, you need substantial additional information concerning the card itself. Nobody here can help without that information. Still then the provider of the card has to provide documentation, where the data you want to read is stored, and which access rights are necessary to do so, which keys to use etc. It is very optimistic to expect, that everything to be known can be found out by looking at the card. Sorry, but your question is currently an invitation to guess based on no facts.
Does anyone know where I can find one?
[Update] I have bought many SIM card readers from eBay and the software is always extremely poor. I would like to code my own - something like http://www.codeproject.com/Articles/16653/A-Smart-Card-Framework-for-NET
I intend to use such a cheap SIM card reader and simply write my own software. There appear to be only two major APIs. I just wondered if there was a component which handles them ...
I can't remember the name of those two APIs (one ... might have been ... Phoenix (?)), but anyone who can answer the question can.
I recommend you to head to this page.
You can find there valuable information about a DIY GSM Simcard interface and how to write a GSM Simcard emulator.
As far as I remember ASIM was written in Turbo Pascal but it's very instructive.
A delphi stock Serial communication will do I believe.
Edit:
I update the answer as suggesed the OP.
PMCAM2 is CAM soft emulator written in Delphi. It uses Phoenix interface to read ISO 7816 compliant smart card (Pay TV conditional access).
I am looking for SDKs which can do finger print matching. Rest of my code is mostly in C so I prefer if the SDK has C API's. Also it would be great if the SDK is free. Does anybody has experience with these SDKs and recommend any particular SDK? Also, while looking in these SDK what are the important features I should concentrate?
I've used two SDKs in the past, but only as a C# developer. Both the SDKs below say that they support C:
Griaule Fingerprint SDK (requires paid-for license)
Digital Persona OneTouch (free sdk)
A quick summary of features to consider:
Are you verifying that a fingerprint matches that of a known user, or identifying a user from a single fingerprint?
The Griaule SDK implements both Verify and Identify patterns.
DigitalPersona's free SDK only supports Verify - to Identify, you have to loop through all the fingerprints in your database and see which one matches best. They state that this is 'inefficient', but if you have very few users (< 200), it seems quick enough.
Adjustment of discrimination sensitivity (false positives/false negatives)
Balance up how closely a print must be identified. A high sensitity may cause a legitimate user's prints to be rejected, but a low sensitivity may match one users' prints to the wrong user. Assess the impact of each case and code accordingly.
The deployment overheads differed - the DP components came with a merge module, but I only recall seeing standalone installs for Griaule.
What fingerprint capture devices are you intending to support? Check very carefully that the SDK will support yours!
Check the licensing terms very carefully the Griaule costs can be substantial based on the number of clients you expect to roll out to.
The Griaule SDK required a license file be deployed, both on client and server.
DP (free edition) did not.
The .NET DP SDK came with a visually pretty, and easy to use, fingerprint registration dialog, but the version I downloaded (v1.4.0) had a bug with the fingerprint capture component taking up to 10 seconds to initialise. I don't know if this has been resolved yet. However, it was straightforward to code a bespoke UI.
Overall, I favoured the DP SDK, but it was a close-run thing. Basically, being license-free and better documented suited me more.
You can use Innovatrics IDKit PC SDK. You can get a free version for 6 months. This provides a C API as well as a C# API. I have been extremely impressed with this package.
If your platform is not a PC, there are packages for other platforms as well.
This is very useful with detail information about fingerprint integration with windows based software: http://www.codeproject.com/Articles/38881/Fingerprint-Reader-Integration-using-the-M-SYS-SDK This integration was using this fingerprint sdk. It solves problems with low level free sdks and also supports other biometric modality.
This is a really simple question, but the answer is really complicated. Most of the Free or at least royalty free matching SDKs are tied to a vendors fingerprint scanner. If you are wanting to use one of those SDKs you will have to commit to their scanners.
The next question is how is the software going to be used. Fingerprint matcher tend to fall into one of two categories, 1 to 1 or 1 to N. 1 to 1 is assuming you know who the user is and you want to just VERIFY their identity with a fingerprint. 1 to N searches through a database of users and finds them by their fingerprint. Depending on the size of your user population, if you are doing 1 to N you may need to confirm the performance of the algorithm first to ensure it will meet your needs.
The other option that you have is there are fingerprint scanners that do what is known as match on device. These scanners have embedded matching algorithms and databases that do all the work for you. You get all the licenses you need when you buy the fingerprint sensor. These are really useful in embedded applications.