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 aparticular 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 solvethe issue. I only requested that the security properties that exist aremade clear.
Yes, I agree with you that needs to be clear in the security section that PERC does not solve this. It’s a desirable property of a conferencing system so it would be bad if people expected it to be there.
Regarding your below questions I will reply to that separately and it
may take me a couple of days.
No problem, I totally understand theses things take some time to sort out. Thank you for looking into it.
|
