[OSC_dev] Authentication / Encryption

[Chris]

Hi,

I was wondering, is there a common practice for authenticating OSC
senders and receivers against each other?

Obviously there's transport layer security (OpenVPN, IPSec), but this is
usually quite difficult to set up, besides, I would prefer an all-in-one
solution.

Alternatively one could use a message broker that provides encryption
and authentication, e.g. XMPP or AMQP, and send OSC messages as payload.
There's also the possibility of tunneling everything in a TLS session or
doing some custom authentication inside OSC messages.

So, has this been done before? Is there a recommendation I could stick to?

Thanks
-Chris

[Andy W. Schmeder]

Post by Chris
I was wondering, is there a common practice for authenticating OSC
senders and receivers against each other?

No.

Post by Chris
Obviously there's transport layer security (OpenVPN, IPSec), but this is
usually quite difficult to set up, besides, I would prefer an all-in-one
solution.

SSH tunnels between two points are extremely easy to set up (between any two UNIX-style machines at least).

One can also prioritize SSH traffic for low delay at any intermediate firewall or router, this improves the interactive timing performance considerably.

Here is some more info on that:

http://www.revsys.com/writings/quicktips/ssh-tunnel.html

Post by Chris
Alternatively one could use a message broker that provides encryption
and authentication, e.g. XMPP or AMQP, and send OSC messages as payload.
There's also the possibility of tunneling everything in a TLS session or
doing some custom authentication inside OSC messages.

"Custom" is really only an option if your goal is to prevent casual interference, e.g. keep some users from changing certain settings in a system such as an output gain limiter.

If thats the case, and you only need authentication (not encryption) its reasonably simple to implement it in an OSC #bundle structure, using SHA1 or similar hash function (but avoid MD5 if possible) to authenticate the sender without transmitting a cleartext password. Similar methods are used to authenticate users in web applications without HTTPS (e.g., using Javascript to compute the hash function in the browser). I can elaborate more if desired.


---

Andy W. Schmeder
email: andy [at] cnmat.berkeley.edu
skype: andy.schmeder

Programmer/Analyst II
Research Group
Center for New Music and Audio Technologies
University of California at Berkeley
http://cnmat.berkeley.edu

[l***@proquariat.de]

Post by Andy W. Schmeder
SSH tunnels between two points are extremely easy to set up (between any two UNIX-style machines at least).
One can also prioritize SSH traffic for low delay at any intermediate firewall or router, this improves the interactive timing performance considerably.
http://www.revsys.com/writings/quicktips/ssh-tunnel.html

Thanks, I totally forgot about SSH tunnels. But still, I would prefer
something that doesn't need any extra steps besides starting my program.

Post by Andy W. Schmeder

Post by Chris
Alternatively one could use a message broker that provides encryption
and authentication, e.g. XMPP or AMQP, and send OSC messages as payload.
There's also the possibility of tunneling everything in a TLS session or
doing some custom authentication inside OSC messages.

"Custom" is really only an option if your goal is to prevent casual interference, e.g. keep some users from changing certain settings in a system such as an output gain limiter.
If thats the case, and you only need authentication (not encryption) its reasonably simple to implement it in an OSC #bundle structure, using SHA1 or similar hash function (but avoid MD5 if possible) to authenticate the sender without transmitting a cleartext password. Similar methods are used to authenticate users in web applications without HTTPS (e.g., using Javascript to compute the hash function in the browser). I can elaborate more if desired.

My goal is to send sensor data through a network (that can not alway be
trusted) to a server and I want to be sure that this data is neither
spoofed nor tampered. Encryption is just a nice to have feature but not
really necessary at the moment.
I'm no security expert, so I'm always a bit cautious implementing
something like this myself. So, can you please elaborate?

Thanks
-Chris

[Jeff Koftinoff]

You can read up on Digital Signature Algorithims here:

http://en.wikipedia.org/wiki/Digital_Signature_Algorithm

the openssl and gnu-tls libraries have implementations of FIPS-186-3 which may be useful.

Regards,
Jeff

Post by l***@proquariat.de

Post by Andy W. Schmeder
SSH tunnels between two points are extremely easy to set up (between any two UNIX-style machines at least).
One can also prioritize SSH traffic for low delay at any intermediate firewall or router, this improves the interactive timing performance considerably.
http://www.revsys.com/writings/quicktips/ssh-tunnel.html

Thanks, I totally forgot about SSH tunnels. But still, I would prefer
something that doesn't need any extra steps besides starting my program.

Post by Andy W. Schmeder

Post by Chris
Alternatively one could use a message broker that provides encryption
and authentication, e.g. XMPP or AMQP, and send OSC messages as payload.
There's also the possibility of tunneling everything in a TLS session or
doing some custom authentication inside OSC messages.

