wrong ASN.1 encoding?

Hello,

It looks like the functions asn1_encode_integer() and
sc_asn1_decode_integer() from src/libopensc/asn1.c are not
correct.

For example the integer 128 is encoded 0x80 but should be
encoded 0x00
0x80. 0x80 is the encoding of -128
-128 is encoded FF FF FF 80 but I don't know if that is a
valid coding.

I am not expert in ASN.1 so am not sure it is a bug.
I found ASN.1 encoding examples in [1]:
##
## INTEGER (tests 13 - 21)
##

my %INTEGER = (
  pack("C*", 0x02, 0x02, 0x00, 0x80), 	      128,
  pack("C*", 0x02, 0x01, 0x80), 	      -128,
  pack("C*", 0x02, 0x02, 0xff, 0x01), 	     
-255,
  pack("C*", 0x02, 0x01, 0x00), 	      0,
  pack("C*", 0x02, 0x03, 0x66, 0x77, 0x99),  
0x667799,
  pack("C*", 0x02, 0x02, 0xFE, 0x37),	     -457,
  pack("C*", 0x02, 0x04, 0x40, 0x00, 0x00, 0x00),	
    2**30,
  pack("C*", 0x02, 0x04, 0xC0, 0x00, 0x00, 0x00),	
    -2**30,
);


I propose the attached patch for asn1_encode_integer().
sc_asn1_decode_integer() should also be patched.

Do we have ASN.1 experts on this list?

bye

[1] http://search.cpan.org/src/GBARR/Convert-ASN1-0.21/
t/00prim.t

-- 
 Dr. Ludovic Rousseau

_______________________________________________
opensc-devel mailing list
opensc-devellists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc
-devel

Ludovic Rousseau ha scritto:
> Do we have ASN.1 experts on this list?

Yes. You are right, these are the rules:

If the contents octets of an integer value encoding consist
of more than 
one octet, then the bits of the first octet and bit 8 of the
second octet:
  a) shall not all be ones; and
  b) shall not all be zero.
NOTE – These rules ensure that an integer value is always
encoded in the 
smallest possible number of octets.

The correct encodings of 128 and -128 are:

  (128) 02:02:00:80
(-128) 02:01:80

Anything else is wrong.

--
Alessandro Premoli
_______________________________________________
opensc-devel mailing list
opensc-devellists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc
-devel

Andreas Steffen ha scritto:
> Additionally prepended 0x00 octets for positive and
0xFF octets for
> negative numbers, respectively are discarded.

No, this is false. Even the relaxed ASN.1 BER encoding
*requires* that 
integer values be always encoded in the smallest possible
number of 
octets. See the ITU-T X.690 standard.

--
Alessandro Premoli
_______________________________________________
opensc-devel mailing list
opensc-devellists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc
-devel

Andreas Steffen ha scritto:
> Additionally prepended 0x00 octets for positive and
0xFF octets for
> negative numbers, respectively are discarded.

If with "discarded" you mean that they will not
appear in the encoded 
form, yes. If you mean the decoder should ignore them, then
no.

--
Alessandro Premoli
_______________________________________________
opensc-devel mailing list
opensc-devellists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc
-devel

Yes, this is what I mean: they *must not* be encoded, so
that the
shortest possible representation results that still allows
to
differentiate between positive and negative numbers. This is
what
my examples show.

Andreas

P.S. A couple of years ago I did an analysis of Microsoft's
      Kerberos protocol. They encoded certain 32-bit integer
variables
      constantly as 0x02 0x04 0x.. 0x.. 0x.. 0x..,
irrespectively of
      the actual value.

Alessandro Premoli wrote:
> Andreas Steffen ha scritto:
>> Additionally prepended 0x00 octets for positive and
0xFF octets for
>> negative numbers, respectively are discarded.
> 
> If with "discarded" you mean that they will
not appear in the encoded 
> form, yes. If you mean the decoder should ignore them,
then no.
> 
> -- 
> Alessandro Premoli

============================================================
==========
Andreas Steffen                         andreas.steffenstrongswan.org
strongSwan - the Linux VPN Solution!               
www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[
ITA-HSR]==
_______________________________________________
opensc-devel mailing list
opensc-devellists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc
-devel

ASN.1 integers are encoded as two's complement numbers. This
means that the most significant bit of a positive number
must be zero
and the most significant bit of a negative integer must be
set to one.
Additionally prepended 0x00 octets for positive and 0xFF
octets for
negative numbers, respectively are discarded. Here are some
examples
I used in my ASN.1 lecture a couple of years back

    http://www.
strongsec.com/zhw/KSy_ASN1.pdf  (slide 22)

BER coding of two‘s complement integers

