Interesting Implications


Vote on Hacker News

August 3, 2014
WebRTC Security - an overview & privacy/MiTM concerns (including a MiTM example)
January 19, 2014
Bitcoins for BOINC
November 14, 2013
Book Review - Getting Started with WebRTC
August 5, 2013
Secure Distributed CSP - secure scheduling using homomorphic encryption & constraint satisfaction & a (small) paper error
May 5, 2013
5/5/2013 - State of WebRTC DataChannel Support
May 4, 2013
The most awesome plugin you have never heard of - Ming
March 17, 2013
What happened to Blink Personal

Fork this blog:

WebRTC Security - an overview & privacy/MiTM concerns (including a MiTM example) - 2014-08-03 11:13:04

Before we begin, this post assumes you know what WebRTC[0] is. Continuing on…

What your average webrtc connection look like:


There is something that isn't shown in the diagram above. First, each client will contact a STUN server[1] which is uses to determine it’s public IP to later connect to the other client:

via wireshark

Each client will also create a new DTLS key-pair for each connection[2 page 17].

Each connection then communicates that information [3][4], over the signaling channel (often the website itself) in a handshake fashion in order to negotiate parameters. Both sides then attempt to initiate a connection.

What this looks like going over wss (“web socket secure”) in Chrome:

Once that connection is established, a DTLS handshake occurs BETWEEN THE PEERS! If a media connection is needed (non-data), it will use DTLS-SRTP [5][6] where DTLS is used only as a keying mechanism. The signaling server here, was only responsible for communicating DTLS certificate hashes. As long as both hosts trust the server to deliver this hash to the other host, then the peer can be trusted to be who they say they are (or at least who the server says they are).

DTLS-SRTP handshake:


A side note, there has been some controversy[8] around the use of DTLS-SRTP. Chrome used SDES  for a while (not anymore[10]) and ZRTP (supports short authentication string) was another option[11].

Another side note, SDES was actively fought against directly because of the Snowden leaks (note the date here & the next slide states “Surely that would never happen…” and contains a leaked slide):

via, found via (other interesting slide decks there as well)

Alright, so webrtc is simple enough… however there are a couple of problems:

1) Same Origin DTLS Certificates

Interestingly, Chrome and Firefox appear to have different interpretations of section 5.5 of the WebRTC security draft[2 section 5.5]:


Chrome appears to always use the same certificate for the same origin, while Firefox will issue a new certificate. For Chrome, this appears to have been done for performance[7].

This can be tested easily using and Chrome and watching the wss “recieve_anwser” message that comes through from a Firefox client connecting to Chome:
1st connection: a=fingerprint:sha-256 B3:CC:...
2nd connection: a=fingerprint:sha-256 44:D0:...

And in Chrome they are the same (on the same website/origin):
1st connection: a=fingerprint:sha-256 40:BF:...
2nd connection: a=fingerprint:sha-256 40:BF:...

I raised this as issue in a bug report to Chrome as a privacy concern. They cited a lack of W3C API[9] support (I still feel as though they are falling on the anti-privacy side of this API switch...): [Security: WebRTC DTLS key reused on same website]

2a) IdP!

One thing we never mentioned above was how Alice and Bob can prove they are Alice and Bob, without trusting the signaling server. They can do this using a “web-based Identity Provider” (IdP)[14][15].

Remember this picture from above:

However, IdP support is definitely not finalized currently:
-in Chrome, there is no IdP support[16]. Had trouble finding further information.
-in Firefox, there is some support it appears[12][13].

So what’s the problem with this?

Just as WebRTC makes connecting 2 users trivial… it also makes MiTM trivial as well. Let’s do what I can best describe as a server-assisted MiTM with a real life example.

2.b) Server assisted MiTM due to no IdP requirement
In this example, an “evil” server will use a user you specify as an “evil” user to MiTM the other two users in the room. Steps to recreate:

1) Create a room (in Firefox or Chrome) on and connect using username “mitm” (usernames are important here)

2) Connect to that same room in a second tab using username “alice”

3) Connect in a third tab to that same room using username “bob”

4) Chat (file transfer isn’t supported in my code) between “alice” and “bob”

5) observe on user “mitm” that both “alice” and “bob” chat appears:

It will also appears  as well (the MiTM user has will upload everything back to the server to prove this is a MiTM)!

So what happened here? all chat leaving alice/bob goes over a single WebRTC connection and looks normal?
The “evil”server first picks up user “mitm” and sets that as the MiTM’ing user. Alice and Bob are then connected directly to that user! The only way to avoid this would be for Alice/Bob to compare DTLS fingerprints out of band, effectively becoming their own IdP (a text message saying “hey my fingerprint is C0:9E:C2…” is going to be hard to explain to someone) or to a service providing IdP.

