[PATCH] scd: Improve KDF-DO support

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[PATCH] scd: Improve KDF-DO support

Arnaud Fontaine
Hi,

KDF-DO support as been recently introduced in GnuPG, but the
implementation provided is not compliant with OpenPGP specifications.
The attached patch fixes two issues:
- when the KDF-DO algorithm is set to NONE (... 81 01 00 ...), no KDF
should be applied which is not the case in the current implementation
where KDF is applied as soon as the bit is set in extended capabilities
and a DO exists (which is required by the spec) whatever its content
(which is not compliant with the spec);
- the specification says the KDF-DO is encapsulated in a tag F9 + length
object, but the current implementation assumes the F9 tag + length are
not present; so the currently used offsets in the DO buffer must be
incremented by 2.

Cheers,
Arnaud Fontaine

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

fix_kdf_do.patch (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] scd: Improve KDF-DO support

NIIBE Yutaka
Hello,

Arnaud Fontaine <[hidden email]> writes:
> The attached patch fixes two issues:
> - when the KDF-DO algorithm is set to NONE (... 81 01 00 ...), no KDF
> should be applied which is not the case in the current implementation
> where KDF is applied as soon as the bit is set in extended capabilities
> and a DO exists (which is required by the spec) whatever its content
> (which is not compliant with the spec);

I will apply this part.  It's good if you submit this part only, at first.

> - the specification says the KDF-DO is encapsulated in a tag F9 + length
> object, but the current implementation assumes the F9 tag + length are
> not present; so the currently used offsets in the DO buffer must be
> incremented by 2.

My interpretation is different.  It is a constructed DO.  For all other
constructed DOs, OpenPGPcard responds with the constructed DO's
tag+length omitted.  For example, 65 or 6E.  Is F9 special?
--

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] scd: Improve KDF-DO support

Arnaud Fontaine
Hello,

the specification (section 4.4.1, page 22, in v3.3) says:
"Constructed DOs (C, marked yellow) are returned including their tag and
length"
and in the same section, page 25, F9 (KDF-DO) in marked as a constructed
DO, "format C".

So, from my understanding of these elements, the KDF-DO must be returned
with its tag and length.

Cheers
--
Arnaud Fontaine

Le 08/02/2018 à 01:19, NIIBE Yutaka a écrit :

> Hello,
>
> Arnaud Fontaine <[hidden email]> writes:
>> The attached patch fixes two issues:
>> - when the KDF-DO algorithm is set to NONE (... 81 01 00 ...), no KDF
>> should be applied which is not the case in the current implementation
>> where KDF is applied as soon as the bit is set in extended capabilities
>> and a DO exists (which is required by the spec) whatever its content
>> (which is not compliant with the spec);
>
> I will apply this part.  It's good if you submit this part only, at first.
>
>> - the specification says the KDF-DO is encapsulated in a tag F9 + length
>> object, but the current implementation assumes the F9 tag + length are
>> not present; so the currently used offsets in the DO buffer must be
>> incremented by 2.
>
> My interpretation is different.  It is a constructed DO.  For all other
> constructed DOs, OpenPGPcard responds with the constructed DO's
> tag+length omitted.  For example, 65 or 6E.  Is F9 special?
>

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] scd: Improve KDF-DO support

NIIBE Yutaka
Arnaud Fontaine <[hidden email]> wrote:
> the specification (section 4.4.1, page 22, in v3.3) says:
> "Constructed DOs (C, marked yellow) are returned including their tag and
> length"
> and in the same section, page 25, F9 (KDF-DO) in marked as a constructed
> DO, "format C".
>
> So, from my understanding of these elements, the KDF-DO must be returned
> with its tag and length.

Well, I have test version of Version 3.3 card from Achim.  It doesn't
put tag for 65 and 6E, at least.

I don't think it supports KDF-DO.

In this situation, I think that it's better for GnuPG to allow an
implementation of omitting tag, even if it allows violation of the
specification.
--

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] scd: Improve KDF-DO support

Arnaud Fontaine
Le 08/02/2018 à 11:43, NIIBE Yutaka a écrit :
> In this situation, I think that it's better for GnuPG to allow an
> implementation of omitting tag, even if it allows violation of the
> specification.

