Subject: [Perc] What is happening with the design team for E2E protection in SRTP

From: Magnus Westerlund <[email-masked]>
Date: Wed, 9 Sep 2015 12:00:27 +0200

Hi,

To my understanding the chairs where going to start up a design team for 
discussing and developing a proposal for how the end-to-end protection 
should be done in SRTP.

Considering that it is only slightly more than a month to draft cut-off 
and 1,5 months to Yokohama, if we should make any progress prior to that 
we need to get started.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 24 Sep 2015 15:46:21 -0600

> and 1,5 months to Yokohama, if we should make any progress prior to that

Any further news on this?

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 24 Sep 2015 22:11:36 -0400

On Wed, Sep 9, 2015 at 6:00 AM, Magnus Westerlund <
[email-masked]> wrote:

> and 1,5 months to Yokohama, if we should make any progress prior to that we
> need to get started.
>
> Cheers
>
> Magnus Westerlund
>

Is this set in stone or are people willing to consider how to do it
differently.

There is a technique called proxy re-encryption, or recryption as we are
calling it for short. In your normal public key encryption scheme you have
an encryption key and a decryption key and that is it.

In a Diffie-Hellman scheme, i.e. all the ECC schemes we might use there is
a third option. A person with a decryption key can generate a recryption
key that allows a third party to take a message encrypted under encryption
key X and recrypt it to encryption key Y without ever having the ability to
decrypt the message.

This has been applied to mailing lists so that messages can be sent to the
list under a single encryption key and then remailed to a set of recipients
under their encryption key without the remailer having decryption
capability. Only the administrator of the list (who knows the decryption
key) can add or remove users. And only the administrator needs to know all
the members of the list.

So think of a mailing list as a security label. If you are a authorized for
that label you get to see the traffic, otherwise you do not.

In a recryption scheme, a security label is associated with a public
encryption key. Anyone who posts documents to that label encrypts them
under that key. The administrator of the security label knows the
decryption key. Granting read access to the label to a recipient means
calculating the recryption key for the recipient's public encryption key
and posting it to the service.

We can think of a chat room or a video cam room as a security label.
Whoever sets up the room gets to decide who can join or not. Those
decisions are made on their local machine which is the only place that is
vulnerable to a disclosure breach. The service is just a dumb
remailer/directory/recryptor.

The math is pretty straightforward. If you understand how DH works,
recryption is pretty straghtforward.

As far as IP goes, Matt Blaze invented the idea 20 years ago before we had
so many devices we really needed it. The DH version is ten years old.

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 29 Sep 2015 01:46:42 +0000

Phillip,

Noting is set in stone, yet.

I have a couple of questions:

1) How large is the ciphertext for these schemes vs. the plaintext?  
With the symmetric cryptography used on SRTP, the size of the ciphertext 
equals the plaintext.
2) I think you're saying a middlebox could receive a message encrypted 
using key X (that it does not know) and re-encrypt that so that key Y is 
used to decrypt.  I assume the middlebox is using a public key Y and 
only the corresponding private key for Y can decrypt it?

Paul

------ Original Message ------
From: "Phillip Hallam-Baker" <[email-masked]>
To: "Magnus Westerlund" <[email-masked]>
Cc: [email-masked]
Sent: 9/24/2015 10:11:36 PM
Subject: Re: [Perc] What is happening with the design team for E2E 
protection in SRTP

