I know time and resources went into developing the SSL, SSH, software. However i have a
curious question. Other embedded Ethernet devices offer this for free with the TCP/IP stack. I am curios why NB chose not to go this route.
SSL, SSH, HTTPS (sold separately)
Re: SSL, SSH, HTTPS (sold separately)
Two reasons:
1)Support SSL/SSH generates a huge amount of support.
People don't understand certificates etc... and they expect us to help them figure it all out.
2)Issues with the development kit and possible export control issues, no SSL/SSH greatly simplifies the export regime for the NNDK.
1)Support SSL/SSH generates a huge amount of support.
People don't understand certificates etc... and they expect us to help them figure it all out.
2)Issues with the development kit and possible export control issues, no SSL/SSH greatly simplifies the export regime for the NNDK.
Re: SSL, SSH, HTTPS (sold separately)
Gotcha, i understand.
I just wish there was a secure way to send control data from one unit to the other.
I just wish there was a secure way to send control data from one unit to the other.
Re: SSL, SSH, HTTPS (sold separately)
If you control both ends of the connection and they can have a shared secret then just use AES to encode your data stream...
Paul
Paul
Re: SSL, SSH, HTTPS (sold separately)
Plus if your creating a production product it's not all that expensive to use it with modules, $495. While certainly not free, its a lot better than what others are charging for license fees on just the software.
Re: SSL, SSH, HTTPS (sold separately)
The problem with aes is that if you send send something from one end to the other, and someone captures that packet they can just resend it again and the receiving end wont know the difference.
For example if the remote end it at a security door, which has an electric door lock, and i send it an aes encrypted message of "unlock door 1". If somone looking on the LAN captured that message, (even though its encrypted) they could just merly send that same message again to the remote end and it would unlock the door again.
The only way to get around this problem, would be to first use a key that both ends know, then have one end ask the other for a new key, which it would randomly generate. send that new key back, then they both would use the new key to communicate. After the connection is closed then they discard that new key, and repeat that same process the next time they talk.
Though its doable, i would much rather have a simpler method to do this which all that is already taken care of in the background.
For example if the remote end it at a security door, which has an electric door lock, and i send it an aes encrypted message of "unlock door 1". If somone looking on the LAN captured that message, (even though its encrypted) they could just merly send that same message again to the remote end and it would unlock the door again.
The only way to get around this problem, would be to first use a key that both ends know, then have one end ask the other for a new key, which it would randomly generate. send that new key back, then they both would use the new key to communicate. After the connection is closed then they discard that new key, and repeat that same process the next time they talk.
Though its doable, i would much rather have a simpler method to do this which all that is already taken care of in the background.