Anyone used the Wiznet ethernet chips?

[Kjelt]

I should link this. It is very important that you never apply this kind of security. Even tough it's tempting to use in embedded systems.

This is a kind of Security by Obscurity which is flat out useless if your communication channel is breached.

No it definitly is not security by obscurity, you both misread or misinterpret my post then.
If you use Auth.Enc. with a secret PSK and are NIST compliant on both sides you are doing the same thing as with for instance the AES-CCM ciphersuite and you do not need any DHKE. The weakest link is the master key as it should be.

[technix]

I should link this. It is very important that you never apply this kind of security. Even tough it's tempting to use in embedded systems.

This is a kind of Security by Obscurity which is flat out useless if your communication channel is breached.

No it definitly is not security by obscurity, you both misread or misinterpret my post then.
If you use Auth.Enc. with a secret PSK and are NIST compliant on both sides you are doing the same thing as with for instance the AES-CCM ciphersuite and you do not need any DHKE. The weakest link is the master key as it should be.

Now you already have AES-CCM please tell me how much more will it cost you to step up to an MCU that runs a proper copy of Linux. Allwinner A13 + its accompanying PMIC costs 1.5 bucks a pop, and add one DDR2 SDRAM chip, and one NAND (or eMMC) chip (or microSD card) you got a full blown BBB equivalent that runs full blown Linux at 800MHz+. Then you can add a Ethernet PHY chip (can be cheaper than ENC28J60 or W5200) interfacing A13's MII to use the onboard 10/100 Ethernet.

[Kjelt]

It is software and <10kB

[technix]

It is software and <10kB

You don't need special software to program for Allwinner A13 - it is all open source. And about the size limit with the NAND/SD card support of A13 your program (that runs on Linux) can expand to a few gigabytes if you want to (e.g. big database) and you can give it up to 2GB of RAM.

[nctnico]

Now you already have AES-CCM please tell me how much more will it cost you to step up to an MCU that runs a proper copy of Linux. Allwinner A13 + its accompanying PMIC costs 1.5 bucks a pop, and add one DDR2 SDRAM chip, and one NAND (or eMMC) chip (or microSD card) you got a full blown BBB equivalent that runs full blown Linux at 800MHz+. Then you can add a Ethernet PHY chip (can be cheaper than ENC28J60 or W5200) interfacing A13's MII to use the onboard 10/100 Ethernet.

I read a lot of 'adds' which gets me in the ballpark of $30 AND a lot of extra software engineering because Linux board support packages need a lot of bug fixing AND the need for a 6 layer PCB instead of 2 layers. Using Linux doesn't add up to something cheaper and (in this case) better.

[Kjelt]

BTW I had my security protocol running on a low power stm8 , low power meaning 5mA , I would really like to see you do that with something running Linux 
But I agree that if someone has to make a 24/7 connected device that is accessible from third parties webbrowsers and should run TLS that an embedded Linux device would be very nice.
As Nico said, the budget is often a restriction, power can be a restriction, so can software maintenance be a restriction (you want Nico to update each device each and every time a bug is found?)

[Chris C]

Security through "obscurity" in this context means using anything but a known and common standard.  It's easy to show many examples of this type of security gone wrong.  But that's not entirely due to poor decisions on the part of the implementers, it's also due to the prevalence of this kind of security.  Looking at the failures alone is educational, but ultimately misleading as to the effectiveness of this kind of security.  One must also consider that for every one that went wrong, many more went right.

That could even include some systems that are technically weak, and easily broken.  I have found security exploits on a few devices.  One is quite scary in terms of what it could be used for.  But this was done for personal use only, to get around some limitation of the device.  I didn't use my knowledge write a virus.  Nor did I publicly document it like some security "researchers" tend to do, under a false flag of increasing security awareness.  And no one else appears to have done this either.  Therefore, the public can continue using these devices, without fear of script kiddies like Mallory walking around and causing mischief.  Even if something can be exploited, there is no issue unless the exploit actually enters the wrong hands.

