eSSL - SSL certificates for embedded systems
Nowadays, network technologies are developing so rapidly that until recently the slogan “ Internet in every refrigerator ” seemed crazy , no longer seems fantastic. But at the same time, security issues of embedded devices with a WEB interface with access to the local and, God forbid, to the global network, are becoming relevant. SSL technology is designed to help this by allowing you to work with the WEB interface over the HTTPS protocol, but embedded systems have their own characteristics here.
SSL technology allows you to encrypt traffic between two devices. You probably know that SSL certificates are issued to web sites and are tied to domains or subdomains. Certificates are issued by trusted Certification Authorities and signed electronically. Certificates are confirmed in browsers by checking the certificate chain ( Certification Path ), the root certificates of these centers are already distributed with the distributions of the main browsers, and such verification is invisible to the user. If the trusted root certificate was not found by the browser, the user is issued a page warning that the connection to the server is not secure.
The problem with embedded systems is that,
How to solve these problems?
Further, I will present to your court the results of my research on this issue verified experimentally. The term eSSL came to my mind in the process of writing this article, so I ask that you use any references with a link to embedders.org .
So, I’ll cover a few important aspects of the structure of certificates that allow us to use them in the way we need. Any certificate is a collection of string fields signed with a private key . The certificate also contains a public key for authenticating the data contained in these string fields. The list of fields is defined in the X.509 v3 format and is described in RFC 5280(This is the latest edition of the document, before that RFC 3280 was in effect ). The certificate contains a commomName field that describes the name of the subject of certification, usually it matches the domain of the website for which the certificate is issued, but there are no restrictions on the standard for what will be entered on this line, for example, the line "Vasya Pupkin" will also be valid for this field from the point of view of the standard is the first aspect . But web browsers check this particular field for compliance with the name of the site that presents the certificate. Fortunately for us, the X509 v3 format defines additional extensions, one of which is subjectAltName , which allows you to add identifiers associated with the main name of the certification subject (commomName ). These identifiers can be:
and this is the second and perhaps the most important aspect of the structure of certificates of the 3rd version of the standard. The fact is that you can add several such identifiers, i.e. You can enter several IP addresses for which the issued certificate will be valid. And this is what we need if a certain device has two Ethernet interfaces for working in different sub-networks, and even the ability to access the network through various types of modems, if the connection is via PPP, then this will be the third interface with its own IP address Empirically, I have established one important point in the assignment of alternative IP addresses. Internet Explorer and FireFox browsers perform alternative name checking differently. FireFox verifies the address that is specified in the IP identifier, and IE - checks the address with the DNS identifier . Therefore, in order to verify the certificate in both browsers, each required IP address must be specified as both IP and DNS . How to do this will be described later.
Let me give you an example of one of the possible scenarios for using certificates in embedded systems. This scenario does not require the purchase of certificates, but has limitations in use. So,
I emphasize that this scenario is not safe , the manufacturers of routers use a similar method, and smart hackers extract keys from the firmware and put code.google.com/p/littleblackbox into the database . This method is not convenient either, because we must pass the root certificate to the end user. And we will also be required to store the root certificate and private key to it in a safe place. Ideally, both of these functions are provided by one of the trusted certification authorities, but they charge a fee for this.
Next, I will tell you how to implement the proposed scenario in practice. All actions will be performed on a computer running Linux (Debian) and the openssl program.
Now we need to create an end-user or server certificate and sign it with the root certificate, which we created in the previous section. The main problem for me was that my device has several network interfaces that connect to different networks and, accordingly, have different IP addresses.
So, we have created 2 types of certificates, a root certificate and a user certificate. The root certificate is usually created once and is subsequently used to sign user certificates that we distribute to users, i.e. put on our devices. We will figure out how to apply them.
The user certificate and the key to it must be placed on the target device, I have a certain board with an ARM controller and Linux on board. I will not describe this process, because it depends on the WEB server that we have installed there.
But the root certificate needs to be imported as the root certificate of a trusted certification authority into each user's browser. Only in this case the browser will not show warnings when entering the page of your embedded WEB server.
In FireFox 6, this is done through the menu Preferences -> Encryption -> View Certificates , select the Authorities tab .
Next, click Import and open the file of our root certificate ca.crt , when asked about usage, put a checkmark on the identification of WEB servers.
And we can see our certificate in the list of trusted centers
In the Start menu in the search bar, type certmgr and press the key combination Ctrl + Shift + Enter, answer yes to the request for administrator rights. You will start the certificate manager.
Double-click on the Trusted Root Certification Authorities section.
Right-click on Certificates -> All Tasks -> Import ... The
Certificate Import Wizard starts, follow its instructions and specify ca.crt as the certificate. If you get an error,
then correct the key in the registry HKEY_LOCAL_MACHINE \ SOFTWARE \ Policies \ Microsoft \ SystemCertificates \ Root \ ProtectedRoots \ Flags set it to 0 and restart the certificate manager.
We examined some features of SSL certificates that allow you to identify a system that has several IP addresses and / or Domain names, and also examined the simplest scenario for using certificates in embedded systems. Can this scenario be improved? Of course you can. For example, you can make the root certificate generated directly on the device and given to the user upon request, for example, on a USB Stick. In this case, the theft of the root certificate does not entail danger for similar devices from other customers. Using self-signed certificates is certainly not the best practice, but sometimes for manufacturers of embedded systems this is the only way to ensure the minimum security of their devices.
Part of the information related to user certificates can also be used when purchasing certificates signed by trusted certification authorities. In this case, the highest level of security that SSL technology can provide is ensured.
Silent General Information About SSL
SSL technology allows you to encrypt traffic between two devices. You probably know that SSL certificates are issued to web sites and are tied to domains or subdomains. Certificates are issued by trusted Certification Authorities and signed electronically. Certificates are confirmed in browsers by checking the certificate chain ( Certification Path ), the root certificates of these centers are already distributed with the distributions of the main browsers, and such verification is invisible to the user. If the trusted root certificate was not found by the browser, the user is issued a page warning that the connection to the server is not secure.
The problem with embedded systems is that,
- firstly, this is not a website in the general sense of the word (remember, for example, the Wi-Fi router’s web interface), at the time of product release it does not have a final IP address, and it is even less likely that it would have some kind of domain.
- secondly, the end user can change both the IP and the domain, if there was one, at least for the purpose of all the same security.
- thirdly, buying a certificate is quite expensive, and the issue of cost reduction is always worth it.
How to solve these problems?
eSSL - embedded Secure Socket Layer
Further, I will present to your court the results of my research on this issue verified experimentally. The term eSSL came to my mind in the process of writing this article, so I ask that you use any references with a link to embedders.org .
So, I’ll cover a few important aspects of the structure of certificates that allow us to use them in the way we need. Any certificate is a collection of string fields signed with a private key . The certificate also contains a public key for authenticating the data contained in these string fields. The list of fields is defined in the X.509 v3 format and is described in RFC 5280(This is the latest edition of the document, before that RFC 3280 was in effect ). The certificate contains a commomName field that describes the name of the subject of certification, usually it matches the domain of the website for which the certificate is issued, but there are no restrictions on the standard for what will be entered on this line, for example, the line "Vasya Pupkin" will also be valid for this field from the point of view of the standard is the first aspect . But web browsers check this particular field for compliance with the name of the site that presents the certificate. Fortunately for us, the X509 v3 format defines additional extensions, one of which is subjectAltName , which allows you to add identifiers associated with the main name of the certification subject (commomName ). These identifiers can be:
- E-mail address
- DNS
- IP address
- and URI
and this is the second and perhaps the most important aspect of the structure of certificates of the 3rd version of the standard. The fact is that you can add several such identifiers, i.e. You can enter several IP addresses for which the issued certificate will be valid. And this is what we need if a certain device has two Ethernet interfaces for working in different sub-networks, and even the ability to access the network through various types of modems, if the connection is via PPP, then this will be the third interface with its own IP address Empirically, I have established one important point in the assignment of alternative IP addresses. Internet Explorer and FireFox browsers perform alternative name checking differently. FireFox verifies the address that is specified in the IP identifier, and IE - checks the address with the DNS identifier . Therefore, in order to verify the certificate in both browsers, each required IP address must be specified as both IP and DNS . How to do this will be described later.
Embedded SSL scenario
Let me give you an example of one of the possible scenarios for using certificates in embedded systems. This scenario does not require the purchase of certificates, but has limitations in use. So,
- We will need to create a self-signed root certificate, in which case we will become our certification authority.
- Next, we need to create a certificate for our web-interface and sign it with the root certificate created in the first step.
- We place this certificate in the memory of our embedded system where the embedded web server can find it .
- To all users of the web interface, we must issue our root certificate, but not a private key .
- Web interface users must import our root certificate into their web browsers on all computers from which they are supposed to log in to the web interface.
I emphasize that this scenario is not safe , the manufacturers of routers use a similar method, and smart hackers extract keys from the firmware and put code.google.com/p/littleblackbox into the database . This method is not convenient either, because we must pass the root certificate to the end user. And we will also be required to store the root certificate and private key to it in a safe place. Ideally, both of these functions are provided by one of the trusted certification authorities, but they charge a fee for this.
Next, I will tell you how to implement the proposed scenario in practice. All actions will be performed on a computer running Linux (Debian) and the openssl program.
Create a root certificate
- Install openssl-1.0
- Edit the file '/etc/ssl/openssl.cnf' (or rather copy it to your home folder) by changing the following lines there:
[ CA_default ] dir = . # Where everything is kept unique_subject = no # Set to 'no' to allow creation of # several ctificates with same subject.
Here dir is the base directory in which our own Certificate Authority will be located. Create it in the current directory.
Because our devices can have the same name (the commonName parameter when creating the certificate), therefore, by the unique_subject parameter , we allow creating many certificates for one subject.
We set the key length to 2048 (or maybe 4096) bits.[ req ] default_bits = 2048
Further, you can specify the default parameters so as not to enter them manually each time, although for the root certificate they will need to be entered only once if you are not going to make a hundred or two root certificates.[ req_distinguished_name ] countryName = Country Name (2 letter code) countryName_default = RU countryName_min = 2 countryName_max = 2 stateOrProvinceName = State or Province Name (full name) stateOrProvinceName_default = Saint-Petersburg localityName = Locality Name (eg, city) localityName_default = Saint-Petersburg 0.organizationName = Organization Name (eg, company) 0.organizationName_default = My Cool Company # we can do this but it is not needed normally :-) #1.organizationName = Second Organization Name (eg, company) #1.organizationName_default = World Wide Web Pty Ltd organizationalUnitName = Organizational Unit Name (eg, section) #organizationalUnitName_default = commonName = Common Name (eg, YOUR name) commonName_default = My Device commonName_max = 64 - Create a my-certs directory where our Certification Authority will be. Create a conf subdirectory and put our configuration file there.
- Edit the following lines in the file '/usr/lib/ssl/misc/CA.pl':
$SSLEAY_CONFIG="-config /home/user/my-certs/conf/openssl.cnf"; $CADAYS="-days 3650"; # 10 years $CATOP=".";
Here $ SSLEAY_CONFIG sets the path to the configuration file.
$ CADAYS indicates how many days the root certificate will be valid.
$ CATOP indicates which directory we will work in. This parameter should match what we specified in the dir in the configuration file in step 2. - Run command
/usr/lib/ssl/misc/CA.pl -newca
She will create the necessary directory structure and root certificate, and sign it by herself.
Upon request, enter the password for the future root certificate and then repeat itEnter PEM pass phrase: Verifying - Enter PEM pass phrase: - Enter the necessary information about you as a Certification Authority: country, region, city, company. In the 'common Name' field, enter something like 'My Device root Certificate', this line will be shown in the future in the certificate verification path in the user's browser. To view the contents of the newly created certificate, run the command (here in the example a certificate with a key of 1024 bits)
openssl x509 -in cacert.pem -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: d9:98:4f:55:e0:bb:b3:3c Signature Algorithm: sha1WithRSAEncryption Issuer: C=RU, ST=Saint-Petersburg, O=My Cool Company, CN=My Device root Certificate Validity Not Before: Oct 11 12:16:26 2011 GMT Not After : Oct 8 12:16:26 2021 GMT Subject: C=RU, ST=Saint-Petersburg, O=My Cool Company, CN=My Device root Certificate Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (1024 bit) Modulus: 00:d1:d1:0a:11:a3:1e:67:2b:d2:39:3e:ea:bf:44: 04:f9:2a:ae:c4:37:a2:76:8b:fc:de:6c:04:5a:56: 35:0b:12:8e:e6:31:62:5a:88:b4:53:a5:bf:9f:63: ea:6d:33:f9:4a:84:a5:8b:b1:f3:0b:9e:56:f8:27: 0d:8c:be:1d:76:be:6c:e5:c9:f3:f1:b0:cd:df:79: b4:0b:05:db:25:15:c1:e5:b3:08:17:af:67:e9:be: 44:a2:ce:ed:9a:6c:16:bb:f6:8c:73:ab:dd:86:5a: 82:73:6c:5e:03:fa:6e:8e:06:07:dd:8e:fb:95:51: 16:4b:91:87:be:15:9e:12:21 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: 1F:1С:A6:43:A2:49:E7:16:49:EC:FD:73:71:72:D7:7F:24:6D:AC:17 X509v3 Authority Key Identifier: keyid:1F:1С:A6:43:A2:49:E7:16:49:EC:FD:73:71:72:D7:7F:24:6D:AC:17 X509v3 Basic Constraints: CA:TRUE Signature Algorithm: sha1WithRSAEncryption 60:f2:cf:c7:52:11:83:c7:ea:b7:ae:68:8a:63:7a:89:5b:d6: 4e:ae:ba:0d:9d:a3:e6:86:07:db:54:77:59:b1:f9:dc:38:bd: a2:31:b6:18:80:80:3d:e1:20:13:23:28:26:b8:b0:aa:4f:a8: f7:92:89:13:2a:48:62:29:fb:3c:b7:ab:23:cb:97:ae:7c:21: 15:8e:23:e3:13:a1:e1:0d:85:dc:d0:8d:f7:fc:a5:60:0e:bc: 5d:ea:31:d1:b4:ac:f6:24:b2:7e:4e:27:88:67:16:94:6e:5d: 4b:b4:ef:fa:8a:49:71:23:62:81:78:2c:03:a3:3d:ae:c9:7b: 5c:f8 - Then make an RSA key without a password
~/my-certs$ openssl rsa -in private/cakey.pem -out private/ca.key Enter pass phrase for private/cakey.pem: writing RSA key
It must be specified in the configuration file ( /home/user/my-certs/conf/openssl.cnf ), then when creating user certificates you will not need to enter the password for the root certificate each time.private_key = $dir/private/ca.key # The private key - Create a certificate in x509 format
~/my-certs$ openssl x509 -in cacert.pem -out ca.crt
It must be specified in the configuration file, then when creating user certificates, you will not need to enter the password for the root certificate each time.certificate = $dir/ca.crt # The CA certificate - As a result, we will have 4 files
private/ca.key private/cakey.pem ca.crt cacert.pem
These files must be "cherished like the apple of an eye" because they will sign all certificates for end users. But the ca.crt file will be transferred to end users for import into browsers.
Certificates for devices
Now we need to create an end-user or server certificate and sign it with the root certificate, which we created in the previous section. The main problem for me was that my device has several network interfaces that connect to different networks and, accordingly, have different IP addresses.
- We will edit our openssl.cnf configuration file and add the following, perhaps the most important lines that will solve our problems at the end of the [usr_cert] section and before the [v3_req] section .
subjectAltName=@alt_names [alt_names] # Имена. Можно указать хоть сколько, главное чтобы цифры после точки были разными. IP.0 = 192.168.10.1 IP.1 = 192.168.1.1 DNS.0 = 192.168.10.1 DNS.1 = 192.168.1.1
Here alternative names are added that appeared in the extensions of version v3 of the x509 standard and can be a DNS name, IP address or URI address. There may be several of them, the main thing is that the figure after the point differs. Empirically, I found that FireFox swallows IP names , and IE8 swallows DNS names . Therefore, the IP addresses we need to be duplicated as IP for FireFox and as DNS for IE8, if, of course, we want to work in IE and FireFox. - Now you can create certificates. Here you need to execute a sequence of openssl calls with different parameters in order to simplify your life, I wrote the following simple script:
#!/bin/bash echo "*** Create request for sign ***" openssl req -config conf/openssl.cnf -new -keyout certs/$1.pem -out tmp.pem let ret=$? if let "$ret!=0" then rm tmp.pem echo $ret exit 1 fi echo "*** Create RSA key without password ***" openssl rsa -in certs/$1.pem -out certs/$1.key let ret=$? if let "$ret!=0" then rm tmp.pem echo $ret exit 1 fi echo "*** Sign certificate by our own trusted key ***" openssl ca -config conf/openssl.cnf -policy policy_anything -out certs/$1.pem -infiles tmp.pem let ret=$? if let "$ret!=0" then rm tmp.pem echo $ret exit 1 fi rm tmp.pem echo "*** Create certificate ***" openssl x509 -in certs/$1.pem -out certs/$1.crt let ret=$? if let "$ret!=0" then echo $ret exit 1 fi
At startup, it needs to pass the name of the new certificate as a parameter, for examplenewcert.sh device
Such a call will create 2 files device.crt and device.key , i.e. certificate and key to it. During the execution of the script, questions will be asked about the password for the new certificate, as well as the country, city, company for whom the certificate is issued. In the commonName field, you can specify any line, for example, My cool device , in normal practice, the domain for which the certificate is issued is written here, but we write the IP addresses (and domains) in the alternative names section, so that browsers do not swear in scary words, but when viewing the certificate show a beautiful check path.
How to apply all this?
So, we have created 2 types of certificates, a root certificate and a user certificate. The root certificate is usually created once and is subsequently used to sign user certificates that we distribute to users, i.e. put on our devices. We will figure out how to apply them.
The user certificate and the key to it must be placed on the target device, I have a certain board with an ARM controller and Linux on board. I will not describe this process, because it depends on the WEB server that we have installed there.
But the root certificate needs to be imported as the root certificate of a trusted certification authority into each user's browser. Only in this case the browser will not show warnings when entering the page of your embedded WEB server.
Import a root certificate in FireFox 6 (Linux)
In FireFox 6, this is done through the menu Preferences -> Encryption -> View Certificates , select the Authorities tab .
Next, click Import and open the file of our root certificate ca.crt , when asked about usage, put a checkmark on the identification of WEB servers.
And we can see our certificate in the list of trusted centers
Import root certificate in IE8 (Windows 7 64bit)
In the Start menu in the search bar, type certmgr and press the key combination Ctrl + Shift + Enter, answer yes to the request for administrator rights. You will start the certificate manager.
Double-click on the Trusted Root Certification Authorities section.
Right-click on Certificates -> All Tasks -> Import ... The
Certificate Import Wizard starts, follow its instructions and specify ca.crt as the certificate. If you get an error,
then correct the key in the registry HKEY_LOCAL_MACHINE \ SOFTWARE \ Policies \ Microsoft \ SystemCertificates \ Root \ ProtectedRoots \ Flags set it to 0 and restart the certificate manager.
Conclusion
We examined some features of SSL certificates that allow you to identify a system that has several IP addresses and / or Domain names, and also examined the simplest scenario for using certificates in embedded systems. Can this scenario be improved? Of course you can. For example, you can make the root certificate generated directly on the device and given to the user upon request, for example, on a USB Stick. In this case, the theft of the root certificate does not entail danger for similar devices from other customers. Using self-signed certificates is certainly not the best practice, but sometimes for manufacturers of embedded systems this is the only way to ensure the minimum security of their devices.
Part of the information related to user certificates can also be used when purchasing certificates signed by trusted certification authorities. In this case, the highest level of security that SSL technology can provide is ensured.