[Top] [All Lists]

Re: EMSK issue

2008-03-23 20:46:03
For example, consider using a USRK to secure HTTP.  If your access
provider did this to deliver firmware updates to your handset, this
might be reasonable, but if required it for authentication,
this would be unreasonable.

I do not believe that either application is reasonable.   The EAP peer
has no reason to trust a third party to update its firmware merely
because they can prove possession of a key derived from the EMSK.

Given that any proxy on the path could obtain such a key, the HOKEY 
approach provides such flimsy security that it needs to be
restricted to use in protecting a commodity (e.g. network access)
that has virtually no value.

Using such an approach to secure a high value commodity (e.g. 
the integrity of firmware or drivers running on the user's machine) 
is a bad idea because now the value of the asset being protected (e.g. 
absolute control over the user's machine) is much greater, while the 
security being provided is inferior compared to existing techniques. 

Existing firmware distribution models provide much higher levels of trust,
typically providing verification of the identity of the third party, as
well as demonstration that they are authorized to provide firmware
updates, and proof that the firmware itself has not been tampered with.

This is not merely an academic question, because the example you give is 
in fact one under consideration at the present time (e.g. WiMAX OTA 

Whatever security problems the Internet has at the present time, I am sure 
that it would be possible to make the situation *much* worse through 
compromise of the firmware/drivers running on millions of wireless 
broadband machines. 

IETF mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • Re: EMSK issue, Bernard Aboba <=