Cryptography January 2007

cryptography@lists.squeakfoundation.org

4 participants
8 discussions

first cut at CertificateExtensions and ASN1 issues
by Robert Withers 29 Jan '07

29 Jan '07

I made a first cut at parsing the CertificateExtensions. I grab the OID and then I do an ASN1 DER decoding of the value. We have shortcomings in the way we decode the tag for DER/BER encodings. We don't decode multi-byte tags for example. When I was decoding the cert extensions, I ran across several new tags, namely 128 and 130. According to ASN1dubuisson.pdf, these are context-specific, primitive types. When we have the high order bit set, we are masking the low order bits. I changed the mask to mask out the high order bit. This means that my 2 tags decode to a ByteArray, while the ExplicitConstructed type (101xxxxx) still decodes correctly. You may want to review my code in Cryptography- ASN package, specifically the ASN1Value class>>#typeClassForTag: Robert

2 8

Re: [Cryptography Team] Re: SSL Certificate Validation
by Rob Withers 27 Jan '07

27 Jan '07

I am not currently parsing the certificate extensions, and discussion of the commonName vs the subjectAltName has always confused me. This would be something that could be worked on with X509. I don't understand what you mean when you say "it's bad practice to put authorization data into an authentication instrument like a certificate". I would think that once a certificate is authenticated, then it's identity (commonName or subjectAltName) could be used for authorization. At least the SSL spec speaks about it working this way. Rob ----- Original Message ---- From: Cerebus <cerebus2(a)gmail.com> To: Cryptography Team Development List <cryptography(a)lists.squeakfoundation.org> Sent: Thursday, January 25, 2007 12:52:22 PM Subject: Re: [Cryptography Team] Re: SSL Certificate Validation Common name FQDNs are deprecated. FQDNs belong in the subjectAltName extension. Also, be aware that issuers are usually designated via the authorityKeyIdentifier extension, not via the issuer DN. Finally, it's bad practice to put authorization data into an authentication instrument like a certificate. You cannot be certain that revocation will be performed in a timely fashion. Authorization decisions should rely on local data using the identity proved by the certificate. On 1/24/07, Robert Withers <reefedjib(a)yahoo.com> wrote: > Ron, > > I should be clear that there are additional validation requirements > that I am not checking. For instance, the commonName of the > certificate is supposed to match the hostname of the server. There > are lots of rules in this area and a careful perusal of the spec is > recommended. > > I think that adding the ability to generate and sign certificates > would be useful. Of course we would need a Squeak root certificate > and private key to do so, unless we stick with self-signed certs. If > we generate a root cert and publish the private key/password, that > would be little different than access to the swiki for upload - and > the same level of security. YMMV. > > When I have a little time, I may look into client certificates. This > will require testing with OpenSSL. I'll keep you informed if I get > into it. > > Rob > > On Jan 24, 2007, at 6:49 AM, Ron Teitelbaum wrote: > > > Very cool Rob! > > > > I've been working with the code, testing on multiple machines and it's > > working well! I haven't been focusing on the actual certificates, > > but will > > need to do so in a few months. I'm hoping to be able to create client > > certificates automatically during installation and to be able to > > renew them > > periodically. For all this to work I'll need to have client and > > server > > certificates working and validated plus a working CA. I'm planning > > on using > > certificate extensions to handle service authorization. I'm very > > pleased > > with the code and how well it responds. I'll start working with > > the new > > code and let you know if I see any issues. > > > > Thank you for your work on this!! > > > > Ron > > > > > >> From: Robert Withers > >> Sent: Wednesday, January 24, 2007 12:29 AM > >> > >> All, > >> > >> I've been doing a little SSL coding, since it isn't a fully developed > >> project yet. The most glaring omission has been the lack of > >> certificate chain processing and validation, thereby leaving a rather > >> large security hole in the implementation. The code still doesn't > >> handle client certificates. > >> > >> I have added the capability for a certificate to verify itself with > >> it's parent certificate. Roughly, this entails comparing the hash of > >> the certificate (tbsCertificate) with its decrypted signature. using > >> the parent certificate's publicKey. The parent is identified as > >> having the same subject as the child's issuer. A self-signed > >> certificate has the same issuer and subject. These are currently > >> allowed. Furthermore, the certificate is valid if the validity dates > >> enclose the current date. > >> > >> The code hook for all this is in > >> SSLSecurityCoordinator>>#validateCertificateChain: certChain > >> > >> The test certificate currently passes, but will expire later this > >> year. > >> > >> I also added the CACert, Verisign and Thawte's root CAs to the > >> SSLCertificateStore, but there is no mechanism to add external root > >> certs. > >> > >> I also coded and tested MD2 hash function, so that some certs can be > >> validated. > >> > >> Changes to the following packages: > >> Cryptography-ASN1 > >> Cryptography-MD4 > >> Cryptography-SSL > >> Cryptography-Tests > >> Cryptography-X509 > >> > >> cheers, > >> Robert > >> > > > > > > _______________________________________________ > Cryptography mailing list > Cryptography(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography > _______________________________________________ Cryptography mailing list Cryptography(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

