Security for web managed embedded device - Page 1
Forum section: electronics / projects

author: tridentsx
author_rank: Regular Contributor
timestamp: January 11, 2014, 08:27:46 pm
content: 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 warningWhat other options are there ?

author: nctnico
author_rank: Super Contributor
timestamp: January 11, 2014, 08:43:39 pm
content: Forget about https. Running SSL on a microcontroller is extremely slow.

author: tridentsx
author_rank: Regular Contributor
timestamp: January 11, 2014, 08:54:51 pm
content: The design is based on a TI Sitara em335x, not an MCU more a high end SOC, hence SSL works just fine.

author: nctnico
author_rank: Super Contributor
timestamp: January 11, 2014, 09:05:16 pm
content: Go for SSL then O0 Official certificates are not that expensive.

author: tridentsx
author_rank: Regular Contributor
timestamp: January 11, 2014, 09:59:03 pm
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: January 11, 2014, 10:52:22 pm
content: 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-systemshttp://www.devttys0.com/2010/12/breaking-ssl-on-embedded-devices/http://stackoverflow.com/questions/9584071/ssl-web-enabled-embedded-device

author: tridentsx
author_rank: Regular Contributor
timestamp: January 12, 2014, 12:53:06 am
content: 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 toadd a browser exception, this has to be a very common problem can't believe it hasn't been solved in an elegant way.

author: Unknown
author_rank: Unknown
timestamp: January 12, 2014, 01:16:23 am
content: Quote from: tridentsx on January 12, 2014, 12:53:06 amAnyone 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.

author: nctnico
author_rank: Super Contributor
timestamp: January 12, 2014, 01:50:26 am
content: 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.

author: apelly
author_rank: Unknown
timestamp: January 12, 2014, 02:12:02 am
content: QuoteThat 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.

author: Harvs
author_rank: Super Contributor
timestamp: January 12, 2014, 02:30:49 am
content: 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.

author: tridentsx
author_rank: Regular Contributor
timestamp: January 12, 2014, 04:22:29 am
content: 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.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 internetit 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

author: nctnico
author_rank: Super Contributor
timestamp: January 12, 2014, 02:54:39 pm
content: 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.

author: madires
author_rank: Super Contributor
timestamp: January 12, 2014, 03:51:26 pm
content: 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.

author: kxenos
author_rank: Frequent Contributor
timestamp: January 12, 2014, 04:16:52 pm
content: 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.

author: bgsteiner
author_rank: Contributor
timestamp: January 12, 2014, 10:00:04 pm
content: You could also generate your own SSL certificates. they may not be up to a high standard but it's better than nothing

author: alxnik
author_rank: Regular Contributor
timestamp: January 12, 2014, 10:03:59 pm
content: 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).

author: madires
author_rank: Super Contributor
timestamp: January 13, 2014, 12:16:32 pm
content: Quote from: kxenos on January 12, 2014, 04:16:52 pmA proper implementation of IPsec on an embedded device? I'd love to see thatBut the real problem with VPN support is the user. How much users are capable of setting up VPN connections?

author: kxenos
author_rank: Frequent Contributor
timestamp: January 13, 2014, 09:05:56 pm
content: 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.

author: ivaylo
author_rank: Frequent Contributor
timestamp: January 14, 2014, 07:59:06 am
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: January 14, 2014, 09:01:53 am
content: Quote from: madires on January 13, 2014, 12:16:32 pmIt 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.

author: amyk
author_rank: Super Contributor
timestamp: January 14, 2014, 09:50:12 am
content: Quote from: alxnik on January 12, 2014, 10:03:59 pmAgree 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...

author: madires
author_rank: Super Contributor
timestamp: January 14, 2014, 02:37:06 pm
content: Quote from: nctnico on January 14, 2014, 09:01:53 amA 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.

author: tridentsx
author_rank: Regular Contributor
timestamp: January 14, 2014, 10:41:30 pm
content: What if I get a wildcard certificate for example *.gadget.comThen 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.comAt 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.

author: amyk
author_rank: Super Contributor
timestamp: January 15, 2014, 07:33:13 am
content: Personally I would not buy any sort of embedded device that depends on and requires some server not under my control for its operation...

author: nctnico
author_rank: Super Contributor
timestamp: January 15, 2014, 07:52:09 am
content: Well then throw your phone, settop box, game console and PC out of the window...I have given the problem a bit more thought. It is feasible to create a browser plugin which implements a lightweight encryption protocol which could run on 40MHz ARM controllers with 16kB SRAM. That protocol would become the 'Internet of Things' security layer. The amount of data transferred will be relatively small so the encryption can be 256bit or more without a big performance hit.

author: ivaylo
author_rank: Frequent Contributor
timestamp: January 15, 2014, 09:35:47 am
content: QuoteThis won't work. Most of your devices will have private IP addresses while your DNS will probably be public.

