Where or how do you get a secure embedded TCP/IP stack

[richardman]

Perhaps my language was too strong, ha ha. Anyway, of course one can run lwIP without an RTOS. There's even a page on this
http://lwip.wikia.com/wiki/LwIP_with_or_without_an_operating_system

It's for 1.40 and earlier, but probably not too much different from 2.0. However, I still maintain that with an easy to use RTOS, there's no particular advantage of using lwIP that way in the general scenario.

[cdev]

There is no good reason to put critical infrastructure on the Internet and a great many reasons not to. Frankly, it should be illegal to put 'critical infrastructure' on the public Internet. I thought it was, actually.

So frankly, something is not adding up.

[rstofer]

But very rarely is the actual transport layer at fault for an exploit.

Exactly!  Encryption, or the lack thereof, is not the responsibility of TCP or IP.  These two protocols just deliver packets and, in the case of TCP, guarantee delivery.  But it's just packets, the contents are determined at a higher level.  Buffer overflow isn't really possible with TCP because packet size is limited by the protocol.

The maximum TCP packet is 64k but the maximum transmission unit (MTU) of Ethernet is 1500 bytes.

I wouldn't be in a hurry to blame TCP or IP for security problems.  They're just the messenger, not the message.  Time is better spent getting SSL to work.

Nope. SSL is not some magic sauce you can pour over a piece of code and call it secure. It doesn't work that way. At a higher level you'll need to design the system securely right from the start. As a rule of thumb a well designed system is still secure without encrypting the messages.

I don't see how a system can be secure without encryption if the packets can be intercepted.  Plain text is just that: plain.  Easy to read, etc.

Now, for an isolated network, not connected to the Internet, sure, it can be secure without encryption but that's the exception these days.  For better or worse, everything is connected to the Internet.  And everybody can read every packet, one way of another.  Just ask the NSA!

Which leads me to wonder what the utilities are thinking when they do connect to the Internet.  Encrypted or not!  It just won't end well.

[nctnico]

But very rarely is the actual transport layer at fault for an exploit.

Exactly!  Encryption, or the lack thereof, is not the responsibility of TCP or IP.  These two protocols just deliver packets and, in the case of TCP, guarantee delivery.  But it's just packets, the contents are determined at a higher level.  Buffer overflow isn't really possible with TCP because packet size is limited by the protocol.

The maximum TCP packet is 64k but the maximum transmission unit (MTU) of Ethernet is 1500 bytes.

I wouldn't be in a hurry to blame TCP or IP for security problems.  They're just the messenger, not the message.  Time is better spent getting SSL to work.

Nope. SSL is not some magic sauce you can pour over a piece of code and call it secure. It doesn't work that way. At a higher level you'll need to design the system securely right from the start. As a rule of thumb a well designed system is still secure without encrypting the messages.

I don't see how a system can be secure without encryption if the packets can be intercepted.  Plain text is just that: plain.  Easy to read, etc.

Then please read about how to implement a secure system and you'll see exactly why 1) encryption is only a very small part of security 2) secure systems need to be designed to be secure from the ground up. The very short explaination is that a secure system also 'senses' someone has broken in and is able to take counter measures.

[Berni]

Encryption does help protect you from people looking at your data and sending fake data to you, but only if everything is done correctly.

The more difficult problem is unexpected input data. The application layers can start getting pretty complex functionality and that vastly increases the chances that a weird input might cause it to do something stupid. This means weird unused ID codes in messages, massive data lengths in messages, negative numbers where there should be only positive ones, or even just selecting a very specific combinations of settings that causes the software to trip up somewhere down the line.

Even if you had a perfectly secure stack with heavy encryption that's correctly implemented you could still get hacked. So your encryption if flawless, but then someone hacks the device you are talking to and convinces it to send you a command with "Read username, length -1" It all goes fine trough the layers until the application layer on top of it goes check it and it does "if(length < sizeof(username))" so it looks just fine. It sends the username into the send function and it might be taking length as unsigned(since negative lengths don't make sense anyway) and so interprets -1 as being 4294967296 and simply starts sending out a 4GB long message containing basically all of the local RAM. Whops...

