Your favorite 'free' embedded TCP/IP stack?

[nctnico]

For a future project I need an embedded TCP/IP stack. I have used uiP before but I found it was quite buggy and not performing very well (especially with Windows clients). So this time I want to use something different. At the moment I have an eye on nichelite (NXP ARM devices come with a license for Nichelite) or Lwip. Any other stacks I missed? Code size isn't really important; I rather use something which is complete.

[RABeng224]

I have used the Microchip TCP/IP on a few products. Works well and supports many features. Only thing is that you must use the stack on a Microchip part. I found the PIC32s to be the only real way to go. You need at least 128k of flash if you want to use WiFi. 

[free_electron]

Good luck finding a free one.
They all stink  (incomplete / incompatible / plain wrong / not portable). The closest working one is the one in uCOS but that is not free...

if you want to get out from under the hassle : slap on a Wiznet7xxx series ethernet MAC and you are done. all TCP/IP is handled by that beast. they are cheap

[westfw]

Linux.

I have used uiP before but I found it was quite buggy and not performing very well

Perhaps you should describe how small you need it to be.  uIP and Linux serve different needs, even if you can get either one on a playing-card sized PCB for $50...

(I am coming to the depressing conclusion that Internet THINGS require a pretty significant CPU/etc, just to stand a chance of being able to fit "adequate secuity."  Yeah, that probably means using a Raspberry Pi instead of a "Wiznet Ethernet Shield.")

[nctnico]

I haven't decided on an OS yet but if I'm going the OS route I think it will be FreeRtos. It depends on whether I need task scheduling or not. In the past I have implemented my own small HTTP server and client. From my experience TLS/SSL is beyond the reach of a microcontroller so I won't go that route (again).

[SPRX]

I use Microchip TCP/IP, and is really works for me.

I modified the Microchip TCP/IP and developed a Multicast based application recently, and happy with the stack architecture.

[madires]

(I am coming to the depressing conclusion that Internet THINGS require a pretty significant CPU/etc, just to stand a chance of being able to fit "adequate secuity."  Yeah, that probably means using a Raspberry Pi instead of a "Wiznet Ethernet Shield.")

I assume with IPv4/IPv6 dual stack, some low level IPv6 stuff like SLAAC, daemons (http/https) and AAA (authentication, authorization and accounting) the common solution will be a gateway running Linux, e.g. Raspberry Pi, and tons of "things" interconnected by a simple bus. Otherwise each "thing" would need a powerful CPU and a OS which makes everyting expensive and large. And the use of RF modules for communication shouldn't be overdone since the ISM bands are already very crowded.

[nctnico]

I don't think a gateway is really required but instead of using TLS/SSL to make something secure you'd need to use a proprietary protocol which ensures a proper level of security.

[alm]

TLS is doable in a 32-bit micro if you just limit yourself to one set of algorithms, and don't offer the dozens of options that implementations like OpenSSL support. A proprietary protocol is not going to offer much security. Good crypto protocol are very hard: even implementations and protocols developed by companies like Google and Microsoft have flaws. A proprietary protocol has no chance of coming even close to the quality that standard protocols like TLS achieved after many years of smart people working on it and finding flaws in it. If even basic TLS is too intensive, then try at least to find a standard protocol that is simpler and cheaper.

[cyr]

If code size really isn't important then I would suggest eCos, with the full BSD-derived TCP/IP stack. You need something with external RAM to make that work though (couple of megs probably), not a small micro.

[Hardcorefs]

Good luck finding a free one.
They all stink  (incomplete / incompatible / plain wrong / not portable). The closest working one is the one in uCOS but that is not free...

if you want to get out from under the hassle : slap on a Wiznet7xxx series ethernet MAC and you are done. all TCP/IP is handled by that beast. they are cheap

If that nonsense was at all true.... then linux would not work....

[Dago]

I don't think a gateway is really required but instead of using TLS/SSL to make something secure you'd need to use a proprietary protocol which ensures a proper level of security.

I hope I'm misunderstanding but are you saying that for example ~every web banking connection is insecure because all of them use SSL and not a "proprietary protocol"?

[madires]

I don't think a gateway is really required but instead of using TLS/SSL to make something secure you'd need to use a proprietary protocol which ensures a proper level of security.

Security by obscurity doesn't work!

[free_electron]

Good luck finding a free one.
They all stink  (incomplete / incompatible / plain wrong / not portable). The closest working one is the one in uCOS but that is not free...

if you want to get out from under the hassle : slap on a Wiznet7xxx series ethernet MAC and you are done. all TCP/IP is handled by that beast. they are cheap

