Security for web managed embedded device

[tridentsx]

How is encryption normally managed for embedded devices with web interface?

The options I have found are

-- Use digest authentication with HTTP, but its fairly insecure
-- Use a self signed certificate with HTTPS, that is generated on first startup of device, this gives the dreaded browser security warning

What other options are there ?

[nctnico]

Forget about https. Running SSL on a microcontroller is extremely slow.

[tridentsx]

The design is based on a TI Sitara em335x, not an MCU more a high end SOC, hence SSL works just fine.

[nctnico]

Go for SSL then  O0 Official certificates are not that expensive.

[tridentsx]

Doesn't an official certificate have to be tied to a fqdn or an IP?

I assume thats not possible for an embedded device, I don't know where a customer will install the device or what IP they are going to assign, hence I can't get the certificate created !

How much is an official SSL certificate ? Whats the longest validity time for SSL certificate from official CA?

I have searched the internet but there is not a lot of info available, with all hype around "Internet Of Things" there has to be some simple solution.

[nctnico]

That is a problem indeed. Did you already find these pages? They offer some interesting thoughts on the matter (unfortunaly no real solution so far):

http://stackoverflow.com/questions/2978506/certificates-for-ssl-enabled-embedded-systems
http://www.devttys0.com/2010/12/breaking-ssl-on-embedded-devices/
http://stackoverflow.com/questions/9584071/ssl-web-enabled-embedded-device

[tridentsx]

Yes I have seen those pages but as you mentioned there is no real solution.

I am thinking about having a custom encrypted protocol from my devices to an online server where they connect. Then the end user connect to the online server to manage their device. I don't like that solution because I have many gadgets that has become obsolete because the company that created them stopped supporting their online service.

Another option is to let the end user create a custom certificate when they enable HTTPS and instruct them how to
add a browser exception,  this has to be a very common problem can't believe it hasn't been solved in an elegant way.

[Lurch]

I am thinking about having a custom encrypted protocol from my devices to an online server where they connect. Then the end user connect to the online server to manage their device.

Anyone who even thinks of doing this should be taken out and shot immediately, repeatedly.

Why do you need SSL? What is wrong with some basic authentication on the server, no https required? I realise https is a better option but I'm pretty sure I can connect to most of the devices on my network over http and those that do use https have not asked to go through some longwinded self signing process.

[nctnico]

That would be OK if the device is connected to a small network and doesn't control anything important. If the network has a Wifi router things may become less nice. When connecting over the internet I'd definitely add some security. A hybrid solution is to allow http for local IP addresses and force https (SSL) for remote ones.

edit: using an online service (server) to manage devices over a proprietary protocol isn't a bad idea. The device can 'phone home' so you don't need to mess with firewall settings at the customer's network. Lots of home control and alarm systems work this way generating revenue from subscribtions.

[apelly]

I am thinking about having a custom encrypted protocol

That is always a bad idea.

I'm not sure what your application is going to be, but you can consider tunelling over ssh, or VPN.

[Harvs]

It also depends on what the end goal of the security is.
e.g.
- Typical IT scenario is to protect secrecy of data at all costs.
- SCADA on the other hand is usually to keep the process online and safe at all costs, secrecy of data is usually a secondary consideration.

This can lead to some different solutions to problems.

[tridentsx]

Anyone who even thinks of doing this should be taken out and shot immediately, repeatedly.

Why do you need SSL? What is wrong with some basic authentication on the server, no https required? I realise https is a better option but I'm pretty sure I can connect to most of the devices on my network over http and those that do use https have not asked to go through some longwinded self signing process.
[/quote]

Without SSL encryption a 12 year old script kiddie could gain access to critical control functions even from the internet that if abused could cause serious physical damage to property.
As I said I could use self signed certificates but I know I myself wouldn't trust a product that is designed that way, If I allow access to something on my home network from the internet
it better use a relatively safe protocol.

I probably will use HTTP digest for local access and a self signed unique per device certificate for access from the internet and if my product becomes successful I will do the phone home thing.

Carl

[nctnico]

Hopefully there will be some 'internet of things' security standard soon. The people who created SSL obviously left some holes in the usage scenarios. The requirement of an IP or domain is ridiculous. Like those cannot be falsified...

Edit: another way of securing a connection with SSL is to create a trust relationship manually. In that case the webserver in a device doesn't give it's public key to any device trying to connect. Instead it only allows connections from devices which have the public key. If a webbrowser doesn't have a public key for a website then it will ask the user to provide it.

[madires]

SSL is fine but the CA trust system is totaly broken. There are some organisations offering free SSL certificates while applying quite stringent ID verification, something a proper CA should be obliged to do. But their signing certificates aren't included in the web browsers or OSs by default. So using SSL with a self-signed certificate is ok because you can't trust most commercial CAs (too many issues of compromised CAs and certificates are known). And after the NSA revelations I won't trust any SSL certificate anyway anymore. The benefit of SSL is an encrypted end-to-end communication.

