Re: [openssl-users] engine interface for genrsa

[ojike asharpel]

Hello dear,
I joined these group so that l can get assistance for my research work.
Up till now, l have not been able.

Here is my problem.

My Project is an Msc Research on HTTPS Man-In-The-Middle (MITM) Attack
using a Compromised Certificate Authority.
Now I am going to be very elaborative so that you can read my mind and
understand what I want to achieve.
I have a Journal base paper am already working on. The author designed a
new HTTPAS (HTTP Active Secure) … These are the major work he did on his
project. He designed a HTTPAS framework that will enhance Client-Server web
Authentication and make the web authentication more comprehensive incase a
MITM attacker has compromised one or few Certificate Authorities.
Note: The MITM attacker has different vantage point and different attacking
patterns. For the
man-in-the-middle variant ①, the vantage point is close to the victim web
user (e.g. a gateway or a wireless access point of the victim user is
compromised by man-in-the-middle attackers), and
the attackers can blindly hijack all the HTTPS connections from the victim
user to any remote web sites (i.e. the attacking pattern is non-selective
hijacking).
Another Variant 2 takes the case that the vantage point is nearby web
servers. This variant is harder to detect than the others, because nearly
all the Internet paths to the victim web server necessarily pass through
the vantage point.
Look at his designs

He designed a client-side countermeasure which enables a web user to
actively collect site certificates from n different web sites. A
man-in-the-middle attack can be confirmed if these n certificates are
issued from less than μ CAs. (This countermeasure is based on a key insight
that a large number of site certificates from different Internet domains
are unlikely issued by the same CA, only if a man-in-the�middle variant is
launched with a single compromised CA.)
He also designed another Client-side countermeasure by enabling web users
to actively collect site certificates from other web servers of the same
web site. The key insight of this countermeasure is that popular web sites
usually deploy a large distributed system of servers across the Internet to
serve end users from different regions for high availability and
performance (i.e. content delivery network or CDN in short). These web
servers are likely to use the certificates issued from the same CA, while
the man-in-the-middle vantage point near one web server is unlikely to be
close to others, especially the ones located in a different geographical
region.
Concerning his implementations, please read very well…. “We evaluate these
performance overheads

by implementing a prototype of HTTPAS using OpenSSL stacks. Our HTTPAS
prototype runs additional certificate collection and verification tasks in
a parallel manner. We achieve this parallel solution by exploiting the C++
multi-threading programming. We conduct the performance evaluation by
running our HTTPAS prototype implementation in a virtual machine and a real
machine, both of which are located in our laboratory with 8-core 2.67 GHz
central processing unit and 6 GB memory. We use the virtual machine for
HTTPAS performance evaluation due to a very practical reason: lots of
modern web sites are now hosted by cloud computing environments, where
virtual machines are the web servers running behind.



Dear friends, l need help, even though,it might require some financial
involvement.  I all respect that. I want to replicate this work and also
improve it

On Apr 20, 2018 3:46 AM, "Scott Wisniewski" 
wrote:

> FYI:
>
> If you provide an genrsa implementation in your engine that doesn't
> include the private parameters, even if it's marked with RSA_FLAG_EXT_PKEY,
> the openssl executable will not handle it correctly.
>
> That's because genrsa_main assumes that the object that comes back is an
> rsa private key. So it will attempt to save a PEM encoded RSA private key
> even though it doesn't have the private key fields and openssl won't be
> able to open the saved file.
>
> So, if you want to enable use of the openssl executable with genrsa being
> supported by your engine, you will actually need to modify apps/genrsa.c So
> that genrsa_main does:
>
> if (RSA_test_flags(rsa, RSA_FLAG_EXT_PKEY) == RSA_FLAG_EXT_PKEY) {
>
> if (! PEM_write_bio_RSA_PUBKEY(out, rsa))
>
> goto end;
>
> }
>
> else {
>
> if (!PEM_write_bio_RSAPrivateKey(out, rsa, enc, NULL, 0,
>
>  (pem_password_cb *)password_callback,
>
>  _data))
>
> goto end;
>
> }
>
> instead of:
>
> if (!PEM_write_bio_RSAPrivateKey(out, rsa, enc, NULL, 0,
>
> (pem_password_cb *)password_callback,
>
> _data))
>
>goto end;
>
> And then it will save the key you generated in public key pem format.
> which will allow openssl to read it.
>
> One thing to note:
>

Re: [openssl-users] gpgsm/cms: int_rsa_verify:wrong signature length

[Salz, Rich via openssl-users]

Yeah, you're probably right.  I was distracted, should have  looked closer.
 

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] gpgsm/cms: int_rsa_verify:wrong signature length

[Viktor Dukhovni]

> On Apr 23, 2018, at 7:44 PM, Salz, Rich via openssl-users 
>  wrote:
> 
> Your key starts with EF...  Since that has the high-bit on, it should be 
> encoded with a leading zero.