>
>
>On Wed, Sep 9, 2015 at 6:00 AM, Magnus Westerlund 
><[email-masked]> wrote:
>>Hi,
>>
>>To my understanding the chairs where going to start up a design team 
>>for discussing and developing a proposal for how the end-to-end 
>>protection should be done in SRTP.
>>
>>Considering that it is only slightly more than a month to draft 
>>cut-off and 1,5 months to Yokohama, if we should make any progress 
>>prior to that we need to get started.
>>
>>Cheers
>>
>>Magnus Westerlund
>
>There is a technique called proxy re-encryption, or recryption as we 
>are calling it for short. In your normal public key encryption scheme 
>you have an encryption key and a decryption key and that is it.
>
>In a Diffie-Hellman scheme, i.e. all the ECC schemes we might use there 
>is a third option. A person with a decryption key can generate a 
>recryption key that allows a third party to take a message encrypted 
>under encryption key X and recrypt it to encryption key Y without ever 
>having the ability to decrypt the message.
>
>
>This has been applied to mailing lists so that messages can be sent to 
>the list under a single encryption key and then remailed to a set of 
>recipients under their encryption key without the remailer having 
>decryption capability. Only the administrator of the list (who knows 
>the decryption key) can add or remove users. And only the administrator 
>needs to know all the members of the list.
>
>So think of a mailing list as a security label. If you are a authorized 
>for that label you get to see the traffic, otherwise you do not.
>
>calculating the recryption key for the recipient's public encryption 
>key and posting it to the service.
>
>decisions are made on their local machine which is the only place that 
>is vulnerable to a disclosure breach. The service is just a dumb 
>As far as IP goes, Matt Blaze invented the idea 20 years ago before we 
>had so many devices we really needed it. The DH version is ten years 
>old.
>
>
>
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 28 Sep 2015 23:22:44 -0400

On Mon, Sep 28, 2015 at 9:46 PM, Paul E. Jones <[email-masked]>
wrote:

> 1) How large is the ciphertext for these schemes vs. the plaintext?  With
> the symmetric cryptography used on SRTP, the size of the ciphertext equals
> the plaintext.
>

Where do the symmetric keys for the session encryption come from?

This would only affect the key exchange and then only to a rather small
degree. The bulk data would be encrypted under AES as per normal. This is a
scheme you would use in place of RSA or DH for setting up the ASE key.

Crypto data would be of the order of 56 bytes for the maximum strength
keys. In other words, not worth worrying about. One of the nice features of
this scheme is that it makes multiparty communication look pretty much like
a two party communication from the bandwidth point of view.

> used to decrypt.  I assume the middlebox is using a public key Y and only
> the corresponding private key for Y can decrypt it?
>

Well what we are doing here is actually setting up a symmetric session key
that is used as the key for an AES session.

[doing this in straight DH and forgetting the modulo reduction]

So lets say that the public key of the group is e^X and the public key of
the user is e^Y and the recryption key is R.

Note that this public/private key is only used for this particular group
and nothing else.

Alice wants to set up a session. So she chooses a private key A and sends
e^A to the recryptor. The agreed key is e^AX

The recryptor knows only R.

To add a user to the group, the administrator generates a Y, e^Y for them
and calculates the recryption key R = X-Y for that user.

The administrator knows all the values of Y. But that is OK because this
key will only be used for this particular group and the administrator can
read all the messages anyway.

Since the recryptor has to save per-user state, we might as well encrypt Y
under the public key of each user and send it along with the message. Or we
could calculate that as the output of a key agreement on the user's key.

So lets say the user's key is U, e^U, the administrator might calculate
Y=e^XU

The practical upshot of this is that the recryptor can convert the
decryption blob for the group to a per user decryption blob but that is
all. The recryptor cannot decrypt the message and this is provably a zero
knowledge situation.

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 29 Sep 2015 04:31:34 +0000

Phillip,

>>With the symmetric cryptography used on SRTP, the size of the 
>>ciphertext equals the plaintext.
>

In today's deployment, they either come from session signaling over the 
wire (transitive trust model) or from DTLS-SRTP exchanges (but the 
fingerprints for DTLS connections are still often exchanged in 
signaling).  There are exceptions, but I think that's the most popular 
models.

For perc and newer systems in general, increased focus on security is 
going to force changes.  Using trusted third parties to verify 
signatures, etc., is likely, but nothing is specified for perc thus far.

>degree. The bulk data would be encrypted under AES as per normal. This 
>is a scheme you would use in place of RSA or DH for setting up the ASE 
>key.

Initial key exchange is not a big deal -- regardless of what we do.  And 
if we develop a mechanism for efficiently re-keying the conference, then 
all the better.  What's most important is the size of the data packets 
on the wire.  If the scheme allows for comparably-efficient ciphertext 
steeams, then that's good.