As for the Allwinner A13 being $2, that is very likely a bogus claim, originating from a particular Kickstarter for "CHIP - The World's First Nine Dollar Computer".  Many people have analyzed the BOM for this and found $9 to be completely unrealistic, concluding that it's either a scam, or a loss-leader on which they're recovering the loss based on sales of overpriced add-on boards.  In particular, Olimex concluded this product actually has a BOM of about $20.  Part of that was getting a quote from Allwinner on the A13, which was $4.80 in quantity 5,000.

Furthermore, given the complexity of the A13, versus the quality of support and documentation from Allwinner, rolling-your-own product around the bare IC would likely be a painful process; significantly increasing development cost.  The A13 recommendation is not realistic IMO.

Finally, I'm curious.  As it was not stated in this thread, does anyone here actually know what [nctnico]'s device does?  If not, then recommendations for Linux and idealized security might prove to be a bit silly, if it turns out he's developing an Ethernet-controlled dancing Coke can.   (Or something equally innocuous if hacked.)

[nctnico]

Security is an issue because people will definitely try to break into the device to attempt fraud (it needs to pass a certification test and security is part of it). OTOH it is also cost sensitive and it needs to be in production within a couple of months 

[Chris C]

Security is an issue because people will definitely try to break into the device to attempt fraud (it needs to pass a certification test and security is part of it). OTOH it is also cost sensitive and it needs to be in production within a couple of months 

Oh my.  Your project is serious, and the engineer's paradox.  Sorry to hear that.

Are you comfortable identifying and implementing the requirements to pass the certification, from near scratch?  Another thread dedicated to discussion of the feasibility and time requirements on your target class of hardware might get some better answers.

[Jeroen3]

You've made the client aware of this triangle?

[MagicSmoker]

Getting back on topic... we used the WIZ810MJ module to provide an ethernet/web interface in a low volume product for about 6 years and the firmware and/or tcp/ip stack inside it was, as others have mentioned, pretty buggy. Worse is that none of the bugs were fixed in those 6 years. Now we use Cortex ARMs with a built in MAC and an external PHY (Microchip [nee SMSC] LAN8720Ai) for ethernet and uIP for the tcp/ip stack.

The stuff we make uses the ethernet port for configuration/telemetry and isn't connected to the internet so we don't really care about security, per se. YMMV

[nctnico]

Can you elaborate on the bugs?

[MagicSmoker]

Can you elaborate on the bugs?

We used the WIZ810MJ to bolt on ethernet connectivity to an 8b AVR so that customers could change parameters and stream real time data without requiring any special hardware (anything with an ethernet port and a web browser). The biggest and most annoying bug was that the WIZ810MJ would hang if you tried to scroll down a web page before it finished loading, but it would also hang for no reason at all. You would have to cycle power to clear the error because toggling the hardware reset line on the WIZ810MJ module did nothing (a waste of a good I/O pin on the AVR for that one). And this didn't just affect TCP/IP; UDP functionality was lost, too, so we think the problem is in the W5100 firmware, and not necessarily it's (built-in/proprietary) TCP/IP stack.

Complicating the above was that data transfer was really slow even though the SPI bus was clocked at 6MHz and the web pages served by it were basically plain text forms (with one logo picture that took up all of 1.5k). That, of course, lead to more customers scrolling down the web page before it was finished loading.

At any rate, it was the number one cause of customer support questions and it wasn't that cheap, either (~25USD) so it made the decision to go with an ARM that has a MAC, at least, plus an external PHY a lot easier. Getting the 50MHz RMII bus for the PHY to work in a very high noise environment took a couple of board revisions and uIP required some tweaking by our software engineer, but given that this route only cost ~8USD and isn't buggy it was worth the extra effort.

[Chris C]

Interesting.  A couple of thoughts:

1) Reset must be asserted for at least 2us to work as per the datasheet, must be driven both active low and high as the WIZ810MJ lacks a pull-up on the reset line, and must be asserted after power-up else inconsistent behavior can result.  (I had all sorts of weird trouble until I did these things properly.)

2) The W5100 would not be aware of scrolling in the browser, unless there were elements in the webpage that caused the browser to open additional sockets, in an attempt to load those elements in parallel regardless of how many requests were already pending.  The W5100 can handle no more than 4 open sockets, but may be configured for as few as 1.  What you experienced suggests there may have been an issue with the webpage design, that caused it to exceed the basic limitations of the W5100.  Regardless, hanging is certainly NOT an acceptable outcome under any circumstances.  I did not test opening more sockets on my W5100 than it was configured for, but I have seen an Internet-connected W5100 serving up something much like you described.  When it was featured on a major website, it received a lot of hits; and frequently rejected connections, but did not hang.  So I suspect a solvable issue in the MCU-side software, rather than something inaccessible in the W5100 itself.