Are you sure?  That does not look like a key to me...

More likely to be the signature block.  The broken one
is one byte shorter, and perhaps the issue is that the
RSA encrypted data has a leading byte that happens to
be zero (1 chance in ~<256 depending on high bytes of
modulus), and this got left out. Hence:

 int_rsa_verify:wrong signature length:../crypto/rsa/rsa_sign.c:132:

The code in question is:

   if (siglen != (size_t)RSA_size(rsa)) {
   RSAerr(RSA_F_INT_RSA_VERIFY, RSA_R_WRONG_SIGNATURE_LENGTH);
   return 0;
   }

which clearly shows that signature lengths are expected to be
exactly the same size as the modulus (padded with leading zeros
as needed).

Note that per:

   https://tools.ietf.org/html/rfc8017#section-8.2.1

the signature length MUST be the same as the modulus length.
A 256-byte modulus goes with a 2048-bit key.

-- 
Viktor.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] gpgsm/cms: int_rsa_verify:wrong signature length

[Salz, Rich via openssl-users]

Your key starts with EF...  Since that has the high-bit on, it should be 
encoded with a leading zero.

 

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] gpgsm/cms: int_rsa_verify:wrong signature length

[Andreas Fenkart]

Hi,

I am using GnuPG to sign 'swupdate' update images, that are verified on the
target using openssl:

  gpgsm -o sw-description.sig -sb sw-description

swupdate links against the openssl, but the equivalent cmd line is:

  openssl cms -verify -in sw-description.sig -inform DER -content
sw-description \
-CAfile mycert.cert.pem -binary

This works for quite a while with no problem, just suddenly I see this error
when verifying

  140250102395072:error:04091077:rsa routines:int_rsa_verify:wrong
signature length:../crypto/rsa/rsa_sign.c:132:
  140250102395072:error:2E09809E:CMS
routines:CMS_SignerInfo_verify:verification
failure:../crypto/cms/cms_sd.c:738:

gpgsm verfication though works.

Comparing the asn1parse output of working/non-working signatures, I can see
that the non-working signature is 1-byte longer then the working version

$ diff /tmp/works /tmp/broken
76,77c76,77
<   929:d=3  hl=4 l= 561 cons: SET
<   933:d=4  hl=4 l= 557 cons: SEQUENCE
---
>   929:d=3  hl=4 l= 559 cons: SET
>   933:d=4  hl=4 l= 555 cons: SEQUENCE
105c105
<  1234:d=5  hl=4 l= 256 prim: OCTET STRING  [HEX
DUMP]:EF4378D3F5AFDE79974518722EA1B12F7DE7C71239B03676378A9B2AC7F5BB76AF91DFE05B004AA0C68CAD8CE54021C61CD49943BA513888D29A6B5AD41942FC57BCBFE1A1B68607EC875434119A28DC6C3463CE4C9B0C948E89C93CB18B7FFDBCDAB6467501E15CD5B603CAA8693DBF27B70B624F15E2BE0A1BD02EB26E619D2EC6A8A939BAB6CA169ABB6A0A76319AD9208728AE566312B63281D03B77B0A38A46FB63FFF5741D4484B14CBF46D092B42D3878AA333CA6CDF6A2412B4DA4DB2AD2DE401506D9B7C24B6CEC18160BC1CBF30426217C27C4CCFDB3B444BBE9C2C9A95D12925A77FA6E6795DE4FFE223C943F15823BC642483F0244A7551052AE
<  1494:d=3  hl=2 l=   0 prim: EOC
<  1496:d=2  hl=2 l=   0 prim: EOC
<  1498:d=1  hl=2 l=   0 prim: EOC
---
>  1234:d=5  hl=3 l= 255 prim: OCTET STRING  [HEX 
> DUMP]:AE0DAC25E87228FF787FD632BC056BC26601E5077537435AD5F653F52B1D13C5194E1B2E35DBD09C059EE55092575CBB7F9AD5B23F5599CC7009BB494FD96CD2C1D4CD5BC0EE674713ADCA41322BCEF25EC1EDB25EAE308E668E30298C88660917775AA76CCF1E60FA8941181B6F1E7D96600A8B9116ABFDDA7A3AFB4D17B15CC8B761EDE09D6E3B6A257B2F1E129A1BE1F192B8E684B872ACA72BDEC7F482D568ABF482EBB97F5A24D0D14281AD8AF169204A395071C96BF2F4BB780EBD3ABD640D373CA8F0EB7AE46CA37E8A8D5E2DB575354DF79F46E004B700E0FC50F06AD8670FD6855B62B7F1279C2A0640794485A824760ED681C4BF9E2742A0698D
>  1492:d=3  hl=2 l=   0 prim: EOC
>  1494:d=2  hl=2 l=   0 prim: EOC
>  1496:d=1  hl=2 l=   0 prim: EOC