That was just one example of how something bad might happen. There are many many many other scenarios that can cause other bad things to happen. Often this application layer gets pretty huge and complicated and people don't tend to test it against silly nonsense inputs. Especially when the programmers are pulling an all-nighter to meet the deadline.

[legacy]

You definitely don't need an RTOS to do TCP/IP and other networking stuff. To use an RTOS or not depends entirely on the scheduling requirements of the entire application. A network stack is just another interface which inputs/outputs data.

edit:
You need an RTOS multitasking OS for a multi-socket application, e.g. a server-model waiting for several clients to be served 

[westfw]

Multitasking is very helpful.  "Real time" is completely unnecessary.(linux has a fine TCP stack and isn't real time.  Both cisco and Procket used run-to-completion schedulers.)

[forrestc]

You need an RTOS for a multi-socket application, e.g. a server-model waiting for several clients to be served 

Actually you don't.   

I am currently shipping RTOS-free microcontroller-based products which do not currently use a RTOS, and which support several HTTP clients being connected at the same time. 

There is a lot of misconception that a RTOS or OS is needed for this type of stuff.    Really what RTOS'es get you are things like being able to write code in run-to-completion style instead of cooperative multitasking style, better scheduling, and good inter-task communication (which simplifies message or event based programming).   There are other advantages as well, but being able to serve several network clients is not one of them.  In fact, the  highest-performance web servers on the web service all of their clients in a single task (per CPU).   This is actually a common performance-increasing strategy.  Search for "evented server" to see how common this is and to better understand why a servicing all of your clients in a single thread is more efficient. 

[nctnico]

You definitely don't need an RTOS to do TCP/IP and other networking stuff. To use an RTOS or not depends entirely on the scheduling requirements of the entire application. A network stack is just another interface which inputs/outputs data.

edit:
You need an RTOS multitasking OS for a multi-socket application, e.g. a server-model waiting for several clients to be served 

Nope. Not even under Unix. Look at how a typical BSD sockets select server works for example. All the connections are handled within the same thread. Often this is more efficient because you don't have the overhead of inter-process communication / data sharing (mutexes/semaphores) and task switching.

[legacy]

Nope. Not even under Unix. Look at how a typical BSD sockets select server works for example. All the connections are handled within the same thread. Often this is more efficient because you don't have the overhead of inter-process communication / data sharing (mutexes/semaphores) and task switching.

ehmmm with ucOS/2 on MPUs you don't have processes, and you don't have threads, and there is no fork(), and in the simplest working scenario (which I have used several time) tasks can even share variables on the global pool (of course with semaphores), or by passing messages, and it's less complex than all the stuff you have in Linux.

[legacy]

As a proof-of-concept the web server has to do is follow these steps:
- Listen on a TCP port
- Whenever a client tries to open a connection, (and there is a task able to serve it), accept it
- Parse the text sent by the client, HTTP request
- Process said request
- Reply a textual answer, HTTP response

I have to handle a maximal of six requests, therefore I have six equal  (static-) tasks waiting for a connection. They share the same code, but each task has its private context (local variables).

These tasks, plus an additional couple of tasks for the TCP/IP networking, are scheduled by ucOS/2.

What is wrong with this scheme? It's simple, it does its job, and the code is neat, and doesn't require to significantly refactor your code 

[NorthGuy]

As a proof-of-concept the web server has to do is follow these steps:
- Listen on a TCP port
- Whenever a client tries to open a connection, (and there is a task able to serve it), accept it
- Parse the text sent by the client, HTTP request
- Process said request
- Reply a textual answer, HTTP response

I have to handle a maximal of six requests, therefore I have six equal  (static-) tasks waiting for a connection. They share the same code, but each task has its private context (local variables).

These tasks, plus an additional couple of tasks for the TCP/IP networking, are scheduled by ucOS/2.

What is wrong with this scheme? It's simple, it does its job, and the code is neat.

It is nothing wrong with this. The OS here allows you to write your tasks in a linear fashion (as if other threads didn't exist). The OS does consume some resources and slows down things a bit in return, but people don't worry about these things nowadays. Without OS, you would have to write your tasks as state machines which get called when a relevant packet arrives.

You can do the same on the big HTTP server. You can use threads - each HTTP request runs in its own thread which is processed in a linear fashion. Or, you can use select() to poll. Polling is more efficient and will work faster, but your tasks will have to be written as state machines. Although select() limits the number of sockets you can poll. Therefore, it would be even more efficient if you got rid of select() and Berkeley sockets altogether and handled the packets by yourself. This way you could handle much more connections (50k is not out of limits), but you would need to write your own TCP stack.

[westfw]

with ucOS/2 on MPUs you don't have tasks...

...These tasks, plus an additional couple of tasks for the TCP/IP networking, are scheduled by ucOS/2.

Huh?  Does ucOS/2 have "tasks" or not?  Or were you using a more exacting definition of "task" the first time?

[richardman]

Huh?  Does ucOS/2 have "tasks" or not?  Or were you using a more exacting definition of "task" the first time?

uCOS definitely have tasks.

[legacy]

with ucOS/2 on MPUs you don't have tasks...

...These tasks, plus an additional couple of tasks for the TCP/IP networking, are scheduled by ucOS/2.

Huh?  Does ucOS/2 have "tasks" or not?  Or were you using a more exacting definition of "task" the first time?

lapsus, it doesn't have processes, it has static-tasks.

[legacy]

"static-tasks" means statically linked at compile time.

[Marco]

First rule of security ... never trust other people's code written in C. It's a well known fact that there are between 0-1 people capable of programming something securely in C, the 1 being you.

If it absolutely positively has to be written in C, HCC Embedded used MISRA compliant procedures to write one.

[westfw]

First rule of security ... never trust other people's code written in C. It's a well known fact that there are between 0-1 people capable of programming something securely in C, the 1 being you.

Meh.  1st rule is that you don't trust yourself to write security code.  "Don't trust anyone else" is the 2nd rule  :-(Rule 3 is that coders can't be trusted to understand cryptography, cryptographers can't be trusted understand code, few of either understands hardware, and none of them understand human nature.  :-( :-(

[SiliconWizard]

Oh yes. And don't forget:



 

[westfw]

That's "four"...

[richardman]

That's "four"...

 

[Karel]

I don't believe it exists.
Apart from giants like Google, IBM, Amazon, microsoft, etc,
a normal company does not have the resources to do this.
Besides, you very likely also need ARP, DHCP, firewall, etc.
It's simply too much work for a normal company.

If you really need network connectivity, use Linux and update often.

[hans]

I agree.

The state space of a modern TCP stack is so huge that you would spend ages to write verification tests for it. But let's not forget that vulnerabilities also originate often from the applications using TCP.

A little while back I heard a story from a lead engineer at a wireless SoC vendor, that they had tested their Bluetooth stack (that ran on a separate CPU in the SoC) to be robust against all forms of packet inputs. I'm not sure how they tested this - because even for bluetooth you can have a huge state space explosion that would have to verify against all inputs.
You get in the realms of formal verification, where you could write assertions or contracts (coming in C++20) that need to be proven never to be violated. If you then have some fallback behaviour (simplest would be send a RST packet and close the connection), I suppose you could have a reasonably robust TCP stack.

Of course you then still have the DoS attacks, as sanitizing inputs costs CPU time, which makes it easier to flood a device with requests or frames it needs to process.

Hence, don't put embedded devices publicly facing the internet or a big LAN.

[Marco]

As I said, there's HCC Embedded.

Or you can save the cash and use something written in Java, it rules out the source of 99% of exploitable bugs.

[legacy]

That's "four"...

it depends on the base and complement-type