SRTP work status update

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. 

As planned on the road map
(http://www.sip-communicator.org/index.php/Dev
elopment/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/wi
ki/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. 

Thanks,
Su

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

	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 ;)


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. 
> 
> As planned on the road map
> (http://www.sip-communicator.org/index.php/Dev
elopment/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/wi
ki/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. 
> 
> Thanks,
> Su
> 
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
> 
-- 

(C) Matthew Rubenstein

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

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. 
> 
> As planned on the road map
> (http://www.sip-communicator.org/index.php/Dev
elopment/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/wi
ki/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. 
> 
> Thanks,
> Su
> 
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
> 
> 

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

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  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. 
>
> As planned on the road map
> (http://www.sip-communicator.org/index.php/Dev
elopment/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.w
ikipedia.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. 
>
> Thanks,
> Su
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip- 
> communicator.dev.java.net
>

-- 
Romain KUNTZ
kuntzlsiit.u-strasbg.fr
Louis Pasteur University - Networks and Protocols Team


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Hi Emil,

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

On 6/18/07, Emil Ivov <emchoemcho.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. 
I'm wondering if my understanding is correct, because from
wikipedia,
I know there two
definitions of Null Cipher. (http://en.wi
kipedia.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. 

> > 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/wi
ki/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. 
> >
> > Thanks,
> > Su
> >
> >
------------------------------------------------------------
---------
> > To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> > For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
> >
> >
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
>
>

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

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. 
> 
> On 6/18/07, Emil Ivov <emchoemcho.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. 
> I'm wondering if my understanding is correct, because
from wikipedia,
> I know there two
> definitions of Null Cipher. (http://en.wi
kipedia.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. 
> 
>>> 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/wi
ki/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. 
>>>
>>> Thanks,
>>> Su
>>>
>>>
------------------------------------------------------------
---------
>>> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
>>> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
>>>
>>>
>>
------------------------------------------------------------
---------
>> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
>> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
>>
>>
>>
>>
------------------------------------------------------------
------------
>>
>>
------------------------------------------------------------
---------
>> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
>> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

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. 
> I'm wondering if my understanding is correct, because
from wikipedia,
> I know there two
> definitions of Null Cipher. (http://en.wi
kipedia.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 :-D !

Keep up the good work !

Jean

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

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   ).

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. 
>> I'm wondering if my understanding is correct,
because from wikipedia,
>> I know there two
>> definitions of Null Cipher. (http://en.wi
kipedia.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 :-D !
> 
> Keep up the good work !
> 
> Jean
> 
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
> 
> 

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

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   ).
>
> 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. 
>>> 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 :-D !
>>
>> Keep up the good work !
>>
>> Jean
>>
>>
------------------------------------------------------------
---------
>> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
>> For additional commands, e-mail: dev-helpsip- 
>> communicator.dev.java.net
>>
>>
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip- 
> communicator.dev.java.net
>

-- 
Romain KUNTZ
kuntzlsiit.u-strasbg.fr
Louis Pasteur University - Networks and Protocols Team


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

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
 .
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   ).
>>
>> 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. 
>>>> I'm wondering if my understanding is
correct, because from wikipedia,
>>>> I know there two
>>>> definitions of Null Cipher. (http://en.wi
kipedia.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 :-D !
>>>
>>> Keep up the good work !
>>>
>>> Jean
>>>
>>>
------------------------------------------------------------
---------
>>> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
>>> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
>>>
>>>
>>
>>
------------------------------------------------------------
---------
>> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
>> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
>>
> 
> --Romain KUNTZ
> kuntzlsiit.u-strasbg.fr
> Louis Pasteur University - Networks and Protocols Team
> 
> 
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
> 
> 

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net