On Tuesday, December 11 at 09:59AM, Douglas E. Engert wrote:
>
>
>
> On 12/7/2012 5:15 PM, Frank Morgner wrote:
> > Hi!
> >
> > Currently, sc_check_apdu checks the length of an R-APDU buffer using
> > SC_MAX_APDU_BUFFER_SIZE, which defines the maximum length
different indentation settings. dir-local settings
> seem the easiest way to assign a style per directory (tree).
Your editor should be intelligent enough to guess the right settings.
For vim I recently found this plugin
http://www.vim.org/scripts/script.php?script_id=4251
--
Frank Mor
fix would be to use 0xff+1/0x+1 instead. However, in
multiple files I have seen this wrong usage of SC_MAX_APDU_BUFFER_SIZE
(eg, see `grep rbuf *.c | grep SC_MAX_APDU_BUFFER_SIZE`). Unfortunately
I dont have time to check libopensc in depth, so I leave this up to the
community.
--
Frank Morgner
pensc-devel mailing list
> opensc-devel@lists.opensc-project.org
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
--
Frank Morgner
Virtual Smart Card Architecture http://vsmartcard.sourceforge.net
OpenPACEhttp://openpace.sourceforge.ne
;t 64 elements in the array...)
I would not be so critical. The wrong 'magic' value would simply lead to
an undetected card driver. It does not lead to a security hole...
> On 10/31/2012 2:10 PM, Frank Morgner wrote:
> > +1, I always wondered why I could got to the default dr
) sc_get_default_driver },
> { NULL, NULL }
> };
>
> than the limit defined in types.h:
>
> #define SC_MAX_CARD_DRIVERS 32
>
> So the binary from the website ignores all drivers that come after
> "PIV-II". Since my cards use the default driver, 0.13 is c
| 32429 Minden, Germany
>|'##> <##'| Phone +49 171 8334920
> -http://www.cardcontact.de
> http://www.tscons.de
> http://www.openscdp.org
>
> ___
> opensc-devel mai
PIN pad be used to enter card PINs
> when using the opensc minidriver?
>
> - Tim
>
> ___
> opensc-devel mailing list
> opensc-devel@lists.opensc-project.org
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>
--
Frank Morgner
Virtual Smart Card Archi
e pcscd exited.
> > I guess the CASTLES EZ100PU driver crashed at some point. Bad driver
> > quality?
> >
> >
> > After a quick search I found [1] that the SLE5542 card is a _memory_ card.
> > You can't use such a card with PC/SC.
> > You can't
//github.com/OpenSC/OpenSC/pull/83
[1] http://vsmartcard.sourceforge.net/npa/README.html
[2] http://openpace.sourceforge.net
[3] http://www.opensc-project.org/pipermail/opensc-devel/2012-June/018203.html
--
Frank Morgner
Virtual Smart Card Architecture http://vsmartcard.sourceforge.
7;const' qualifier from
pointer target type [enabled by default]
card-iasecc.c:2223:25: warning: assignment discards 'const' qualifier from
pointer target type [enabled by default]
--
Frank Morgner
Virtual Smart Card Architecture http://vsmartcard.sourceforge.net
OpenPACE
present in sc_card_t, when
sm_card_operation.get_sm_apdu is called. The session information is
available in both cases.
2. APDU chains: Why not handle multiple APDUs with subsequent calls to
sm_card_operations.get_sm_apdu (an error code could indicate if more
APDUs must be transmitte
/finalize essentially seem to do the
same.
--
Frank Morgner
Virtual Smart Card Architecture http://vsmartcard.sourceforge.net
OpenPACEhttp://openpace.sourceforge.net
IFD Handler for libnfc Devices http://sourceforge.net/projects/ifdnfc
pgp0mjRWKuH1Q.pgp
Description
he current SM
framework, however, does not give me any advantages. What I want is
better integration of my cards (thats why I am bothering with the SM
framework so much), reusable code and clean interfaces. Both of the
latter points require changes to the current SM framework.
> Can you do t
On Sunday, June 10 at 03:39PM, Viktor Tarasov wrote:
> Le 10/06/2012 14:21, Frank Morgner a écrit :
> > Uh, I think I am a bit late on this discussion...
> >
> > But I wanted to add a general concern that there are some conceptual
> > problems with the SM branch (and th
ibopensc/card-epass2003.c
[3] https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/sm.h
--
Frank Morgner
Virtual Smart Card Architecture http://vsmartcard.sourceforge.net
OpenPACEhttp://openpace.sourceforge.net
IFD Handler for libnfc Devices http://sourceforge.net/
should I do?
Have a look at the following files to get a feel how OpenSSL is
included and do just the same for libgcrypt:
- configure.ac
- src/libopensc/pkcs15.c
- src/libopensc/Makefile.am
--
Frank Morgner
Virtual Smart Card Architecture http://vsmartcard.sourceforge.net
OpenPACE
> Unfortunately I do not have access to that either.
>
> But you have me more hints to search the web.
There are several drafts and previews of 7816-4 available on the web:
http://lmgtfy.com/?q=iso7816-4
--
Frank Morgner
Virtual Smart Card Architecture http://v
d (SIM?) card included in the reader.
To talk to the NFC-interface of the reader, you can use libnfc [1] or
the cyberflex-shell [2]. I have written a wrapper driver around libnfc
for PCSC-Lite [2]. May be there are also other (proprietary) drivers out
there...
[1] http://www.libnfc.org
[2] https://git
//www.freelancer.com/projects/C-Programming-Computer-Security/patch-OpenSC-support-OpenPGP-Card.html
--
Frank Morgner
Virtual Smart Card Architecture http://vsmartcard.sourceforge.net
OpenPACE http://openpace.sourceforge.net
IFD Handler for libnfc Devic
o fork OpenSC on github and send a pull request, when you're
done. See http://www.opensc-project.org/opensc/wiki/GetInvolved for
further information.
[1] Yes, this is somewhat of inconsistent as it is not always done...
--
Frank Morgner
Virtual Smart Card Architecture htt
quot;.
>
> Is my APDU is correct?
The card seems to tell you that the PIN you entered is incorrect. The
encoding doesn't look correct. I suggest BCD encoding, which is
something like:
12 34 56 78
or ASCII encoding, which is something like this:
31 32 33 34 35 36 37 38
Maybe if we knew
to identify the card. Identification
is done to support card specific behaviour and commands.
--
Frank Morgner
Virtual Smart Card Architecture http://vsmartcard.sourceforge.net
OpenPACE http://openpace.sourceforge.net
IFD Handler for libnfc Devices http://sourcefor
___
> opensc-devel mailing list
> opensc-devel@lists.opensc-project.org
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>
--
Frank Morgner
Virtual Smart Card Architecture http://vsmartcard.sourceforge.net
OpenPACE http://openpace.sou
On Saturday, March 24 at 07:07AM, Anders Rundgren wrote:
>
> http://www.globalplatform.org/specifications/review/GPD_SE_Access_Control_v0_10_0.pdf
>
> By adding ACL information to keys during enrollment you can limit key
> "misuse" by bad apps.
>
> Although GP specifies a generic scheme not limi
On Monday, March 26 at 09:17AM, helpcrypto helpcrypto wrote:
>
> > Another issues with this project is many of the modifications can only be
> > tested
> > by a subset of developers (maybe only one) who have the cards that can use
> > the modification.
>
> Maybe its an stupid idea (or already do
Hi!
> > I don't think that's enough? It doesn't matter if the card trusts the CA,
> > it's that the CA has to trust the card.
> Difficult to do more with the common cards.
As Andreas said, the German identity card (nPA) has this functionality
(BSI TR-03110). A whole bunch of technical guideline
On Thursday, January 19 at 11:46AM, Szabó Áron wrote:
>
> Hi,
>
> I have to test a rather old Bull card with the OpenSC v0.12.2 on Windows, I
> try to retrieve all the stored files by using "SELECT FILE" and "READ BINARY"
> APDU commands (after performing a successful authentication by using
>
Hi!
> > Internally, the API should facilitate re-use by OpenSC components and
> > card drivers. Sorry, I have not had the time to learn about PACE more
> > than the generic overviews, nor how it fits into the
> > cards-and-readers-and-current-software-stack bigger picture. Given
> > that what you
On Saturday, January 07 at 09:20PM, Frank Morgner wrote:
> Hi!
>
> > IIRC the original discussion had a few combined aspects:
> > * splitting sc_transmit into an APDU version and byte array version (yes)
> > * exporting the byte array version to libopensc (libopensc &qu
Hi!
> IIRC the original discussion had a few combined aspects:
> * splitting sc_transmit into an APDU version and byte array version (yes)
> * exporting the byte array version to libopensc (libopensc "removal"
> from exported interfaces was to discourage relentless linking against
> libopensc fo
On Wednesday, November 23 at 10:07PM, Anders Rundgren wrote:
>
> Hi,
> I just wonder what your opinion is about Java smart card io which is a
> part of JDK 1.6 and forward.
>
> I did a minute test and it wasn't overly convincing :-(
>
> OTOH, as we all know that smart card middle ware is "hell o
Hi!
> > >> Do you need to use SCardTransmit() or SCardControl() at the PC/SC level?
> > >> OpenSC mixes SCardTransmit() and SCardControl(). Maybe a good
> > >> evolution would be to have separate functions.
> > >
> > > PACE needs SCardControl with 0x20. Yes, I think separating control and
> > > tr
Hi!
> >>> BTW, what is the status of SM in trunk. It used to be scheduled for
> >>> 0.12.3. If there is clearity about how to integrate it, I could also
> >>> provide a generic implementation of PACE (generic = "PACE done by OpenSC
> >>> not by the reader").
> >>
> >> There is SM dedicated github
Hi!
> > BTW, what is the status of SM in trunk. It used to be scheduled for
> > 0.12.3. If there is clearity about how to integrate it, I could also
> > provide a generic implementation of PACE (generic = "PACE done by OpenSC
> > not by the reader").
>
>
> There is SM dedicated github branch
> h
Hi!
> > Ah yes, I forgot about that. It's already long ago... Anyway, the idea
> > of sc_transmit_bytes has been given up in favor of sc_bytes2apdu, since
> > all the opensc tools do not want to send an arbitrary buffer but an
> > apdu.
>
> Will you propose a new patch?
>
> >> Do you need to use
Hi!
> > Actually PACE is executed with SCardControl. The current implementation
> > for control commands in OpenSC would not allow executing PACE, because
> > reader-pcsc.c:237 always encodes an APDU. This is OK if you are only
> > using PIN verification/modification (which require an encoded APDU
Hi!
> > I wrote a patch for libccid to support PACE. Due to a lack of
> > standardization on the USB level there is only my ccid-emulator, which
> > can be used with this feature. See
> > http://sourceforge.net/projects/vsmartcard/ for the libccid patch and
> > ccid-emulator.
>
> Thanks for the i
On Monday, October 10 at 12:43PM, Anders Rundgren wrote:
>
> On 2011-10-10 12:05, Martin Paljak wrote:
> > Hello,
> >
> > On Mon, Oct 10, 2011 at 12:27, Anders Rundgren
> > wrote:
> >> Is there any support for trusted (OS-level) PIN input in OpenSC?
>
> > Trusted path for me means guaranteed by
Hi!
> > I wrote a patch for libccid to support PACE. Due to a lack of
> > standardization on the USB level there is only my ccid-emulator, which
> > can be used with this feature. See
> > http://sourceforge.net/projects/vsmartcard/ for the libccid patch and
> > ccid-emulator.
>
> Thanks for the i
On Wednesday, October 05 at 09:53AM, Ludovic Rousseau wrote:
>
> 2011/10/5 Martin Paljak :
> > On Tue, Oct 4, 2011 at 17:56, Frank Morgner
> >
> >> Note that the two readers mentioned above do not use libccid.
> > Does this mean that they are not CCID compatible?
Hi!
> > You can add Reiner SCT's cyberJack RFID komfort and cyberJack RFID
> > standard to this list (both also support SM, which is absolutely
> > transparent to the application). I have been told that filtering VERIFY
> > (or similar commands) is bound to a certain type of card.
>
> So the fire
Hi!
> >> Some pinpad readers have what they call a "firewall". The reader will
> >> not allow you to use a VERIFY command without using the pinpad feature
> >> i.e. it is not possible to send a PIN 'in the clear' to the card
> >> without using the pinpad feature.
> > This should be quite limited l
Hi!
> sc_enum_apps fails because sc_select_file returns an "unknown" SW 6A88
> which gets translated to SC_ERROR_DATA_OBJECT_NOT_FOUND in iso7816.c.
> Looking at ISO7816-4, it is not listed as a "relevant SW" for SELECT
> command, which is failing (which also makes sense to me)
Regarding the erro
On Thursday, June 30 at 07:08PM, Juan Antonio Martinez wrote:
> In OpenDNIe[1] we had a similar problem: on SM establishment we need to
> override default meaning of some error codes, to get a common SM error
> and parse it. I solved it by mean of providing own check_sw() at
> card_ops function poi
a good practice.
>
> Merged.
>
> On Wed, May 18, 2011 at 15:01, Frank Morgner
> wrote:
> > Hi!
> >
> > I discovered some errors due to uninitialized parameters. This might
> > only concern opensc when used with pcsc-lite version 1.5.5, but it
> > doesn&#x
Hi!
I discovered some errors due to uninitialized parameters. This might
only concern opensc when used with pcsc-lite version 1.5.5, but it
doesn't hurt to set them anyway.
Cheers, Frank.
Index: src/libopensc/reader-pcsc.c
===
--- sr
Hi!
> Many thanks Franck and Martin, using exclusive mode solved my problem:
...
> I wonder if there is not a problem in shared more or if we should not
> ask users to use exclusive mode only.
No problem, I had a similar problem where two applications accessed a
smart card. One "initialized" the
On Friday, May 06 at 03:03PM, Jean-Michel Pouré - GOOZE wrote:
> Le vendredi 06 mai 2011 à 14:41 +0300, Martin Paljak a écrit :
> > Have a look at the wiki:
> > http://www.opensc-project.org/opensc/wiki/SecurityConsiderations
>
> Sure.
>
> I am worried about:
> * Application A opens communicati
On Friday, April 29 at 07:00PM, Jean-Michel Pouré - GOOZE wrote:
> Le vendredi 29 avril 2011 à 12:37 +0200, Jean-Michel Pouré - GOOZE a
> écrit :
> > I suspect a low level issue under GNU/Linux, any idea?
>
> For those interested, I posted a message on Muscle mailing list:
> http://lists.drizzle.c
On Tuesday, April 26 at 09:07PM, Peter Stuge wrote:
> Frank Morgner wrote:
> > But you can also accept the overhead and use standardized
> > interfaces. This approach gives you support for a wide variety of
> > applications and (existent) hardware/software.
>
> The *o
On Tuesday, April 26 at 08:34PM, NdK wrote:
>
> On 26/04/2011 18:51, Frank Morgner wrote:
>
> > You forgot to mention Virtual Smart Card Architecture
> Already seen that, but always "wrappers wrapped in other wrappers" :(
Well, it IS what you requested: CCID+virtua
On Tuesday, April 26 at 12:41PM, Anders Rundgren wrote:
>
> I don't know what you had in mind with an "USB P11 token"
> but in case you would like to participate in an effort
> making sort of a USB P11 token there is already a project
> to dig in to:
>
> http://webpki.org/auth-token-4-the-cloud.h
Hi!
> > I guess there's some kind of (international/EU) standard for travel
> > documents (ICAO MRTD?) that define names for common fields of such
> > documents. That could be used as a reference, probably there's even
> > a standardized translation available somewhere under *.eu
>
> http://open
Hi!
I think that a flag could be invented for switching between these
two modes of operation (the otherwise unused "flags" parameter to
sc_read_binary). The default could be the mode that honors passed
in parameters.
>>> Actually the 0x6282 is mapped to the general SC_ERROR_CA
Hi!
> > But all other functions of libopensc require the caller to allocate
> > enough space.
> Vital for maintainable software: who needs memory, allocates (*and
> frees*) it. As a sage said a long time ago: "or you rewrite your project
> this way, or your project will rewrite you" :)
As long as
I just realized that my patch also contains the following line in
sc_bytes2apdu:
apdu->flags = SC_APDU_FLAGS_NO_GET_RESP|SC_APDU_FLAGS_NO_RETRY_WL;
This might not be wanted and can safely be removed.
Cheers, Frank.
pgp2LaAVxTlyh.pgp
Description: PGP signature
__
Hi!
> > Looking at your patch - I like the approach more:
> > - removes code duplication (there's one more instance in piv-tool.c)
> > - feels like easier to read (but verification would need attention what I
> > can't afford right now, sickathome) - has a nice debug log statement.
> >
> > It w
Hi!
> >> In the svn tree there is a change that breaks my code: The ISO
> >> driver automatically sends read binary APDUs until the number of
> >> requested bytes is reached (iso7816.c:136).
> > You mean r5237 [1] ?
Yes!
> >> Previously only one APDU was sent. The change surely intendeds to
> >>
In the svn tree there is a change that breaks my code: The ISO driver
automatically sends read binary APDUs until the number of requested
bytes is reached (iso7816.c:136). Previously only one APDU was sent. The
change surely intendeds to read as much as possible (and requested). The
problem is that
On Tuesday, April 19 at 02:03PM, Martin Paljak wrote:
>
> On Mon, Apr 18, 2011 at 23:22, Peter Marschall wrote:
> > I guess the library should be deferred for later.
> > It may need discussions where the code shall go: maybe even directly into
> > libopensc ;-)
> OK, all commited.
>
> Thanks!
P
Hi!
> > Are your key sets relevant to the encoding of the APDU? If not, then
> > you could see key sets as part of the crypto layer.
>
> The block size of the cipher is relevant for padding. So it actually
> depends on the notion of key set you decide to implement. If you keep
> the specific bloc
Hi!
> > AFAIK, ISO 7816 defines data encoding, input for the
> > cryptographic layer and some padding methods. Everything you
> > listed would be part of the crypto layer which is not fixed by
> > ISO 7816.
> Can you explain yourself ? Yes, it's another crypto layer, that
>
Hi!
> > I think you should call the SM routines in sc_transmit_apdu instead
> > of in do_single_transmit. The SM APDU is usually longer than the
> > non-SM APDU. So the secured APDU could extend the readers/cards
> > maximum APDU length and is subject to splitting via chaining (which
> > is done i
Hi!
> >>> AFAIK, ISO 7816 defines data encoding, input for the cryptographic
> >>> layer and some padding methods. Everything you listed would be
> >>> part of the crypto layer which is not fixed by ISO 7816.
> >> Can you explain yourself ?
> >> Yes, it's another crypto layer, that sits beside th
Hi!
> >>> The smart cards I worked with, that used SM implemented more or less
> >>> what is defined in ISO 7816. The Wiki states, that GlobalPlatform SCP01
> >>> uses a different SM protocol. What exactly does differ from ISO 7816?
> >> keyset format; session key derivation data; session keys cal
On Sunday, March 27 at 01:42PM, Viktor TARASOV wrote:
> > http://www.opensc-project.org/opensc/wiki/SecureMessaging
>
> I've added my vision onto the SM implementation .
> Still to be finalized the proposal for the SM data types.
> I'll try to look over the prior works to see how their needs can b
On Sunday, March 27 at 10:23AM, Viktor TARASOV wrote:
> Le 25/03/2011 23:07, Frank Morgner a écrit :
> > The smart cards I worked with, that used SM implemented more or less
> > what is defined in ISO 7816. The Wiki states, that GlobalPlatform SCP01
> > uses a different SM p
Hi!
> > SM is a term from ISO-7816, which AFAIK only has something like a
> > security environment to group operations. So why do you propose to wrap
> > chained APDUs with SM?
>
> Thanks for the comment. To tell the truth, I didn't explain this. I
> propose to apply the general "transformation"
The smart cards I worked with, that used SM implemented more or less
what is defined in ISO 7816. The Wiki states, that GlobalPlatform SCP01
uses a different SM protocol. What exactly does differ from ISO 7816?
Cheers, Frank.
pgpSBV8TPswXL.pgp
Description: PGP signature
_
Hi!
> I've updated the page with my proposed architecture. I believe that
> it's a bit too abstract to see immediately whether it makes sense, but
> I've thrown it away and redone a few times, because I'm trying to code
> it in the meantime and I've already expunged the bits that made the
> least
Hi!
> I also need to get a clearer picture.
> Probably we should create 'SM' dedicated wiki page and there to resume
> the specifications and architectural approaches .
Has there been any progress or even some results on the discussion about
SM in OpenSC?
Greets,
Frank.
pgpujRmk0xbv1.pgp
Descr
> > But why don't you store the needed SM-data in the card's
> > private data? This way each card handle has it's own SM context and
> > could access the card with different SM parameters (if supported).
>
> Sorry I can't: AFAIK DNIe is "read only", at least at user level
> Ideally, virtual channe
On Monday, February 14 at 12:22PM, jons...@terra.es wrote:
> In the testing process of OpenDNIe I've found a problem related with
> concurrent
> access to opensc-pkcs11 library.
>
> In short: as DNIe can only handle one SM at a time (no virtual channel
> support),
> there is no (known) way to g
Hi!
> at the moment I'm working on a driver for synchronous protocols for
> several CCID card readers. Since the driver would extend the CCID
> driver for several USB IDs, I planned to move a lot of the declarations
> from ifd-ccid.c to a separate header file, because I want to reuse
> most of the
On Thursday, January 27 at 01:57PM, Jean-Michel Pouré - GOOZE wrote:
> Dear Friends,
>
> Can OpenSC / libp11 or any framework access the random number generator
> which is available in some cards, including the Feitian PKI?
The card driver can set a flag SC_CARD_CAP_RNG. I am not sure if this is
Hi!
> > One of the longstanding problems of OpenSC is lack of documentation,
> > both developer (source comments, internal architecture, tutorials on
> > how to add new card drivers other way than copypaste etc) and
> > end-user docs. This is unfortunately quite usual for open source
> > projects,
Hi!
> >>> You're not supposed to link against libopensc via the sc_* API but use
> >>> PKCS#11. It is possible but not encouraged, thus the .pc file is
> >>> removed.
> >>
> >> Why is it not encouraged?
>
> The effort that would be required to have a well designed and
> documented public API and
Hi!
> You're not supposed to link against libopensc via the sc_* API but use
> PKCS#11. It is possible but not encouraged, thus the .pc file is
> removed.
Why is it not encouraged?
> Why do you need libopensc.pc (or what is linking agains libopensc)?
I am using smart card abstraction offered by
This is only possible for readers, that can handle SM themselves. Those
readers exist for example for the new German Identity card. If you are
handling SM with OpenSC, you need to do PIN-Management without the help
of the reader's pinpad. Old readers (PCSCv1?) had the capabilities to
send the PIN b
I have set up my Ubuntu machine as described in
http://www.opensc-project.org/opensc/wiki/WindowsInstaller
Unfortunately I am getting the following error:
/bin/bash ../../libtool --tag=CC --mode=link i586-mingw32msvc-gcc
-DSIMCLIST_NO_DUMPRESTORE -fno-strict-aliasing --include=cardmod-mingw-com
On Tuesday, October 26 at 11:58AM, Peter Stuge wrote:
> Juan Antonio Martinez wrote:
> > An ideal solution for me (and for the other people that is working
> > with SM cards) would be adding a new card operation
> > "card_transmit_apdu()", that defaults in iso7816.c to
> > sc_transmit_apdu(), but c
On Tuesday, October 26 at 11:05AM, Juan Antonio Martinez wrote:
> Working in new code for DNIe card, I've found a problem:
> sc_transmit_apdu() must be overriden to allow secure messaging
> routine perform apdu wrapping when SM is on
>
> I've coded a kind of "virtual channel" that hides SM issues
Hi!
On Tuesday, October 12 at 10:33AM, Viktor TARASOV wrote:
> >>> 1. There is no kind of abstraction in the current SM code. At the
> >>> moment every card driver implements its own version of secure
> >>> messaging.
>
> SM is not implemented by card driver, but the separate SM procedures.
> T
Hi!
> >> What are the limitations in OpenSC?
> >
> > 1. There is no kind of abstraction in the current SM code. At the
> > moment every card driver implements its own version of secure
> > messaging. This leads to duplicated code. For example, what I saw
> > at the first glance is that every car
On Thursday, September 30 at 12:02PM, Martin Paljak wrote:
> > The code (also needs a patched version of OpenSSL) is much more
> > extensive than other SM cards in opensc-sm.trunk, that's why I doubt
> > that there is a chance of integrating the nPA into OpenSC.
> What are the limitations in OpenSC
> in my opinion the usage of OpenSSL in libopensc.so should be removed
> altogether. If cryptography is needed by some cards (i.e. for
> initialisation/personalisation), then this should be done by dedicated
> tools. CardOS is a good example. It requires encrypted APDU:s for the
> delete_MF and cre
87 matches
Mail list logo