This is my gpgsm version, I did not upgrade to the latest version yet

  $ gpgsm --version
  gpgsm (GnuPG) 2.1.7-unknown
  libgcrypt 1.6.3
  libksba 1.3.3-unknown
  Copyright (C) 2015 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.


Any idea?

kind regards,
Andi
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] engine interface for genrsa

[William Roberts]

On Thu, Apr 19, 2018 at 7:45 PM, Scott Wisniewski
 wrote:
> FYI:
>
> If you provide an genrsa implementation in your engine that doesn't include
> the private parameters, even if it's marked with RSA_FLAG_EXT_PKEY, the
> openssl executable will not handle it correctly.
>
> That's because genrsa_main assumes that the object that comes back is an rsa
> private key. So it will attempt to save a PEM encoded RSA private key even
> though it doesn't have the private key fields and openssl won't be able to
> open the saved file.
>
> So, if you want to enable use of the openssl executable with genrsa being
> supported by your engine, you will actually need to modify apps/genrsa.c So
> that genrsa_main does:
>
> if (RSA_test_flags(rsa, RSA_FLAG_EXT_PKEY) == RSA_FLAG_EXT_PKEY) {
>
> if (! PEM_write_bio_RSA_PUBKEY(out, rsa))
>
> goto end;
>
> }
>
> else {
>
> if (!PEM_write_bio_RSAPrivateKey(out, rsa, enc, NULL, 0,
>
>  (pem_password_cb *)password_callback,
>
>  _data))
>
> goto end;
>
> }
>
>
> instead of:
>
> if (!PEM_write_bio_RSAPrivateKey(out, rsa, enc, NULL, 0,
>
> (pem_password_cb *)password_callback,
>
> _data))
>
>goto end;
>
>
> And then it will save the key you generated in public key pem format. which
> will allow openssl to read it.

Good to know, thanks for the detail.

>
> One thing to note:
>
> None of the open source engines I checked (neither the PCKS11 engine, the
> NCipher engine, nor the CAPI engine) implement the genrsa hook. If you are
> looking for wide compatibility you may wish to ask your clients to do key
> generation using an external utility (as that's how almost everyone else
> does it).

I have only looked at the PKCS11 module, and it's quite limited in
functionality.
I've been extending it submitting patches as they make sense. I just added
random support.


>
> On Fri, Apr 13, 2018 at 5:28 PM, William Roberts 
> wrote:
>>
>> On Fri, Apr 13, 2018 at 2:55 PM, Richard Levitte 
>> wrote:
>> > In message
>> >  on 
>> > Fri,
>> > 13 Apr 2018 09:17:28 -0700, William Roberts  
>> > said:
>> >
>> > bill.c.roberts> I am currently working on writing an openssl engine
>> > bill.c.roberts> to interface with a piece of hardware.
>> > bill.c.roberts>
>> > bill.c.roberts> I am trying to understand how to implement
>> > bill.c.roberts> rsa key generation, where the private key
>> > bill.c.roberts> bytes would not be available.
>> > bill.c.roberts>
>> > bill.c.roberts> I am currently invoking the
>> > bill.c.roberts> command:
>> > bill.c.roberts>
>> > bill.c.roberts> openssl genrsa -engine foo
>> > bill.c.roberts>
>> > bill.c.roberts> Which is calling my callback for RSA keygen, registered
>> > via ENGINE_set_RSA()
>> > bill.c.roberts> and I set the flags: RSA_FLAG_EXT_PKEY.
>> > bill.c.roberts>
>> > bill.c.roberts> However, genrsa app seems to want rsa->e set here:
>> > bill.c.roberts>
>> > https://github.com/openssl/openssl/blob/OpenSSL_1_0_2g/apps/genrsa.c#L291
>> > bill.c.roberts>
>> > bill.c.roberts> I can't find documentation on how to handle the keygen
>> > interface
>> > bill.c.roberts> for RSA.
>> > bill.c.roberts>
>> > bill.c.roberts> Can someone point me in the right direction?
>> >
>> > e and n are public components of any RSA key pair (and RSA structure
>> > in OpenSSL).  You *must* make them available.  The rest of the numbers
>> > are private and do not need to be part of the RSA structure that
>> > OpenSSL handles.
>>
>> Thanks. I went and read the RSA page on Wikipedia, and sure enough it
>> has what common meanings of what all the single letter variables
>> are in the RSA struct.
>> https://en.wikipedia.org/wiki/RSA_(cryptosystem)
>>
>> >
>> > Cheers,
>> > Richard
>> >
>> > --
>> > Richard Levitte levi...@openssl.org
>> > OpenSSL Project http://www.openssl.org/~levitte/
>> > --
>> > openssl-users mailing list
>> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users