[kxenos]

I don't think you have to decide for a specific CA. I think that you, as a designer, should just give the capability for the client to set whatever CA they want since your device can support SSL. I think a nice idea is to allow your device to become a VPN endpoint. That way the user can choose whether they want to set up a VPN to the device or not. Usually they will just have the router to be the VPN endpoint and not the device itself.
I think you should provide the capabilities of SSL and VPN and let the user decide and configure their solution according to their usage scenario.

[bgsteiner]

You could also generate your own SSL certificates. they may not be up to a high standard but it's better than nothing

[alxnik]

SSL for an embedded device is just fine.

Considering certificates or more correctly PKI, domain names and IPs are mandatory in order to get a certificate from a CA company is totally mandatory simply because the these companies exist in order to ensure that the site you are connecting is the one you think you are connecting.

However, PKI through internet companies (as in godaddy etc) is not necessary. These are used in general purpose consumer oriented services just because the CAs of these companies are bundled in all the mainstream browsers.

Long story short. Make your own (self signed) CA. Give your CA certificate to clients and ask them to install it, or otherwise accept it (browser exception). You can streamline this through an installer. If this is done then you can locally create keys/certs on the devices and sign them with your CA (this can be automated/streamlined quite easily).

[madires]

I think you should provide the capabilities of SSL and VPN and let the user decide and configure their solution according to their usage scenario.

A proper implementation of IPsec on an embedded device? I'd love to see that  But the real problem with VPN support is the user. How much users are capable of setting up VPN connections?

[kxenos]

Indeed, the user is the worst thing that can happen to a system. Some years ago, I got a job as sys admin. I soon did a security audit, defined a security policy, wrote procedures, issued new usernames/passwords to the users (no domain controller), updated the passwords of every machine etc. and a month later I found out that there where post-it notes with usernames/passwords underneath the screens! 

I don't know the resource requirements for IPsec but I have seen some sort of it implemented in modems and routers that where using ARM7 or 9 so I believe it should be doable, but I have no experience in this.

[ivaylo]

Pick any of the Javascript encryption libraries and include them with your distribution. Then write all communication from browser to device via encrypted Ajax/Json/Jsonp or whatever. Especially if like you say you have the processing horsepower. Not entirely trivial but doable.

[nctnico]

I think you should provide the capabilities of SSL and VPN and let the user decide and configure their solution according to their usage scenario.

A proper implementation of IPsec on an embedded device? I'd love to see that 

It can be done. If you have about 512kB of SRAM and a 200MHz ARM cpu it is possible to use PolarSSL on a microcontroller. A couple of years I have experimented with it a lot and got it working but it was too slow and the memory was too small.

[amyk]

SSL for an embedded device is just fine.

Considering certificates or more correctly PKI, domain names and IPs are mandatory in order to get a certificate from a CA company is totally mandatory simply because the these companies exist in order to ensure that the site you are connecting is the one you think you are connecting.

However, PKI through internet companies (as in godaddy etc) is not necessary. These are used in general purpose consumer oriented services just because the CAs of these companies are bundled in all the mainstream browsers.

Agree with this recommendation. Provide the ability to install certificate on the device, so the user can set it up with her own certificates and thus have control over how she chooses to build the trust modle. Obviously, make it so that you must have physical access to do so...

[madires]

A proper implementation of IPsec on an embedded device? I'd love to see that 

It can be done. If you have about 512kB of SRAM and a 200MHz ARM cpu it is possible to use PolarSSL on a microcontroller. A couple of years I have experimented with it a lot and got it working but it was too slow and the memory was too small.

A clock rate >=400MHz and a few MB RAM should be ok. I know some older SOHO routers running IPsec with that kind of hardware (but mostly with a crypto engine in hardware for high throughput). But there's another problem. IPsec is a quite complex protocol and the specs are written in a way that asks for implementation faults weakening the security. Unfortunately that was intended as we learned from the NSA revelations. Nobody can be sure that a specific IPsec implementation is "secure" and I'd guess that implementations for low power MCUs have a lot of trade-offs. This topic is very interesting anyway because of the Internet of Things. One of the original ideas of IPv6 was to make IPsec mandatory but that was dropped over the years due to pressure by the industry (and NSA?). Now we got fast low-power ARM cores and cheap RAM. BTW, Google just bought Nest to collect even more data on you.

[tridentsx]

What if I get a wildcard certificate for example *.gadget.com
Then I let the device register to a DYN DNS service running on gadget.com that registers the device with a sub domain name like serial.gadget.com

At factory s/w install I sign a certificate using the *.gadget.com for serial.gadget.com and install it to the device ?
Would that work ?

It would require me to run a server on the internet which I was planning on anyway to host s/w updates.

[amyk]

Personally I would not buy any sort of embedded device that depends on and requires some server not under my control for its operation...