[sip-comm-dev] [gsoc] SRTP work status update


#1

Hi all,

After some time's work, there are some new thoughts / status updates
regarding SRTP implementation that I'd like to share with you. :slight_smile:

As planned on the road map
(http://www.sip-communicator.org/index.php/Development/RoadmapSuBing),
in the last few weeks my work is primarily focused on the following 4
items:

1. Migrate current RTPConnector implementation into sip communicator's
media package.
2. Design an encryption service interface.
3. Implement encryption service using NULL transform.
4. Implement encryption service using bouncy castle, if time permits.

For each of them, I will explain the detailed status:
1. The migration work is started, but not finished. I put
TransformConnector's code under a new package at
"net.java.sip.communicator.impl.media.transformer". Then I modified
CallSessionImpl's initializeRtpManager method, using
TransformConnector to initialize RTPManager. The TransformConnector
object is created through TransformManager.createSRTPConnector method,
by passing master key and srtp/srtcp's encryption policy. Because we
uses customized RTPConnector to transport our RTP packets, we can't
use RTPManager's addTarget / removeTargets methods as specified by the
JMF API doc. So, we need to modify the initStreamTarget /
stopStreaming method of CallSessionImpl, replace the
addTarget/removeTargets method call with our TransformConnector's
equivelent method. This is where I am currently working on.

2. I created a crypto service in sip-communicator. Its has a
"CryptoManager" interface, which is used to create different "Cipher"
objects for different encryption algorithms/methods. At first I
thought may be the Cipher interface should only have two methods:
encrypt(byte[] data) and decrypt(byte[] data). But later after I
learnt a little more about real cryptography implementation. I found
that maybe we need more methods. E.g. for AES ICM method, we will
sometimes need to set the IV (initial vector) for each encryption
call. So, may be the encryption service's interface will be more
specific than I initially thought.

3. NULL Transform is simply copy the input data into the output
buffer. So, this work is done within minutes.

4. I did some study on bouncycastle, and implemented a AES ICM Cipher
based on it. This piece of work is done and tested.

Besides the above 4 items, I did some more study on libsrtp's source
code and RFC3711.
Then I found that besides RTP packet intercepting and encryption, we
will have three more work to be listed on the road map. That is,
first, message authentication - authenticate the srtp packet using
digest algorithms such as HMC_SHA1. Second, Key deravition -- generate
encryption/authentication/salting keys based on master keys / master
salts. And third, replay attack database - identify replayed SRTP
packets. I've learned some information on these topics, but further
study is needed.

Also, there is a problem we should take care of, that is how we
negotiate master keys with other clients? Accroding to libsrtp FAQ
(http://srtp.sourceforge.net/faq.html#Q16), this is beyond the scope
of SRTP and there many ways to solve this problem. According to
wikipedia (http://en.wikipedia.org/wiki/Secure_Real-time_Transport_Protocol#SRTP_Interoperability),
sip seems to be the only protocol that most clients support. So, I
guess we could use the "SDP Security Descriptions" way. But further
study on SDP Security Description is needed.

Although there are some problems need to be studied and maybe
discussed. There are still clear jobs for me to do. So I will continue
my work according to the roadmap and my current understanding.

If you have any questions / suggestions, please contact me directly. :slight_smile:

Thanks,
Su

路路路

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Thank you for the detailed and clear status. And for the work that's
produced that status :). I'm confident that your coding will be as
detail-oriented and clear.

聽聽To quote Bruce Schneier, "security is a process". Open source is a
necessary part of securing software. Because secure code can be trusted
when other people have reviewed and tested it. That "peer review" is the
most important part of any security coding project. What plans do you
have for testing your implementation? Who will test it? Is there a
community that's expecting to receive the code at some point to test? Is
there a group of people on this list, or off it, who is qualified and
willing to test it?

聽聽I'm looking forward to your code passing the tests with flying colors -
a "flying colored bouncy castle" will be a fine thing with which to call
my friends :wink:

路路路

On Tue, 2007-06-12 at 22:38 +0800, Bing Su wrote:

Hi all,

After some time's work, there are some new thoughts / status updates
regarding SRTP implementation that I'd like to share with you. :slight_smile:

As planned on the road map
(http://www.sip-communicator.org/index.php/Development/RoadmapSuBing),
in the last few weeks my work is primarily focused on the following 4
items:

1. Migrate current RTPConnector implementation into sip communicator's
media package.
2. Design an encryption service interface.
3. Implement encryption service using NULL transform.
4. Implement encryption service using bouncy castle, if time permits.

For each of them, I will explain the detailed status:
1. The migration work is started, but not finished. I put
TransformConnector's code under a new package at
"net.java.sip.communicator.impl.media.transformer". Then I modified
CallSessionImpl's initializeRtpManager method, using
TransformConnector to initialize RTPManager. The TransformConnector
object is created through TransformManager.createSRTPConnector method,
by passing master key and srtp/srtcp's encryption policy. Because we
uses customized RTPConnector to transport our RTP packets, we can't
use RTPManager's addTarget / removeTargets methods as specified by the
JMF API doc. So, we need to modify the initStreamTarget /
stopStreaming method of CallSessionImpl, replace the
addTarget/removeTargets method call with our TransformConnector's
equivelent method. This is where I am currently working on.

2. I created a crypto service in sip-communicator. Its has a
"CryptoManager" interface, which is used to create different "Cipher"
objects for different encryption algorithms/methods. At first I
thought may be the Cipher interface should only have two methods:
encrypt(byte[] data) and decrypt(byte[] data). But later after I
learnt a little more about real cryptography implementation. I found
that maybe we need more methods. E.g. for AES ICM method, we will
sometimes need to set the IV (initial vector) for each encryption
call. So, may be the encryption service's interface will be more
specific than I initially thought.

3. NULL Transform is simply copy the input data into the output
buffer. So, this work is done within minutes.

4. I did some study on bouncycastle, and implemented a AES ICM Cipher
based on it. This piece of work is done and tested.

Besides the above 4 items, I did some more study on libsrtp's source
code and RFC3711.
Then I found that besides RTP packet intercepting and encryption, we
will have three more work to be listed on the road map. That is,
first, message authentication - authenticate the srtp packet using
digest algorithms such as HMC_SHA1. Second, Key deravition -- generate
encryption/authentication/salting keys based on master keys / master
salts. And third, replay attack database - identify replayed SRTP
packets. I've learned some information on these topics, but further
study is needed.

Also, there is a problem we should take care of, that is how we
negotiate master keys with other clients? Accroding to libsrtp FAQ
(http://srtp.sourceforge.net/faq.html#Q16), this is beyond the scope
of SRTP and there many ways to solve this problem. According to
wikipedia (http://en.wikipedia.org/wiki/Secure_Real-time_Transport_Protocol#SRTP_Interoperability),
sip seems to be the only protocol that most clients support. So, I
guess we could use the "SDP Security Descriptions" way. But further
study on SDP Security Description is needed.

Although there are some problems need to be studied and maybe
discussed. There are still clear jobs for me to do. So I will continue
my work according to the roadmap and my current understanding.

If you have any questions / suggestions, please contact me directly. :slight_smile:

Thanks,
Su

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--

(C) Matthew Rubenstein

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hello Su,

Thank you for your detailed update! I appreciate this.

(more inline)

Bing Su wrote:

Hi all,

After some time's work, there are some new thoughts / status updates
regarding SRTP implementation that I'd like to share with you. :slight_smile:

As planned on the road map
(http://www.sip-communicator.org/index.php/Development/RoadmapSuBing),
in the last few weeks my work is primarily focused on the following 4
items:

1. Migrate current RTPConnector implementation into sip communicator's
media package.
2. Design an encryption service interface.
3. Implement encryption service using NULL transform.
4. Implement encryption service using bouncy castle, if time permits.

For each of them, I will explain the detailed status:
1. The migration work is started, but not finished. I put
TransformConnector's code under a new package at
"net.java.sip.communicator.impl.media.transformer". Then I modified
CallSessionImpl's initializeRtpManager method, using
TransformConnector to initialize RTPManager. The TransformConnector
object is created through TransformManager.createSRTPConnector method,
by passing master key and srtp/srtcp's encryption policy. Because we
uses customized RTPConnector to transport our RTP packets, we can't
use RTPManager's addTarget / removeTargets methods as specified by the
JMF API doc. So, we need to modify the initStreamTarget /
stopStreaming method of CallSessionImpl, replace the
addTarget/removeTargets method call with our TransformConnector's
equivelent method. This is where I am currently working on.

Oh. I imagine this one is a headache, so good luck! Still, make sure you don't forget to test the case of plain old RTP, so that it would work when no security is being used.

2. I created a crypto service in sip-communicator. Its has a
"CryptoManager" interface, which is used to create different "Cipher"
objects for different encryption algorithms/methods.

Cool! Feel free to send it over whenever you feel comfortable.

At first I
thought may be the Cipher interface should only have two methods:
encrypt(byte[] data) and decrypt(byte[] data). But later after I
learnt a little more about real cryptography implementation. I found
that maybe we need more methods. E.g. for AES ICM method, we will
sometimes need to set the IV (initial vector) for each encryption
call. So, may be the encryption service's interface will be more
specific than I initially thought.

OK, I see. I guess the tricky part would be to make the service generic enough so that it would work for most kinds of encryption. If you feel this is not going to be possible, don't hesitate to add method specific interfaces (i.e. one for AES ICM, one for ... whatever else you are planning to implement). These are just thoughts though. You are better placed to know what is it you need exactly.

3. NULL Transform is simply copy the input data into the output
buffer. So, this work is done within minutes.

OK. I am still curious to see the code. Do you think you'd be able to publish some of it one of these days?

4. I did some study on bouncycastle, and implemented a AES ICM Cipher
based on it. This piece of work is done and tested.

Cool!

Besides the above 4 items, I did some more study on libsrtp's source
code and RFC3711.
Then I found that besides RTP packet intercepting and encryption, we
will have three more work to be listed on the road map. That is,
first, message authentication - authenticate the srtp packet using
digest algorithms such as HMC_SHA1.

I am not sure that I understand this (but this is not really a surprise since I really am no expert as far as cryptography goes). Could you please explain some more or post some pointers? Who would be authenticating and against who?

Second, Key deravition -- generate
encryption/authentication/salting keys based on master keys / master
salts. And third, replay attack database - identify replayed SRTP
packets. I've learned some information on these topics, but further
study is needed.

It would be nice if you could post some more details on how and where you are planning to put these in SIP Communicator. At which point do they intervene?

Also, there is a problem we should take care of, that is how we
negotiate master keys with other clients? Accroding to libsrtp FAQ
(http://srtp.sourceforge.net/faq.html#Q16), this is beyond the scope
of SRTP and there many ways to solve this problem. According to
wikipedia (http://en.wikipedia.org/wiki/Secure_Real-time_Transport_Protocol#SRTP_Interoperability),
sip seems to be the only protocol that most clients support. So, I
guess we could use the "SDP Security Descriptions" way. But further
study on SDP Security Description is needed.

Yes, sounds reasonable. Are there any clients that already do this? I'll be curious to see examples of sample session negotiation flows.

Although there are some problems need to be studied and maybe
discussed. There are still clear jobs for me to do. So I will continue
my work according to the roadmap and my current understanding.

Great! Glad to know you are making progress!

Cheers
Emil

路路路

If you have any questions / suggestions, please contact me directly. :slight_smile:

Thanks,
Su

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hi Su,

Thank you for your progress report.
I think Emil has already commented most of the important points. On my side, I would have one more comment: reading your mail, it seems that several side issues were raised (key negotiation etc.). Could you update your roadmap accordingly, and add those items according to their level of importance? Even though you may not have time to address all of them within GSoC, it will help us to have such a document, so that other people (or maybe you :wink: that would be willing to work on that topic after the summer of code would know what's the status and related issues to solve to improve the overall implementation.

Thanks again for your detailed output,

Cheers,
romain

路路路

On 2007/06/12, at 16:38, Bing Su wrote:

Hi all,

After some time's work, there are some new thoughts / status updates
regarding SRTP implementation that I'd like to share with you. :slight_smile:

As planned on the road map
(http://www.sip-communicator.org/index.php/Development/RoadmapSuBing),
in the last few weeks my work is primarily focused on the following 4
items:

1. Migrate current RTPConnector implementation into sip communicator's
media package.
2. Design an encryption service interface.
3. Implement encryption service using NULL transform.
4. Implement encryption service using bouncy castle, if time permits.

For each of them, I will explain the detailed status:
1. The migration work is started, but not finished. I put
TransformConnector's code under a new package at
"net.java.sip.communicator.impl.media.transformer". Then I modified
CallSessionImpl's initializeRtpManager method, using
TransformConnector to initialize RTPManager. The TransformConnector
object is created through TransformManager.createSRTPConnector method,
by passing master key and srtp/srtcp's encryption policy. Because we
uses customized RTPConnector to transport our RTP packets, we can't
use RTPManager's addTarget / removeTargets methods as specified by the
JMF API doc. So, we need to modify the initStreamTarget /
stopStreaming method of CallSessionImpl, replace the
addTarget/removeTargets method call with our TransformConnector's
equivelent method. This is where I am currently working on.

2. I created a crypto service in sip-communicator. Its has a
"CryptoManager" interface, which is used to create different "Cipher"
objects for different encryption algorithms/methods. At first I
thought may be the Cipher interface should only have two methods:
encrypt(byte[] data) and decrypt(byte[] data). But later after I
learnt a little more about real cryptography implementation. I found
that maybe we need more methods. E.g. for AES ICM method, we will
sometimes need to set the IV (initial vector) for each encryption
call. So, may be the encryption service's interface will be more
specific than I initially thought.

3. NULL Transform is simply copy the input data into the output
buffer. So, this work is done within minutes.

4. I did some study on bouncycastle, and implemented a AES ICM Cipher
based on it. This piece of work is done and tested.

Besides the above 4 items, I did some more study on libsrtp's source
code and RFC3711.
Then I found that besides RTP packet intercepting and encryption, we
will have three more work to be listed on the road map. That is,
first, message authentication - authenticate the srtp packet using
digest algorithms such as HMC_SHA1. Second, Key deravition -- generate
encryption/authentication/salting keys based on master keys / master
salts. And third, replay attack database - identify replayed SRTP
packets. I've learned some information on these topics, but further
study is needed.

Also, there is a problem we should take care of, that is how we
negotiate master keys with other clients? Accroding to libsrtp FAQ
(http://srtp.sourceforge.net/faq.html#Q16), this is beyond the scope
of SRTP and there many ways to solve this problem. According to
wikipedia (http://en.wikipedia.org/wiki/Secure_Real-time_Transport_Protocol#SRTP_Interoperability),
sip seems to be the only protocol that most clients support. So, I
guess we could use the "SDP Security Descriptions" way. But further
study on SDP Security Description is needed.

Although there are some problems need to be studied and maybe
discussed. There are still clear jobs for me to do. So I will continue
my work according to the roadmap and my current understanding.

If you have any questions / suggestions, please contact me directly. :slight_smile:

Thanks,
Su

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Romain KUNTZ
kuntz@lsiit.u-strasbg.fr
Louis Pasteur University - Networks and Protocols Team

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Hi Emil,

Thank you for your reviewing.
I'd like to communicate in this detailed way, if it works fine. :slight_smile:

Hello Su,

Thank you for your detailed update! I appreciate this.

Oh. I imagine this one is a headache, so good luck! Still, make sure you
don't forget to test the case of plain old RTP, so that it would work
when no security is being used.

Of course, plain old RTP implementation is the basic need of SIP Communicator.
I must make sure there is problem about this.

> 2. I created a crypto service in sip-communicator. Its has a
> "CryptoManager" interface, which is used to create different "Cipher"
> objects for different encryption algorithms/methods.

Cool! Feel free to send it over whenever you feel comfortable.

> At first I
> thought may be the Cipher interface should only have two methods:
> encrypt(byte[] data) and decrypt(byte[] data). But later after I
> learnt a little more about real cryptography implementation. I found
> that maybe we need more methods. E.g. for AES ICM method, we will
> sometimes need to set the IV (initial vector) for each encryption
> call. So, may be the encryption service's interface will be more
> specific than I initially thought.

OK, I see. I guess the tricky part would be to make the service generic
enough so that it would work for most kinds of encryption. If you feel
this is not going to be possible, don't hesitate to add method specific
interfaces (i.e. one for AES ICM, one for ... whatever else you are
planning to implement). These are just thoughts though. You are better
placed to know what is it you need exactly.

I am looking at some reference implementation -- in fact, in JCE and
bouncy castle, they have their abstraction. But that would be much
more complicated than we would need. So, I think maybe I can borrow a
subset of their abstraction and then define ours.

> 3. NULL Transform is simply copy the input data into the output
> buffer. So, this work is done within minutes.

OK. I am still curious to see the code. Do you think you'd be able to
publish some of it one of these days?

Yes, they are in the attachments. If there is any problem, please tell me. :slight_smile:
I'm wondering if my understanding is correct, because from wikipedia,
I know there two
definitions of Null Cipher. (http://en.wikipedia.org/wiki/Null_cipher)
But in libsrtp, their implementation is simply leave the plain text
untouched, i.e. my current "copy" implementation.

> 4. I did some study on bouncycastle, and implemented a AES ICM Cipher
> based on it. This piece of work is done and tested.

Cool!

> Besides the above 4 items, I did some more study on libsrtp's source
> code and RFC3711.
> Then I found that besides RTP packet intercepting and encryption, we
> will have three more work to be listed on the road map. That is,
> first, message authentication - authenticate the srtp packet using
> digest algorithms such as HMC_SHA1.

I am not sure that I understand this (but this is not really a surprise
since I really am no expert as far as cryptography goes). Could you
please explain some more or post some pointers? Who would be
authenticating and against who?

As defined in RFC3711 section 4.2 "Message Authentication and
Integrity", SRTP offers authentication service besides encryption
service. This service ensures that the RTP packets received haven't
been altered by attackers.

> Second, Key deravition -- generate
> encryption/authentication/salting keys based on master keys / master
> salts. And third, replay attack database - identify replayed SRTP
> packets. I've learned some information on these topics, but further
> study is needed.

It would be nice if you could post some more details on how and where
you are planning to put these in SIP Communicator. At which point do
they intervene?

Actually, these all belong to SRTP implementation and will be enclosed
in the srtp related package. Key deravition is used at the beginning
of the session, and replay attack database is used all over the
session. Key deravition is a required if we want to make srtp call
with other clients. However replay attack database is optional, based
on my understanding. :slight_smile:

> Also, there is a problem we should take care of, that is how we
> negotiate master keys with other clients? Accroding to libsrtp FAQ
> (http://srtp.sourceforge.net/faq.html#Q16), this is beyond the scope
> of SRTP and there many ways to solve this problem. According to
> wikipedia (http://en.wikipedia.org/wiki/Secure_Real-time_Transport_Protocol#SRTP_Interoperability),
> sip seems to be the only protocol that most clients support. So, I
> guess we could use the "SDP Security Descriptions" way. But further
> study on SDP Security Description is needed.

Yes, sounds reasonable. Are there any clients that already do this? I'll
be curious to see examples of sample session negotiation flows.

I am also not very clear how many clients are doing this. But
according to the wiki link above, CounterPath's eyeBeam does. And from
this link: http://en.wikipedia.org/wiki/SDES you can find a example of
the exchanged SDP messages. Hope this could answer your question.

> Although there are some problems need to be studied and maybe
> discussed. There are still clear jobs for me to do. So I will continue
> my work according to the roadmap and my current understanding.

Great! Glad to know you are making progress!

Thank you Emil, it's fun to work with all you guys.

crypto-service-code.zip (7.17 KB)

路路路

On 6/18/07, Emil Ivov <emcho@emcho.com> wrote:

Cheers
Emil

>
> If you have any questions / suggestions, please contact me directly. :slight_smile:
>
> Thanks,
> Su
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
> For additional commands, e-mail: dev-help@sip-communicator.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Hi Romain,

Thank you for your kind reminder :slight_smile:

I think perhaps I need some more study on those side issues,
especially after reading Werner's mail. Could you please give me a few
days to sort the things up. And then update the roadmap?
I think the update will be more stable and more precise when I am more
clear about the problems (and possiblly their general solution).

Best regards,
Su

路路路

On 6/18/07, Romain KUNTZ <kuntz@clarinet.u-strasbg.fr> wrote:

Hi Su,

Thank you for your progress report.
I think Emil has already commented most of the important points. On
my side, I would have one more comment: reading your mail, it seems
that several side issues were raised (key negotiation etc.). Could
you update your roadmap accordingly, and add those items according to
their level of importance? Even though you may not have time to
address all of them within GSoC, it will help us to have such a
document, so that other people (or maybe you :wink: that would be
willing to work on that topic after the summer of code would know
what's the status and related issues to solve to improve the overall
implementation.

Thanks again for your detailed output,

Cheers,
romain

On 2007/06/12, at 16:38, Bing Su wrote:

> Hi all,
>
> After some time's work, there are some new thoughts / status updates
> regarding SRTP implementation that I'd like to share with you. :slight_smile:
>
> As planned on the road map
> (http://www.sip-communicator.org/index.php/Development/RoadmapSuBing),
> in the last few weeks my work is primarily focused on the following 4
> items:
>
> 1. Migrate current RTPConnector implementation into sip communicator's
> media package.
> 2. Design an encryption service interface.
> 3. Implement encryption service using NULL transform.
> 4. Implement encryption service using bouncy castle, if time permits.
>
> For each of them, I will explain the detailed status:
> 1. The migration work is started, but not finished. I put
> TransformConnector's code under a new package at
> "net.java.sip.communicator.impl.media.transformer". Then I modified
> CallSessionImpl's initializeRtpManager method, using
> TransformConnector to initialize RTPManager. The TransformConnector
> object is created through TransformManager.createSRTPConnector method,
> by passing master key and srtp/srtcp's encryption policy. Because we
> uses customized RTPConnector to transport our RTP packets, we can't
> use RTPManager's addTarget / removeTargets methods as specified by the
> JMF API doc. So, we need to modify the initStreamTarget /
> stopStreaming method of CallSessionImpl, replace the
> addTarget/removeTargets method call with our TransformConnector's
> equivelent method. This is where I am currently working on.
>
> 2. I created a crypto service in sip-communicator. Its has a
> "CryptoManager" interface, which is used to create different "Cipher"
> objects for different encryption algorithms/methods. At first I
> thought may be the Cipher interface should only have two methods:
> encrypt(byte[] data) and decrypt(byte[] data). But later after I
> learnt a little more about real cryptography implementation. I found
> that maybe we need more methods. E.g. for AES ICM method, we will
> sometimes need to set the IV (initial vector) for each encryption
> call. So, may be the encryption service's interface will be more
> specific than I initially thought.
>
> 3. NULL Transform is simply copy the input data into the output
> buffer. So, this work is done within minutes.
>
> 4. I did some study on bouncycastle, and implemented a AES ICM Cipher
> based on it. This piece of work is done and tested.
>
> Besides the above 4 items, I did some more study on libsrtp's source
> code and RFC3711.
> Then I found that besides RTP packet intercepting and encryption, we
> will have three more work to be listed on the road map. That is,
> first, message authentication - authenticate the srtp packet using
> digest algorithms such as HMC_SHA1. Second, Key deravition -- generate
> encryption/authentication/salting keys based on master keys / master
> salts. And third, replay attack database - identify replayed SRTP
> packets. I've learned some information on these topics, but further
> study is needed.
>
> Also, there is a problem we should take care of, that is how we
> negotiate master keys with other clients? Accroding to libsrtp FAQ
> (http://srtp.sourceforge.net/faq.html#Q16), this is beyond the scope
> of SRTP and there many ways to solve this problem. According to
> wikipedia (http://en.wikipedia.org/wiki/Secure_Real-
> time_Transport_Protocol#SRTP_Interoperability),
> sip seems to be the only protocol that most clients support. So, I
> guess we could use the "SDP Security Descriptions" way. But further
> study on SDP Security Description is needed.
>
> Although there are some problems need to be studied and maybe
> discussed. There are still clear jobs for me to do. So I will continue
> my work according to the roadmap and my current understanding.
>
> If you have any questions / suggestions, please contact me
> directly. :slight_smile:
>
> Thanks,
> Su
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
> For additional commands, e-mail: dev-help@sip-
> communicator.dev.java.net
>

--
Romain KUNTZ
kuntz@lsiit.u-strasbg.fr
Louis Pasteur University - Networks and Protocols Team

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

Hi Su,

Hey you service looks really nice! Do you want me to commit it?

There are only a few formalities that need to be fixed:

1. Include SIP Communicator license header in all files (you can use any other SC file as an example)

2. Make sure you have complete javadocs for avery method/field in your classes (that's even advised for private ones)

3. According to SC conventions we are using package imports as opposed to explicit ones.

Cheers
Emil

Bing Su wrote:

路路路

Hi Emil,

Thank you for your reviewing.
I'd like to communicate in this detailed way, if it works fine. :slight_smile:

On 6/18/07, Emil Ivov <emcho@emcho.com> wrote:

Hello Su,

Thank you for your detailed update! I appreciate this.

Oh. I imagine this one is a headache, so good luck! Still, make sure you
don't forget to test the case of plain old RTP, so that it would work
when no security is being used.

Of course, plain old RTP implementation is the basic need of SIP Communicator.
I must make sure there is problem about this.

2. I created a crypto service in sip-communicator. Its has a
"CryptoManager" interface, which is used to create different "Cipher"
objects for different encryption algorithms/methods.

Cool! Feel free to send it over whenever you feel comfortable.

At first I
thought may be the Cipher interface should only have two methods:
encrypt(byte[] data) and decrypt(byte[] data). But later after I
learnt a little more about real cryptography implementation. I found
that maybe we need more methods. E.g. for AES ICM method, we will
sometimes need to set the IV (initial vector) for each encryption
call. So, may be the encryption service's interface will be more
specific than I initially thought.

OK, I see. I guess the tricky part would be to make the service generic
enough so that it would work for most kinds of encryption. If you feel
this is not going to be possible, don't hesitate to add method specific
interfaces (i.e. one for AES ICM, one for ... whatever else you are
planning to implement). These are just thoughts though. You are better
placed to know what is it you need exactly.

I am looking at some reference implementation -- in fact, in JCE and
bouncy castle, they have their abstraction. But that would be much
more complicated than we would need. So, I think maybe I can borrow a
subset of their abstraction and then define ours.

3. NULL Transform is simply copy the input data into the output
buffer. So, this work is done within minutes.

OK. I am still curious to see the code. Do you think you'd be able to
publish some of it one of these days?

Yes, they are in the attachments. If there is any problem, please tell me. :slight_smile:
I'm wondering if my understanding is correct, because from wikipedia,
I know there two
definitions of Null Cipher. (http://en.wikipedia.org/wiki/Null_cipher)
But in libsrtp, their implementation is simply leave the plain text
untouched, i.e. my current "copy" implementation.

4. I did some study on bouncycastle, and implemented a AES ICM Cipher
based on it. This piece of work is done and tested.

Cool!

Besides the above 4 items, I did some more study on libsrtp's source
code and RFC3711.
Then I found that besides RTP packet intercepting and encryption, we
will have three more work to be listed on the road map. That is,
first, message authentication - authenticate the srtp packet using
digest algorithms such as HMC_SHA1.

I am not sure that I understand this (but this is not really a surprise
since I really am no expert as far as cryptography goes). Could you
please explain some more or post some pointers? Who would be
authenticating and against who?

As defined in RFC3711 section 4.2 "Message Authentication and
Integrity", SRTP offers authentication service besides encryption
service. This service ensures that the RTP packets received haven't
been altered by attackers.

Second, Key deravition -- generate
encryption/authentication/salting keys based on master keys / master
salts. And third, replay attack database - identify replayed SRTP
packets. I've learned some information on these topics, but further
study is needed.

It would be nice if you could post some more details on how and where
you are planning to put these in SIP Communicator. At which point do
they intervene?

Actually, these all belong to SRTP implementation and will be enclosed
in the srtp related package. Key deravition is used at the beginning
of the session, and replay attack database is used all over the
session. Key deravition is a required if we want to make srtp call
with other clients. However replay attack database is optional, based
on my understanding. :slight_smile:

Also, there is a problem we should take care of, that is how we
negotiate master keys with other clients? Accroding to libsrtp FAQ
(http://srtp.sourceforge.net/faq.html#Q16), this is beyond the scope
of SRTP and there many ways to solve this problem. According to
wikipedia (http://en.wikipedia.org/wiki/Secure_Real-time_Transport_Protocol#SRTP_Interoperability),
sip seems to be the only protocol that most clients support. So, I
guess we could use the "SDP Security Descriptions" way. But further
study on SDP Security Description is needed.

Yes, sounds reasonable. Are there any clients that already do this? I'll
be curious to see examples of sample session negotiation flows.

I am also not very clear how many clients are doing this. But
according to the wiki link above, CounterPath's eyeBeam does. And from
this link: http://en.wikipedia.org/wiki/SDES you can find a example of
the exchanged SDP messages. Hope this could answer your question.

Although there are some problems need to be studied and maybe
discussed. There are still clear jobs for me to do. So I will continue
my work according to the roadmap and my current understanding.

Great! Glad to know you are making progress!

Thank you Emil, it's fun to work with all you guys.

Cheers
Emil

If you have any questions / suggestions, please contact me directly. :slight_smile:

Thanks,
Su

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

Hi Su,

I am looking at some reference implementation -- in fact, in JCE and
bouncy castle, they have their abstraction. But that would be much
more complicated than we would need. So, I think maybe I can borrow a
subset of their abstraction and then define ours.

Also, do not try to rewrite something already done. If bouncycastle/JCE is too big, we can solve this later. I think the most interesting part is to get it to work first. Also, you say that we do not need such complications. Is it because we plan to begin with simple ciphers, or do you mean that we will never need large parts of these abstractions ?

> 3. NULL Transform is simply copy the input data into the output
> buffer. So, this work is done within minutes.

OK. I am still curious to see the code. Do you think you'd be able to
publish some of it one of these days?

Yes, they are in the attachments. If there is any problem, please tell me. :slight_smile:
I'm wondering if my understanding is correct, because from wikipedia,
I know there two
definitions of Null Cipher. (http://en.wikipedia.org/wiki/Null_cipher)
But in libsrtp, their implementation is simply leave the plain text
untouched, i.e. my current "copy" implementation.

Yes, this is what we mean in this project. Null cipher as "no cipher at all", how secure :smiley: !

Keep up the good work !

Jean

路路路

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#9

Hi Emil,

It's such a honor that my code could be accepted and committed to CVS. :slight_smile:
But for now, I'm not sure if it is stable enough to be put into the
primary repository.
So, if there is no requirement from other module. I'd like to continue
working on it.

For the formalities, I will follow them with no doubt. :slight_smile:

BTW: The code of SIP Communicator is so beautiful. I love it, hoho.

Best regards,
Su

路路路

On 6/19/07, Emil Ivov <emcho@emcho.com> wrote:

Hi Su,

Hey you service looks really nice! Do you want me to commit it?

There are only a few formalities that need to be fixed:

1. Include SIP Communicator license header in all files (you can use any
other SC file as an example)

2. Make sure you have complete javadocs for avery method/field in your
classes (that's even advised for private ones)

3. According to SC conventions we are using package imports as opposed
to explicit ones.

Cheers
Emil

Bing Su wrote:
> Hi Emil,
>
> Thank you for your reviewing.
> I'd like to communicate in this detailed way, if it works fine. :slight_smile:
>
> On 6/18/07, Emil Ivov <emcho@emcho.com> wrote:
>> Hello Su,
>>
>> Thank you for your detailed update! I appreciate this.
>>
>> Oh. I imagine this one is a headache, so good luck! Still, make sure you
>> don't forget to test the case of plain old RTP, so that it would work
>> when no security is being used.
>
> Of course, plain old RTP implementation is the basic need of SIP Communicator.
> I must make sure there is problem about this.
>
>>> 2. I created a crypto service in sip-communicator. Its has a
>>> "CryptoManager" interface, which is used to create different "Cipher"
>>> objects for different encryption algorithms/methods.
>> Cool! Feel free to send it over whenever you feel comfortable.
>
>>> At first I
>>> thought may be the Cipher interface should only have two methods:
>>> encrypt(byte[] data) and decrypt(byte[] data). But later after I
>>> learnt a little more about real cryptography implementation. I found
>>> that maybe we need more methods. E.g. for AES ICM method, we will
>>> sometimes need to set the IV (initial vector) for each encryption
>>> call. So, may be the encryption service's interface will be more
>>> specific than I initially thought.
>> OK, I see. I guess the tricky part would be to make the service generic
>> enough so that it would work for most kinds of encryption. If you feel
>> this is not going to be possible, don't hesitate to add method specific
>> interfaces (i.e. one for AES ICM, one for ... whatever else you are
>> planning to implement). These are just thoughts though. You are better
>> placed to know what is it you need exactly.
>
> I am looking at some reference implementation -- in fact, in JCE and
> bouncy castle, they have their abstraction. But that would be much
> more complicated than we would need. So, I think maybe I can borrow a
> subset of their abstraction and then define ours.
>
>>> 3. NULL Transform is simply copy the input data into the output
>>> buffer. So, this work is done within minutes.
>> OK. I am still curious to see the code. Do you think you'd be able to
>> publish some of it one of these days?
>
> Yes, they are in the attachments. If there is any problem, please tell me. :slight_smile:
> I'm wondering if my understanding is correct, because from wikipedia,
> I know there two
> definitions of Null Cipher. (http://en.wikipedia.org/wiki/Null_cipher)
> But in libsrtp, their implementation is simply leave the plain text
> untouched, i.e. my current "copy" implementation.
>
>>> 4. I did some study on bouncycastle, and implemented a AES ICM Cipher
>>> based on it. This piece of work is done and tested.
>> Cool!
>>
>>> Besides the above 4 items, I did some more study on libsrtp's source
>>> code and RFC3711.
>>> Then I found that besides RTP packet intercepting and encryption, we
>>> will have three more work to be listed on the road map. That is,
>>> first, message authentication - authenticate the srtp packet using
>>> digest algorithms such as HMC_SHA1.
>> I am not sure that I understand this (but this is not really a surprise
>> since I really am no expert as far as cryptography goes). Could you
>> please explain some more or post some pointers? Who would be
>> authenticating and against who?
>
> As defined in RFC3711 section 4.2 "Message Authentication and
> Integrity", SRTP offers authentication service besides encryption
> service. This service ensures that the RTP packets received haven't
> been altered by attackers.
>
>>> Second, Key deravition -- generate
>>> encryption/authentication/salting keys based on master keys / master
>>> salts. And third, replay attack database - identify replayed SRTP
>>> packets. I've learned some information on these topics, but further
>>> study is needed.
>> It would be nice if you could post some more details on how and where
>> you are planning to put these in SIP Communicator. At which point do
>> they intervene?
>>
> Actually, these all belong to SRTP implementation and will be enclosed
> in the srtp related package. Key deravition is used at the beginning
> of the session, and replay attack database is used all over the
> session. Key deravition is a required if we want to make srtp call
> with other clients. However replay attack database is optional, based
> on my understanding. :slight_smile:
>
>>> Also, there is a problem we should take care of, that is how we
>>> negotiate master keys with other clients? Accroding to libsrtp FAQ
>>> (http://srtp.sourceforge.net/faq.html#Q16), this is beyond the scope
>>> of SRTP and there many ways to solve this problem. According to
>>> wikipedia (http://en.wikipedia.org/wiki/Secure_Real-time_Transport_Protocol#SRTP_Interoperability),
>>> sip seems to be the only protocol that most clients support. So, I
>>> guess we could use the "SDP Security Descriptions" way. But further
>>> study on SDP Security Description is needed.
>> Yes, sounds reasonable. Are there any clients that already do this? I'll
>> be curious to see examples of sample session negotiation flows.
>>
>
> I am also not very clear how many clients are doing this. But
> according to the wiki link above, CounterPath's eyeBeam does. And from
> this link: http://en.wikipedia.org/wiki/SDES you can find a example of
> the exchanged SDP messages. Hope this could answer your question.
>
>>> Although there are some problems need to be studied and maybe
>>> discussed. There are still clear jobs for me to do. So I will continue
>>> my work according to the roadmap and my current understanding.
>> Great! Glad to know you are making progress!
>>
>
> Thank you Emil, it's fun to work with all you guys.
>
>> Cheers
>> Emil
>>
>>> If you have any questions / suggestions, please contact me directly. :slight_smile:
>>>
>>> Thanks,
>>> Su
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
>>> For additional commands, e-mail: dev-help@sip-communicator.dev.java.net
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
>> For additional commands, e-mail: dev-help@sip-communicator.dev.java.net
>>
>> ------------------------------------------------------------------------
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
>> For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#10

Hi Su,

路路路

On 2007/06/20, at 22:39, Bing Su wrote:

I think perhaps I need some more study on those side issues,
especially after reading Werner's mail. Could you please give me a few
days to sort the things up. And then update the roadmap?

Sure, feel free to update it when you'll have a better view of the whole picture.

Cheers,
--
Romain KUNTZ
kuntz@lsiit.u-strasbg.fr
Louis Pasteur University - Networks and Protocols Team

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#11

Hi,

just jumping in here. Regarding SRTP I'm not aware of any Java
implementation. But it may help to look at a C++ implementation.
I've done (together with code from the minisip project) SRTP
implementation in GNU ccRTP library. The C++ code is tested against
the C implementation libsrtp.

Also available in the GNU ccRTP is an implememtation of ZRTP, a
protocol specified by Phil Zimmermann to enable key negotiation
for SRTP (for some later stage :slight_smile: ).

As crypto libraries the SRTP implementation uses openSSL or
libgcrypt. Just as a side note: I've done a project inside
Apache (in the incubator) called JuiCE, an implementation of
a Java JCE that uses openSSL as its backend crypto engine.

I'm not actively involved in development of SIP communicator,
but I would be available to help during a Java implementation of
SRTP etc.

Regards,
Werner

Jean Lorchat wrote:

路路路

Hi Su,

I am looking at some reference implementation -- in fact, in JCE and
bouncy castle, they have their abstraction. But that would be much
more complicated than we would need. So, I think maybe I can borrow a
subset of their abstraction and then define ours.

Also, do not try to rewrite something already done. If bouncycastle/JCE
is too big, we can solve this later. I think the most interesting part
is to get it to work first. Also, you say that we do not need such
complications. Is it because we plan to begin with simple ciphers, or do
you mean that we will never need large parts of these abstractions ?

> 3. NULL Transform is simply copy the input data into the output
> buffer. So, this work is done within minutes.

OK. I am still curious to see the code. Do you think you'd be able to
publish some of it one of these days?

Yes, they are in the attachments. If there is any problem, please tell
me. :slight_smile:
I'm wondering if my understanding is correct, because from wikipedia,
I know there two
definitions of Null Cipher. (http://en.wikipedia.org/wiki/Null_cipher)
But in libsrtp, their implementation is simply leave the plain text
untouched, i.e. my current "copy" implementation.

Yes, this is what we mean in this project. Null cipher as "no cipher at
all", how secure :smiley: !

Keep up the good work !

Jean

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#12

Hi Werner,

I'm glad to hear we have someone with a strong experience in SRTP implementation! Su Bing is currently working on RTP Encryption for SIP Communicator as part of a Google Summer of Code project. He regularly reports his work on this ML, so feel free to jump into the discussion. I guess he'll be happy to hear from you.

Thanks for the pointers,
Romain

路路路

On 2007/06/19, at 18:52, Werner Dittmann wrote:

Hi,

just jumping in here. Regarding SRTP I'm not aware of any Java
implementation. But it may help to look at a C++ implementation.
I've done (together with code from the minisip project) SRTP
implementation in GNU ccRTP library. The C++ code is tested against
the C implementation libsrtp.

Also available in the GNU ccRTP is an implememtation of ZRTP, a
protocol specified by Phil Zimmermann to enable key negotiation
for SRTP (for some later stage :slight_smile: ).

As crypto libraries the SRTP implementation uses openSSL or
libgcrypt. Just as a side note: I've done a project inside
Apache (in the incubator) called JuiCE, an implementation of
a Java JCE that uses openSSL as its backend crypto engine.

I'm not actively involved in development of SIP communicator,
but I would be available to help during a Java implementation of
SRTP etc.

Regards,
Werner

Jean Lorchat wrote:

Hi Su,

I am looking at some reference implementation -- in fact, in JCE and
bouncy castle, they have their abstraction. But that would be much
more complicated than we would need. So, I think maybe I can borrow a
subset of their abstraction and then define ours.

Also, do not try to rewrite something already done. If bouncycastle/JCE
is too big, we can solve this later. I think the most interesting part
is to get it to work first. Also, you say that we do not need such
complications. Is it because we plan to begin with simple ciphers, or do
you mean that we will never need large parts of these abstractions ?

3. NULL Transform is simply copy the input data into the output
buffer. So, this work is done within minutes.

OK. I am still curious to see the code. Do you think you'd be able to
publish some of it one of these days?

Yes, they are in the attachments. If there is any problem, please tell
me. :slight_smile:
I'm wondering if my understanding is correct, because from wikipedia,
I know there two
definitions of Null Cipher. (http://en.wikipedia.org/wiki/Null_cipher)
But in libsrtp, their implementation is simply leave the plain text
untouched, i.e. my current "copy" implementation.

Yes, this is what we mean in this project. Null cipher as "no cipher at
all", how secure :smiley: !

Keep up the good work !

Jean

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Romain KUNTZ
kuntz@lsiit.u-strasbg.fr
Louis Pasteur University - Networks and Protocols Team

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#13

Hi Jean,

Hi Su,

> I am looking at some reference implementation -- in fact, in JCE and
> bouncy castle, they have their abstraction. But that would be much
> more complicated than we would need. So, I think maybe I can borrow a
> subset of their abstraction and then define ours.

Also, do not try to rewrite something already done. If bouncycastle/JCE
is too big, we can solve this later. I think the most interesting part
is to get it to work first. Also, you say that we do not need such
complications. Is it because we plan to begin with simple ciphers, or do
you mean that we will never need large parts of these abstractions ?

Yes, the primary task is to get SRTP working, let's concentrate on this.
The "complication" is actually referring to the different algorithms,
encryption modes (stream / block) and other functionalities provided
by JCE/bouncycastle. All we need is algorithms such as AES_ICM and
HMC_SHA1 (defined by RFC3711). So we don't need their whole
abstractions. (Since different ciphers may require different
abstractions)

>> > 3. NULL Transform is simply copy the input data into the output
>> > buffer. So, this work is done within minutes.
>>
>> OK. I am still curious to see the code. Do you think you'd be able to
>> publish some of it one of these days?
>
> Yes, they are in the attachments. If there is any problem, please tell
> me. :slight_smile:
> I'm wondering if my understanding is correct, because from wikipedia,
> I know there two
> definitions of Null Cipher. (http://en.wikipedia.org/wiki/Null_cipher)
> But in libsrtp, their implementation is simply leave the plain text
> untouched, i.e. my current "copy" implementation.

Yes, this is what we mean in this project. Null cipher as "no cipher at
all", how secure :smiley: !

Cool :smiley:

Keep up the good work !

Thank you, Jean.

Best regards,
Su

路路路

On 6/19/07, Jean Lorchat <lorchat@sfc.wide.ad.jp> wrote:

Jean

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#14

Hi Werner,

Thank you very much. These information is very helpful for me. :slight_smile:

Best regards,
Su

路路路

On 6/20/07, Werner Dittmann <Werner.Dittmann@t-online.de> wrote:

Hi,

just jumping in here. Regarding SRTP I'm not aware of any Java
implementation. But it may help to look at a C++ implementation.
I've done (together with code from the minisip project) SRTP
implementation in GNU ccRTP library. The C++ code is tested against
the C implementation libsrtp.

Also available in the GNU ccRTP is an implememtation of ZRTP, a
protocol specified by Phil Zimmermann to enable key negotiation
for SRTP (for some later stage :slight_smile: ).

As crypto libraries the SRTP implementation uses openSSL or
libgcrypt. Just as a side note: I've done a project inside
Apache (in the incubator) called JuiCE, an implementation of
a Java JCE that uses openSSL as its backend crypto engine.

I'm not actively involved in development of SIP communicator,
but I would be available to help during a Java implementation of
SRTP etc.

Regards,
Werner

Jean Lorchat wrote:
> Hi Su,
>
>> I am looking at some reference implementation -- in fact, in JCE and
>> bouncy castle, they have their abstraction. But that would be much
>> more complicated than we would need. So, I think maybe I can borrow a
>> subset of their abstraction and then define ours.
>
> Also, do not try to rewrite something already done. If bouncycastle/JCE
> is too big, we can solve this later. I think the most interesting part
> is to get it to work first. Also, you say that we do not need such
> complications. Is it because we plan to begin with simple ciphers, or do
> you mean that we will never need large parts of these abstractions ?
>
>>> > 3. NULL Transform is simply copy the input data into the output
>>> > buffer. So, this work is done within minutes.
>>>
>>> OK. I am still curious to see the code. Do you think you'd be able to
>>> publish some of it one of these days?
>>
>> Yes, they are in the attachments. If there is any problem, please tell
>> me. :slight_smile:
>> I'm wondering if my understanding is correct, because from wikipedia,
>> I know there two
>> definitions of Null Cipher. (http://en.wikipedia.org/wiki/Null_cipher)
>> But in libsrtp, their implementation is simply leave the plain text
>> untouched, i.e. my current "copy" implementation.
>
> Yes, this is what we mean in this project. Null cipher as "no cipher at
> all", how secure :smiley: !
>
> Keep up the good work !
>
> Jean
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
> For additional commands, e-mail: dev-help@sip-communicator.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#15

Su, all,

just my thoughts here regarding SRTP and associated stuff:

After looking at JMF and its RTP implementation I would
also use some sort of RTPConnector to implement SRTP because,
as Su wrote, SRTP is a transformation of existing RTP packets.

How to do that? My rough ideas here:

In general:
- define and implement a class that can handle SRTP packtes,
聽聽probably a superset of RTP (if a RTP class exists in JMF, haven't
聽聽checked this, otherwise a brand new class). In GNU ccRTP I just
聽聽added some functions to IncomingRTPPacket and OutgoingRTPPacket
聽聽classes that control encryption/decryption (protect/unprotect) of
聽聽this packet.

- define and implement a SRTP Crypto Context class (you may have
聽聽a look at the CryptoContext C++ class in GNU ccRTP). This
聽聽class stores all necessary SRTP crypto context data as per
聽聽RFC3711 and contains the necessary crypto, hash, replay
聽聽detection, and HMAC functions.

- before an application can use SRTP the app has to create a
聽聽SRTP CryptoContext and intialize it with necessary data, such
聽聽as master key, master salt, authentication length, etc. The
聽聽application must provide this CryptoContext to the SRTP
聽聽transformation. It is the task of the application to negotiate
聽聽the keys and other data with its peer. Usually the application
聽聽has to create 2 CryptoContexts: one to send and one to receive
聽聽data.

The pure SRTP implementation is IMHO fairly straight forward :slight_smile: .
Be aware that SRTP uses its own encryption modes: a specific
Integer Counter Mode (ICM) and a so called F8 mode. Both modes are
AFAIK not available in generic crypto libraries such a BouncyCastle
or alike. The ICM is commonly used (somewhere I have a F8
implementation in Java). It should be quite simple to copy the
counter mode code from C++ to Java.

In contrast to libsrtp which uses own (or copied) AES, SHA1
implementations I would propose to use the basic AES
crypto algorithm (simple AES codebook mode because the counter mode
is done by SRTP itself) and the SHA1 either using BouncyCastle or
the standard Java JCE implementation - both work for this purpose.

The real hard part is the key and parameter negotiation. Currently
two (three) ways are common:
- MIKEY which uses SIP/SDP and signed X.509 cerificates to negotiate
聽聽keys.
- ZRTP which does not use any certificate, does not depend on SIP or
聽聽any other signaling protocol.
- DTLS-SRTP which depends on:
聽聽- TLS (DTLS) with a specific extension,
聽聽- SIP,
聽聽- self-signed certificates and the
聽聽- SIP Identity service (RFC4474)
聽聽to negotiate keys.

The current state is: MIKEY seems to be out of the game; ZRTP is
available, also in several products; DTLS-SRTP is discussed as the
proposed IETF standard to SRTP key negotiation (it will take some time
to get there), ZRTP will be an informational RFC.

DTLS-SRTP is IMO insecure by design because it opens several attack
vectors and is also somewhat hard to use for real P2P applications such
as P2PSIP (attention: I'm biased here in favour of ZRTP). If you need
more information about the vulnerabilities of DTLS-SRTP or ZRTP just
give me a ping.

Sending a packet (the "write" part):

- create a SRTP object and parse the "data" byte array into this
聽聽object to initialize it. Have getter/setter methods for
聽聽required data fields, such as SSRC etc.

- get the SSRC of the RTP packet and check if a crypto context is
聽聽available for this SSRC (crypto contexts are identified using SSRC).

- If no crypto context is available just send the data without
聽聽any modification (pure RTP).

- otherwise encrypt the data and compute the authentication HMAC.
聽聽The authentication HMAC is the only data field that is usually
聽聽added (recommended) to the plain RTP data. SRTP does not extend
聽聽RTP data otherwise, it just encrypts the data (payload).

- serialize the encrypted data again, including optional HMAC
聽聽authentication data, and send it as usual using UDP.

Receiving a packet (the "read" part):

- similar to write, just the other way around: get the SSRC of
聽聽the incoming RTP data (RTP header is not encrypted) and check
聽聽if a crypto context is available.

- if yes, perform SRTP processing to perform authentication, replay
聽聽check, and decrypt it. The return the data.

Su, if you like to discuss in more detail I'm glad to do so.

Regards,
Werner

Romain KUNTZ wrote:

路路路

Hi Werner,

I'm glad to hear we have someone with a strong experience in SRTP
implementation! Su Bing is currently working on RTP Encryption for SIP
Communicator as part of a Google Summer of Code project. He regularly
reports his work on this ML, so feel free to jump into the discussion. I
guess he'll be happy to hear from you.

Thanks for the pointers,
Romain

On 2007/06/19, at 18:52, Werner Dittmann wrote:

Hi,

just jumping in here. Regarding SRTP I'm not aware of any Java
implementation. But it may help to look at a C++ implementation.
I've done (together with code from the minisip project) SRTP
implementation in GNU ccRTP library. The C++ code is tested against
the C implementation libsrtp.

Also available in the GNU ccRTP is an implememtation of ZRTP, a
protocol specified by Phil Zimmermann to enable key negotiation
for SRTP (for some later stage :slight_smile: ).

As crypto libraries the SRTP implementation uses openSSL or
libgcrypt. Just as a side note: I've done a project inside
Apache (in the incubator) called JuiCE, an implementation of
a Java JCE that uses openSSL as its backend crypto engine.

I'm not actively involved in development of SIP communicator,
but I would be available to help during a Java implementation of
SRTP etc.

Regards,
Werner

Jean Lorchat wrote:

Hi Su,

I am looking at some reference implementation -- in fact, in JCE and
bouncy castle, they have their abstraction. But that would be much
more complicated than we would need. So, I think maybe I can borrow a
subset of their abstraction and then define ours.

Also, do not try to rewrite something already done. If bouncycastle/JCE
is too big, we can solve this later. I think the most interesting part
is to get it to work first. Also, you say that we do not need such
complications. Is it because we plan to begin with simple ciphers, or do
you mean that we will never need large parts of these abstractions ?

3. NULL Transform is simply copy the input data into the output
buffer. So, this work is done within minutes.

OK. I am still curious to see the code. Do you think you'd be able to
publish some of it one of these days?

Yes, they are in the attachments. If there is any problem, please tell
me. :slight_smile:
I'm wondering if my understanding is correct, because from wikipedia,
I know there two
definitions of Null Cipher. (http://en.wikipedia.org/wiki/Null_cipher)
But in libsrtp, their implementation is simply leave the plain text
untouched, i.e. my current "copy" implementation.

Yes, this is what we mean in this project. Null cipher as "no cipher at
all", how secure :smiley: !

Keep up the good work !

Jean

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--Romain KUNTZ
kuntz@lsiit.u-strasbg.fr
Louis Pasteur University - Networks and Protocols Team

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#16

Oh, I forgot to cc it. ;-p

路路路

---------- Forwarded message ----------

From: Bing Su <nova.su@gmail.com>

Date: Jun 21, 2007 4:22 AM
Subject: Re: [sip-comm-dev] [gsoc] SRTP work status update
To: Werner Dittmann <Werner.Dittmann@t-online.de>

Hi Werner,

Your comments are fantastic!
In fact I was a little confused by some details of SRTP these days. I
wanted to solve them by reading RFCs, wikis and other project's codes.
But after reading your mail, I found many of my efforts could be
saved.
Thank you for your help, Werner. :slight_smile:

On 6/21/07, Werner Dittmann <Werner.Dittmann@t-online.de> wrote:

Su, all,

just my thoughts here regarding SRTP and associated stuff:

After looking at JMF and its RTP implementation I would
also use some sort of RTPConnector to implement SRTP because,
as Su wrote, SRTP is a transformation of existing RTP packets.

How to do that? My rough ideas here:

In general:
- define and implement a class that can handle SRTP packtes,
聽聽probably a superset of RTP (if a RTP class exists in JMF, haven't
聽聽checked this, otherwise a brand new class). In GNU ccRTP I just
聽聽added some functions to IncomingRTPPacket and OutgoingRTPPacket
聽聽classes that control encryption/decryption (protect/unprotect) of
聽聽this packet.

AFAIK, the handling of RTP packet in JMF is done by some classes
hidden deeply in the library's implementation. Though JMF has a SCSL
licensed source zip, the RTP related source code are unavailable -
only interfaces are provided. So, perhaps the only way to intercept
RTP packet is to use RTPConnector.

- define and implement a SRTP Crypto Context class (you may have
聽聽a look at the CryptoContext C++ class in GNU ccRTP). This
聽聽class stores all necessary SRTP crypto context data as per
聽聽RFC3711 and contains the necessary crypto, hash, replay
聽聽detection, and HMAC functions.

Thank you again, Werner. I used to look at libsrtp's srtp_stream_ctx_t
structure, but didn't realize the importance of "crypto context"
concept. Now I think this class should be the key class of SRTP
implementation. My previous design was to put all these data in a self
defined
"SRTPTransformEngine" class, which is unique for each RTPManager. But
obviously, the data should be kept in CryptoContext class. Because one
RTPManager could handle mutiple RTP streams, and each stream will have
one set of data, thus one CryptoContext object.

- before an application can use SRTP the app has to create a
聽聽SRTP CryptoContext and intialize it with necessary data, such
聽聽as master key, master salt, authentication length, etc. The
聽聽application must provide this CryptoContext to the SRTP
聽聽transformation. It is the task of the application to negotiate
聽聽the keys and other data with its peer. Usually the application
聽聽has to create 2 CryptoContexts: one to send and one to receive
聽聽data.

You mean the one send stream, one receive stream scenario, am I right?

The pure SRTP implementation is IMHO fairly straight forward :slight_smile: .
Be aware that SRTP uses its own encryption modes: a specific
Integer Counter Mode (ICM) and a so called F8 mode. Both modes are
AFAIK not available in generic crypto libraries such a BouncyCastle
or alike. The ICM is commonly used (somewhere I have a F8
implementation in Java). It should be quite simple to copy the
counter mode code from C++ to Java.

Oh, this is part of my confusion.
Wikipedia says SRTP is using Segmented Integer Counter Mode.
(http://en.wikipedia.org/wiki/Secure_Real-time_Transport_Protocol) And
bouncy castle has a Segmented Integer Counter Cipher class,
SICBlockCipher. I took a look at its code, its algorithm seems
different from the one implemented in libsrtp. If I'm right, then
which one shall we use, the SICBlockCipher or libsrtp's algorithm?
Maybe I shall have take a look at ccRtp's implementation and RFC3711.
Then make this clear.

In contrast to libsrtp which uses own (or copied) AES, SHA1
implementations I would propose to use the basic AES
crypto algorithm (simple AES codebook mode because the counter mode
is done by SRTP itself) and the SHA1 either using BouncyCastle or
the standard Java JCE implementation - both work for this purpose.

Sure, we don't need to reinvent the wheel.

The real hard part is the key and parameter negotiation. Currently
two (three) ways are common:
- MIKEY which uses SIP/SDP and signed X.509 cerificates to negotiate
聽聽keys.
- ZRTP which does not use any certificate, does not depend on SIP or
聽聽any other signaling protocol.
- DTLS-SRTP which depends on:
聽聽- TLS (DTLS) with a specific extension,
聽聽- SIP,
聽聽- self-signed certificates and the
聽聽- SIP Identity service (RFC4474)
聽聽to negotiate keys.

The current state is: MIKEY seems to be out of the game; ZRTP is
available, also in several products; DTLS-SRTP is discussed as the
proposed IETF standard to SRTP key negotiation (it will take some time
to get there), ZRTP will be an informational RFC.

DTLS-SRTP is IMO insecure by design because it opens several attack
vectors and is also somewhat hard to use for real P2P applications such
as P2PSIP (attention: I'm biased here in favour of ZRTP). If you need
more information about the vulnerabilities of DTLS-SRTP or ZRTP just
give me a ping.

I'm not aware of the key management protocols until recently. So I
don't have a clear thought on this. I did a little research, it seems
that ZRTP has some benefits: it supports Forking, Media-before-SDP,
and does not depend on the signaling protocol or PKI. From wikipedia,
I see "Ekiga, Twinkle and Asterisk also implement ZRTP and are
available under GPL. X-Lite and eyeBeam implement ZRTP but are
proprietary."
And there is a comparison PPT on various key management protocols:
http://www3.ietf.org/proceedings/06mar/slides/raiarea-1/raiarea-1.ppt

I think we should have more discussion regarding which key management
protocol we will use.:slight_smile:

Sending a packet (the "write" part):

- create a SRTP object and parse the "data" byte array into this
聽聽object to initialize it. Have getter/setter methods for
聽聽required data fields, such as SSRC etc.

I think I will have this done in SRTPTransformEngine. And it will have
a table for mapping SSRC to CryptoContext. When new rtp streams are
added, we shall create corresponding CryptoContexts and update the
table.

- get the SSRC of the RTP packet and check if a crypto context is
聽聽available for this SSRC (crypto contexts are identified using SSRC).

This is done using the mapping table.

- If no crypto context is available just send the data without
聽聽any modification (pure RTP).

- otherwise encrypt the data and compute the authentication HMAC.
聽聽The authentication HMAC is the only data field that is usually
聽聽added (recommended) to the plain RTP data. SRTP does not extend
聽聽RTP data otherwise, it just encrypts the data (payload).

- serialize the encrypted data again, including optional HMAC
聽聽authentication data, and send it as usual using UDP.

Receiving a packet (the "read" part):

- similar to write, just the other way around: get the SSRC of
聽聽the incoming RTP data (RTP header is not encrypted) and check
聽聽if a crypto context is available.

- if yes, perform SRTP processing to perform authentication, replay
聽聽check, and decrypt it. The return the data.

Thank you, Werner.
Your detailed thoughts make me more clear about what I am going to do.

Su, if you like to discuss in more detail I'm glad to do so.

I surely like to discuss more about SIP Communicator's SRTP
implementation with you as this project goes on. Your experience is
invaluable to me. :slight_smile:

Best regards,
Su

Regards,
Werner

Romain KUNTZ wrote:
> Hi Werner,
>
> I'm glad to hear we have someone with a strong experience in SRTP
> implementation! Su Bing is currently working on RTP Encryption for SIP
> Communicator as part of a Google Summer of Code project. He regularly
> reports his work on this ML, so feel free to jump into the discussion. I
> guess he'll be happy to hear from you.
>
> Thanks for the pointers,
> Romain
>
> On 2007/06/19, at 18:52, Werner Dittmann wrote:
>
>> Hi,
>>
>> just jumping in here. Regarding SRTP I'm not aware of any Java
>> implementation. But it may help to look at a C++ implementation.
>> I've done (together with code from the minisip project) SRTP
>> implementation in GNU ccRTP library. The C++ code is tested against
>> the C implementation libsrtp.
>>
>> Also available in the GNU ccRTP is an implememtation of ZRTP, a
>> protocol specified by Phil Zimmermann to enable key negotiation
>> for SRTP (for some later stage :slight_smile: ).
>>
>> As crypto libraries the SRTP implementation uses openSSL or
>> libgcrypt. Just as a side note: I've done a project inside
>> Apache (in the incubator) called JuiCE, an implementation of
>> a Java JCE that uses openSSL as its backend crypto engine.
>>
>> I'm not actively involved in development of SIP communicator,
>> but I would be available to help during a Java implementation of
>> SRTP etc.
>>
>> Regards,
>> Werner
>>
>> Jean Lorchat wrote:
>>> Hi Su,
>>>
>>>> I am looking at some reference implementation -- in fact, in JCE and
>>>> bouncy castle, they have their abstraction. But that would be much
>>>> more complicated than we would need. So, I think maybe I can borrow a
>>>> subset of their abstraction and then define ours.
>>>
>>> Also, do not try to rewrite something already done. If bouncycastle/JCE
>>> is too big, we can solve this later. I think the most interesting part
>>> is to get it to work first. Also, you say that we do not need such
>>> complications. Is it because we plan to begin with simple ciphers, or do
>>> you mean that we will never need large parts of these abstractions ?
>>>
>>>>>> 3. NULL Transform is simply copy the input data into the output
>>>>>> buffer. So, this work is done within minutes.
>>>>>
>>>>> OK. I am still curious to see the code. Do you think you'd be able to
>>>>> publish some of it one of these days?
>>>>
>>>> Yes, they are in the attachments. If there is any problem, please tell
>>>> me. :slight_smile:
>>>> I'm wondering if my understanding is correct, because from wikipedia,
>>>> I know there two
>>>> definitions of Null Cipher. (http://en.wikipedia.org/wiki/Null_cipher)
>>>> But in libsrtp, their implementation is simply leave the plain text
>>>> untouched, i.e. my current "copy" implementation.
>>>
>>> Yes, this is what we mean in this project. Null cipher as "no cipher at
>>> all", how secure :smiley: !
>>>
>>> Keep up the good work !
>>>
>>> Jean
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
>>> For additional commands, e-mail: dev-help@sip-communicator.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
>> For additional commands, e-mail: dev-help@sip-communicator.dev.java.net
>>
>
> --Romain KUNTZ
> kuntz@lsiit.u-strasbg.fr
> Louis Pasteur University - Networks and Protocols Team
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
> For additional commands, e-mail: dev-help@sip-communicator.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#17

Su,

some comments inline.

Regards,
Werner

Bing Su wrote:
.....

In general:
- define and implement a class that can handle SRTP packtes,
聽聽probably a superset of RTP (if a RTP class exists in JMF, haven't
聽聽checked this, otherwise a brand new class). In GNU ccRTP I just
聽聽added some functions to IncomingRTPPacket and OutgoingRTPPacket
聽聽classes that control encryption/decryption (protect/unprotect) of
聽聽this packet.

AFAIK, the handling of RTP packet in JMF is done by some classes
hidden deeply in the library's implementation. Though JMF has a SCSL
licensed source zip, the RTP related source code are unavailable -
only interfaces are provided. So, perhaps the only way to intercept
RTP packet is to use RTPConnector.

ok, probably you should define a class that handles SRTP packet then.
It's similar to RTP though. I'm not sure if JMF can handle full RTP
with the variable (optional) numbers of CSRC identifiers. When
looking at the "data" byte array and reparse it into RTP packets
pls have a look at this.

- define and implement a SRTP Crypto Context class (you may have
聽聽a look at the CryptoContext C++ class in GNU ccRTP). This
聽聽class stores all necessary SRTP crypto context data as per
聽聽RFC3711 and contains the necessary crypto, hash, replay
聽聽detection, and HMAC functions.

Thank you again, Werner. I used to look at libsrtp's srtp_stream_ctx_t
structure, but didn't realize the importance of "crypto context"
concept. Now I think this class should be the key class of SRTP
implementation. My previous design was to put all these data in a self
defined
"SRTPTransformEngine" class, which is unique for each RTPManager. But
obviously, the data should be kept in CryptoContext class. Because one
RTPManager could handle mutiple RTP streams, and each stream will have
one set of data, thus one CryptoContext object.

Indeed, the crypto context is the important data structure. In C++ and
other OO languages it should also provide the member functions to
deal with it.

- before an application can use SRTP the app has to create a
聽聽SRTP CryptoContext and intialize it with necessary data, such
聽聽as master key, master salt, authentication length, etc. The
聽聽application must provide this CryptoContext to the SRTP
聽聽transformation. It is the task of the application to negotiate
聽聽the keys and other data with its peer. Usually the application
聽聽has to create 2 CryptoContexts: one to send and one to receive
聽聽data.

You mean the one send stream, one receive stream scenario, am I right?

Yes.

The pure SRTP implementation is IMHO fairly straight forward :slight_smile: .
Be aware that SRTP uses its own encryption modes: a specific
Integer Counter Mode (ICM) and a so called F8 mode. Both modes are
AFAIK not available in generic crypto libraries such a BouncyCastle
or alike. The ICM is commonly used (somewhere I have a F8
implementation in Java). It should be quite simple to copy the
counter mode code from C++ to Java.

Oh, this is part of my confusion.
Wikipedia says SRTP is using Segmented Integer Counter Mode.
(http://en.wikipedia.org/wiki/Secure_Real-time_Transport_Protocol) And
bouncy castle has a Segmented Integer Counter Cipher class,
SICBlockCipher. I took a look at its code, its algorithm seems
different from the one implemented in libsrtp. If I'm right, then
which one shall we use, the SICBlockCipher or libsrtp's algorithm?
Maybe I shall have take a look at ccRtp's implementation and RFC3711.
Then make this clear.

IMHO the ICM implementation of BouncyCastle is not compatible with
the ICM of SRTP. The implementtaion of the SRTP codes in GNU ccRTP
can be found in ./src/ccrtp/crypto/ . The subdirs gcrypt and openSSL
contain the crypto libraryr specific implementations. They use the same
class file (.h) to guarantee compatibility.

In contrast to libsrtp which uses own (or copied) AES, SHA1
implementations I would propose to use the basic AES
crypto algorithm (simple AES codebook mode because the counter mode
is done by SRTP itself) and the SHA1 either using BouncyCastle or
the standard Java JCE implementation - both work for this purpose.

Sure, we don't need to reinvent the wheel.

The real hard part is the key and parameter negotiation. Currently
two (three) ways are common:
- MIKEY which uses SIP/SDP and signed X.509 cerificates to negotiate
聽聽keys.
- ZRTP which does not use any certificate, does not depend on SIP or
聽聽any other signaling protocol.
- DTLS-SRTP which depends on:
聽聽- TLS (DTLS) with a specific extension,
聽聽- SIP,
聽聽- self-signed certificates and the
聽聽- SIP Identity service (RFC4474)
聽聽to negotiate keys.

The current state is: MIKEY seems to be out of the game; ZRTP is
available, also in several products; DTLS-SRTP is discussed as the
proposed IETF standard to SRTP key negotiation (it will take some time
to get there), ZRTP will be an informational RFC.

DTLS-SRTP is IMO insecure by design because it opens several attack
vectors and is also somewhat hard to use for real P2P applications such
as P2PSIP (attention: I'm biased here in favour of ZRTP). If you need
more information about the vulnerabilities of DTLS-SRTP or ZRTP just
give me a ping.

I'm not aware of the key management protocols until recently. So I
don't have a clear thought on this. I did a little research, it seems
that ZRTP has some benefits: it supports Forking, Media-before-SDP,
and does not depend on the signaling protocol or PKI. From wikipedia,
I see "Ekiga, Twinkle and Asterisk also implement ZRTP and are
available under GPL. X-Lite and eyeBeam implement ZRTP but are
proprietary."
And there is a comparison PPT on various key management protocols:
http://www3.ietf.org/proceedings/06mar/slides/raiarea-1/raiarea-1.ppt

I think we should have more discussion regarding which key management
protocol we will use.:slight_smile:

Let's discuss this some time later - it's a topic of itself. To implement
ZRTP we just need a small interface during RTP processing (RTPConnector)
and some ways to comminucate with the GUI.

<SNIP ---- SNAP>

路路路

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#18

Hi, Werner

I've checked out ccRtp's code and did some study these days.
I found it very clear and well documented. By reading the code, many
of the problems become clear.

I am implementing the logic of srtp in Java. Do you mind if I take
your code as a main reference and implement some of the logic in java
according to your design?

I believe I won't have better implementation than yours. :slight_smile:
And taking your work as reference will greatly speed up the progress.

Su,

some comments inline.

Regards,
Werner

ok, probably you should define a class that handles SRTP packet then.
It's similar to RTP though. I'm not sure if JMF can handle full RTP
with the variable (optional) numbers of CSRC identifiers. When
looking at the "data" byte array and reparse it into RTP packets
pls have a look at this.

Thank you for reminding me this, I'll keep this in mind.

>
Indeed, the crypto context is the important data structure. In C++ and
other OO languages it should also provide the member functions to
deal with it.

So, I plan to have a similar class in my design. It will handle all
the concrete work.

> You mean the one send stream, one receive stream scenario, am I right?
Yes.

Cool :slight_smile:

IMHO the ICM implementation of BouncyCastle is not compatible with
the ICM of SRTP. The implementtaion of the SRTP codes in GNU ccRTP
can be found in ./src/ccrtp/crypto/ . The subdirs gcrypt and openSSL
contain the crypto libraryr specific implementations. They use the same
class file (.h) to guarantee compatibility.

OIC, then the counter mode algorithm shall be implemented separately
according to RFC.

Let's discuss this some time later - it's a topic of itself. To implement
ZRTP we just need a small interface during RTP processing (RTPConnector)
and some ways to comminucate with the GUI.

OK, let's have the SRTP work done at first and then discuss how we
should do with key management protocol later.

Thank you for your valuable help, Werner.

Best regards,
Su

路路路

On 6/21/07, Werner Dittmann <Werner.Dittmann@t-online.de> wrote:

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net