So why did I do this?
I really want to highlight why peer identification is important here and the need for IdP providers going forward, especially as I was not able to find any plans for Chrome implementation of this.


Errata, example SDP offers:
Chrome: {"eventName":"send_offer", "data":{ "socketId":"fc30d05c-eb57-cd3d-b3d2-8b0ccdb40e72", "sdp":"{\"sdp\":\" v=0 o=- 5300757472543531077 2 IN IP4 s=- t=0 0 a=group:BUNDLE audio data a=msid-semantic: WMS m=audio 1 RTP/SAVPF 111 103 104 0 8 106 105 13 126 c=IN IP4 a=rtcp:1 IN IP4 a=ice-ufrag:lzXFi7u68Ec7QJ1W a=ice-pwd:9Wb5GELV3i1r5dxF000mCeYn a=ice-options:google-ice a=fingerprint:sha-256 40:BF:C0:9E:C2:C4:AE:8E:95:24:23:B0:73:71:0A:AE:E3:26:3D:23:9F:23:B9:D2:E7:BE:E4:DE:6C:8A:30:74 a=setup:actpass a=mid:audio a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:3 a=recvonly a=rtcp-mux a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 m=application 1 DTLS/SCTP 5000 c=IN IP4 a=ice-ufrag:lzXFi7u68Ec7QJ1W a=ice-pwd:9Wb5GELV3i1r5dxF000mCeYn a=ice-options:google-ice a=fingerprint:sha-256 40:BF:C0:9E:C2:C4:AE:8E:95:24:23:B0:73:71:0A:AE:E3:26:3D:23:9F:23:B9:D2:E7:BE:E4:DE:6C:8A:30:74 a=setup:actpass a=mid:data a=sctpmap:5000 webrtc-datachannel 1024 \",\"type\":\"offer\"}"}} Firefox: {"eventName":"receive_answer", "data":{ "sdp":"{\"type\":\"answer\",\"sdp\":\"v=0 o=Mozilla-SIPUA-28.0 23700 0 IN IP4 s=SIP Call t=0 0 a=ice-ufrag:0d0fe3b0 a=ice-pwd:181e81eaf818127ee68eb53a0db4732f a=fingerprint:sha-256 E7:B0:4C:16:05:50:32:00:25:A1:7A:42:5A:AF:20:B6:05:80:EB:CB:4F:1E:FC:0A:5B:45:11:FC:1B:08:D6:02 m=audio 61300 RTP/SAVPF 111 126 c=IN IP4 a=rtpmap:111 opus/48000/2 a=ptime:20 a=rtpmap:126 telephone-event/8000 a=fmtp:126 0-15 a=inactive a=setup:active a=candidate:0 1 UDP 2128609535 61300 typ host a=candidate:1 1 UDP 1692467199 61300 typ srflx raddr rport 61300 a=candidate:2 1 UDP 2128543999 61301 typ host a=candidate:4 1 UDP 2128478463 61302 typ host a=candidate:0 2 UDP 2128609534 61303 typ host a=candidate:2 2 UDP 2128543998 61304 typ host a=candidate:4 2 UDP 2128478462 61305 typ host a=rtcp-mux m=application 61306 DTLS/SCTP 5000 c=IN IP4 a=sctpmap:5000 webrtc-datachannel 1024 a=setup:active a=candidate:0 1 UDP 2128609535 61306 typ host a=candidate:2 1 UDP 2128543999 61307 typ host a=candidate:4 1 UDP 2128478463 61308 typ host a=candidate:0 2 UDP 2128609534 61309 typ host a=candidate:2 2 UDP 2128543998 61310 typ host a=candidate:4 2 UDP 2128478462 61311 typ host \"}","socketId":"fc30d05c-eb57-cd3d-b3d2-8b0ccdb40e72"}}

-- comments --

Bitcoins for BOINC - 2014-01-19 13:06:07

A tweet:

and inspiration:

For a few years now I have been thinking about how to monetize BOINC credits & then Bitcoins happened.  I'm writing this as a proposal to show how BOINC can create a incentive to further expand it's volunteer computing network. 
I believe the only way this can be done correctly is to be done by each project individually.

What are BOINC credits
"Within the BOINC platform for volunteer computing, the BOINC Credit System helps volunteers keep track of how much CPU time they have donated to various distributed computing projects. The credit system is designed to avoid cheating by validating results before granting credit on projects. This ensures users are returning accurate results for both scientific and statistical reasons."

Some great examples of volunteer computing projects that use this credits system are:
rosetta@home - Distributed protein folding to help cure diseases
seti@home - Distributed search of radio signals for extraterrestrial intelligence

