Currently we provision our customers' adaptors by providing each adaptor the address of a TFTP server as part of the DHCP response. The config files reside on the server but presently in unencrypted form. How can we encrypt these and still have the adaptor understand them? The documentation does give a couple of hints but is confusing and seems to assume an https solution, which isn't really appropriate given the TFTP solution we use (we could change, but it is an upheaval I would rather avoid - I'd rather simply provide encrypted files on the TFTP server).
If you use tftp, you can encrypt them using e.g. the MAC address as the encryption key of the device. The provisioning guide (in the documentation section) provides information about how to accomplish it: basically you need to encrypt the file (using SPC) with the key (recommend MAC address as then you dont need to pass the key to the device), and then in the device profile rule, need to include the encryption key as a token. I recommend you have a look at the provisioning guide as it explains the mechanism.
Thanks for your answer. By "SPC" you mean the Profile Compiler, right? We don't use that at present - can we use openssl as described in the provisioning guide and get the same behaviour/results?
I don't understand when you say at one point "basically you need to encrypt the file [...] with the key (recommend MAC address as then you dont need to pass the key to the device)" and then "in the device profile rule, need to include the encryption key as a token". So if I use something like:
openssl enc –e –aes-256-cbc –k
to encrypt each config file which then get placed on the TFTP server, do the adaptors need to be separately informed of the keys/passphrases or not?
If the paraphrase is the MAC or serial number, it is not required as these are MACRO variables on the device. Check the provisioning guide for a full explanation about how to use MACROS.
I seem to have encrypted the file correctly (I can decrypt it using "openssl enc -d ..." as mentioned in the documentation), but the adaptor I am using to test this on is not showing the new values, so I'm not sure if it is not requesting the file from the TFTP server (that part is out of my hands, and there does not seem to be any log information anywhere) or if the adaptor cannot decrypt the file it fetches.
Is there any way to find out from the adaptor when it last tried to download a config file, why the fetch or decrypt might have failed, or anything like that? Or is there some way I can hand it the encrypted file "directly" so I know it gets it (that would at least tell me that if the changes still don't take then something in the encryption/decryption is incorrect)?
An additional point: how should the MAC address be formatted when used as the passphrase? For example if the MAC is 00:25:9C:6D:08:45 one could use that as the passphrase, or without the ":"s, or lowercase 00:25:9c:6d:08:45, or lower case without ":"s. Did I miss anything out?
The error is in the encryption string. This is because the unit can download the file but can't read it.
That's because the guide mentioned here in the "string" is wrong.
If you are using XML as a configtemplate and unix you can do this:
To encrypt a file you need to do two thing
1. zip the file using
2. encrypt the file using openssl
openssl enc -e -aes-256-cbc -k passkey -in file.xml.gz -out file.cfg
This works as long as you place the correct value in Profile rule.(this downloads a lowercase macaddress file ex. 0000aaaabbbb.cfg)
This only works with xml!!!
For plaintext configs you might want to use the SPC tool created by Cisco.
create the file and write this in a windows command window
spc --aes --ascii-key passkey file.txt file.cfg
If you want to be able to decrypt the files (if you are using a configenerator that also encrypts the files) i would recommend the use of XML.
Only thing you then have to do to decrypt the files are:
openssl enc -d -aes-256-cbc -k passkey -in file.cfg -out file.xml.gz
> That's because the guide mentioned here in the "string" is wrong.
What do you mean? What "string"?
> If you are using XML as a configtemplate
> 1. zip the file using
Why? Why on earth would I need to compress it? Please stop trying to complicate matters.
> This works as long as you place the correct value in Profile rule.(this downloads a lowercase macaddress file ex. 0000aaaabbbb.cfg)
That's exactly what I get - the file on the tftp server is named exactly as you said. Whether I should use this lower case value as the passphrase, uppercase, with or without the typical ":" separation characters seems to be completely unknown. I can confirm that 00259a6b01666 for example does not work, neither does 00259A6B01666. The config file is successfully retrieved from the tftp server, however.
> If you want to be able to decrypt the files (if you are using a configenerator that also encrypts the files) i would recommend the use of XML.
Only thing you then have to do to decrypt the files are:
I can do this on the command line. The problem occurs in "live" use when the adaptor itself tries to decrypt the config.
When it comes to the "string" i just meant the string of replies.
if you wonder why on earth you need to compile please ask linksys/cisco that question. That is what is written in the admin prov docs.
Yes. the unit recognizes the file when it decrypts the .cfg file. if it finds a txt file it opens it straight away.
But the xml files needs to be compressed to an archivel, dont know why. its just how it is.
Odd. The Provisioning Guide I have says "The SPA configuration profile open format consists of a text file (with XML-like syntax), optionally
compressed using the gzip deflate algorithm (RFC1951), and further optionally encrypted" (my emphasis) and the examples don't seem to indicate a compressed file:
Example 2-8 Encrypting the Configuration Profile
# example encryption key = SecretPhrase1234
openssl enc –e –aes-256-cbc –k SecretPhrase1234 –in profile.xml –out profile.cfg
Still, I will try it out...
by the way.
are you using @ or $ in you encryption key? that won't work. I've learned that the hard way when using xml.
I had the same problem as you when i tried to implement ata xml files on a https server.
No, just the MAC as suggested by Alberto. So I encrypt an XML config with (for example):
openssl enc -e -aes-256-cbc -k 00259c6d0845 -in 00259c6d0845.cfg -out 00259c6d0845.cfg
and can happily decrypt the resulting file on the command line as well, using
openssl enc -d -aes-256-cbc -k 00259c6d0845 -in 00259c6d0845.cfg
I am trying your suggestion of gzipping the config first, now, and will let you know what happens.
No, doesn't work.
Edit: Wait. It's still trying to get the .cfg file...
I don't suppose there is any way of configuring things so that
are you using tftp or http(s)?
what is the server address? i'll create two configfiles so you can test.
also need the macaddress for the unit you are testing on.
btw. what firmware are the units running? and what version of spc are you using?
We're using tftp, but we don't use spc, we create xml config files via our own software that fits in with the rest of our environment. Those files work fine, I'm now trying to add encryption to that to protect the customer information. Firmware version is 5.1.6(LS) apparently. You could try 00:25:9c:6d:08:45 if you want.
Well I don't know what is wrong. I've tried using the MAC as the passphrase/encryption key as advised by Alberto, using both upper and lower case, with and without separating ":"s, and nothing seems to work.