"Custom" is really only an option if your goal is to prevent casual interference, e.g. keep some users from changing certain settings in a system such as an output gain limiter.
If thats the case, and you only need authentication (not encryption) its reasonably simple to implement it in an OSC #bundle structure, using SHA1 or similar hash function (but avoid MD5 if possible) to authenticate the sender without transmitting a cleartext password. Similar methods are used to authenticate users in web applications without HTTPS (e.g., using Javascript to compute the hash function in the browser). I can elaborate more if desired.

My goal is to send sensor data through a network (that can not alway be
trusted) to a server and I want to be sure that this data is neither
spoofed nor tampered. Encryption is just a nice to have feature but not
really necessary at the moment.
I'm no security expert, so I'm always a bit cautious implementing
something like this myself. So, can you please elaborate?
Thanks
-Chris
_______________________________________________
OSC_dev mailing list
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Ross Bencina]

Post by l***@proquariat.de
My goal is to send sensor data through a network (that can not alway be
trusted) to a server and I want to be sure that this data is neither
spoofed nor tampered. Encryption is just a nice to have feature but not
really necessary at the moment.
I'm no security expert, so I'm always a bit cautious implementing
something like this myself. So, can you please elaborate?

So what you need is a digital signature. Each message needs to be signed
so you can verify that it was sent by who you expected, and not tampered
with.

You could use public key cryptography: the sender could sign with a
private key and the receiver could check that the signature is correct
(with a public key).

Then you just need to make sure that the key exchange is secure :)

Or if you can pre-distribute a shared private key you could use a shared
private key based signing algorithm. e.g. HMAC:

http://en.wikipedia.org/wiki/HMAC

HMAC is easy to implement. I've seen it used to confirm that URLs havn't
been tampered.

I have no idea about whether it's cryptographically strong enough for
your application. In part this depends on the strength of the private key.

You could generate your OSC bundle with a placeholder message:

[
/hmac-md5 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
]

The sender computes the hash and substitute it into the message. The
receiver would do the reverse (extract the hash and replace with Xs,
then compute the message hash and compare it to the received one).

Ross

[l***@proquariat.de]

I read up on digital signatures and in my case replay-attacks are a
possibility (I don't want ancient sensor data presented as current data).
So I need a nonce in my signed messages. Is it safe to just use an OSC
timetag as nonce? I would store the last received timetag in a database
and only accept messages from that client with timetags greater than the
one in the database.


-Chris

Post by Ross Bencina

Post by l***@proquariat.de
My goal is to send sensor data through a network (that can not alway be
trusted) to a server and I want to be sure that this data is neither
spoofed nor tampered. Encryption is just a nice to have feature but not
really necessary at the moment.
I'm no security expert, so I'm always a bit cautious implementing
something like this myself. So, can you please elaborate?

So what you need is a digital signature. Each message needs to be signed
so you can verify that it was sent by who you expected, and not tampered
with.
You could use public key cryptography: the sender could sign with a
private key and the receiver could check that the signature is correct
(with a public key).
Then you just need to make sure that the key exchange is secure :)
Or if you can pre-distribute a shared private key you could use a shared
http://en.wikipedia.org/wiki/HMAC
HMAC is easy to implement. I've seen it used to confirm that URLs havn't
been tampered.
I have no idea about whether it's cryptographically strong enough for
your application. In part this depends on the strength of the private key.
[
/hmac-md5 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
]
The sender computes the hash and substitute it into the message. The
receiver would do the reverse (extract the hash and replace with Xs,
then compute the message hash and compare it to the received one).
Ross
_______________________________________________
OSC_dev mailing list
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Roger Dannenberg]

Be aware that cryptography alone does not prevent replay attacks where
someone holds a message and retransmits it later. This can be prevented
by using sequence numbers or some other shared state combined with a
reliable transport protocol, but this may conflict with minimizing
latency and ignoring dropped packets as in UDP. If you tunnel UDP
through an SSH tunnel, the UDP will be delivered reliably because SSH is
built above TCP. I suppose with clock synchronization, timestamps, and a
history buffer recording recent packet ID's, you could encrypt UDP data
to authenticate the sender and you could toss out late and duplicate
packets at the receiving end. You'd still have to implement a secure key
exchange as Ross says. I haven't seen anyone take this approach, so take
it as a suggested possibility that needs to be thought through.

In short: Moving from UDP to a secure transport may have a significant
impact on the network behavior (this could be good, i.e. no dropped
packets, or bad, i.e. higher latency).

-Roger

Post by Ross Bencina