If that nonsense was at all true.... then linux would not work....

Linux is an operating system. TS is asking for a stack to go on an embedded processor. he aint going to be running linux on that cpu. He may not be running an operating system at all. There are plenty of network stacks out there that do not employ an operating system .

In that category (network stack without OS) , with the restriction free, it is slim pickins to get one that works. The closest one i know is uCos but it is not completely free. You pay licence per install.
Microchip has one but that is for their stuff only..

Linux has nothing to do with this.

[nctnico]

I don't think a gateway is really required but instead of using TLS/SSL to make something secure you'd need to use a proprietary protocol which ensures a proper level of security.

Security by obscurity doesn't work!

A lot of people say thay but they are just parotting anarchaic hackers.

First lets find out what obscurity means: it means to hide something. If we look at TLS/SSL then you'll see it will only work securely if the private key is kept secret. So TLS/SSL is security by obscurity! If you look closely at any security measure used to protect communication between two electronic devices you'll see that for it to be secure something (a key, an encryption method or both) must be hidden. So every secret communication between two electronic devices is security by obscurity.

Now lets get back to the hackers. What do they really mean by saying security through obscurity doesn't work? They mean to say they don't trust profit driven companies and gouvernments to come up with encryption methods which cannot be hacked or monitored. Its a pure political statement (and a bit of a lack of trust in our engineering skills)!

In an ideal world there would be infinite resources available to implement the best available encryption method. In the real world there are always technical tradeoffs. From a technical point of view you need to implement a method which is safe enough and fits within the available resources. For example: you can't run a hefty encryption algorithm in a smart-card so you have to compromise. And even with a component using weak encryption a system as a whole can still be secure. In NL they use Mifare cards as a wireless credit card for public transport. To make things worse: the credit is stored onto the cards without any encryption. The system is still secure though because the administrative back-end notices when the balance (money-in / money-out) doesn't add up.

Anyway, it seems my choice is still limited to lwip (open source) and Nichelite (a commercial product for which NXP paid the license)...

[dfmischler]

No.  What is meant by "security by obscurity" is when the security of the system depends on the algorithm(s) staying secret.  It is OK to depend on the secrecy of keys, as long as there are no problems with your key distribution and management methods (granted that this is easier said than done).

[madires]

Security by obscurity doesn't work!

A lot of people say thay but they are just parotting anarchaic hackers.

No, it means that if someone claims he has "the most secure protocol" nobody is able to verify that, because nobody but the owner of the new protocol has access to the algorithm. It's like claiming a new law of physics without providing the scientific evidence and saying "trust me!". Good secure encryption is based on well known and tested methods. Too much proprietary encryption methods (= security by obscurity) were broken and proofed to be badly designed already. If a new encryption method can't be peer-reviewed by several security experts we can't trust the method. The latest example are the engine start codes for VW's (and all of their brands) cars. Current security is just a gag order to silence the security researchers 

[nctnico]

Thats parotting anarchaic hackers again... If it ain't open we can't trust it...

If you go down that road you'd need to test all your food for toxins as well 

In real life you can hire 'hackers' to test the security level of your system without needing to open the protocols or releasing the specifications. VW probably bought an off-the-shelf system with the required security level (without needing a 1GHz ARM CPU in the keyfob). They just underestimated the resourcefulness of car thieves. This has nothing to do with open or closed encryption systems; its just a bad tradeoff between cost, functionality and ease of use.

You can do a small experiment yourself: call a lock smith to open your door. You'll be amazed how fast he/she can pick your lock. Yet most thieves just smash in a window so a good lock even though it can be opened by any expert within severals seconds is an adequate security measure because common thieves clearly lack the skill to pick it.

[Dago]

In real life you can hire 'hackers' to test the security level of your system without needing to open the protocols or releasing the specifications.

That's one hell of a hacker team if they can verify your encryption algorithm in a reasonable time scope. Maybe you could refer us to that hacker team so they could help the whole mathematician community to verify something simple like the AES encryption algorithm is safe to use? It has only been around for 16 years with open specifications and these wankers are still not sure if its safe or not! Surely a no biggie for the "hacker" team.

And I have no idea why you would have to put a "1GHz ARM CPU" in the keyfob to implement a reasonable security measure (which VW did not do).

But please carry on 

[alm]

Security through obscurity does not mean that you must release the specs, but that releasing the specs should not degrade the security. I.e. making the protocol proprietary will not improve security. Opening the protocol proves that you only rely on the cryptography, and for example the fact that testing 2¹²⁷ combinations takes a very long time, rather than some obscure but trivial to figure out fact.

