More info in my AES128-CBC question

[Aram Perez]

Hi David,

On Apr 21, 2007, at 2:04 PM, David Wagner wrote:

> Hagai Bar-El writes:
>> What Aram wrote is "many of the attendees have very little security
>> experience", not: "there are no attendees with security experience".
>> There are people at the relevant OMA group who know enough about
>> security, but just like in the real world -- they are outnumbered by
>> plain "feature-set" people, and thus have to come up with very clear
>> arguments to get their way.
>
> So the people who don't know anything about security are reluctant to
> listen to those who do?  That's not a good sign.  It may be standard
> operating procedure in groups like this, but that doesn't make it  
> right.
> It's still dysfunctional and dangerrous.  If the committee doesn't  
> have
> a commitment to security and is reluctant to listen to the experts,
> that's a risk factor.

As Hagai stated, welcome to the "real world". There may be standards  
organization (IETF?) that do really worry about security, but in the  
"real world", dead lines and existing products unfortunately  
influence security decisions.

> If you're sick and you go to a doctor, do you tell the doctor "you'd
> better come up with some very clear arguments if you want me to follow
> your advice"?  Do you tell your doctor "you'd better build a strong  
> case
> before I will listen to you"?  I would hope not.  That would be silly.
> Doctors are medical professionals with a great deal of training and
> expertise in the subject.  They can speak with authority when it comes
> to your health.  So why do people with no training in security think
> that they can freely ignore the advice of security professionals  
> without
> any negative consequences?

You're totally correct but it doesn't change the "reality" of the  
situation. Later this week I will create a document with the  
arguments sent to me and others from papers on the web and send it to  
this working group of OMA so there will be an "official record" of my  
objection to the decision.

> [snip]
>> AND (3) If you don't care about replacement attacks on the (1 to i)
>> blocks that will result only in a (possibly-undetected) corruption  
>> when
>> decrypting the i+1 block (rather than two blocks, with a varying and
>> non-attacker-changeable). [...]
>
> Wait a minute.  This reference to replacement attacks has me  
> concerned.
> Does the protocol use a message authentication code (MAC)?  I hope so.
> If your protocol uses a MAC, and uses it properly, then replacement
> attacks are not an issue, and the only issue with using a fixed IV is
> related to confidentiality.  If you don't use a MAC, you've got bigger
> problems, and even random IVs won't be enough.

No, there will be message integrity. For those of you asking, here's  
a high level overview of the protocol is as follows:

1) Do a Mutual Authentication with Key Exchange

A --> B  CertChainA | ControlOptions
B --> A  CertChainB | E[PubA, RanB | ControlOptions |  
ChosenOptions]  //Using RSA-OAEP
A --> B E[PubB, RandA | H[RanB]]  //SHA-1
B --> A H[RanA | RanB]

The ControlOptions includes protocol version and encryption algorithm.

2 ) Using a KDF, derive an AES-128 session encryption key SK, an HMAC- 
SHA-1 message integrity key MK and either a counter or IV
      Either AES-CTR or AES-CBC will be support

3) Data needing confidentiality is encrypted with the SK in the mode  
selected in step 1. The message is integrity protected with MK. A new  
MK is generated after a message is sent using MK(i+1) = H[MK(i)]

Hope this clarifies things somewhat.

Thanks for the replies,
Aram Perez


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com