Purposed Payment system
1)Have a BTC "donate now" button on the homepage of your BOINC project
2)Each day pay a fraction of total donations(ie. Bitcoins) out to all users participating(opt-in?). Or in other words:

pay each user per day: (Uc / Tc)(B/100)
Uc = BOINC credit issued to this user (in this day)
Tc = Total BOINC credit of all users enrolled in the payment system (in this day)
B  = Total Bitcoins available
1/100 = % payment per day (could probably make this closer to 1/1000 to make funds last longer depending on donations received).

It's probably possible to get more complicated than just paying out 1/100th of total donations each day, but this does ensure that available funds will last for >100 days & this will incentivize active user to join sooner as the daily payout will go down over time without further donations. 
Actual money($) presents a problem when presented with micro-transactions as processing fees can be large (ie. to issue checks), one way to get around this is to set a minimum payment threshold (ie. $50+  minimum is common). With a virtual currency you are only limited by the payment processor (ie. Coinbase will only pay fees on transactions greater than .001BTC or ~$1).

Why not just create a "bitcoin for BOINC" points website?
2 reasons. 
First is that not every project is interested in having a financial motive tied to their project or they might not be setup to handle such a motive ( money would be a strong incentive to exploit a weak BOINC work verification checker).
Second is that nobody should trust a third party. Each BOINC project should be able to handle their own donations & be a single source of paying for BOINC points to avoid multiple payments for the same BOINC credits.
I have a BOINC project, what should I consider before implementing something like this?
-That your project has a strong way to verify that work has been done before credit is issued.
-You could use this system to market your BOINC project as the Bitcoin/BOINC credit rate might be higher than mining Bitcoins on GPUs.
-That it is in the best interest of your project to have a monetary reward for volunteer computing. Keep in mind that there would be no obligation to pay any Bitcoin/BOINC credit rate. This could create competition where the project gets more computing resources than if those Bitcoins had been converted into dedicated servers. 
-That you have considered the tax & legal consequences of accepting and distributing Bitcoins (I can offer no advice on this).

-- comments --

Book Review - Getting Started with WebRTC - 2013-11-14 21:01:15

I wish I had read this 8 months ago... 

disclaimer: I have been working with WebRTC for about 8 months now and do not think I'm exactly the target audience of this book. I did, however, receive a copy from the publisher to review.

The book is divided into three parts:

The first part does a dive into the world of WebRTC and how communication works at a high level. This is everything I wish I had available to me 8 months ago when there was very little information online about how to use this new technology. Everything presented here is correct, and gives a great base to then go research exactly what the state(codec's, browser support) of WebRTC currently is.

The second part shows you how to build a video/audio/chat application using WebRTC (vaguely similar to which is a great WebRTC example). This section does a deep dive into how to use the video/audio & datachannel streams of WebRTC and then extends it further to show how to use the datachannel to share files.

The third section describes a couple of business use cases and describes what to worry about if you're considering how to use WebRTC inside of your business. These are all important topics that are often overlooked.

Overall I would say that this is a great starting point and a relatively quick read that will get you up to speed with WebRTC in no time!

Publisher link:

-- comments --

Secure Distributed CSP - secure scheduling using homomorphic encryption & constraint satisfaction & a (small) paper error - 2013-08-05 21:26:33

Before we begin, this blog post is based on a 2004 paper called "Secure distributed constraint satisfaction: reaching agreement without revealing private information" by Makoto Yokoo, Koutarou Suzuki & Katsutoshi Hirayama. I found this paper to be brilliant, but extremely difficult to read and rather confusing, so I decided to create this blog post as a resource for anybody hoping to understand this paper. I also believe I have identified an error/oversight contained in this paper (see step 5).
Paper link:

To understand this, we first have to define three ideas:
1) Constraint Satisfaction Problem: Given a set of arbitrary constraints, find a solution to a problem which satisfies these constraints. This can be a Sudoku puzzle, the 8 queens problem etc. We are going to define this here as a scheduling problem where a series of users have constraints in the form of existing calendar entries.
For further reading -
2) Homomorphic Encryption: When a operation (such as addition) is applied to the encrypted version of several values (ie. E(X) + E(Y) = E(Z)), the decrypted result is the same as the result if the operation was applied to the plaintext (ie. D(E(Z)) = D(E(X)) + D(E(Y))). Note: E = encryption function, D = decryption function
For futher reading:
3) ElGamal Encryption: ElGamal is a public key crypto algorithm. Input X and a random number r produce an encrypted pair E(x,y) based on a public key {p,t,B} and can then be decrypted using a private key. This encrypted pair is multiplicatively homomorphic.
For futher reading:

The problem
We have a group of people who are attempting to schedule a meeting. However, they are all competitors. They can't share there schedules or busyness, or else they might gain some sort of competitive edge. They still need to plan this meeting.

