Your favorite 'free' embedded TCP/IP stack?

[nctnico]

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.

So we agree on 'security by obscurity doesn't work' is just FUD. If it wheren't then many security system we depend on each day (rfid tags, credit/debit cards, SIM-card etc, etc) wouldn't work.

edit: BTW I never proposed to attempt to design an encryption algorithm from scratch.

[dfmischler]

So we agree on 'security by obscurity doesn't work' is just FUD.

What do you mean “we”?

There is great wisdom in the idea that a cryptosystem's algorithms should be able to withstand public scrutiny and that the only thing that should need to be secret is the key material.  The more our society depends on the integrity of protocols for RFID tags, credit/debit cards, etc. the greater the incentive for an attacker to attempt to compromise them.  That means more and more resources are likely to be available to attackers of these systems.  If the protocols and implementations are not up to the task then we need better ones.

[flynnjs]

Sorry this is getting a bit [OT] from TCP/IP stacks 

So we agree on 'security by obscurity doesn't work' is just FUD.

I wouldn't say we agree on that. If resources are limited and the
defender has a very large risk appetite and little to lose then there
is no point in boiling the ocean.
What we do agree on is the vast majority of security by obscurity
techniques are many orders of magnitude quicker to compromise
than modern good quality mathematically proven crypto system.

Just like embedded engineers chose the "right" micro or FPGA
for the job a good security consultant will also suggest using the
right tool for the job.
Take, for example, an online game which is free to use and has
no per game revenue. The only thing to be lost through cheating
is the "fun" but it is vulnerable to interception. In this case you
wouldn't insist players buy a state of the art quantum crypto box
would you?

[nctnico]

Sorry this is getting a bit [OT] from TCP/IP stacks 

Well its more or less on topic because security issues are something to consider when attaching a microcontroller to a network (or maybe even to internet). Its not trivial to come up with a solution which offers adequate protection while using only a small amount of resources.

So we agree on 'security by obscurity doesn't work' is just FUD.

I wouldn't say we agree on that. If resources are limited and the
defender has a very large risk appetite and little to lose then there
is no point in boiling the ocean.
What we do agree on is the vast majority of security by obscurity
techniques are many orders of magnitude quicker to compromise
than modern good quality mathematically proven crypto system.

Like I typed before: Many systems (rfid tags, debit cards, SIM cards, etc) use secret encryption/hashing algorithms to keep their data safe. AFAIK it took several decades before Mifare RFID cards got hacked. In order to hack a modern RFID tag you'd need to analyse the chip itself by peeling it apart layer by layer. A major disadvantage of using 'open' encryption methods is that the level of security they offer gradually diminishes with the increasing computational power provided by relatively cheap hardware. A while ago someone hired a large chunk of 'computer cloud' to crack passwords. To keep the security level up you'd need to upgrade every few years. Its a real rat race which has killed several 'good' encryption methods. And then there may be flaws in the algorithms themselves. MD5 used to be very popular until someone discovered a severe vulnerability. Nowadays the use of SHA1 is adviced. Now try and update a microcontroller application...

In most cases the real problem with getting a system secure is that people don't design systems with security in mind or have little clue about how hackers work. A few years ago I examined a so called secure protocol for home automation from a major vendor. The switches already worked by simply capturing and re-playing the messages. The 'encryption' itself was nothing more than a standard CRC checksum with an adjustable seed.

[alm]

The advantage of open protocols, like for example TLS, is that they have withstood the test of hackers and cryptographers trying to break it for years. This does not mean they won't get broken, but it is much easier to estimate a time frame for it to be broken. For example, I wouldn't use SHA-1 and especially MD-5 for an application that had to be secure for five years, but I wouldn't be as worried about using AES in a similar application. Because I can look up all known attacks against that algorithm, or ask someone in the field.