Add to this is that the far majority of people suck and writing secure software or protocols, and relying on standard protocols and standard implementations become a much safer bet. Look at the number of security holes that got fixed in almost any crypto protocol implementation. Are you much smarter then the people who wrote that, or does your implementation contain a similar number of bugs that you didn't find yet but a determined attacker might? Say you optimized a decryption function to make it run faster: you probably just made it vulnerable to side channel attacks.

My guess is that VW (and/or their supplier) overestimated the security level of the protocol. Whoever designed it thought it did not contain any unknown weaknesses, and either there was no review or the reviewer failed to spot it.

Very few thieves use lockpicking skills because the time it takes to learn, but also the time it takes to open the door. Plus you're looking quite suspicious if the neighbors come by. They rely on speed: smash a window and be gone in less then a minute before anyone notices you. This is generally not a problem for software security: you can buy a program to do the hard work, you can often work from a relatively safe location (eg. a car near the target car in the VW example), and nobody sees you interacting (unless they deployed a network intrusion system and are actually monitoring the alerts). Plus lockpicking is only easy for the cheap locks that nobody cares about (eg. random family homes). Anything containing valuables will use a more sophisticated lock that requires brute force to open without a key. For example a properly designed VW-branded electronic lock .

[nctnico]

Add to this is that the far majority of people suck and writing secure software or protocols, and relying on standard protocols and standard implementations become a much safer bet. Look at the number of security holes that got fixed in almost any crypto protocol implementation.

That is always an interesting discussion: just dump the received data into an encryption engine or use some kind of hand-shaking protocol around it. I like to keep things as simple as possible so I'd ditch the protocol if I can. Most of the security holes are found in surrounding protocols; the versatility of TLS/SSL is not helping much.

And then again a system shouldn't rely just on encryption. Security is based on three legs (triple A): Authentification, Authorisation and Accounting. If one leg 'breaks' the system should still be secure.

@Dago: 'Hackers for hire' are not going to verify AES etc but they look at how the triple A is implemented and what kind of hacks would be possible. They look at the architecture of a system and if you want also at the implementation (buffer overflows, etc).

[alm]

The problem is that even the implementation of encryption is non-trivial. ECB is unsuitable for almost any application, for example, but is the default block cipher mode. There are also subtle issues with padding, IVs and even the responses it returns. For example, if the system distinguishes between a checksum failure and incorrect password, then this may already be enough information to break the password in a limited number of tries. And this is just the basic stuff, I'm not a cryptographer.

I agree that auditing helps. That's no excuse to make authentication weaker than it needs to be, though.

[dfmischler]

My guess is that VW (and/or their supplier) overestimated the security level of the protocol. Whoever designed it thought it did not contain any unknown weaknesses, and either there was no review or the reviewer failed to spot it.

I don't know, but it might also be that a weakness was identified internally but brushed aside by management.

I pointed out what I thought was a serious weakness in the crypto-based security of a product used by the public that an employer of mine developed, but the guy in charge of the product discounted my concern.  So far, I think the product has not been compromised and it has been almost 20 years.  Then again, the product may have been quietly improved after my involvement.

[westfw]

parotting anarchaic hackers

Actually, the "don't invent your own" missive comes from the cryptographic research community, and the people who have tried to do it.  Mostly, it's "don't invent your own cryptographic algorithms", although there are plenty of cases where people have screwed up the larger aspects of security, even given a "good" cryptographic algorithm to start with.  (WEP is one example, IIRC.)

(been there, done that.  That's why that particular algorithm is now called "obfuscation" rather than "encryption."  Sigh.)

OTOH, cryptographic researchers have a very high bar for "good."

Stanford had/has a free online class on cryptography: https://www.coursera.org/course/crypto
I recommend it.  It's pretty fierce, but even if you can't quite follow everything (like me), the descriptions of infamous failures are ... enlightening.

[flynnjs]

Obsure doesn't mean hidden. It means unclear.

A key is hidden, completely out of the reach of an attacker (if you've got it right!)
and in a good system it takes a long time for them to guess or calculate it.
An obsure system is available to an attacker but just not immediately clear. It is
just a matter of time until it is understood and therefore compromised.

It could be possible to have a very obsure system which could take longer to
understand than the key discovery time for a hidden system.

Whether you decide to implement your security by a proper mathamatically
proven hard function or through obscurity is up to you and depends on:
1) The resources available (developement effort, equipment size etc)
2) The capability of the attacker you're trying to defend against
3) Most importantly: your risk appetite towards the impact and likelihood.