author: HackedFridgeMagnet
author_rank: Super Contributor
timestamp: January 15, 2014, 10:58:03 am
content: NAT, Port forwarding?

author: nctnico
author_rank: Super Contributor
timestamp: January 15, 2014, 12:14:21 pm
content: If you can explain that to you grandmother (just in case: when she was still alive) it is a good solution. You need something plug & play.

author: madires
author_rank: Super Contributor
timestamp: January 15, 2014, 02:27:45 pm
content: Quote from: amyk on January 15, 2014, 07:33:13 amUnfortunately more and more companies are trying to copy Apple's Walled Garden, because that creates a more sustainable revenue and most users don't seem to care about the Walled Garden until they hit that wall hard. And if you say anything it's first "You're just jealous of my iJunk!". And after they hit the wall I'll say "I told you!".The problem with that dependency on the vendor's servers is not just control and data collection (privacy issues). If the vendor shuts down the servers your device becomes junk. That happens all the time with online computer games. You pay $60 for a game which only runs if you're online. A year later the servers are shut down for whatever reason and you can't play the game anymore. And the sad thing is, a lot of people are happily buying those games.

author: Kirigozo
author_rank: Contributor
timestamp: January 15, 2014, 09:37:57 pm
content: Wow!EEs are now doing computer security!Sounds like "script-kiddy heaven" with bonuses.Tridentsx, it is time to find a security consultant who specializes in embedded systems because it is obvious that none here know anything about computer security beyond setting you up to be pwned up the whazoo.It's that or pray the client doesn't order a pen test.Hey! I heard a rumor that, next week, the plumbers are running a special on open heart surgery.

author: ivaylo
author_rank: Frequent Contributor
timestamp: January 16, 2014, 02:25:00 am
content: I still think using readymade Javascript components may be the best bet here. The pages will be structured a bit differently and the device's server has to publish a few additional json interfaces but nothing an EE can't handle. Let me see if I get some free time next few weeks I may throw a prototype together.

author: ivaylo
author_rank: Frequent Contributor
timestamp: January 16, 2014, 05:56:54 am
content: @tridentsx: How are you going to program the web server on your device? I looked at the TI Sitara em335x thing and during the 3min I spent all I see is C/C++ and this "lwIP, a free, BSD-style license, TCP/IP stack from Swedish Institute of Computer Science". Are you going to compile in a web server somehow (if so which one) or build around this IwIP thing, do some sort of C/C++ CGI or something else?

author: tridentsx
author_rank: Regular Contributor
timestamp: January 16, 2014, 06:17:49 am
content: I will run a linux kernel with lighttpd as a web server and a mysql database.

author: madires
author_rank: Super Contributor
timestamp: January 16, 2014, 12:32:41 pm
content: Quote from: ivaylo on January 16, 2014, 02:25:00 amJavascript and security, that's called an oxymoron ;-)

author: ivaylo
author_rank: Frequent Contributor
timestamp: January 16, 2014, 07:28:14 pm
content: Err..., encryption is encryption (what the exact question was about). No difference between something encrypted with JS or C++. If a setup is secure is completely another matter (seen systems using heftiest encryption in a stupid way which made them easy to exploit).Otherwise I am not suggesting security on the web be replaced by encrypted json streams. Just not seeing a better solution for the poster's original question. When I see it I'd go my merry way (been interested in a solution myself though).

author: nctnico
author_rank: Super Contributor
timestamp: January 16, 2014, 09:31:20 pm
content: Quote from: madires on January 16, 2014, 12:32:41 pmYou may laugh about but if you generate a public/private key pair in the embedded device and have the javascript use the public key to encrypt the data you can send encrypted data back to the device. Vice versa is the same. Javascript can produce a public/private key from which it sends the public key to the device. Presto: end to end encryption.That is the beauty of public/private key encryption: you can have the source code and an encryption key but you still won't be able to decode the messages (quickly).

author: amyk
author_rank: Super Contributor
timestamp: January 17, 2014, 11:22:15 am
content: Quote from: nctnico on January 16, 2014, 09:31:20 pmJS, on an embedded device, for encryption?Why not just use SSL instead...

author: ivaylo
author_rank: Frequent Contributor
timestamp: January 17, 2014, 05:32:04 pm
content: QuoteDid you read the discussion at all?

author: rx_tx
author_rank: Newbie
timestamp: January 17, 2014, 09:57:17 pm
content: I would go for a self signed cert in this case. An embedded system of this nature should not be connected to an external network anyway, and the people with access should be able to add an exception an approve that cert. Unless there is some routines in place for updating the server software regulary. Linux kernel, lighttpd and mysql releases security patches that need to be applied and if your system cant handle those, ssl or not doesn't matter all that much. And if you have a system in place for handling software updates, updating a certificate should be a walk in the park.Sent from my iPad using Tapatalk