EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Java Bouncy Castle and SecureBlackBox compatability problem?

Posted: 05/02/2007 16:36:23
by Sergey Sarnavskiy (Basic support level)
Joined: 05/02/2007
Posts: 4

Hi all,

Here's my problem:
My company has some webservices that our clients can interact with, one of wich is Authentication by Certificate. The way it works is they Sign the user name they wish to use with their private key, and send the result with some information about their certificate to us. We use their private key(get the right one from the certificate stuff they send us) to decrypt the signature and verify that such a user really belongs to them. The mechanism for verifying the signature on our side uses your SecureBlackBox.

I am the QA Automation person for our company, so I'm currently trying to write client side code to sign the username. All my code is written in Java, so I'm forced to use Java's Bouncy Castle Cryptography Library
to do the signing (our customers can't be expected to use your product, so I can't be using it to test the signing process). The user name I'm sending in currently is 'xtester16@enviance.com', without the apostrophies, but SecureBlackBox verifies the encrypted string it gets from me, it sees
'$?♦☼xtester16@enviance.com '. I don't really understand where it gets the wierd characters in the beginning from, or why there are space characters attached to the end(padding?). When I try to verify my string through Bouncy Caslte on my side, the verification goes through successfully(can't figure out a way to get back the embedded user name though, verify on my end only seems to give back a boolean result).

Anyway, here my code for Signing:

CMSSignedDataGenerator signedDateGen = new CMSSignedDataGenerator();
signedDateGen.addSigner((PrivateKey)priv, (X509Certificate)cert, CMSSignedDataGenerator.DIGEST_SHA1 );
CMSProcessable content = new CMSProcessableByteArray(inputBuf);
CMSSignedData data = signedDateGen.generate( content, true, "BC" );
byte[] result = data.getEncoded();

So, do you guys have any idea why Signing this way would produce something that SecureBlackBox can't quite verify correctly?
Posted: 05/02/2007 23:26:52
by Ken Ivanov (Team)

Obviously, Java Bouncy Castle performs some data conversion before signing (and the corresponding backward conversion after verifying the message). Most likely, the prefix contains some meta information. Please contact Java Bouncy Castle support for further details about the actual conversion.

BTW, is *validation* result correct (i.e., does TElMessageVerifier.Verify return 0)?
Posted: 05/03/2007 00:48:05
by Eugene Mayevski (Team)

Can you please check the exact codes of the symbols, which are added before the e-mail address? It can be that Bouncy Castle puts some OID or ASN.1 formatting there.

Sincerely yours
Eugene Mayevski
Posted: 05/03/2007 11:45:36
by Sergey Sarnavskiy (Basic support level)
Joined: 05/02/2007
Posts: 4

Ok, the exact hex codes of prefix are:

24 3F 04 0F
$ ? ♦ ☼

Going to post the results of TElMessageVerifier.Verify as soon as one of our developers here checks it for me.
Posted: 05/03/2007 19:14:03
by Sergey Sarnavskiy (Basic support level)
Joined: 05/02/2007
Posts: 4

I just got got some replies from guys on Bouncy Castle message list. They claim that Bouncy Castle doesn't do any data conversion on encapsulated signed content and suggest that I might not be using the DER String encoding method that you guys support. I'm using String.getBytes(userName);.

I'll also get a developer here to check our server code, perhaps the error message we're seeing is just coded wrong and the wierd characters appear as the result of that.
Posted: 05/07/2007 12:10:33
by Sergey Sarnavskiy (Basic support level)
Joined: 05/02/2007
Posts: 4

Guys at Bouncy Castle figured out what was going on and I was able to send a message that your product read just fine. Here's the last two messages from them explaining what was wrong:

If you use GuiDumpAsn you see a difference in th encoding of:

EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType,


BC has an OctetString embedded in another OctetString. Don't know if this is correct. I don't think so.



I think this explains almost all of what is going on.

The BC encoding is a correct BER encoding - it's a constructed octet string, ie. an indefinite length octet string which is essentially a collection of DER encoded octet strings terminated by a two 0 bytes.

I probably should have thought of this earlier, were it not for a couple of weirdities.

Firstly the header you're seeing:

24 3F 04 0F
$ ? ♦ ☼

This is wrong, the second byte should be 0x80, otherwise I probably would have recognised it straight off, the fourth byte is also wrong (assuming you're getting one byte per character for the email address)

Second the blank "padding", which is also wrong as both those bytes are actually zero.

Third, in this case the octet string is explicitly tagged - it should have at least tried to interpret the first two bytes as the octet string header. I'd guess what you're actually been given is debug output based on how many bytes it could pick up from the encapsulated content info structure. It has probably given up, thinking the encapsulated info cannot be interpreted. If this is the case it explains everything.

There's a couple of things you can try to do to work around this.

The first thing to check is that something isn't happening to convert the 0x80 byte into an 0x3f before they get the message, such an encoding is clearly invalid in this case - there isn't enough data to provide that many bytes.

The second is that a lot of people that don't handle indefinite length BER still handle constructed strings providing they are specified with a definite length. You can try sending them a message by using an ANS1InputStream to reread the contents of CMSSignedData.getEncoded() and then writing the object out to a DEROutputStream, this will mean all the structures are encoded using definite length headers, and it may mean they can process the message.

Failing that you can take the extreme measure of changing the BC code to generate a single DEROctetString for the encapsulated content and see if that works for them, or you can ask them to fix the bug and properly recognise BER data (it's really not that hard, and mandatory if you need to handle large messages), we have people using the CMS streaming API to encapsulate and sign or encrypt messages that are man giga-bytes in size, you can't do this on a limited memory machine if you can't use BER.

If you need any clarification feel free to ask.




Anyway, I used his suggestion to encode all my structures with definite length headers and SecureBlackBox verified it 8)

Thank you for your help as well,
Sergey Sarnavskiy
Posted: 05/07/2007 12:32:06
by Eugene Mayevski (Team)

Thanks for the information. I suspected that the contents were a wrapped data, but, as support mentioned, the bytes in the prefix are not correct, so we couldn't recognize them either.

Sincerely yours
Eugene Mayevski



Topic viewed 5580 times

Number of guests: 1, registered members: 0, in total hidden: 0


Back to top

As of July 15, 2016 EldoS business operates as a division of /n software, inc. For more information, please read the announcement.

Got it!