Sounds like the ARM route worked out nicely for you in the end though, and that's all that matters.

[Sal Ammoniac]

Linux's network stack is a lot better tested than whatever you can roll for yourself or used in chips like W5200 and friends - it is used in 95% of all servers worldwide

I doubt it's close to 95%. It is substantial, though, and that means there are hoards of hackers attempting to crack it on a continuous basis.

[nctnico]

Linux's network stack is a lot better tested than whatever you can roll for yourself or used in chips like W5200 and friends - it is used in 95% of all servers worldwide

I doubt it's close to 95%. It is substantial, though, and that means there are hoards of hackers attempting to crack it on a continuous basis.

The number of servers and desktops running Linux is dwarfed by the number of Android devices (Android uses the Linux kernel). So yes people are likely to want to hack the Linux network stack.

[technix]

Linux's network stack is a lot better tested than whatever you can roll for yourself or used in chips like W5200 and friends - it is used in 95% of all servers worldwide

I doubt it's close to 95%. It is substantial, though, and that means there are hoards of hackers attempting to crack it on a continuous basis.

The number of servers and desktops running Linux is dwarfed by the number of Android devices (Android uses the Linux kernel). So yes people are likely to want to hack the Linux network stack.

About 92% of servers, over 70% of smartphones (Android, Bada, Ubuntu Touch and more) and over 98% of TOP500 supercomputers runs Linux, making it such a high profile target - running on billions of devices big and small - probably even more than Windows desktops. Hackers will want to hack it (any part of it, including the network stack) and a Linux kernel breach will hurt a lot of people and even leak some critical national safety intelligence, but so far the high profile compromises are all userland breaches (both OpenSSL and GNU Bash runs in user mode, not kernel mode. Both always had some competitors like GnuTLS and LibreSSL for OpenSSL, as well as Z shell and Debian Almquist Shell for GNU Bash) and this fact attests the security of Linux kernel. So even if your project cannot use the full Linux kernel for any reason, lifting the network stack code from Linux and adapt it for yourself is still a better idea, safety wise, than using your homebrew or a chip like W5200.

[nctnico]

If the Linux kernel source wasn't such an utter mess I agree it would make sense to try and adapt the Linux network stack for microcontroller use.

[Mechanical Menace]

Nor did I publicly document it like some security "researchers" tend to do, under a false flag of increasing security awareness.

As a security researcher you go to the vendor with the information first, and generally agree to wait until the issue is fixed before you publish full details. It's only when nothing is being done, they are ignored or illegally threatened that security researchers you so despise tend to publish anyway, to let the public know they aren't secure and those they trust to provide that security don't care.

And no one else appears to have done this either.  Therefore, the public can continue using these devices, without fear of script kiddies like Mallory walking around and causing mischief.

Not every black hat is a script kiddie. All the public can be sure of in your case is no one is even trying to fix a known problem, so it is almost certainly being exploited. You could do it, what makes you think you're so special no one else could?

Even if something can be exploited, there is no issue unless the exploit actually enters the wrong hands.

And every time an exploit is just ignored instead of reported AND fixed that becomes more likely. If it isn't fixed it's better for the public to know they are not secure and be able to take precautions than falsely believe nothing is wrong so do nothing.

[diyaudio]

I keep seeing mention of allwinner aXX products, I also noticed its a "Chinese  supported chip" and this chip has brute force flooded the market and made its way in cheap to medium quality electronic products.. Anyway, the point im  trying to make is this..if you try and Google SDK resources on any allwinner chip details, the platform is sparse and very very nebulous... its also mostly used in China for "their engineers" its a useless platform for English speaking people because majority of its SDK resources is biased to the Chinese space so what use is that to the rest of the world.
 

           

[MagicSmoker]

Interesting.  A couple of thoughts:

1) Reset must be asserted for at least 2us to work as per the datasheet, must be driven both active low and high as the WIZ810MJ lacks a pull-up on the reset line, and must be asserted after power-up else inconsistent behavior can result.  (I had all sorts of weird trouble until I did these things properly.)

Yep, that's generally true of any microprocessor. I directly connected the reset terminal on the WIZ810MJ to a pin on the AVR and during the boot sequence the code would bring that pin low for 10ms then high again. We also tried resetting the W5100 whenever there was a prolonged absence of data on the MISO line and LINK was active; no love - power needed to be cycled to unfreeze the little bastard.

...The W5100 can handle no more than 4 open sockets, but may be configured for as few as 1.

Yep, we knew of that limitation.

What you experienced suggests there may have been an issue with the webpage design, that caused it to exceed the basic limitations of the W5100.

Now you are invoking the age-old dispute: the hardware engineer says the software is buggy while the software engineer says the hardware is glitchy...

In the end, though, the real problem was that Wiznet failed to provide meaningful technical support so I will no longer consider using them. Better hardware and/or software engineers might succeed where we have failed, but why bother when there are so many uC out there with ethernet support built in (and even some with both the MAC and PHY)?

[nctnico]

Interesting.  A couple of thoughts:

1) Reset must be asserted for at least 2us to work as per the datasheet, must be driven both active low and high as the WIZ810MJ lacks a pull-up on the reset line, and must be asserted after power-up else inconsistent behavior can result.  (I had all sorts of weird trouble until I did these things properly.)

Yep, that's generally true of any microprocessor. I directly connected the reset terminal on the WIZ810MJ to a pin on the AVR and during the boot sequence the code would bring that pin low for 10ms then high again. We also tried resetting the W5100 whenever there was a prolonged absence of data on the MISO line and LINK was active; no love - power needed to be cycled to unfreeze the little bastard.

To me this sounds like either a reset problem (I think reset must be low during power up) and/or a power supply problem (maximum current or decoupling). The  WIZ810MJ module doesn't look very well designed. I'm missing power decoupling, overvoltage protection and measures to reduce emitted EMC radiation (no a common mode transformer in an ethernet transformer is not going to cut it). But maybe these components are mounted on the bottom.

[Chris C]

As a security researcher you go to the vendor with the information first, and generally agree to wait until the issue is fixed before you publish full details. It's only when nothing is being done, they are ignored or illegally threatened that security researchers you so despise tend to publish anyway, to let the public know they aren't secure and those they trust to provide that security don't care.

In general, I agree with you.  My concern is situations in which:

1) The product is no longer being manufactured, or has been replaced with a new product that lacks the issue; but the affected product is still in widespread use.
2) The issue is of a nature that it cannot be fixed or protected against, without incurring expenses that either the manufacturer or consumers would consider excessive.
3) The issue could be easily exploited by someone with minimal skills, if they are aware of the issue.
4) No evidence can be found that the issue is publicly known, or is being exploited.  This does not preclude the possibility that exploitation exists, but it is likely to be on such a limited scale that losses are infinitesimally small, compared to those that would be incurred if the issue was made publicly known.

For as long as all four conditions hold, there is NO possible positive outcome from making the issue public.  A responsible security researcher will understand this, and withhold the information.

But as you said, not every black hat is a script kiddie.  Some call themselves security researchers.  And would gladly boost their fame regardless of the consequences to others, if not reveling to have caused those consequences.

[nctnico]

The 5th option is: the security hole is already being abused but nobody tells anyone about it.

[technix]

I keep seeing mention of allwinner aXX products, I also noticed its a "Chinese  supported chip" and this chip has brute force flooded the market and made its way in cheap to medium quality electronic products.. Anyway, the point im  trying to make is this..if you try and Google SDK resources on any allwinner chip details, the platform is sparse and very very nebulous... its also mostly used in China for "their engineers" its a useless platform for English speaking people because majority of its SDK resources is biased to the Chinese space so what use is that to the rest of the world.
 

         

Sorry buddy but I took offense from your comments, and look at the sidebar to find out where I am from, and why I took the offense.

If you don't feel like tackling the SDK you can just grab the linux-sunxi code and forge ahead - drivers usually does not depend on chip detail thanks to Linux driver layering. Also, you could have asked Allwinner nicely for documentations.