>keys. In other words, not worth worrying about. One of the nice 
>features of this scheme is that it makes multiparty communication look 
>pretty much like a two party communication from the bandwidth point of 
>view.

And that's important.

>>using key X (that it does not know) and re-encrypt that so that key Y 
>>is used to decrypt.  I assume the middlebox is using a public key Y 
>>and only the corresponding private key for Y can decrypt it?
>
>Well what we are doing here is actually setting up a symmetric session 
>key that is used as the key for an AES session.
>
>So lets say that the public key of the group is e^X and the public key 
>of the user is e^Y and the recryption key is R.
>
>Note that this public/private key is only used for this particular 
>group and nothing else.
>
>Alice wants to set up a session. So she chooses a private key A and 
>sends e^A to the recryptor. The agreed key is e^AX
>
>To add a user to the group, the administrator generates a Y, e^Y for 
>them and calculates the recryption key R = X-Y for that user.
>
>
>The administrator knows all the values of Y. But that is OK because 
>this key will only be used for this particular group and the 
>administrator can read all the messages anyway.
>
>Since the recryptor has to save per-user state, we might as well 
>encrypt Y under the public key of each user and send it along with the 
>message. Or we could calculate that as the output of a key agreement on 
>the user's key.
>
>all. The recryptor cannot decrypt the message and this is provably a 
>zero knowledge situation.

OK, I get the gist of what you're suggesting, but I need a more complete 
write-up to get it clear in my head.  Do you have suggestions for 
reading?

What should be clear to me, though, and isn't is "why".  I think I 
understand that each participant in the conference has a distinct key 
and there is a separate key used by the recryptor.  So, with two 
encryption steps a media flow arrives at an endpoint and it can decrypt 
it.  By why use two encryption steps?  I'm missing the security benefit 
of that vs. all members of the conference using the same symmetric key 
and the conference server taking no action on the E2E encrypted part of 
the packet.

Does this help with "revoking" a key from a user?  Does it make it more 
efficient to distribute keys to new users?  Does it address issues where 
a person joins late and is given a key, but can (if they had the data 
packets) decrypt previously-transmitted media?  (Protecting the 
confidentiality of the conference as users come and leave is important 
considerations; I should not be able to decrypt packets after I leave or 
that were sent before I join.)

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 29 Sep 2015 08:23:53 -0400

> Phillip,
...

> understand that each participant in the conference has a distinct key and
> there is a separate key used by the recryptor.  So, with two encryption
> steps a media flow arrives at an endpoint and it can decrypt it.  By why
> use two encryption steps?  I'm missing the security benefit of that vs. all
> members of the conference using the same symmetric key and the conference
> server taking no action on the E2E encrypted part of the packet.
>
> efficient to distribute keys to new users?  Does it address issues where a
> person joins late and is given a key, but can (if they had the data

The point of doing two encryption steps instead of one is to shrink the
security perimeter and reduce the trust in the cloud service that does
session setup.

I am concerned with hardening systems to make them 'PRISM-proof' and
'Snowden-proof'. We all know about the problem of pervasive surveillance
but the risk of system administrator malfeasance is equally important.
Particularly if the contact service is going to be hosted by a third party.

This approach gives end to end security. The contact service can add or
remove members from the conference but can only add them from the list
created by the group administrator.

In this respect, the contact service is untrusted. It cannot ever get
access to the content.

If you want to support revocation however, the contact service becomes
trusted to enforce the revocation but not performing recryption for the
revoked party. So this is a trusted-untrusted service. The cloud service is
trusted to provide security refinements but a breach of the contact service
does not cause disclosure of content.

If you want to change either the composition of the group or change the
administrator, you will need to perform a rekey of the group. But that need
not cause any sort of interruption in service. Just keep the old keys
running until the rekey event is complete.

As for further documentation, there isn't very much at all. You can look up
'Proxy Re-Encryption' on wikipedia and there is a link to a bibliography of
a half dozen papers. This is not a technique I invented, Matt Blaze did
that 20 odd years ago. But nobody seems to have done anything with it since
or realized the true potential.

This should be a basic building block for crypto protocols. It is how you
make any two party communication into a multiparty communication.