Putting private key in HTTP post makes protocol vulnerable to man-in-the-middle attacks about phant HOT 20 CLOSED

HTTPS is supported on data.sparkfun.com (if the client supports it), and you can send your key via a request header, but HTTPS is the best way to avoid that type of attack. The main issue with HTTPS is that most IoT devices can't do HTTPS.

We are open to ideas if you have any.

from phant.

Yeah, we are definitely aware.

Some discussion of what to do about this starting here and here.

from phant.

(Heh, sorry 'bout overlapping comment @toddtreece.)

from phant.

To keep the system usable for small systems (think Arduino) it might be a good idea to let the device generate a random key (or use some unique identifier like a MAC address) and let the owner of the account determine which devices are accepted. Don't use the same private key for posting data as for doing important stuff like delete the stream. Maybe add a mechanism where clients and servers can call a plugin library (via callback function) to encrypt/decrypt/sign data. For many simple projects, the whole encrypting thing is probably not an issue so they would use no plugin, for others, it may be a lot more important to guarantee the integrity between client and server so they would plug in a library with something SSL-ish.

from phant.

Solving the general problem: what encrypted transport can a IoT device use is difficult. @quartzjer has been working on Telehash for a while, which is an overlay network that supports encryption by default. It runs on the Pinoccio devices I believe. I'm not sure of how easily it is deployed though.

Back to the more immediate problem. An ARM / Linux device like Beagles and PI will have no problem handling SSL. AVRs are another story. If you are willing to use hardware to solve the problem, then you could use the ATECC108s, like those on the CryptoCape to supply random and provide digital signatures. However, it's not the most open thing to require everybody buy an ECC108, (or a CryptoCape, although I wouldn't mind :p)

Another idea would be to use some like HOTP, like Google Authenticator, for one time passwords. But that might be awkward for unattended devices.

from phant.

We talked to @quartzjer about using telehash as a input, and I think that's still possible. He had mentioned that he should be able to get it running on an Arduino, but I haven't had time to check in with him lately.

from phant.

What is that private key and how is it used? Is the the server's private key or for the device? It looks like it is used just for a serial number? https://github.com/sparkfun/phant/blob/master/lib/http_input.js#L113

from phant.

Public Key: Unique identifier for the data stream
Private Key: Used with the public key to auth and post data
Delete Key: One time use. Used to completely remove a stream and its metadata

This might not be the most secure thing in the world, but we were trying to make it simple to create a stream without requiring an account. All data is public, and even if you hide your stream from the public list, someone can read it if they have the public key (and obviously write if they get the private key).

from phant.

Ok, thanks that helps and I understand the challenge now.

So you don't need cryptography for confidentiality, since all data is
public, but you want to authenticate users and protect the integrity of
their data. The constraints are that the device, connecting to the service
is most likely an Arduino w/o any sophisticated crypto libs AND w/o a
reliable random generator.

The problem is, people will probably assume that nobody can change their
stream (fair assumption) and may rely on the data in the service. It sounds
like not a big deal if others can read it, but it might be a big deal if
people change the data. Big deal here means: 1.) they might not trust your
service anymore or 2.) may make incorrect decisions based on a hacked
stream.

Right now, the public / private key pairs are a bit overkill b/c you are
using them like a cookie. In fact, it may just be easier to do that: Server
presents cookie to Arduino, Arduino gives it back. You have the same MITM
problem, but it's easier for all parties involved.

The cookie approach is not bad per se, but you should let users know that
this service is more like a public wall. i.e. You guys are offering a cool
service, it's fun, it's helpful, but don't rely on it for critical data
applications.

The general problem: how to have a vanilla Arduino communicate securely
with a web service, probably shouldn't be tackled by this service.
Personally, I think that is ok as long as fix the expectations for your
users.

Anyway, thanks for spinning this up. As always, SF is awesome.

On Thu, Jul 10, 2014 at 2:31 PM, Todd Treece [email protected]
wrote:

Public Key: Unique identifier for the data stream
Private Key: Used with the public key to auth and post data
Delete Key: One time use. Used to completely remove a stream and its
metadata

This might not be the most secure thing in the world, but we were trying
to make it simple to create a stream without requiring an account. All data
is public, and even if you hide your stream from the public list, someone
can read it if they have the public key (and obviously write if they get
the private key).

—
Reply to this email directly or view it on GitHub
#49 (comment).

from phant.

Wait, the device needs Node.js to work right? So arduinos are out?!

The beagle should be generating the key pairs, posting the public key to the server. You can still use the cookie for ID/tracking, but the beagle should sign its posts and the server should verify them.

from phant.

Wait, the device needs Node.js to work right? So arduinos are out?!

Servers need Node.js; the goal is that clients should pretty well be able to run on anything that can put together an HTTP request.

from phant.

...and eventually UDP, TCP, telehash etc. The server generates the keys when the new stream is made and gives them to the user. The user then uses the public/private pair to post data.

from phant.

The only reason to use a public / private key pair is if you are going to sign, encrypt, or decrypt something. It doesn't look that's happening but it's being used as an ID.

If you want an ID, drop the key pairs, they aren't doing anything for you, use a cookie.

If you want to strongly authenticate users you either need to require them to not only generate a HTTP request, but perform cryptographic operations. This requirement will eliminate some devices.

If you don't want to eliminate some devices, then the device must either have a crypto library in addition to whatever they are doing, or add a chip like the ATECC108 which will generate private/public key pairs where the private key never leaves the chip.

from phant.

I think we might be causing confusion with our terminology. We aren't using the term 'keys' to represent public key crypto, just keys to a locked thing. It should probably be something like: ID, post secret, delete secret.