Post by l***@proquariat.de
My goal is to send sensor data through a network (that can not alway be
trusted) to a server and I want to be sure that this data is neither
spoofed nor tampered. Encryption is just a nice to have feature but not
really necessary at the moment.
I'm no security expert, so I'm always a bit cautious implementing
something like this myself. So, can you please elaborate?

So what you need is a digital signature. Each message needs to be signed
so you can verify that it was sent by who you expected, and not tampered
with.
You could use public key cryptography: the sender could sign with a
private key and the receiver could check that the signature is correct
(with a public key).
Then you just need to make sure that the key exchange is secure :)
Or if you can pre-distribute a shared private key you could use a shared
http://en.wikipedia.org/wiki/HMAC
HMAC is easy to implement. I've seen it used to confirm that URLs havn't
been tampered.
I have no idea about whether it's cryptographically strong enough for
your application. In part this depends on the strength of the private key.
[
/hmac-md5 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
]
The sender computes the hash and substitute it into the message. The
receiver would do the reverse (extract the hash and replace with Xs,
then compute the message hash and compare it to the received one).
Ross
_______________________________________________
OSC_dev mailing list
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Jeff Koftinoff]

It may be worthwhile to investigate DTLS:

http://stackoverflow.com/questions/7008597/securing-udp-openssl-or-gnutls-or

Regards,
Jeff

Post by Roger Dannenberg
Be aware that cryptography alone does not prevent replay attacks where
someone holds a message and retransmits it later. This can be prevented
by using sequence numbers or some other shared state combined with a
reliable transport protocol, but this may conflict with minimizing
latency and ignoring dropped packets as in UDP. If you tunnel UDP
through an SSH tunnel, the UDP will be delivered reliably because SSH is
built above TCP. I suppose with clock synchronization, timestamps, and a
history buffer recording recent packet ID's, you could encrypt UDP data
to authenticate the sender and you could toss out late and duplicate
packets at the receiving end. You'd still have to implement a secure key
exchange as Ross says. I haven't seen anyone take this approach, so take
it as a suggested possibility that needs to be thought through.
In short: Moving from UDP to a secure transport may have a significant
impact on the network behavior (this could be good, i.e. no dropped
packets, or bad, i.e. higher latency).
-Roger

Post by Ross Bencina

Post by l***@proquariat.de
My goal is to send sensor data through a network (that can not alway be
trusted) to a server and I want to be sure that this data is neither
spoofed nor tampered. Encryption is just a nice to have feature but not
really necessary at the moment.
I'm no security expert, so I'm always a bit cautious implementing
something like this myself. So, can you please elaborate?

So what you need is a digital signature. Each message needs to be signed
so you can verify that it was sent by who you expected, and not tampered
with.
You could use public key cryptography: the sender could sign with a
private key and the receiver could check that the signature is correct
(with a public key).
Then you just need to make sure that the key exchange is secure :)
Or if you can pre-distribute a shared private key you could use a shared
http://en.wikipedia.org/wiki/HMAC
HMAC is easy to implement. I've seen it used to confirm that URLs havn't
been tampered.
I have no idea about whether it's cryptographically strong enough for
your application. In part this depends on the strength of the private key.
[
/hmac-md5 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
]
The sender computes the hash and substitute it into the message. The
receiver would do the reverse (extract the hash and replace with Xs,
then compute the message hash and compare it to the received one).
Ross
_______________________________________________
OSC_dev mailing list
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

_______________________________________________
OSC_dev mailing list
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Roger Dannenberg]

And a couple of links away, here's a very nice paper that pretty much
covers everything we discussed:

http://crypto.stanford.edu/~nagendra/papers/dtls.pdf

Post by Jeff Koftinoff
http://stackoverflow.com/questions/7008597/securing-udp-openssl-or-gnutls-or
Regards,
Jeff

Post by Roger Dannenberg
Be aware that cryptography alone does not prevent replay attacks where
someone holds a message and retransmits it later. This can be prevented
by using sequence numbers or some other shared state combined with a
reliable transport protocol, but this may conflict with minimizing
latency and ignoring dropped packets as in UDP. If you tunnel UDP
through an SSH tunnel, the UDP will be delivered reliably because SSH is
built above TCP. I suppose with clock synchronization, timestamps, and a
history buffer recording recent packet ID's, you could encrypt UDP data
to authenticate the sender and you could toss out late and duplicate
packets at the receiving end. You'd still have to implement a secure key
exchange as Ross says. I haven't seen anyone take this approach, so take
it as a suggested possibility that needs to be thought through.
In short: Moving from UDP to a secure transport may have a significant
impact on the network behavior (this could be good, i.e. no dropped
packets, or bad, i.e. higher latency).
-Roger

