Hi Cullen, On 2019-05-16 08:21, Cullen Jennings wrote: > >> On May 14, 2019, at 3:15 PM, Magnus Westerlund via Datatracker <noreply@xxxxxxxx> wrote: >> >> >> A significant security vunerability in PERC that should be made more explicit >> and is totally missing is the risks with compromised endpoints. Beyond the very >> evident thing that this endpoint can decrypt all media it receives there are >> far more sinister risk here. Namely the potential for injection of media that >> attempts to impersonate another endpoints media stream. Most of SRTP's cipher >> suits only use symmetric crypto functions, thus enabling anyone with the key to >> send a packet with any SSRC, and have that being accepted as that source.. Where >> it is has no practical usage in point to point communication, in conferencing >> it becomes an issue. It allows the usage of media level replay or deep fakes to >> be used to create media streams that are injected into the media distributors >> using an SSRC of another endpoint. >> >> The mitiagations that are missing from this document. The fact that a media >> distributor that is not compromised or collaborating with the compromised >> endpoint could actually prevent such media injection by applying source >> filtering of SSRCs and drop all that aren't associated with the endpoint.. The >> other potential mitigation is to introduce another cipher suit that uses a non >> symmetric integrity protection mechanism, such as TESLA to prevent this type of >> injection. > And the related issue that the main way this can happen is attacker manipulation of the fingerprint so the providing ways to protect that along with SSRC based signalling or TELSA is the obvious solution space to this. And just to frame the discussion, let me point out the issue you raise is not so much about an SSRC but binding the identity of a member of the group to the audio received. Yes, agree that the fundamental is to know which identity that create a particular packet. How that is accomplished there are many solutions. > > As other have pointed out, which member inside the conference the media is from is not something PERC provides any information about. Many existing conference systems have existing approaches to solve this problem and they can add PERC as a tool with out breaking theses so it to be specified here. Something that used TESLA could work fine with PERC as well. I do think future work can look at what we need for rosters and active speakers and how to use things like STIR and fingerprints and SDP to tie identity to the media. However, I think that problem is fairly separable from the issue of making sure the operator of the media switch does not have access to the media content. Yes, and to be clear I don't expect that base PERC solution should solve the issue. I only requested that the security properties that exist are made clear. Regarding your below questions I will reply to that separately and it may take me a couple of days. Cheers Magnus > > But just to explore what solutions could be build on top of PERC to solve this, let me cary on. > > Early on the WG did consider one an Ericssons proposal that used SSRC based signalling for many things but the WG moved away from that at least partially over concerns of Ericsson IPR in this space. In trying to refresh some of the state on possible solutions to this I came across. > > https://patentimages.storage.googleapis.com/07/b2/6a/f34fd49f38a5a4/US20180205720A1.pdf > > which has the following claim > > 39) A method for a server for enabling setting up a secure peer - to - peer connection between a first peer and a second peer , wherein at least one of the first peer and the second peer is a web browser , the method comprising : receiving a request for a web application from the first peer ; sending a directive to the first peer requesting a fingerprint of a certificate of the first peer ; receiving a first fingerprint from the first peer ; and sending the first fingerprint to the second peer . > > So just to make sure I understand this, if we have a case where a webapp sends an SDP offer that goes to the first peer, this requests the certificate and of the first peer and sends it in the SDP answer to the webapp that then sends that answer on to the second peer. It seems this claim surely covers a bunch stuff we are doing in WebRTC as well as PERC and needs to be disclosed. You agree ? > > One thing that would work well is an approach like the CSP protection in the above patent mixed with the ability for the KD to bind the client to the web conference application as described in > > https://patentimages.storage.googleapis.com/d0/de/1a/5cbafd9903417b/WO2018063041A1.pdf > > Actually claim 1 seems like that is pretty much perfect for solving this. Claim 1 reads > > 1. A method for a server to bind a device application to a web service, wherein Web Real Time Control, WebRTC, functionality is provided to the server, the method comprises: > -receiving a request for the web service from the device application, wherein communication between the server and the device application is done via https and WebRTC and the device application has generated WebRTC credentials comprising a private key, certificate of the private key and a fingerprint of the certificate, > -receiving the fingerprint and fingerprint generation algorithm of the certificate, > -storing the fingerprint and fingerprint generation algorithm and associating the fingerprint with the device application, and > -using Datagram Transport Layer Security, DTLS, providing the certificate of the device application, in combination with the stored fingerprint to identify the device application to bind the device application to the web service. > > So to walk thorough the parts of this claim. When a user joins the web conference that uses PERC, the request and responses for the fingerprints are send via the SDP offer and answers over HTTPS, the website learns the fingerprint for the user and then when the DTLS connection to the KD is formed, the way the KD correlates to the user to make sure they are the right one to authorize into the conference is by using that same fingerprint. Let me know if I am misunderstanding this or if a disclosure is needed. > > I think you should propose this stuff to dispatch as way to solve the problem of knowing who in a conference the media is coming from. Please let me know if I am misunderstanding theses claims and if disclosures need to be made. > > > > > > -- Magnus Westerlund ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx ----------------------------------------------------------------------