The reason we aren't just using the private key to post, is because I wanted all of the routes to use the same format: /streams/public_key, /input/public_key, /output/public_key. That way people wouldn't get confused and use the private key in places where they should be using the public key, or use the wrong private key and post to the wrong stream (if they have multiple streams). It doesn't add security, but I think it helps standardize the HTTP request format.

I think that this issue is much larger than phant or data.sparkfun.com, and I hope SparkFun can help encourage innovation in this area. It would be great if we could make versions of WiFi and Ethernet shields that handled HTTPS, but I'm guessing that's a lot to ask for.

All I know is I'm definitely not the one to solve this. I can barely deal with the keys to my house.

from phant.

Phant and data.sparkfun.com already support SSL; the solution is to simply not allow your requests to go over a non-SSL connection if you want to avoid leaking your private stream key.

There are absolutely methods which enable us to push data semi-securely over a non-SSL connection, such as using a TOTP code, or by signing requests with the private key, but they all have their own issues. Ultimately, it's adding unnecessary complexity, and it's attempting to come up with a solution for an issue which is already solved.

Arduino devices are intended to be simple, cheap, and user-friendly, which means they aren't the most feature-rich platforms (granted, the Arduino Yun can support SSL by means of the on-board AR9331 used for the WiFi stack). Many dev boards with an ARM processor are likely to have some form of SSL support (for example, NETMF on the FEZ or Linux on the RasPi/PcDuino/BeagleBone) if you want to stick with a one-board solution which is comparably priced.

If it's really a problem and you have no other option, I'd recommend implementing some kind of request proxy which handles your own layer of security. Off the top of my head, an 'easy' 5-minute solution would be to identically seed a random number generator on both ends and XOR your entire request. Could someone catch on to what you're doing and figure out your seed? Sure, but the effort required to implement something better but-not-quite-ssl, such as telehash, on both ends likely far outweighs the $30 cost for a RasPi.

from phant.

At minimum can you change "private key" to "cookie?" When you code includes
a public "private key" in plaintext and you pass that over an insecure
channel, you are effectively throwing chum in the water and attracting
sharks.

On Wed, Jul 16, 2014 at 3:09 PM, Nick Wilson [email protected]
wrote:

Phant and data.sparkfun.com already support SSL; the solution is to
simply not allow your requests to go over a non-SSL connection if you want
to avoid leaking your private stream key.

There are absolutely methods which enable us to push data semi-securely
over a non-SSL connection, such as using a TOTP
https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm
code, or by signing requests with the private key, but they all have their
own issues. Ultimately, it's adding unnecessary complexity, and it's
attempting to come up with a solution for an issue which is already solved.

Arduino devices are intended to be simple, cheap, and user-friendly, which
means they aren't the most feature-rich platforms (granted, the Arduino Yun
can support SSL by means of the on-board AR9331 used for the WiFi stack).
Many dev boards with an ARM processor are likely to have some form of SSL
support (for example, NETMF http://www.netmf.com/ on the FEZ
https://www.ghielectronics.com/catalog/product/450 or Linux on the RasPi
https://www.sparkfun.com/products/12994//PcDuino
https://www.sparkfun.com/products/12077/BeagleBone
https://www.sparkfun.com/products/12857) if you want to stick with a
one-board solution which is comparably priced.

If it's really a problem and you have no other option, I'd recommend
implementing some kind of request proxy which handles your own layer of
security. Off the top of my head, an 'easy' 5-minute solution would be to
identically seed a random number generator on both ends and XOR your entire
request. Could someone catch on to what you're doing and figure out your
seed? Sure, but the effort required to implement something better
but-not-quite-ssl, such as telehash, on both ends likely far outweighs the
$30 cost for a RasPi.

—
Reply to this email directly or view it on GitHub
#49 (comment).

from phant.

Hey Josh - I think a terminology switch is in the works, if nothing else since "key" has so far only clouded conversation.

I'm also not really thinking of the underlying issue as closed - I do think we're hoping to work out an input module with better security/identity/tamper-resistance properties. Lotta discussions still to be had about this.

from phant.

@jbdatko Yeah. What about switching key to hash? I think cookie could cause just as much confusion when sending HTTP requests. Or would changing the name private to something like push key or publish key, and changing public key to ID be less confusing? I don't think it's going to be that hard to change either way, I just thought the lock and key analogy was something people would understand right away.

from phant.

From what I've read of the architecture, publish key/ID sounds like a more
descriptive name.
On Jul 19, 2014 7:45 AM, "Todd Treece" [email protected] wrote:

@jbdatko https://github.com/jbdatko Yeah. What about switching key to
hash? I think cookie could cause just as much confusion when sending
HTTP requests. Or would changing the name private to something like push
key or publish key, and changing public key to ID be less
confusing? I don't think it's going to be that hard to change either way, I
just thought the lock and key analogy was something people would understand
right away.

—
Reply to this email directly or view it on GitHub
#49 (comment).

from phant.

There are absolutely methods which enable us to push data semi-securely over a non-SSL connection, such as using a TOTP code, or by signing requests with the private key, but they all have their own issues. Ultimately, it's adding unnecessary complexity, and it's attempting to come up with a solution for an issue which is already solved.

@Nick-W what's the issue of "signing requests with the private key"?
It's not needed to sign the whole request, but only to sign a one-time and always increasing magic number, then include the public key, the signature and the number in the request. This will need less computation on both client and server side than the HTTPS solution. Anyway this will require users to play with cryptography in application, thus not perfect especially when a TLS/SSL termination proxy device/solution is cheap/easy to deploy.

from phant.