3 2

SSL Certificate Validation
by Robert Withers 27 Jan '07

27 Jan '07

All, I've been doing a little SSL coding, since it isn't a fully developed project yet. The most glaring omission has been the lack of certificate chain processing and validation, thereby leaving a rather large security hole in the implementation. The code still doesn't handle client certificates. I have added the capability for a certificate to verify itself with it's parent certificate. Roughly, this entails comparing the hash of the certificate (tbsCertificate) with its decrypted signature. using the parent certificate's publicKey. The parent is identified as having the same subject as the child's issuer. A self-signed certificate has the same issuer and subject. These are currently allowed. Furthermore, the certificate is valid if the validity dates enclose the current date. The code hook for all this is in SSLSecurityCoordinator>>#validateCertificateChain: certChain The test certificate currently passes, but will expire later this year. I also added the CACert, Verisign and Thawte's root CAs to the SSLCertificateStore, but there is no mechanism to add external root certs. I also coded and tested MD2 hash function, so that some certs can be validated. Changes to the following packages: Cryptography-ASN1 Cryptography-MD4 Cryptography-SSL Cryptography-Tests Cryptography-X509 cheers, Robert

3 6

Fortuna improved too
by Chris Muller 11 Jan '07

11 Jan '07

I forgot to mention, Fortuna now also will accept nextBits: requests of any size, not just multiples of 8 bits (which its byte-generating nature made very easy). Cheers..

2 1

Cryptography-RandomAndPrime-cmm.11
by Chris Muller 11 Jan '07

11 Jan '07

I hope no one minds, Fortuna is only about 10 methods and a now brother of SecureRandom; so I moved it in.

1 0

Cryptography-Tests-cmm.22
by Chris Muller 11 Jan '07

11 Jan '07

I added some additional tests for our RandomGenerators and made these refactorings in the process: - Moved testByteArrayPadding to CryptoRijndaelTest. - Renamed CryptoMiscTest to CryptoRandomTest. CryptoRandomTest now enumerates all subclasses of SecureRandomGenerator, so Fortuna is included too.

1 0

Re: SSL Error
by Chris Muller 04 Jan '07

04 Jan '07

Happy Holidays Ron! Looking at the differences between Cryptography-Core-rww.17 and Cryptography-Core-cmm.18, one possibility might be sharing the same vector of a BlockCipher with another place? Its real easy to do (particularly in test code) but since it's a ByteArray that, for many modes, modified in place, it cannot be shared. Which primitives is your code using; for example if you're not using CTR mode then we could probably eliminate all 23 changes on that class. I reviewed all of the changes once again between those two versions and they all look good. That leaves the differences between Cryptography-RandomAndPrime-rww.2.mcz and Cryptography-RandomAndPrime-RJT.10.mcz. That was all the SecureRandom refactoring, do you think it might be the cause? - Chris ----- Original Message ---- From: Ron Teitelbaum <Ron(a)USMedRec.com> To: Cryptography Team Development List <cryptography(a)lists.squeakfoundation.org>; chris(a)funkyobjects.org Sent: Tuesday, January 2, 2007 9:39:04 PM Subject: SSL Error Chris and All, It appears that the changes to Cryptography-RandomAndPrime and Cryptography-Core break the SSL Code. If you load Cryptography-RandomAndPrime-rww.2.mcz Cryptography-Core-rww.17.mcz Then run our SSL example code: 'https://tls.secg.org:40023' asUrl retrieveContents. You will get back the proper contents. Loading Cryptography-RandomAndPrime-RJT.10.mcz Cryptography-Core-cmm.18 It breaks with a return message from the server Bad Record Mac. I tried loading each method individually and thought I'd isolated it, but I got inconsistent results. The RJT version of RandomAndPrime was my change to ensure the initial vector had the proper number of bytes. Test to Mac with the new code appears to still be working. I have not been able to isolate the error yet, but I thought I'd mention it incase anyone has an idea about which change is causing the error. Any help would be appreciated. Thanks, Ron Teitelbaum Cryptography Team Leader Happy New Year to everyone!

3 3

SSL Error
by Ron Teitelbaum 03 Jan '07

03 Jan '07

Chris and All, It appears that the changes to Cryptography-RandomAndPrime and Cryptography-Core break the SSL Code. If you load Cryptography-RandomAndPrime-rww.2.mcz Cryptography-Core-rww.17.mcz Then run our SSL example code: 'https://tls.secg.org:40023' asUrl retrieveContents. You will get back the proper contents. Loading Cryptography-RandomAndPrime-RJT.10.mcz Cryptography-Core-cmm.18 It breaks with a return message from the server Bad Record Mac. I tried loading each method individually and thought I'd isolated it, but I got inconsistent results. The RJT version of RandomAndPrime was my change to ensure the initial vector had the proper number of bytes. Test to Mac with the new code appears to still be working. I have not been able to isolate the error yet, but I thought I'd mention it incase anyone has an idea about which change is causing the error. Any help would be appreciated. Thanks, Ron Teitelbaum Cryptography Team Leader Happy New Year to everyone!

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Cryptography January 2007