Do you suggest to support both implementations, with and without the
tag+length ?
Is it OK if I submit a patch that supports both ?

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] scd: Improve KDF-DO support

Arnaud Fontaine
Here is a patch that deals with both implementations (with and without tag).

Le 08/02/2018 à 13:51, Arnaud Fontaine a écrit :

> Le 08/02/2018 à 11:43, NIIBE Yutaka a écrit :
>> In this situation, I think that it's better for GnuPG to allow an
>> implementation of omitting tag, even if it allows violation of the
>> specification.
>
> Do you suggest to support both implementations, with and without the
> tag+length ?
> Is it OK if I submit a patch that supports both ?
>
> _______________________________________________
> Gnupg-devel mailing list
> [hidden email]
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
>

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

fix_kdf_do.patch (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] scd: Improve KDF-DO support

Achim Pietig
In reply to this post by Arnaud Fontaine
Hi,

this is a common missunderstandig how data objects are read or written.

The leading Tag (like 65 or F9) is the the index under what the data object is stored in the card.
This Tag is used to address the content of the DO within commands like Get Data or Put Data in the P1P2 bytes.
The data field or response field only contains the values of these DOs.
In case of a simple DO it is a single value, in case of a constructed DO the child-DOs with Tag/Lenght/Value (TLV).

"Constructed DOs (C, marked yellow) are returned including their tag and length" means the content of the DO, for constructed DOs a concatenation of all child DOs.
The main Tag (in P1P2) is never used/given/returned in the data field of the commands.

In the nearest future I will launch an update of the V3.3 specification with examples for all commands (no technical changes, only for better understanding).

Regards
Achim Pietig


Am 08.02.2018 um 09:35 schrieb Arnaud Fontaine:

> Hello,
>
> the specification (section 4.4.1, page 22, in v3.3) says:
> "Constructed DOs (C, marked yellow) are returned including their tag and
> length"
> and in the same section, page 25, F9 (KDF-DO) in marked as a constructed
> DO, "format C".
>
> So, from my understanding of these elements, the KDF-DO must be returned
> with its tag and length.
>
> Cheers
>

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] scd: Improve KDF-DO support

Arnaud Fontaine
I think adding some examples is a good idea to clarify ambiguous
sentences such as the one I have quoted.

So no encapsulating tag in the response, only the child ones. Correct ?

@Yutaka
If this is correct, the following patch is enough to trigger the
KDF_ITERSALTED_S2K only when needed.

Cheers
--
Arnaud Fontaine

Le 08/02/2018 à 18:19, Achim Pietig a écrit :

> Hi,
>
> this is a common missunderstandig how data objects are read or written.
>
> The leading Tag (like 65 or F9) is the the index under what the data object is stored in the card.
> This Tag is used to address the content of the DO within commands like Get Data or Put Data in the P1P2 bytes.
> The data field or response field only contains the values of these DOs.
> In case of a simple DO it is a single value, in case of a constructed DO the child-DOs with Tag/Lenght/Value (TLV).
>
> "Constructed DOs (C, marked yellow) are returned including their tag and length" means the content of the DO, for constructed DOs a concatenation of all child DOs.
> The main Tag (in P1P2) is never used/given/returned in the data field of the commands.
>
> In the nearest future I will launch an update of the V3.3 specification with examples for all commands (no technical changes, only for better understanding).
>
> Regards
> Achim Pietig
>
>
> Am 08.02.2018 um 09:35 schrieb Arnaud Fontaine:
>> Hello,
>>
>> the specification (section 4.4.1, page 22, in v3.3) says:
>> "Constructed DOs (C, marked yellow) are returned including their tag and
>> length"
>> and in the same section, page 25, F9 (KDF-DO) in marked as a constructed
>> DO, "format C".
>>
>> So, from my understanding of these elements, the KDF-DO must be returned
>> with its tag and length.
>>
>> Cheers
>>

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

fix_kdf_do.patch (674 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] scd: Improve KDF-DO support

Achim Pietig
Hi,

the actual V3.3 card returns H81, &H01, &H00, &H9000 to a Get Data with P1P2 = 00F9, that means KDF-DO is present, but not used/personalised.

Reagrds
Achim


Am 08.02.2018 um 19:03 schrieb Arnaud Fontaine:

