WIP: support for Belgian eID cards #104
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
BELPIC (BELgian Personal Identity Card) is the official electronic ID card of Belgium. Start adding a virtual implementation of this card to vsmartcard. Not remotely there yet, but at least this runs without error already, and sends the correct ATR when asked. Beyond that... much TODO.
The BeID card does not allow the user to create extra files, so disallow when it is tried
Current BeID development tools work with XML files to represent the data on the card. Reuse that format, so that existing developers don't have to regenerate their cards (and so that a certain level of interoperability between those tools exists) We may add another option in the future, but that's not for now. Also, add the Belpic applet's AID as the DF name for the MF
Generated by <https://github.com/Fedict/eid-test-cards/tree/master/gen_virtual_cards>. TODO: generate it here, rather than there. Not for now.
(and trigger a travis build while we're at it) Signed-off-by: Wouter Verhelst <w@uter.be>
The basic VirtualSmartcard implementation parses and logs the APDU sent to the card in the execute instance method, and logs the received APDU after calling that method. The Relay implementation, however, overrides the execute method, but does not log it. The result, when running at the info log level, is that you see the reply from the card, but not the request from the application. This is confusing. Additionally, if the relay implementation shows the request APDU, then it can be used as a method to analyze what an application is trying to do. To remedy all that, parse the APDU and log that parsed value, but don't do anything further with it. Signed-off-by: Wouter Verhelst <w@uter.be>
Some unknown cards, which the Relay card may need to deal with, may not use the APDU format. Trying to parse commands sent to those cards as though they were in the APDU format is obviously wrong. However, most cards do support APDU, so default to logging parsed APDUs, still.
Also, implement a stub version of the "GET CARD DATA" and "LOG OFF" commands that are proprietary to the Belpic applet.
Now that we have a correct ins2handler dict, drop the unneeded create method
The spec for the Belgian electronic ID card interprets the ISO 7816 "SELECT FILE" command in a somewhat simplified way. First, the MF (3F00) can be selected from anywhere when P1 = 0x02; second, child DFs are selected also with P1 = 0x02. The applet does not interpret or treat specially cases where P1 = 0x00 or P1 = 0x01. In order to not to have to rewrite the "select file" logic that already exists in the Iso7816OS class, filter those two commands so that they contain the P1 value which the Iso7816OS class would search for.
The belpic applet does not deal with file sizes. It just returns less data than was requested, and the remote is supposed to figure out that the file was smaller than it assumed before based on that. It still returns SW12 0x9000 in that case, however. Add a "formatResult" method which filters out the SW12 = 0x6282 case, so that applications don't see values they don't expect.
Otherwise the file is unavailable and the eid-mw PKCS#11 module complains that the card is broken.
frankmorgner
approved these changes
Jun 20, 2017
|
|
||
| def formatResult(self, seekable, le, data, sw, sm): | ||
| r = R_APDU(Iso7816OS.formatResult(self, seekable, le, data, sw, sm)) | ||
| # The Belpic applet provides a bogus file length of 65536 for |
|
I absolutely consider your code acceptable! Your code concentrates on your card without changing (and potentially breaking) much of the other stuff. From a user's perspective it's a bad idea to have too many ways of doing the same thing (e.g. for initializing the card with data). But if your tooling is used elsewhere it's definitely good to have this available as an option for the virtual smart card as well. Is there something "useful" one can do with the implementation in its current state? Do you actually want to merge the code or did you only want to get this feedback? |
|
On Tue, Jun 20, 2017 at 02:48:11PM -0700, Frank Morgner wrote:
I absolutely consider your code acceptable! Your code concentrates on your card
without changing (and potentially breaking) much of the other stuff..
Good :-)
From a user's perspective it's a bad idea to have too many ways of doing the
same thing (e.g. for initializing the card with data). But if your tooling is
used elsewhere it's definitely good to have this available as an option for the
virtual smart card as well.
Yeah, that was my thinking too. I think it makes sense to have something
that looks similar to how you did the nPA thing, for people who want to
play with this but aren't really developing for the Belgian eID, but at
the same time also integrate with the tooling that already exists.
Is there something "useful" one can do with the implementation in its current
state?
I need to do some more tests, but I believe it can be used for read-only
operations already, yes.
The "run eid-viewer and see what breaks" test seemed somewhat
successful, at least, and is wat triggered this pull request. It gets
corrupt data with the example XML data (which I now found out is a
broken one, I'll fix that later), but at least it doesn't say "I don't
recognize this card" anymore like it did a few days ago.
Do you actually want to merge the code or did you only want to get this
feedback?
Well, I want to finish the SAM work first, but eventually, yeah. This is
done on billable time (at low priority), so expect it in a few weeks or
so.
…--
Could you people please use IRC like normal people?!?
-- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
Hacklab
|
|
@yoe , what's the status on your SAM implementation? |
|
I got side-tracked by other things that had way higher priority. Those are almost finished by now, and then I plan to take this up again. Thanks for your interest :) |
|
So no new work on this PR? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This includes code that is also in #103; should probably be considered with that in mind.
When parsing the XML file found in virtualsmartcard/belpic-example-data/belpic.xml, the official eID software (found in Fedict/eid-mw here on github, in case you want to test) detects it as a belpic-compliant card (with invalid data). The XML format is the same format that the current development tooling for the Belgian electronic ID card already uses, so it's not completely useless -- but one major TODO item is still to make the BelpicOS class parse from a config file, like the nPA implementation already does, rather than externalizing that to other tooling. Nevertheless, it's not completely useless provided it's used with that other tooling.
Please let me know whether this is going in a direction you would consider acceptable.