• -129: 1111 1111 0111 1111 = 02 02 FF 7F
• -128: 1111 1111 1000 0000 = 02 01 80
• -127: 1111 1111 1000 0001 = 02 01 81
•   -1: 1111 1111 1111 1111 = 02 01 FF
•    0: 0000 0000 0000 0000 = 02 00
•    1: 0000 0000 0000 0001 = 02 01 01
•  127: 0000 0000 0111 1111 = 02 01 7F
•  128: 0000 0000 1000 0000 = 02 02 00 80
•  129: 0000 0000 1000 0001 = 02 02 00 81

Best regards

Andreas

Alessandro Premoli wrote:
> Ludovic Rousseau ha scritto:
>> Do we have ASN.1 experts on this list?
> 
> Yes. You are right, these are the rules:
> 
> If the contents octets of an integer value encoding
consist of more than 
> one octet, then the bits of the first octet and bit 8
of the second octet:
>   a) shall not all be ones; and
>   b) shall not all be zero.
> NOTE – These rules ensure that an integer value is
always encoded in the 
> smallest possible number of octets.
> 
> The correct encodings of 128 and -128 are:
> 
>   (128) 02:02:00:80
> (-128) 02:01:80
> 
> Anything else is wrong.
> 
> --
> Alessandro Premoli

============================================================
==========
Andreas Steffen                         andreas.steffenstrongswan.org
strongSwan - the Linux VPN Solution!               
www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[
ITA-HSR]==
_______________________________________________
opensc-devel mailing list
opensc-devellists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc
-devel

> Yes, this is what I mean: they *must not* be encoded,
so that the
> shortest possible representation results that still
allows to
> differentiate between positive and negative numbers.

Ok, we agree. Sorry if my first message seemed a bit rude.

> P.S. A couple of years ago I did an analysis of
Microsoft's
>       Kerberos protocol. They encoded certain 32-bit
integer variables
>       constantly as 0x02 0x04 0x.. 0x.. 0x.. 0x..,
irrespectively of
>       the actual value.

I saw even BER encoded certificates and worse. How can you
trust a
signature done by a wrongly encoded(/signed) certificate?
You know,
standards are done to be violated (and usually MS is quite
good in doing
it).

-- 
Ale

_______________________________________________
opensc-devel mailing list
opensc-devellists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc
-devel

On Mon, 11 Feb 2008 14:54, ludovic.rousseaugmail.com
said:

> Do we have ASN.1 experts on this list?

As a quick check you might want to run dumpasn1 on the data.
 dumpasn1
is the most important tool when it comes to ASN.1 encoding
debugging.
It is also worth to read Peter Gutmann's x509 style guide to
learn about
all the incompatibilities.  See http://www.cs.
auckland.ac.nz/~pgut001/ .

A good book on ASN.1 is by Oliver Dubuisson and also
available online at
http://www.oss
.com/asn1/dubuisson.html .


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Auschnahme regelt ein
Bundeschgesetz.

_______________________________________________
opensc-devel mailing list
opensc-devellists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc
-devel

On Feb 11, 2008 2:54 PM, Ludovic Rousseau
<ludovic.rousseaugmail.com> wrote:
> Hello,
>
> It looks like the functions asn1_encode_integer() and
> sc_asn1_decode_integer() from src/libopensc/asn1.c are
not correct.
>
> For example the integer 128 is encoded 0x80 but should
be encoded 0x00
> 0x80. 0x80 is the encoding of -128
> -128 is encoded FF FF FF 80 but I don't know if that is
a valid coding.
>
> I am not expert in ASN.1 so am not sure it is a bug.
> I found ASN.1 encoding examples in [1]:
> ##
> ## INTEGER (tests 13 - 21)
> ##
>
> my %INTEGER = (
>   pack("C*", 0x02, 0x02, 0x00, 0x80),        
128,
>   pack("C*", 0x02, 0x01, 0x80),              
-128,
>   pack("C*", 0x02, 0x02, 0xff, 0x01),        
-255,
>   pack("C*", 0x02, 0x01, 0x00),              
0,
>   pack("C*", 0x02, 0x03, 0x66, 0x77, 0x99),  
0x667799,
>   pack("C*", 0x02, 0x02, 0xFE, 0x37),       
-457,
>   pack("C*", 0x02, 0x04, 0x40, 0x00, 0x00,
0x00),            2**30,
>   pack("C*", 0x02, 0x04, 0xC0, 0x00, 0x00,
0x00),            -2**30,
> );
>
>
> I propose the attached patch for
asn1_encode_integer().
> sc_asn1_decode_integer() should also be patched.

The patch was not complete. The encoding of negative values
was also wrong.

A complete patch is attached.

sc_asn1_decode_integer() should still decode INTEGERs
encoded with the
old/bogus encoding function.

If nobody complains I will commit the patch.

Bye,

[1] http://search.cpan.org/src/GBARR/Convert-ASN1-0.21/
t/00prim.t

-- 
 Dr. Ludovic Rousseau

_______________________________________________
opensc-devel mailing list
opensc-devellists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc
-devel