eSSL - SSL Certificates for Embedded Systems
Nowadays, network technologies are developing so rapidly that the recently seemed delusional slogan " Internet in every refrigerator " no longer seems fantastic. But at the same time, the security issues of embedded devices having a WEB interface with access to the local and, God forbid, the global network are becoming relevant. SSL technology is designed to help this by allowing you to work with the WEB interface using 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 websites and bound to domains or subdomains. Certificates are issued by trusted Certification Authorities and signed with electronic signatures. Certificates are confirmed in browsers by checking the certificate chain ( Certification Path ), the root certificates of these centers are already distributed along with the distributions of the main browsers, and such verification occurs unnoticed by the user. If the trusted root certificate is not found by the browser, a page is issued to the user with a warning that the connection to the server is not secure.
The problem with embedded systems is that
How to solve these problems?
Then I will present to your court the results of my research on this issue verified by experiment. The term eSSL came to my mind in the process of writing this article, so please use any references with the link to embedders.org .
So, I will 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 by a private key . The certificate also contains a public key to verify the authenticity of the data contained in these string fields. The list of fields is defined in the format X.509 v3 and described in RFC 5280 (this is the latest edition of the document at the moment, RFC 3280 was valid before). The certificate contains the commomName field that describes the name of the certification subject, usually it coincides with the domain of the website for which the certificate is issued, but the standard does not prohibit what is written on this line, for example, the line "Vasya Pupkin" will also be valid for From the point of view of the standard, this field is the first aspect . But web browsers check this field for compliance with the name of the site that presents the certificate. Fortunately for us in the X509 v3 format, additional extensions are defined, one of which is subjectAltName , which allows you to add identifiers associated with the main name of the certification entity ( commomName ). These identifiers can be:
and this is the second and perhaps most important aspect of the structure of certificates of the 3rd version of the standard. The fact is that there are 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 device has two Ethernet interfaces to work in different sub-networks, and even the ability to connect to the network through different types of modems, if the connection is via PPP, then this will be the third interface with its IP address. Experimentally, I established one important point in the assignment of alternative IP addresses. Internet Explorer and FireFox browsers check alternate names in different ways. FireFox verifies the address specified in the IP identifier, and IE verifies the address with the DNS identifier. Therefore, to verify the certificate in both browsers, each required IP address must be specified both as IP and as DNS . About how to do this will be discussed next.
I will give for example one of the possible scenarios for the use of certificates in embedded systems. This scenario does not require the purchase of certificates, but has limitations in use. So,
I would especially like to note that this scenario is not secure , router manufacturers use this method, and smart hackers retrieve keys from the firmware and add them to the code.google.com/p/littleblackbox database. This method is not convenient either, because we have to pass the root certificate to the end user. And we also need to keep the root certificate and private key to it in a safe place. Ideally, both of these functions are provided by one of the trusted certificate 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 openssl programs.
')
Now we need to create an end-user or server certificate and sign it with a root certificate that 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, root certificate and user certificate. The root certificate is usually created once and then used to sign user certificates, which we distribute to users, i.e. put on our devices. We will understand how to use them.
The user certificate and the key to it need to be placed on the target device, I have some kind of 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 must be imported as the root certificate of a trusted certificate authority in 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 Preferences -> Encryption -> View Certificates menu, select the Authorities tab.
Next, click Import and open the file of our root certificate ca.crt , to the question of use, put a tick 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 affirmatively to the administrator rights request. 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 will start, follow its instructions and specify ca.crt as the certificate. If the result is an error
Then correct the registry key in HKEY_LOCAL_MACHINE \ SOFTWARE \ Policies \ Microsoft \ SystemCertificates \ Root \ ProtectedRoots \ Flags, set it to 0 and restart the certificate manager.
We considered some features of SSL certificates that allow identifying a system with several IP addresses and / or Domain names, as well as considered the simplest scenario for using certificates in embedded systems. Is it possible to improve this scenario? Sure you may. For example, you can make the root certificate be 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 will not entail danger for similar devices from other buyers. Using self-signed certificates is certainly not the best practice, but sometimes for embedded system manufacturers this is the only way to ensure the minimum security of their devices.
Some of the information relating to user certificates can also be used when purchasing certificates signed by trusted certificate authorities. In this case, it provides the highest level of security that SSL technology can provide.
Silent general information about SSL
SSL technology allows you to encrypt traffic between two devices. You probably know that SSL certificates are issued to websites and bound to domains or subdomains. Certificates are issued by trusted Certification Authorities and signed with electronic signatures. Certificates are confirmed in browsers by checking the certificate chain ( Certification Path ), the root certificates of these centers are already distributed along with the distributions of the main browsers, and such verification occurs unnoticed by the user. If the trusted root certificate is not found by the browser, a page is issued to the user with a warning that the connection to the server is not secure.
The problem with embedded systems is that
- Firstly, this is not a web site in the general sense of the word (remember, for example, the web interface of a Wi-Fi router), at the time the product is released, it does not have a final IP address, and it is even less likely that it will 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 purposes of security.
- thirdly, to buy a certificate is quite expensive, and the question of cost reduction is always worth it.
How to solve these problems?
eSSL - embedded Secure Socket Layer
Then I will present to your court the results of my research on this issue verified by experiment. The term eSSL came to my mind in the process of writing this article, so please use any references with the link to embedders.org .
So, I will 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 by a private key . The certificate also contains a public key to verify the authenticity of the data contained in these string fields. The list of fields is defined in the format X.509 v3 and described in RFC 5280 (this is the latest edition of the document at the moment, RFC 3280 was valid before). The certificate contains the commomName field that describes the name of the certification subject, usually it coincides with the domain of the website for which the certificate is issued, but the standard does not prohibit what is written on this line, for example, the line "Vasya Pupkin" will also be valid for From the point of view of the standard, this field is the first aspect . But web browsers check this field for compliance with the name of the site that presents the certificate. Fortunately for us in the X509 v3 format, additional extensions are defined, one of which is subjectAltName , which allows you to add identifiers associated with the main name of the certification entity ( commomName ). These identifiers can be:
- E-mail address
- DNS
- IP address
- and URI
and this is the second and perhaps most important aspect of the structure of certificates of the 3rd version of the standard. The fact is that there are 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 device has two Ethernet interfaces to work in different sub-networks, and even the ability to connect to the network through different types of modems, if the connection is via PPP, then this will be the third interface with its IP address. Experimentally, I established one important point in the assignment of alternative IP addresses. Internet Explorer and FireFox browsers check alternate names in different ways. FireFox verifies the address specified in the IP identifier, and IE verifies the address with the DNS identifier. Therefore, to verify the certificate in both browsers, each required IP address must be specified both as IP and as DNS . About how to do this will be discussed next.
Scenario for using SSL in embedded systems
I will give for example one of the possible scenarios for the use of 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 own certificate 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 put this certificate in the memory of our embedded system where it can be found by the embedded web server .
- To all users of the web interface, we must issue our root certificate, but not the private key .
- Frontend users must import our root certificate into their web browsers on all computers from which they are supposed to log into the web interface.
I would especially like to note that this scenario is not secure , router manufacturers use this method, and smart hackers retrieve keys from the firmware and add them to the code.google.com/p/littleblackbox database. This method is not convenient either, because we have to pass the root certificate to the end user. And we also need to keep the root certificate and private key to it in a safe place. Ideally, both of these functions are provided by one of the trusted certificate 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 openssl programs.
')
Creating 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 a certificate), so with the unique_subject parameter, we allow to create many certificates for one subject.
Let's set the key length to 2048 (or maybe 4096) bits.[ req ] default_bits = 2048
Further, you can specify default parameters in order not to enter them manually every 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 directory my-certs where our Certification Center will be. Create a conf subdirectory and place 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 in which directory we will work. This parameter must match the one we specified in dir in the configuration file in step 2. - Execute the command
/usr/lib/ssl/misc/CA.pl -newca
It will create the necessary directory structure and root certificate, and sign it with itself.
Upon request, you must enter a password for the future root certificate and then repeat it.Enter PEM pass phrase: Verifying - Enter PEM pass phrase: - Enter the required information about you as a Certification Authority: country, region, city, company. In the field 'common name' you should enter something like 'My Device root Certificate', this line will be displayed later 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 1024 bit key)
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 every 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 every 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" for they will sign all certificates for end users. But ca.crt 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 a root certificate that 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.
- Let's edit our openssl.cnf configuration file and add to the end of the [usr_cert] section and before the [v3_req] section the next, perhaps the most important lines that will solve our problems.
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 you can add alternative names that appear in the x509 standard v3 extensions and can be a DNS name, IP address or URI address. There may be several of them, as long as the number after the point is different. Experienced, I found that FireFox swallows IP names, and IE8 swallows DNS names. Therefore, we need the IP addresses to be duplicated as IP for FireFox and as DNS for IE8, if, of course, we want to work in IE and in FireFox. - Now you can create certificates. Here you need to perform 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 as a parameter the name of the new certificate, 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 string, for example, My cool device , in the usual practice, the domain for which the certificate is issued is recorded here, but we record the IP addresses (and domains) in the alternative name razor, so browsers don't swear by dreadful words, but when viewing the certificate show a beautiful way to check.
How to apply all this?
So, we have created 2 types of certificates, root certificate and user certificate. The root certificate is usually created once and then used to sign user certificates, which we distribute to users, i.e. put on our devices. We will understand how to use them.
The user certificate and the key to it need to be placed on the target device, I have some kind of 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 must be imported as the root certificate of a trusted certificate authority in 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 into FireFox 6 (Linux)
In FireFox 6, this is done through the Preferences -> Encryption -> View Certificates menu, select the Authorities tab.
Next, click Import and open the file of our root certificate ca.crt , to the question of use, put a tick 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 affirmatively to the administrator rights request. 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 will start, follow its instructions and specify ca.crt as the certificate. If the result is an error
Then correct the registry key in HKEY_LOCAL_MACHINE \ SOFTWARE \ Policies \ Microsoft \ SystemCertificates \ Root \ ProtectedRoots \ Flags, set it to 0 and restart the certificate manager.
Conclusion
We considered some features of SSL certificates that allow identifying a system with several IP addresses and / or Domain names, as well as considered the simplest scenario for using certificates in embedded systems. Is it possible to improve this scenario? Sure you may. For example, you can make the root certificate be 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 will not entail danger for similar devices from other buyers. Using self-signed certificates is certainly not the best practice, but sometimes for embedded system manufacturers this is the only way to ensure the minimum security of their devices.
Some of the information relating to user certificates can also be used when purchasing certificates signed by trusted certificate authorities. In this case, it provides the highest level of security that SSL technology can provide.
Matrials used:
Source: https://habr.com/ru/post/136543/
All Articles