> I think adding some examples is a good idea to clarify ambiguous
> sentences such as the one I have quoted.
>
> So no encapsulating tag in the response, only the child ones. Correct ?
>
> @Yutaka
> If this is correct, the following patch is enough to trigger the
> KDF_ITERSALTED_S2K only when needed.
>
> Cheers
>

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] scd: Improve KDF-DO support

Arnaud Fontaine
Hi,

so you (will) have the same problem with the current implementation
where KDF_ITERSALTED_S2K is systematically applied when the card
supports KDF (bit set in the extended capabilities) and a KDF-DO is
present (whatever its content).

Cheers
--
Arnaud Fontaine

Le 08/02/2018 à 19:50, Achim Pietig a écrit :

> Hi,
>
> the actual V3.3 card returns H81, &H01, &H00, &H9000 to a Get Data with P1P2 = 00F9, that means KDF-DO is present, but not used/personalised.
>
> Reagrds
> Achim
>
>
> Am 08.02.2018 um 19:03 schrieb Arnaud Fontaine:
>> I think adding some examples is a good idea to clarify ambiguous
>> sentences such as the one I have quoted.
>>
>> So no encapsulating tag in the response, only the child ones. Correct ?
>>
>> @Yutaka
>> If this is correct, the following patch is enough to trigger the
>> KDF_ITERSALTED_S2K only when needed.
>>
>> Cheers
>>

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] scd: Improve KDF-DO support

Achim Pietig
Hello Arnaud,

as I understand Niibes implementation correctly, the actual definition in the card should work.
If the flag for KDF is set in Extended capabilites, the KDF-DO shall be evaluated (is part of application data 6E; if not can be read separately with Tag F9).

If all child DOs (F9) are filled with valid data, the KDF-support is installed and the passwords are still set to this format.
If the DO is empty (810100 means empty) or not valid, the passwords are in standard format and can be set by any software that can handle that.
During changing the passwords to KDF-format, the KDF-DO must be set to a proper value.

Reagrds
Achim


Am 12.02.2018 um 10:36 schrieb Arnaud Fontaine:
> Hi,
>
> so you (will) have the same problem with the current implementation
> where KDF_ITERSALTED_S2K is systematically applied when the card
> supports KDF (bit set in the extended capabilities) and a KDF-DO is
> present (whatever its content).
>
> Cheers
>

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] scd: Improve KDF-DO support

Arnaud Fontaine
In reply to this post by Arnaud Fontaine

I think there is a misunderstanding: the current GnuPG implementation is ignoring the content of the KDF-DO, including the algorithm tag even if it is set to NONE.

The current (gît master branche) GnuPG implementation with your card (or mine) is just unusable because it systematically applies a derivation of the PIN entered by the user, even when KDF-DO algorithm is set to NONE, thus producing a "Bas PIN value" error making any operation, including PIN change of course, impossible.

I hope it is more clear this way.

--
Arnaud Fontaine

Le 12 févr. 2018 6:18 PM, Achim Pietig <[hidden email]> a écrit :
Hello Arnaud,

as I understand Niibes implementation correctly, the actual definition in the card should work.
If the flag for KDF is set in Extended capabilites, the KDF-DO shall be evaluated (is part of application data 6E; if not can be read separately with Tag F9).

If all child DOs (F9) are filled with valid data, the KDF-support is installed and the passwords are still set to this format.
If the DO is empty (810100 means empty) or not valid, the passwords are in standard format and can be set by any software that can handle that.
During changing the passwords to KDF-format, the KDF-DO must be set to a proper value.

Reagrds
Achim


Am 12.02.2018 um 10:36 schrieb Arnaud Fontaine:
> Hi,
>
> so you (will) have the same problem with the current implementation
> where KDF_ITERSALTED_S2K is systematically applied when the card
> supports KDF (bit set in the extended capabilities) and a KDF-DO is
> present (whatever its content).
>
> Cheers
>

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] scd: Improve KDF-DO support

NIIBE Yutaka
Fontaine Arnaud <[hidden email]> wrote:
> I think there is a misunderstanding: the current GnuPG implementation
> is ignoring the content of the KDF-DO, including the algorithm tag
> even if it is set to NONE.

I applied your patch.  Thanks.
--

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel