Main Site Documentation

Which GHIelectronics product should I use for my project?


#1

I am trying to figure out which GHIelectronics product that I should use for my opensource/closed source project.

My project consists of collecting environmental sensor data, encapsulate the sensor data values inside of a JSON string, then send the JSON string to my server that will take the results and plot them on a graph or show the result in a radial gauge and etc… Now, I would like to encrypt the JSON string first using AES256 or another encrypt cypher before sending the data my server for further processing.

I have already implemented what I explained above minus the encryption part. I have now hit a brick wall while attempting to implement encryption into my project. I have used the Espruino and the mbed platform to gather the sensor data; however, I can’t seem to add encryption to my project because either there isn’t enough memory to sustain the encryption or there isn’t a safe/secure encryption library created. I have come across an mbed library for AES encryption using ECB, however, IMHO ECB really isn’t that secure and I would like to keep up with the current secure AES cyphers and use a well known AES library.

I am thinking of moving away from the other micro-controller platforms and gravitate toward .net framework for micro-controllers. Can someone please recommend a GHIelectronics micro-controller that supports AES256 encryption?


#2

If you need the encryption, I would use any of the G120 based board.
Without encryption you could also use Carb family, but if you go commertial with a Cerb, check with GHI directly before.

And: welcome to the community. :slight_smile:


#3

G120 or G400 is what you need. They support encryption and even support SSL.

Welcome to the community.


#4

Hi, thanks for the warm welcome :slight_smile:

I researched both the G120 and G400 and they both seem to have the same specs except for the form factor. Am I correct about the specifications?

I was looking more at the G120 so I can solder the board down to a custom designed motherboard.

I will be computing PH, Ec and temp of a solution. The PH and Ec value will be computed using another product that will be communicating via i2c. The temp will be calculated by a MCP9701 sensor. All the values will be displayed over 3 7-segment displays from sparkfun and also stored inside of a JSON string. The JSON string will then be encrypted first and sent over SSL to my server.

I was also thinking, if possible, of creating an HTTPs server in netmf to update/change settings and view the results on javascript guages. Would a HTTPs be possible?

As far as the commercial side of my project, will I be required to purchase a commercial license and/or commercial libraries?


#5

Simply put, no they’re very different specs. Check out the specifications tab on each of these:

https://www.ghielectronics.com/catalog/product/373
G120 module $34 ea
120Mhz ARM Cortex M3
~13Mb ram available to user data

https://www.ghielectronics.com/catalog/product/480
G400-s module $69 ea
400Mhz ARM9
92Mb RAM

and that’s just top-line things.


#6

Are you aware of this https://www.us-cert.gov/ncas/alerts/TA14-290A


#7

I am sure that would get resolved in open ssl and then it makes its way into netmf.


#8

I’m sorry, I should of double checked and proof-read my post before posting. I confused the g400-d with the g120.


#9

PiWi, no I wasn’t aware of that :confused: thanks for informing me. I hope that exploit gets fixed.


#10

It’s been fixed in OpenSSL, but it could be a LONG LONG time before it trickles down to actual hardware (OpenSSL -> NETMF -> GHI SDK -> updated firmware).

If you have a NETMF device with which you use SSL, you should be aware that you could be vulnerable to the POODLE bug.


#11

@ Gus - Are you aware of this issue being raised in the netmf/iot group?


#12

This came up before but feel free to post a ticket on netmf codeplex also.


#13

@ godefroi - your optimism and positivity is always helping :slight_smile:


#14

Done -> https://netmf.codeplex.com/workitem/2386


#15

I know you’re joking, but this type of vulnerability can be extremely serious depending on how people are using the affected products. Dismissing it with “I’m sure it’ll get resolved at some point” is disappointing to someone who could be facing legal repercussions and the threat of loss.


#16

I researched more into the POODLE vulnerability and the subject is still over my head; however, my understanding is, SSL 3.0 will soon be deprecated or it has been already and users should use TLS without the ability to downgrade to SSL. Will the SoC microcontrollers support TLS?


#17

I don’t know for sure, but my guess is that they already support TLS 1.1 (at least) and maybe TLS 1.2. The real question is whether they support SSL 3.0 or TLS 1.0 (which can be caused to downgrade to SSL 3.0). If they do, they’re vulnerable.


#18

I know in the desktop/server environment, admins have the ability to set a flag during the server configuration to keep TLS 1.0 from downgrading to SSL 3.0. I wonder if it is possible to do the same in netmf?