1 / 15

Yasuyuki Shintani ECHONET TM Consortium 22 June 2004

Outline of Revised Security Services for Networked Appliances Part II: Secure Communication Middleware Protocol. Yasuyuki Shintani ECHONET TM Consortium 22 June 2004. Remaining Issues?. Comments on York Town meeting.

gazit
Télécharger la présentation

Yasuyuki Shintani ECHONET TM Consortium 22 June 2004

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Outline of Revised Security Services for Networked AppliancesPart II: Secure Communication Middleware Protocol Yasuyuki Shintani ECHONETTM Consortium 22 June 2004

  2. Remaining Issues? • Comments on York Town meeting. • Technical resolution is needed for "Key update function" for the comment from Tom Schmidt. • Definition of "Key Setting Node" is needed. • Document N1078, that was submitted on Yorktown meeting, already has definition of "Key Setting Node“. • Deference between IPsec and ECHONET Security. • ECHONET security focuses small footprint device. • ECHONET security is for security communications between devices within home. Key Setting is relatively easier comparing the security communications between INTERNET Server and device within home.

  3. A comment for “Key update function” • A comment is originally from Mr. Tom Schmidt • The spec talks about changing the key, and makes provision to accommodate devices that are currently off line. • Using the current common key to protect distribution of the new key is dangerous. If the attacker has successfully compromised the system the value of the current key is known and offers no protection of the new key. • Ideally the system needs to limit damage if one or more devices are compromised.

  4. Technical resolution for "Key update function" • We employed AES as our cipher algorithm, and the security strength is strong enough. Then "key update" function is not mandatory. • However, someone worries about the security risk, We recommend householders to perform “key update" periodically using the following methods: • Manually key update: same method as “8.1 Key initialization” (using serial key) • Automatic key update: using DH.

  5. Automatic key update Using DH (Diffie-Hellman)

  6. Automatic key update: using DH • Key update function is optional. • On AES' 128-bit strength, if there exists a method capable of recovering a DES key in one second (though in fact "DES Crackers" usually take a few hours to recover a DES key), it would still require 149 trillion years to crack a 128-bit AES key, which is rather insurmountable from the viewpoint of today's technologies. • However, the security strength could not completely depend on the strength of algorithm used, but may be subject to human frailties. • In this case, It is recommended to perform “key update” operations periodically to avoid any possible security risk. • Automatic key update function is provided for high security demand.

  7. Introduction of DH algorithm • DH allows two users to exchange a secret key over an insecure medium without any prior secrets. Alice and Bob agree on public number g and prime number p. Alice chooses secret value x. Bob chooses secret value y. Alice generates a public value (Za) -> Za = gXmod p. Alice sends the Za to Bob Bob generates a public value (Zb) -> Zb = gymod p. Bob sends the Zb to Alice Alice calculates the shared secret keyK (K = ZbXmod p) to communicate with Bob. Bob calculates the shared secret key K (K = Zaymod p) to communicate with Alice.

  8. Introducing DH to Key Update

  9. Summary

  10. Summary of Security Work • Security for internal/external and IP/non-IP based devices. • In N1077 document which titled “Security Services for Networked Appliances - Part I: Security Requirements”, we explain home network security requirements that may come from inside or outside home. • In N1078/N1101 document which titled “Security Services for Networked Appliances - Part II: Secure Communication Middleware Protocol”, Security for internal and non-IP based devices are described. • In N1014 which titled “Security Services for the Home Network” by Mr. Steven Ungar, security for external/internal and IP based devices are described. • Remaining issues about security work are already resolved. • Technical resolution is needed for "Key update function“. • Definition of "Key Setting Node" is needed. • Deference between IPsec and ECHONET Security.

  11. Appendix

  12. Comparison between “Old Key Update Method” and “New Key Update Method” • Old Key Update Method:Using Old Key for Updating Key • New Key Update Method:Using DH for Update Key 1st Key Generation 2nd Key Generation 3rd Key Generation x x x Old Method 1st Key is compromised Key Update is intercepted 2nd Key is compromised Key Update is intercepted 1st Key is compromised x Protected Protected New Method 2nd Key is compromised Key Update is intercepted 1st Key is compromised Key Update is intercepted Key Update Key Update

  13. IKE uses DH for key exchange Initiator Responder Initiator transits the SAi (SAi states that initiator supports cryptographic algorithms) to Responder. SAi Responder responses the SAr (SAr states that responder selects cryptographic algorithm) to Initiator. SAr Initiator generates the DH public value (Pi) and transits DH public value to responder. Pi Responder generates the DH public value (Pr) and transits DH public value to initiator. Pr DH key exchange Initiator computes the shared secret key according to Pr. Responder computes the shared secret key according to Pi. Initiator uses pre-shared key, DH public values (Pi, Pr), and initiator identification to generate the hash value (HASHi). Responder uses pre-shared key, DH public values (Pi, Pr), and initiator identification to authenticate the hash value (HASHi). Moreover, using pre-shared key, DH public values (Pi, Pr), and responder identification generates the hash value (HASHr). HASHi Initiator uses pre-shared key, DH public values (Pi, Pr), and responder identification to authenticate the hash value (HASHr). HASHr

  14. The common public values of DH

  15. Application of DH algorithm • The Diffie-Hellman key exchange is used by security protocols to provide secret key exchange while communicating on a network such as: • Secure Socket Layer (SSL) • Secure Shell (SSH) • Internet Key Exchange (IKE) • Transport Layer Security (TLS)

More Related