Post by Ross Bencina

Post by l***@proquariat.de
My goal is to send sensor data through a network (that can not alway be
trusted) to a server and I want to be sure that this data is neither
spoofed nor tampered. Encryption is just a nice to have feature but not
really necessary at the moment.
I'm no security expert, so I'm always a bit cautious implementing
something like this myself. So, can you please elaborate?

So what you need is a digital signature. Each message needs to be signed
so you can verify that it was sent by who you expected, and not tampered
with.
You could use public key cryptography: the sender could sign with a
private key and the receiver could check that the signature is correct
(with a public key).
Then you just need to make sure that the key exchange is secure :)
Or if you can pre-distribute a shared private key you could use a shared
http://en.wikipedia.org/wiki/HMAC
HMAC is easy to implement. I've seen it used to confirm that URLs havn't
been tampered.
I have no idea about whether it's cryptographically strong enough for
your application. In part this depends on the strength of the private key.
[
/hmac-md5 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
]
The sender computes the hash and substitute it into the message. The
receiver would do the reverse (extract the hash and replace with Xs,
then compute the message hash and compare it to the received one).
Ross
_______________________________________________
OSC_dev mailing list
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

_______________________________________________
OSC_dev mailing list
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

_______________________________________________
OSC_dev mailing list
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Adrian Freed]

I like the riskier approach of using edge router firewalling to protect a trusted zone. Within this zone
you have a weakest-link-in-the-chain security challenge but you can run whatever you want without incurring
latency.

Post by Jeff Koftinoff
http://stackoverflow.com/questions/7008597/securing-udp-openssl-or-gnutls-or
Regards,
Jeff

Post by Roger Dannenberg
Be aware that cryptography alone does not prevent replay attacks where
someone holds a message and retransmits it later. This can be prevented
by using sequence numbers or some other shared state combined with a
reliable transport protocol, but this may conflict with minimizing
latency and ignoring dropped packets as in UDP. If you tunnel UDP
through an SSH tunnel, the UDP will be delivered reliably because SSH is
built above TCP. I suppose with clock synchronization, timestamps, and a
history buffer recording recent packet ID's, you could encrypt UDP data
to authenticate the sender and you could toss out late and duplicate
packets at the receiving end. You'd still have to implement a secure key
exchange as Ross says. I haven't seen anyone take this approach, so take
it as a suggested possibility that needs to be thought through.
In short: Moving from UDP to a secure transport may have a significant
impact on the network behavior (this could be good, i.e. no dropped
packets, or bad, i.e. higher latency).
-Roger

Post by Ross Bencina

Post by l***@proquariat.de
My goal is to send sensor data through a network (that can not alway be
trusted) to a server and I want to be sure that this data is neither
spoofed nor tampered. Encryption is just a nice to have feature but not
really necessary at the moment.
I'm no security expert, so I'm always a bit cautious implementing
something like this myself. So, can you please elaborate?

So what you need is a digital signature. Each message needs to be signed
so you can verify that it was sent by who you expected, and not tampered
with.
You could use public key cryptography: the sender could sign with a
private key and the receiver could check that the signature is correct
(with a public key).
Then you just need to make sure that the key exchange is secure :)
Or if you can pre-distribute a shared private key you could use a shared
http://en.wikipedia.org/wiki/HMAC
HMAC is easy to implement. I've seen it used to confirm that URLs havn't
been tampered.
I have no idea about whether it's cryptographically strong enough for
your application. In part this depends on the strength of the private key.
[
/hmac-md5 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
]
The sender computes the hash and substitute it into the message. The
receiver would do the reverse (extract the hash and replace with Xs,
then compute the message hash and compare it to the received one).
Ross
_______________________________________________
OSC_dev mailing list
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

_______________________________________________
OSC_dev mailing list
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

_______________________________________________
OSC_dev mailing list
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Tristan Matthews]

Post by Roger Dannenberg
In short: Moving from UDP to a secure transport may have a significant
impact on the network behavior (this could be good, i.e. no dropped
packets, or bad, i.e. higher latency).

FWIW while working on this project
(http://code.sat.qc.ca/trac/scenic/), where we were sending OSC, audio
and video over RTP (i.e. UDP), running over OpenVPN added minimal
overhead/latency.

Best,
Tristan

[Erik de Castro Lopo]

Post by Chris
Obviously there's transport layer security (OpenVPN, IPSec), but this is
usually quite difficult to set up, besides, I would prefer an all-in-one
solution.

I've heard IPSec is difficult to set up, but OpenVPN is really pretty
easy (at least for self signed point to point situation) and it works
really well.

Erik