A closed protocol could be broken in minutes once a determined expert starts researching it. It may have taken years from the day that RFID tag was introduced to the moment it was hacked, but how much time did the researcher spend? How does this compare to the time you would need to invest to find a flaw in say TLS, even if you were determined? The good thing about crypto is that the US government uses it a lot, so if the NSA was aware of an attack on AES, for example, then they would certainly push for new encryption standards. Or try to fix it, like in the DES S-box case.

You bring up a good point about limited time that something is secure. I think a few years ago is a bit pessimistic, MD5 was certainly superseded by SHA-1 at least ten years ago. So choosing the best algorithm available in 2000 would probably have given you SHA-1, something that you wouldn't use in new designs today, but it is still usable for many applications. 3DES encryption, which has also been around for 10+ years, is still acceptable today, although you would use AES for new implementations. In general I would plan for any secure system to receive updates, however, either because of flaws in the cryptography, flaws in the implementation, or design flaws. Preferably updates via internet with a default admin password .

[dfmischler]

[Many systems (rfid tags, debit cards, SIM cards, etc) use secret encryption/hashing algorithms to keep their data safe.

Yes, but there is a strong push from several application industries to switch to or create open standards.  For example, this article from a few years ago suggests dropping the proprietary NYC MTA system developed by Cubic for near field communication using smart credit cards.  And IIRC Cubic systems are also in place in Washington,  London, San Francisco, Brisbane, etc.  How well will the open standards based version work?  Will it be secure?  Remember, it's not just the point of transaction security that matters: the whole network and back-end for clearing transactions, and the human interfaces for straightening out the inevitable problems, matter too.

[boz]

Hi

Will your device be a server or a client? Will it be TCP or can you get away with UDP?

The ethernet hardware normally handles the lower layers so a embedded client just sending data over a udp socket could do this without a stack `par-say`and just a few lines of code to set an IP address and fill the transmit buffer.

Also if your implementing just a client you wont be hacked because there is nothing to hack, if however you implementing a TCP server and controlling say a door lock then security may be a different matter and all the above comments are valid.

[dfmischler]

The ethernet hardware normally handles the lower layers so a embedded client just sending data over a udp socket could do this without a stack `par-say`and just a few lines of code to set an IP address and fill the transmit buffer.

It's been a few years (almost 20) since I wrote anything for TCP/IP on bare metal, but are you remembering the ARP layer to convert IP addresses into MAC addresses?  In my experience a good implementation needs timeouts, sanity checking, caching, retransmissions, etc.  Are newer chips really doing all that for you?  It's not as complicated as TCP, but more work than UDP.  Or are you thinking to avoid all that stuff by just broadcasting it to MAC address FF:FF:FF:FF:FF:FF, and making everybody who doesn't want it filter it?

[madires]

The ethernet hardware normally handles the lower layers so a embedded client just sending data over a udp socket could do this without a stack `par-say`and just a few lines of code to set an IP address and fill the transmit buffer.

Broken by design! A fully agree with dfmischler. You also need an ARP cache with timeouts in case the MAC address of the other side changes. Otherwise the device would have to be power cycled. What about IP address assignment? Enter it manually with two buttons? Or should DHCP be supported? And should we start to talk about IPv6? Supporting just IPv4 is a dead end now.

Also if your implementing just a client you wont be hacked because there is nothing to hack, if however you implementing a TCP server and controlling say a door lock then security may be a different matter and all the above comments are valid.

Never assume that a networked device won't never be hacked or exploited. If there are just a few around the world it's less likely but you can't bet on that.

[nctnico]

The ethernet hardware normally handles the lower layers so a embedded client just sending data over a udp socket could do this without a stack `par-say`and just a few lines of code to set an IP address and fill the transmit buffer.

Broken by design! A fully agree with dfmischler. You also need an ARP cache with timeouts in case the MAC address of the other side changes. Otherwise the device would have to be power cycled.

That is if you want to go the IP route. If you want to go the minimalistic route you can define your own packet structure and use the MAC address to tell where a packet should go. Dumb switches (IOW most of the SOHO switches) don't look further than the MAC addressess anyway. The downside is that this kind of traffic can't be routed over internet (or you'd need to develop a bridge).

[madires]

Broken by design! A fully agree with dfmischler. You also need an ARP cache with timeouts in case the MAC address of the other side changes. Otherwise the device would have to be power cycled.

That is if you want to go the IP route. If you want to go the minimalistic route you can define your own packet structure and use the MAC address to tell where a packet should go. Dumb switches (IOW most of the SOHO switches) don't look further than the MAC addressess anyway. The downside is that this kind of traffic can't be routed over internet (or you'd need to develop a bridge).

Of course you can create you own layer 3 protocol (there a lot already, not just IP) but you have to do it very carefully and it would be very helpful if you know the benefits and problems of other protocols. Binding the destination to a specific MAC is quite problematic because is allows that only the system with that MAC can access the device. Ok, we could add some more MACs but how should the device determine where to send the data? If someone tries to sell that as security feature I'll answer that spoofing MACs is very simple. We could use spoofing also to fix the access problem. But does the user know how to do it? He knows how to use/access the Internet, therefore IP is the best bet.

[dfmischler]

Trust me.  Even if you couldn't go find uIP or whatever implementing TCP/IP from scratch is easier/better/saner than developing your own protocol suite.  I've been there and done that, admittedly before IPV6,

Yes, ARP is a little more complicated than just spitting UDP packets.  So is DHCP.  But it's worth it 

[nctnico]

The user doesn't need to be bothered with IP adresses. You can use all kinds of discovery mechanisms like a lot of network attached devices employ without the device needing an IP address. Most configuration software comes up with a list of devices it found (usually one) and asks which one the user wants to configure or use. Most users (even field engineers) are completely lost when confronted with having to fill in an IP address.

[madires]

The user doesn't need to be bothered with IP adresses. You can use all kinds of discovery mechanisms like a lot of network attached devices employ without the device needing an IP address. Most configuration software comes up with a list of devices it found (usually one) and asks which one the user wants to configure or use. Most users (even field engineers) are completely lost when confronted with having to fill in an IP address.

If the user's PC has just an IP stack (the default) and the networked device not, how should they communicate?  Some devices are shipped with setup tools using the MAC based approach for the initial setup (scanning for known MACs), but an IP address has to be assigned or DHCP be enabled alternatively (often the default action). And because we can't expect users to be IP experts DHCP is enabled by default, it's the default setting for SOHO routers (acting as DHCP server) and all clients. And with IPv6 you got SLAAC (DHCP optionally).

[nctnico]

With libpcap its pretty easy to send and receive your own packets onto the network card. I've used Uip in the past and I tested/prototyped the network side of the software on a PC. My embedded environment behaved much like a virtual machine where my Uip device had it's own MAC adress inside Windows.

Only on consumer SOHO routers DHCP is enabled by default but on professional hardware it most certainly is not. For example Microsoft's crappy DNS/DHCP server simply shuts down when it sees another DHCP server on the network causing all kinds of unwanted effects. In general you don't want multiple DHCP servers on the same network. And then there is lots of other network connected hardware like printers, scanners, etc.

[madires]

With libpcap its pretty easy to send and receive your own packets onto the network card. I've used Uip in the past and I tested/prototyped the network side of the software on a PC. My embedded environment behaved much like a virtual machine where my Uip device had it's own MAC adress inside Windows.

And you end up with a custom protocol and a dedicated user space application :-)

Only on consumer SOHO routers DHCP is enabled by default but on professional hardware it most certainly is not. For example Microsoft's crappy DNS/DHCP server simply shuts down when it sees another DHCP server on the network causing all kinds of unwanted effects. In general you don't want multiple DHCP servers on the same network. And then there is lots of other network connected hardware like printers, scanners, etc.

Yep, if you get professional network elements you're expected to have a good understanding of IP or hired an expert. Therefore SOHO routers got the DHCP server enabled by default. Running services on Windows (servers) requires also some knowledge. BTW, it's just the DHCP server which stops. If the DNS on a domain controller (in case there's only one) would stop the AD would fall apart.