Defining the problem a bit more formally
Each person is going to have a series of unary constraints in this CSP problem. This problem must be solved without sharing the unary constraints with any other person or server.

Step one - defining binary constraint matrix and define a server
Each user is going to define a binary constraint matrix between themself and each other user (using ONLY their own unary constraints). What the matrix below says is that this user can only meet with the other users at times x,r,q,p. This matrix is sparse (in the non-formal-mathematical sense) and can only contain information along the axis as users can only meet at the same time.

We are also going to define a server that issues an ElGamal public key.

Step two - modify the matrix
We are now going to do something strange. This is the first step towards using ElGamal. We are going convert all of the 0's into a random number > 1 (that has certain co-prime properties to the public key, for now, lets just say 3 and 5).

Step three - encrypt
We are going to encrypt each entry in the matrix using ElGamal encryption with the public key of the server (using a different random r value for each entry in the BC. The matrix below is split into two, but this should be viewed as 1 matrix which two values at each entry, ie. (y1,y2)).

Step four - share
Now that each users binary matrix has been encrypted, these can be shared between all users. We are now going to go through and multiply each pair of binary matrices together (this is where it is important that ElGamal is homomorphic). Image credit - right side is directly from the paper itself.

Step five - permutation
We now have a series of encrypted BC matrices that are common knowledge between all users. However, if we just sent these to the servers, the server would know our meeting time after decrypting!
Therefore, we must permute each multiplied matrix (by the same permutation for rows and columns! - the paper specifies a different column/row permutation which doesn't work for >2 users. Once the server decrypts this information later the definition of a column/row must stay consistent because with 3 or more users, you can't have a single user always ends up on the same row/column edge. I view this as an error with the paper section 4.3. It is also entirely possible that this isn't an error & I am missing something.).

Step six - send to server
The server now recieves a series of permutated encrypted matrices. It can (with it's private key) decrypt these matrices and then remove the >1/1 convention that we applied during step 2.
D(E(1)xE(1))=D(E(1)) due to the muliplicative homomorphic property of ElGamal, therefore the server knows which schedule works for both users, however, because all the users permuted their matrix, the server does not know which time slot actually works, only that one does.

step seven - solve the CSP
This step is much more straightforward. Because the server now has a series of matrices between all users, it can find the one time slot that works for everyone (This should be a relatively simple CSP to solve). It can then return this value to all users who know the permutation match for that time slot and therefore have a scheduled meeting!

What we did here was demonstrate a way that, using a server, users can safely schedule meetings without their colleagues having knowledge of their schedules (aka unary constraints) by utilizing the multiplicative homomorphic property of the ElGamal algorithm.

Information leakage
-If a single user and the server colludes in this implementation, it could gain information about other users.
-The server does know the "busy-ness" of a pair of users and can use that to to gain information about a specific user.

Taking this further
The paper talks further about having a layer in between the CSP solver(server) and users called "decryptors" that only provides partial solutions to the server, but if multiple decryptors collude, you can still get the full solution, so at some point, you have to trust the server you are sending the data to (which is why I did not include that information here... also I didn't understand it that well myself).

I can share the C code that I used in the class that this project was written for, but out of respect for this class and future students, I will only share it on request... also it was written for a CS class, so don't expect any quality/scalability :)

PDF Presentation
Link to PDF presentation
(The "not recommended reading" slide in the PDF referred to the paper being moderately difficult to read/understand)

-- comments --

5/5/2013 - State of WebRTC DataChannel Support - 2013-05-05 00:08:21

Supported: Firefox Nightly & all version of Chrome.

The good news is that the difference between Firefox Nightly and Chrome are no longer significant. Having just made (a website that allows files and messages to be transmitted over this WebRTC) firefox nightly compatible, the modification was actually fairly straightforward.

Here are the differences that I currently see:
1) The function window.PeerConnection in Chrome is called mozRTCPeerConnection in Firefox Nightly.

2) The function RTCSessionDescription in Chrome is called mozRTCSessionDescription in Firefox Nightly.

3) Differences in supported protocols. Firefox nightly supports both reliable(TCP) and non-reliable(UDP) connections while Chrome only supports non-reliable(UDP) connections. Because of this, you must use this SDP hack to allow Chrome to send more than 30kbps.
Also, as shacharz mentioned here, there are different options when configuring reliability with createDataChannel:
unreliable: { reliable:false }
reliable: N/A
unreliable: { outOfOrderAllowed: true/false, maxRetransmitNum: 0 }
reliable: {}"

As always, PeerJS has a great page dedicated to the status of WebRTC implementation.

-- comments --

-next page->

The views expressed here are strictly my own. © 2007-2014 Sam Erb