Hi Frank,
>> This might have some small variations in the implementations. For
>> instance, the Italian CNS (national almost-eID card) seems to follow
>> 7816-4 where, when using SM authentication, the first block contains
>> CLA, INS, P1, P2 + padding. But the padding is not 80 followed by as
>>
Le 05/04/2011 20:58, Frank Morgner a écrit :
> My previous remarks in this mail apply to the inner structure of the SM
> module. I consider your layout as the most promising. (Maybe because I
> implemented something similar ;-) ) Beyond that what I have already said
> about where to trigger SM, I h
On 05/04/2011 20:58, Frank Morgner wrote:
> My previous remarks in this mail apply to the inner structure of the SM
> module. I consider your layout as the most promising. (Maybe because I
> implemented something similar ;-) ) Beyond that what I have already said
> about where to trigger SM, I hav
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,
just a couple of comments:
> 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
t
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
>
Le 05/04/2011 16:42, Frank Morgner a écrit :
> 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
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
Le 29/03/2011 01:16, Frank Morgner a écrit :
> 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 forma
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
Le 27/03/2011 18:50, Frank Morgner a écrit :
> 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
>
Le 27/03/2011 19:25, Frank Morgner a écrit :
> 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 ov
>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 need
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 protocol. What exactly do
Le 21/03/2011 15:50, Martin Paljak a écrit :
> Hello,
> On Mar 17, 2011, at 4:37 PM, Frank Morgner wrote:
>>> 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
Le 24/03/2011 22:40, Emanuele Pucciarelli a écrit :
> On Mon, Mar 21, 2011 at 15:50, Martin Paljak wrote:
>
>>> Has there been any progress or even some results on the discussion about
>>> SM in OpenSC?
>>
>> Here's just a skeleton, add links and thoughts if you can:
>>
>> http://www.opensc-projec
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 protocol. What exactly does differ from ISO 7816?
keyset format; session key derivation
Hello there!
>> 3. if we need to, transform this APDU into a sequence of chained
>> APDUs, or something else; for instance, if I understand correctly, the
>> Spanish DNIe doesn't support command chaining, but rather wants this a
>> sequence of ENVELOPE APDUs;
>
> Enveloped APDUs and Chained APDUs
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"
On Fri, Mar 25, 2011 at 22:34, Frank Morgner
wrote:
> 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 t
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
On Mon, Mar 21, 2011 at 15:50, Martin Paljak wrote:
>> Has there been any progress or even some results on the discussion about
>> SM in OpenSC?
>
>
> Here's just a skeleton, add links and thoughts if you can:
>
> http://www.opensc-project.org/opensc/wiki/SecureMessaging
I've updated the page wi
Hello,
On Mar 17, 2011, at 4:37 PM, Frank Morgner wrote:
>> 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 ab
On 17.03.2011 15:37, Frank Morgner wrote:
> 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 i
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
On 12.03.2011 16:20, Emanuele Pucciarelli wrote:
> Hi!
>
>> It's on my conscious .
>> I have a strong intention to start this work as soon as possible .
> I would like to collaborate on this.
It would be very appreciated.
> My hidden agenda [ ;) ] is to
> make this happen in such a way that this w
Hi!
> It's on my conscious .
> I have a strong intention to start this work as soon as possible .
I would like to collaborate on this. My hidden agenda [ ;) ] is to
make this happen in such a way that this work can be used by the
"itacns" driver as well, and possibly by other present and future
d
On 11.03.2011 19:03, Juan Antonio Martinez wrote:
> but still need to decide a common way to
> integrate Secure Messaging cards
It's on my conscious .
I have a strong intention to start this work as soon as possible .
There are few specification items, that imho should be present in this future
El mié, 09-03-2011 a las 10:29 +0100, Viktor TARASOV escribió:
> Hello,
>
>
> On 09.03.2011 09:39, jons...@terra.es wrote:
> > Trying to optimize DNIe card driver, I'd like to cache current df to avoid
> > extra select_file()'s
[...]
> > Also, I've noticed that sc_(un)lock() clears sc_card_cache
Hello,
On 09.03.2011 09:39, jons...@terra.es wrote:
> Trying to optimize DNIe card driver, I'd like to cache current df to avoid
> extra select_file()'s
>
> DNIe card cannot handle select_file(SC_PATH_TYPE_PATH) directly: it has to be
> splitted into
> recursive calls to select_file(SC_PATH_TY
33 matches
Mail list logo
