Re: How do calculate the
>Or is that an attacker wouldn't be able to figure out how to format the parameters? Bingo. Nor will he know valid values for those parameters. If someone goes to the trouble to run the app in an environment where he can scrutinize memory contents, then he can figure all this out. But that's beyond what I'm trying to prevent.
Re: How do calculate the
On 5/18/2011 3:27 AM, G S wrote: I'm probably being obtuse here, but I don't see how encrypting your request with a public key would help you with your original problem. What stops a rogue app from doing the same encryption? They can't see what the parameters are. So what are they going to encrypt? I think you're missing the point, or I'm misunderstanding what you mean by "parameters". Your stated problem was to detect whether a request was originating from your app or not. No solution to this will work unless somehow your app can do something that a fake/spam app cannot do. Your solution was: > 1. Generate a random key and initialization vector to encrypt > the block of text. So a rogue app can generate its own block of text, presumably containing the spam or what not, and it can also certainly generate a random key and IV. > 2. Encrypt that random key with the RSA public key. A rogue app can do this unless you can somehow keep the public key private. This may be possible, but most likely an attacker could extract the key from your application. > 3. Encrypt the data payload with the random key and IV, > using Blowfish or other encryption. Surely an attacker can do this. > 4. Send the encrypted data payload, encrypted random key, and IV to > the server for decryption. Again, no reason an attacker can't do this. So either I'm misunderstanding you, or your method won't actually do anything. Or is the thinking that an attacker won't be able to extract the public key? Or is that an attacker wouldn't be able to figure out how to format the parameters? DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] CA
Hi Erwann! On 05/19/2011 10:20 AM, Erwann ABALEA wrote: "old" end-user certificates can only be verified by the "old" CA certificate, of course (in case the CA is "renewed", with its key changed, etc). I didn't "renew" the CA certificate, I've used the existing private key to create thr new one. >> The only way I found was to give the new Root Certificate the same >> serial number as the previous one. > > That's forbidden by X.509 standard. And the serial number has nothing > to do with the SKI/AKI. I agree, using the same serial number seems to be not valid. But, according to RFC 3280 the Authority Key Identifier "MAY be based on either the key identifier ... or on the issuer name and serial number". My Root CA Certificate and user certificates shows exactly this information: Root CA Certificate: X509v3 Subject Key Identifier: A8:C3:14:22:3A:48:50:66:78:89:97:02:A8:B0:CE:D3:EE:FC:0F:1E X509v3 Authority Key Identifier: keyid:A8:C3:14:22:3A:48:50:66:78:89:97:02:A8:B0:CE:D3:EE:FC:0F:1E DirName: serial:1C:26:30:4D:53:64:7A:83 User Certificate: - X509v3 Subject Key Identifier: 7C:F7:66:B5:A4:83:42:1A:FF:AA:CB:0D:07:37:8A:81:E7:48:B8:1D X509v3 Authority Key Identifier: keyid:A8:C3:14:22:3A:48:50:66:78:89:97:02:A8:B0:CE:D3:EE:FC:0F:1E DirName: serial:1C:26:30:4D:53:64:7A:83 So the Root CA Certificate serial number is part of my X509v3 Authority Key Identifier. > Did you change the private key of the CA? If not, then: > - the SKI of the new CA certificate will be the same as the old > certificate (it's a *Key* identifier, and is generally constructed > from the public key) I didn't change the private key, so the X509v3 Subject Key Identifier is always the same, right. > - you don't need to have the same serial number (remember, it's > forbidden by X.509 standard) Right, I've check that with RFC 2459. - you will be able to verify old end-user certificates with the new CA certificate (since the CA key didn't change), if the rest of the CA certificate permits it (validity dates, extensions). This seems to be a problem if you're using openssl to verify the certificate. I've generated a new CA certificate with the same CA key as before. But only the verification with the "old" CA certificate was working. #> openssl verify -CAfile newca.pem user_cert.pem user_cert.pem: error 20 at 0 depth lookup:unable to get local issuer certificate According to old threads on this list this message has something to do with the AKID/SKID. > If you were in this situation, and only were able to verify end-user > certificates if the new CA certificate had the same serial number as > the old one, then I'm sure you made a mistake in your tests. I agree, maybe I did something wrong here. What steps would I have to do to recertify my CA with openssl? Cheers, Alex __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] CA
Hi Erwann! On 05/19/2011 10:20 AM, Erwann ABALEA wrote: "old" end-user certificates can only be verified by the "old" CA certificate, of course (in case the CA is "renewed", with its key changed, etc). I didn't "renew" the CA certificate, I've used the existing private key to create thr new one. The only way I found was to give the new Root Certificate the same serial number as the previous one. That's forbidden by X.509 standard. And the serial number has nothing to do with the SKI/AKI. I agree, using the same serial number seems to be not valid. But, according to RFC 3280 the Authority Key Identifier "MAY be based on either the key identifier ... or on the issuer name and serial number". My Root CA Certificate and user certificates shows exactly this information: Root CA Certificate: X509v3 Subject Key Identifier: A8:C3:14:22:3A:48:50:66:78:89:97:02:A8:B0:CE:D3:EE:FC:0F:1E X509v3 Authority Key Identifier: keyid:A8:C3:14:22:3A:48:50:66:78:89:97:02:A8:B0:CE:D3:EE:FC:0F:1E DirName: serial:1C:26:30:4D:53:64:7A:83 User Certificate: - X509v3 Subject Key Identifier: 7C:F7:66:B5:A4:83:42:1A:FF:AA:CB:0D:07:37:8A:81:E7:48:B8:1D X509v3 Authority Key Identifier: keyid:A8:C3:14:22:3A:48:50:66:78:89:97:02:A8:B0:CE:D3:EE:FC:0F:1E DirName: serial:1C:26:30:4D:53:64:7A:83 So the Root CA Certificate serial number is part of my X509v3 Authority Key Identifier. Did you change the private key of the CA? If not, then: - the SKI of the new CA certificate will be the same as the old certificate (it's a *Key* identifier, and is generally constructed from the public key) I didn't change the private key, so the X509v3 Subject Key Identifier is always the same, right. - you don't need to have the same serial number (remember, it's forbidden by X.509 standard) Right, I've check that with RFC 2459. - you will be able to verify old end-user certificates with the new CA certificate (since the CA key didn't change), if the rest of the CA certificate permits it (validity dates, extensions). This seems to be a problem if you're using openssl to verify the certificate. I've generated a new CA certificate with the same CA key as before. But only the verification with the "old" CA certificate was working. #> openssl verify -CAfile newca.pem user_cert.pem user_cert.pem: error 20 at 0 depth lookup:unable to get local issuer certificate According to old threads on this list this message has something to do with the AKID/SKID. If you were in this situation, and only were able to verify end-user certificates if the new CA certificate had the same serial number as the old one, then I'm sure you made a mistake in your tests. I agree, maybe I did something wrong here. What steps would I have to do to recertify my CA with openssl? Cheers, Alex __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl-users] Quick eyeball requested - self generate openssl certs/CA
Serial Number/Randomness apart; how many certificates would you expect to issue in a year? How would you deploy the cert for trust among the different browsers? You should ensure that your certificates for SSL usage specify the appropriate EKU OID, in addition to path and issuance restrictions. - SSL/TLS Web Server Authentication serverAuth 1.3.6.1.5.5.7.3.1 -Eduardo > Date: Thu, 19 May 2011 11:28:30 -0700 > To: openssl-users@openssl.org > From: fl...@vicsmba.com > Subject: Re: [openssl-users] Quick eyeball requested - self generate openssl > certs/CA > > A very simple one -- tax the time stamp register or the 4 byte cycles > since 1970, and concatenate the process id (which is unique for a > long time). The same process id cannot get either of those two > numbers in two calls to be the same. Eric > > At 10:24 AM 5/19/2011, you wrote: > >On Thu May 19 2011, Tim Watts wrote: > > > I think I might add some "randomness" into mine - seems easy enough. I > > > won't pretend I fully understand why - mostly because I wasn't clear why > > > the serial is important. > > > > > > >If your CPU has a 'time stamp register' (cycle counts since power-up) - > >You can grab those contents as your counter (usually 8 bytes worth). > >Since this counter advances rapidly (GHz range today) it is unlikely > >you will ever have two machines, or two serial number creations, that > >strike at the same clock cycle since power-up. > >(Thats a pretty small target to hit.) > > > >Usually that will cost you one or two machine cycles to read the counter. > >Relatively fast way to get "an 8 byte number I haven't used before". > > > >Concantinate that with 8 bytes of something else of your choice that > >doesn't vary with the clock cycles since power up. > >If truly paranoid - 'whiten' with the hash function of your choice. > >(or with AES as in another post here - many machines can do AES in hardware.) > > > >Mike > > > >__ > >OpenSSL Project http://www.openssl.org > >User Support Mailing List openssl-users@openssl.org > >Automated List Manager majord...@openssl.org > > > Eric S. Eberhard > (928) 567-3727 Voice > (928) 567-6122 Fax > (928) 301-7537 Cell > > Vertical Integrated Computer Systems, LLC > Metropolis Support, LLC > > For Metropolis support and VICS MBA Support http://www.vicsmba.com > > Pictures of Snake in Spring > > http://www.facebook.com/album.php?aid=115547&id=1409661701&l=1c375e1f49 > > Pictures of Camp Verde > > http://www.facebook.com/album.php?aid=12771&id=1409661701&l=fc0e0a2bcf > > Pictures of Land Cruiser in Sedona > > http://www.facebook.com/album.php?aid=50953&id=1409661701 > > Pictures of Flagstaff area near our cabin > > http://www.facebook.com/album.php?aid=12750&id=1409661701 > > Pictures of Cheryl in a Horse Show > > http://www.facebook.com/album.php?aid=32484&id=1409661701 > > > Pictures of the AZ Desert > > http://www.facebook.com/album.php?aid=58827&id=1409661701 > > (You can see why we love this state :-) ) > > > > > > > > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org
Re: [openssl-users] CA
Hodie XIV Kal. Iun. MMXI, Dave Thompson scripsit: > > From: owner-openssl-us...@openssl.org On Behalf Of Erwann ABALEA > > Sent: Thursday, 19 May, 2011 04:20 > > > Hodie XV Kal. Iun. MMXI, Alex Bergmann scripsit: > > > > The only way I found was to give the new Root Certificate the same > > > serial number as the previous one. > > > > That's forbidden by X.509 standard. And the serial number has nothing > > to do with the SKI/AKI. > > > There are (at least) two kinds of AuthorityKeyIdentifier. > > AKI=SKI identifies only the parent (CA) key (by hash), > and is ambiguous if CA gets new cert for same key. > > AKI=issuerSerial *does* use parent (CA) serial. You're right, the AKI extension can be populated with these 2 informations (in fact, really 3, but 2 of them are linked together in the X.509, and not in RFC5280). -- Erwann ABALEA Département R&D KEYNECTIS - ``Do or do not. There is no try." Yoda __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
