VOIP Tech Chat → Re: Provisioning of the OBi100/110/202 (Made Easy)

I'm not RonR but I have way too much experience working with Obihai provisioning and encryption.

One of the problems I had was if my input file was not a multiple of (going from memory here) 16 bytes, the last bit of the file would end up being decrypted as jibberish which caused the OBi device to discard the whole configuration as invalid.

Solution is to pad your input file with spaces so the file size is a multiple of 16.

I wouldn't be surprised if you ran into the same problem. Of course maybe you found something else altogether.

Syslog logging helped get to the bottom of this in my case.

Wow!!! That was a bull's eye shot

What is the probability of the event when file size is not a multiple of 16 bytes? That's exactly was my chance to make it working...

Huge thumbs down to developers of OBi who did not take care about it and actually did not mention about it (at least I can't see that) in the section of the OBi Device Provisioning Guide, described how to make encrypted provisioning work

This hidden "feature" (I'd rather say - bug) makes my work much harder. Especially if my text editor trims extra white spaces from lines... One more hindrance to remember to jump over while working with other problems.

Thanks a lot, Trev !

And BTW, when I decoded the encrypted configuration file using openssl enc -d .. command it produced correct XML file, exactly as the source. I've checked it, when I tried to troubleshoot this sudden problem...

Yay!Yup... I am sure I lost a solid 20 hours to this until I realised what was going on. Some config files work, most didn't, lots of attempts to isolate which parameters were causing the issue... all I can say is I'm very glad to have been able to help someone else out.I'm fairly confident it's a bug in their decryption function. I let them know about it a few months back when I discovered it but I guess they haven't had a chance to address it yet.

I think you'll find that anything properly encrypted with aes-128-cbc will have a resulting file size that is a multiple of 16. If you're ending up with an encrypted file whose size is not a multiple of 16, it's probably due to a bug in the openssl program you're using. None of the pre-encrypted XML files I've fed to openssl have had a file size that was a multiple of 16, but all of the encrypted output files from openssl are a multiple of 16 and OBi's have never failed to decrypted them properly.

Yes the resulting encrypted file should be a multiple of 16 but the ultimate decrypted plaintext file may not be. I understand there is padding (IIRC if you need 3 bytes of padding, those bytes become 0x03 or something like that) for the purpose of being able to encrypt the whole block, but that padding should be removed when the original content is reconstituted.

Edit: for the record: OpenSSL 1.0.0j 10 May 2012

We've talking about .XML files (plain text) here. Not about encrypted (binary) files.

I've made multiple tests with different source files (all of them have sizes not equal to multiple 16) and openssl (v0.9.8d in my case) decrypts encrypted files exactly as their respective sources. Binary comparison is 1 to 1.

It's the problem with decryption algorithm, used within OBi, that creates that trouble...

I don't know what to tell you. None of the source XML files here are a multiple of 16 bytes in length. Whether I send them to an OBi as a plain-text XML file or a gzip'ed XML file or an AES/RC4 encrypted XML file, the OBi's happily accept them and set the appropriate parameters.