Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Security and privacy in smart grid context : problems and solutions Nicanfar, Hasen 2015

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata


24-ubc_2015_november_nicanfar_hasen.pdf [ 6.36MB ]
JSON: 24-1.0167780.json
JSON-LD: 24-1.0167780-ld.json
RDF/XML (Pretty): 24-1.0167780-rdf.xml
RDF/JSON: 24-1.0167780-rdf.json
Turtle: 24-1.0167780-turtle.txt
N-Triples: 24-1.0167780-rdf-ntriples.txt
Original Record: 24-1.0167780-source.json
Full Text

Full Text

Security and Privacy in Smart GridContext: Problems and SolutionsbyHasen NicanfarB.Sc., Sharif University of Technology, 1993M.Sc., Ryerson University, 2011A THESIS SUBMITTED IN PARTIAL FULFILLMENT OFTHE REQUIREMENTS FOR THE DEGREE OFDOCTOR OF PHILOSOPHYinThe Faculty of Graduate and Postdoctoral Studies(Electrical and Computer Engineering)THE UNIVERSITY OF BRITISH COLUMBIA(Vancouver)October 2015c© Hasen Nicanfar 2015AbstractIn order to improve the power grid and provision the Smart Grid concept,one well-defined approach would be to utilize new information and com-munication technology. Live power consumption data in addition to thetime base power consumption rate are essential requirements in this context.These communications are supposed to be bi-directional between consumers,providers and smart grid administrations (market, operators, etc.). How-ever, one of the most essential requirements that should be preserved is toaddress communication security and privacy. There are many opportunitiesfor adversaries to attack the smart grid system, even remotely anywhere inthe world, that could result in costly issues and damages in the system, evenjeopardize user privacy.In the first part of this thesis, we concentrate on improving the efficiencyof security mechanism and present our tailored authentication and key man-agement mechanisms. We propose two solutions, one for communicationsbetween home appliances and a home gateway (smart meter), while the sec-ond solution aims at communications between the home smart meter andan appropriate server located in the smart grid utility network.We then propose enhancements on key management by developing twokey construction mechanisms based on the Password Authentication KeyExchange (PAKE) protocol. The first is a cluster-based group key mecha-nism between smart grid entities, e.g. consumers in a neighbourhood areanetwork. The second enhancement is a multi-layer key mechanism moti-vated by controlling the home smart appliances using different smart gridcontrollers located in different layers of the controlling hierarchy network.The second part of the thesis concentrates on Privacy. In this part, wepresent a privacy mechanism based on enhanced network coding for com-munications between smart meters and utility servers via a mesh topology.Finally, we propose a privacy-aware security solution for mobile devices. Forexample, to support electric vehicles in buying and selling the power fromand to the grid, or in case of the smart phones in the heterogeneous network(4G and/or 5G), to support handover between the access points.Hasen NicanfariiPrefaceMainly this research was conducted in the WiNMoS laboratory, depart-ment of Electrical and Computer Engineering at the University of BritishColumbia, under the supervision of Professor Victor C.M. Leung. All of thechapters in this thesis are based on work conducted in UBCs WiNMoS lab,and the results are published as follows:Chapter 2[1] H. Nicanfar, P. Jokar, K. Beznosov and V.C.M. Leung, “Efficient Au-thentication and Key Management Mechanisms for Smart Grid Communi-cations”, IEEE Systems Journal, Special Issue on Smart Grid Communica-tions Systems, vol. 8, no. 2, pp. 629-640, June 2014This manuscript and its proposed solution was mainly designed by myselfunder my supervisor direction. P. Jokar reviewed the writing and discussedthe solution, and Dr. K. Beznosov reviewed the solution, as well as directedthe evaluation, especially adding the adversary model. Final review andcorrection are done by my supervisor.[2] H. Nicanfar, P. Jokar and V.C.M. Leung, “Efficient Authenticationand Key Management for the Home Area Network”, in Proc. IEEE ICC,Ottawa, ON, June 2012[3] H. Nicanfar, P. Jokar and V.C.M. Leung, “Smart Grid Authenticationand Key Management for Unicast and Multicast Communications”, in Proc.IEEE PES ISGT, Perth, Australia, Nov. 2011Last two manuscripts ([2] and [3]) and their proposed solutions weremainly designed by myself under my supervisor direction. P. Jokar helpedreview the writing of the manuscript as well as discuss the solution. Finalreview and corrections are done by my supervisor.iiiPrefaceChapter 3[4] H. Nicanfar and V.C.M. Leung, “Password Authenticated Cluster-Based Group-Key Agreement for Smart Grid Communication”, Securityand Communication Networks, Special Issue on Smart Grid Communica-tion Systems: Reliability, Dependability & Performance, vol. 9, no. 1, pp221-233, Jan. 2014The proposed solution was designed by myself under my supervisor di-rection. The manuscripts were written by myself and reviewed and modi-fied/corrected by my supervisor.Chapter 4[5] H. Nicanfar and V.C.M. Leung, “Multilayer Consensus ECC-BasedPassword Authenticated Key-Exchange (MCEPAK) Protocol for Smart GridSystem”, IEEE Transaction on Smart Grid, Special Issue on Security inSmart Grid, vol. 4, no. 1, pp 253-264, Mar. 2013[6] H. Nicanfar and V.C.M. Leung, “Smart Grid Multilayer ConsensusPassword-Authenticated Key Exchange Protocol”, in Proc. IEEE ICC-WSSFCS, Ottawa, ON, June 2012This chapters manuscripts and their proposed solutions were mainly de-signed by myself under my supervisor direction; he also reviewed and cor-rected the manuscripts.Chapter 5[7] H. Nicanfar, P. TalebiFard, A. Alasaad and V.C.M. Leung, “EnhancedNetwork Coding to Maintain Privacy in Smart Grid Communication”, IEEETransaction on Emerging Topics in Computing, Special Issue on Cyber-Physical Systems (CPS), vol.1, no.2, pp.286-296, Dec. 2013[8] H. Nicanfar, P. TalebiFard, A. Alasaad and V.C.M. Leung, “Privacy-Preserving Scheme in Smart Grid Communication Using Enhanced NetworkCoding”, in Proc. IEEE ICC, Budapest, Hungary, June 2013In developing the proposed solutions, I was in-charge of the privacy sideand Smart Grid network, and P. TalebiFard brought the technical informa-tion about the enhance network coding. The design was from a brain storm-ing discussion under my supervisor direction. I also wrote the most part ofivPrefacethe manuscrpit. P. TalebiFard wrote the abstract and conclusion, as wellas rewrote the network coding subsection of the background. The “Com-munication and network performance analysis” was a shared task of the A.Alasaad and P. TalebiFard. A. Alasaad improved the writing and providedthe figures. My supervisor also reviewed and corrected the manuscripts atthe end.Chapter 6[9] H. Nicanfar, J. Hajipour, F. Agharebparast, P. TalebiFard and V.C.M.Leung, “Privacy-Preserving Handover Mechanism in 4G”, in Proc. IEEECNS, Washington, DC, Oct. 2013In developing the proposed solution, I was in charge of the privacy side,and J. Hajipour and F. Agharebparast brought the heterogeneous networkknowledge. In developing the solution, they looked at it from the HetNetpoint of view. The design was done in a team base (including P. Talebi-Fard), under my supervisor direction. I also wrote most of the manuscript.J. Hajipour, F. Agharebparast and P. TalebiFard helped review literature,background, and figures. They also revised and corrected the writing. Mysupervisor also reviewed and corrected the manuscripts at the end.[10] H. Nicanfar, P. TalebiFard, S. Hosseininezhad, V.C.M. Leung andM. Damm, “Security and Privacy of Electric Vehicles in the Smart GridContext: Problem and Solution”, in Proc. ACM DIVANet, Barcelona Spain,Nov. 2013[11] H. Nicanfar, S. Hosseininezhad, P. TalebiFard and V.C.M. Leung,“Robust Privacy-Preserving Authentication Scheme for Communication Be-tween Electric Vehicle as Power Energy Storage and Power Stations”, inProc. IEEE INFOCOM-WS CCSES, Turin, Italy, Apr. 2013In developing the proposed solution, I was in-charge of the privacy sideand Smart Grid network, and S. Hosseininezhad brought the vehicular net-work knowledge. In a brain storming session with P. TalebiFard we devel-oped the solution, under my supervisors direction. I also wrote the mostpart of the manuscript. P. TalebiFard wrote the abstract and conclusion,and S. Hosseininezhad rewrote and modified the literature review and back-ground. M. Damm reviewed the final version from a market point of view,and my supervisor corrected and finalized the last version.vTable of ContentsAbstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iiPreface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iiiTable of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . viList of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xList of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiList of Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiiAcknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . xixDedication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx1 Introduction and Background . . . . . . . . . . . . . . . . . . 11.1 Security Background . . . . . . . . . . . . . . . . . . . . . . 31.1.1 Private and Public Key Encryption Systems . . . . . 31.1.2 Identity-Based Cryptography . . . . . . . . . . . . . . 41.1.3 Elliptic Curve Cryptography . . . . . . . . . . . . . . 71.1.4 Review Some of the Definitions and Attacks . . . . . 81.1.5 Authentication and Key Management . . . . . . . . . 91.2 Privacy Background . . . . . . . . . . . . . . . . . . . . . . . 131.2.1 Definition of Privacy . . . . . . . . . . . . . . . . . . 141.2.2 Smart Grid Privacy Challenges . . . . . . . . . . . . . 151.3 Security Analysis . . . . . . . . . . . . . . . . . . . . . . . . 161.3.1 Automated Validation of Internet Security Protocolsand Application - AVISPA . . . . . . . . . . . . . . . 161.3.2 Adversary Model . . . . . . . . . . . . . . . . . . . . 161.4 A Brief Introduction to Smart Grid . . . . . . . . . . . . . . 171.4.1 SG System Structure . . . . . . . . . . . . . . . . . . 201.4.2 Review Systems and Applications . . . . . . . . . . . 22viTable of Contents1.4.3 Pricing . . . . . . . . . . . . . . . . . . . . . . . . . . 231.4.4 Review Smart Grid Communications for Outside Home(Except Customer Domain) . . . . . . . . . . . . . . 231.4.5 Review Smart Grid Communications for Inside Home(Customer Domain) . . . . . . . . . . . . . . . . . . . 251.4.6 Standards . . . . . . . . . . . . . . . . . . . . . . . . 281.4.7 Smart Grid Security and Privacy . . . . . . . . . . . 281.5 Our Contribution . . . . . . . . . . . . . . . . . . . . . . . . 311.6 Road Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 Efficient Authentication Schema and Key Management Pro-tocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.2 Related Works . . . . . . . . . . . . . . . . . . . . . . . . . . 342.2.1 EIBC: Enhanced Identity-Based Cryptography . . . . 342.2.2 SG Security Schemes in the Literature . . . . . . . . 372.3 Smart Grid Mutual Authentication . . . . . . . . . . . . . . 382.3.1 System Setup . . . . . . . . . . . . . . . . . . . . . . 382.3.2 Mutual Authentication Scheme . . . . . . . . . . . . 402.4 Smart Grid Key Management Protocol . . . . . . . . . . . . 422.4.1 Key Refreshment . . . . . . . . . . . . . . . . . . . . 432.4.2 Multicast Key Mechanism . . . . . . . . . . . . . . . 452.4.3 Broadcast Key Mechanism . . . . . . . . . . . . . . . 482.5 Security and Performance Analysis . . . . . . . . . . . . . . 482.5.1 Formal Validation Using Software Tool: AVISPA . . 492.5.2 Adversary Models . . . . . . . . . . . . . . . . . . . . 492.5.3 Other Security Characteristics . . . . . . . . . . . . . 532.5.4 Performance Analysis . . . . . . . . . . . . . . . . . . 543 Password Authenticated Cluster-Based Group-Key Agree-ment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.2 Literature Review . . . . . . . . . . . . . . . . . . . . . . . . 603.3 PACGKA-I Protocol for Single Cluster . . . . . . . . . . . . 633.3.1 Group Key Construction . . . . . . . . . . . . . . . . 633.3.2 Key Maintenance . . . . . . . . . . . . . . . . . . . . 673.4 Cluster-based Mechanism: PACGKA-II Protocol . . . . . . . 683.4.1 Clustering Scheme . . . . . . . . . . . . . . . . . . . . 683.4.2 The Logic of the Multi-cluster Group Key Mechanism 693.4.3 Key Maintenance . . . . . . . . . . . . . . . . . . . . 70viiTable of Contents3.4.4 Size of the Clusters . . . . . . . . . . . . . . . . . . . 713.5 Security and Performance Analysis . . . . . . . . . . . . . . 723.5.1 Formal Validation using Software Tool . . . . . . . . 733.5.2 Adversary Model . . . . . . . . . . . . . . . . . . . . 733.5.3 Attack Analysis . . . . . . . . . . . . . . . . . . . . . 743.5.4 Overhead Analysis . . . . . . . . . . . . . . . . . . . . 753.5.5 Implementation Considerations . . . . . . . . . . . . 764 Multilayer Consensus ECC-Based Password AuthenticatedKey-Exchange Protocol . . . . . . . . . . . . . . . . . . . . . . 784.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 784.2 Literature Review . . . . . . . . . . . . . . . . . . . . . . . . 804.3 EPAK: ECC-Based Password Authenticated Key-exchangeProtocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814.3.1 Description of EPAK Protocol . . . . . . . . . . . . . 824.3.2 A few Comments About the EPAK Protocol . . . . . 844.3.3 Brief Analysis of the EPAK Protocol . . . . . . . . . 854.4 Multilayer Consensus ECC-Based Password AuthenticatedKey-exchange Protocol . . . . . . . . . . . . . . . . . . . . . 864.5 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 944.5.1 Adversary Models . . . . . . . . . . . . . . . . . . . . 944.5.2 Security Analysis . . . . . . . . . . . . . . . . . . . . 974.5.3 Formal Validation Using Software Tool . . . . . . . . 994.5.4 Performance Analysis . . . . . . . . . . . . . . . . . . 995 Maintaining Privacy by Using Enhanced Network Coding 1025.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 1025.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . 1045.3 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . 1065.4 System Design . . . . . . . . . . . . . . . . . . . . . . . . . . 1085.4.1 Assumptions and System Setup . . . . . . . . . . . . 1085.4.2 Enhanced Network Coding . . . . . . . . . . . . . . . 1095.4.3 Privacy-Preserving Scheme . . . . . . . . . . . . . . . 1105.5 System Evaluation . . . . . . . . . . . . . . . . . . . . . . . . 1155.5.1 Adversary Models . . . . . . . . . . . . . . . . . . . . 1155.5.2 Privacy Performance Analysis . . . . . . . . . . . . . 1185.5.3 Communication and Network Performance Analysis . 118viiiTable of Contents6 Privacy Preservative Context-Aware Security Solution forMobile Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . 1216.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 1216.2 Problem Definition . . . . . . . . . . . . . . . . . . . . . . . 1226.3 Literature Review . . . . . . . . . . . . . . . . . . . . . . . . 1246.4 Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1266.4.1 V2GA Scheme . . . . . . . . . . . . . . . . . . . . . . 1276.4.2 V23PPA Scheme . . . . . . . . . . . . . . . . . . . . . 1306.5 Analysis and Evaluation . . . . . . . . . . . . . . . . . . . . 1326.5.1 Privacy Characteristics . . . . . . . . . . . . . . . . . 1336.5.2 Analyzing the Attacks . . . . . . . . . . . . . . . . . 1336.5.3 Formal Validation Using Software Tool . . . . . . . . 1346.5.4 Cost Analysis . . . . . . . . . . . . . . . . . . . . . . 1346.5.5 Summary of Security Analysis . . . . . . . . . . . . . 1356.5.6 Other Benefits . . . . . . . . . . . . . . . . . . . . . . 1357 Conclusion and Future Works . . . . . . . . . . . . . . . . . . 1377.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1377.2 Suggested Future Works . . . . . . . . . . . . . . . . . . . . 1387.2.1 Future Technology and our Mechanisms . . . . . . . . 140Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141AppendixA AVISPA codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155A.1 Related HLPSL Codes of SGMA and SGKM: Chapter 2 . . 155A.2 Related HLPSL Codes of Group Key: Chapter 3 . . . . . . . 159A.3 Related HLPSL Codes of MCEPAK: Chapter 4 . . . . . . . 164A.4 Related HLPSL Codes of Privacy-Preserved Security Solu-tion: Chapter 6 . . . . . . . . . . . . . . . . . . . . . . . . . 170ixList of Tables1.1 NIST Guideline for Key and Certificate Size (bits) [1] . . . . 72.1 Summary of Resilience to the Attacks . . . . . . . . . . . . . 532.2 FD and FBM Based on Hsm and Lsas . . . . . . . . . . . . . 563.1 Parameters of the Cluster Size Problem . . . . . . . . . . . . 713.2 PACGKA Attacks Resilience Summary . . . . . . . . . . . . . 754.1 EPAK Parameters . . . . . . . . . . . . . . . . . . . . . . . . 814.2 Internal Adversary Knowledge . . . . . . . . . . . . . . . . . 954.3 Overhead Improvement . . . . . . . . . . . . . . . . . . . . . 1004.4 Improvement of Encryption/Decryption Time . . . . . . . . . 1015.1 Delivery of the Privacy Measures . . . . . . . . . . . . . . . . 1176.1 Power and Service Charge . . . . . . . . . . . . . . . . . . . . 1236.2 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1296.3 Smart Grid Server Database . . . . . . . . . . . . . . . . . . . 131xList of Figures1.1 PbKE Main Parties . . . . . . . . . . . . . . . . . . . . . . . 31.2 PAKE Protocol: X.1035 Standard . . . . . . . . . . . . . . . 101.3 Secure Remote Password Protocol . . . . . . . . . . . . . . . 121.4 SG Power Bidirectional Flows . . . . . . . . . . . . . . . . . . 181.5 SG Data Bidirectional Flows . . . . . . . . . . . . . . . . . . 181.6 SG Involved Parties . . . . . . . . . . . . . . . . . . . . . . . 202.1 Smart Grid Topology for AMI . . . . . . . . . . . . . . . . . . 392.2 Smart Grid Mutual Authentication (SGMA) . . . . . . . . . 412.3 Broadcasting an Encrypted and Signed Packet in STR . . . . 432.4 Broadcasting an Encrypted and Signed Packet in MTR . . . 442.5 Unicasting an Encrypted and Signed Packet in LTR . . . . . 452.6 Joining a Multicast Group . . . . . . . . . . . . . . . . . . . . 472.7 AVISPA Results . . . . . . . . . . . . . . . . . . . . . . . . . 493.1 Consumers Group and Producers Group in Different SmartGrid Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.2 Single Cluster (Ring-Based) Structure . . . . . . . . . . . . . 623.3 Multi Cluster Ring-Based Structure . . . . . . . . . . . . . . 683.4 AVISPA Results . . . . . . . . . . . . . . . . . . . . . . . . . 724.1 Required Symmetric Keys . . . . . . . . . . . . . . . . . . . . 794.2 ECC-Based PAKE (EPAK) Protocol . . . . . . . . . . . . . . 824.3 Four Keys Construction Based on PAKE or EPAK . . . . . . 854.4 MCEPAK Protocol Phases and Packets . . . . . . . . . . . . 874.5 AVISPA Results . . . . . . . . . . . . . . . . . . . . . . . . . 995.1 Smart Grid Network Architecture . . . . . . . . . . . . . . . . 1035.2 Matrix of Transfer . . . . . . . . . . . . . . . . . . . . . . . . 1055.3 Matrix of Transfer, With Sub-graphs . . . . . . . . . . . . . . 1085.4 Cost of Computing . . . . . . . . . . . . . . . . . . . . . . . . 1195.5 Probability of Success . . . . . . . . . . . . . . . . . . . . . . 120xiList of Figures6.1 Charging Points in Smart Grid . . . . . . . . . . . . . . . . . 1236.2 Electric Vehicle Communication with CP . . . . . . . . . . . 1266.3 Authentication Between EV and SG Server . . . . . . . . . . 1276.4 AVISPA Results . . . . . . . . . . . . . . . . . . . . . . . . . 134A.1 Chapter 2: Smart Meter (SM) HLPSL Codes . . . . . . . . . 156A.2 Chapter 2: Server (SAS) HLPSL Codes . . . . . . . . . . . . 157A.3 Chapter 2: Session and Environment HLPSL Codes . . . . . 158A.4 Chapter 3: Main HLPSL Codes . . . . . . . . . . . . . . . . . 159A.5 Chapter 3: First Entity HLPSL Codes . . . . . . . . . . . . . 160A.6 Chapter 3: Second Entity HLPSL Codes . . . . . . . . . . . . 161A.7 Chapter 3: Third Entity HLPSL Codes . . . . . . . . . . . . 162A.8 Chapter 3: Forth Entity HLPSL Codes . . . . . . . . . . . . . 163A.9 Chapter 4: Main HLPSL Codes . . . . . . . . . . . . . . . . . 164A.10 Chapter 4: HLPSL Codes of New Appliance (AN ) . . . . . . 165A.11 Chapter 4: HLPSL Codes of Home Controller (HC) . . . . . 166A.12 Chapter 4: HLPSL Codes of Building Controllers (BC) . . . . 167A.13 Chapter 4: HLPSL Codes of Neighbourhood Controller (NC) 168A.14 Chapter 4: HLPSL Codes of Central Controller (CC) . . . . . 169A.15 Chapter 6: Main HLPSL Codes . . . . . . . . . . . . . . . . . 170A.16 Chapter 6: HLPSL Codes of Smart Grid Server . . . . . . . . 171A.17 Chapter 6: HLPSL Codes of Electric Vehicle . . . . . . . . . 172xiiList of Acronyms4G Forth Generation5G Fifth GenerationAAA Authorization, Availability, AccountabilityAAM Advanced Asset ManagementADO Advanced Distribution OperationsADR Automated Demand ResponseAKE Asymmetric Key ExchangeAMI Advanced Metering InfrastructureAMR Automated Meter ReaderAN Home ApplianceAP Access PointASER Average Symbol Error RateATO Advanced Transmission OperationsAVISPA Automated Validation of Internet Security Protocols and Appli-cationBACnet Building and Automation Control NetworkingBAN Building Area NetworkBC Controller of a building area networkBD Burmester and Desmedt (protocol)BEMS Building Energy Management SystemxiiiList of AcronymsBW BandWidthCA Certificate AuthorityCC Smart Grid Central ControllerCDR Cloud-based Demand ResponseCIA Confidentiality, Integrity and AvailabilityCl-AtSe Constraint Logic-based Attack SearcherCP Charging PointCP-ABE Ciphertext-Policy Attribute-Based EncryptionCPS Cyber-Physical SystemD-H Diffie and HellmanDIEMS Distributed Intelligent Energy Management SystemDLP Discrete Logarithm ProblemDOE Department of EnergyDoS Denial of Service (attack)DRM Demand Response ManagementDSL Digital Subscriber LinesEAP Extensible Authentication ProtocolEAP-TLS Extensible Authentication Protocol Transport Layer SecurityEBS Exclusion Basis SystemsEC Elliptic CurveECC Elliptic Curve CryptographyECC-CDH Elliptic Curve Cryptography Cofactor Diffie-HellmanECDH Elliptic Curve Diffie-HellmanEIBC Enhance Identity-Based CryptographyxivList of AcronymsEMS Energy Management SystemENC Enhanced Network CodingEPAK ECC-based Password Authenticated Key-ExchangeES Estate EstimatorEV Electric VehicleFA Feeder AutomationGEV Global Encoding VectorGK Group KeyGKA Group Key AgreementGKR Group Key ReconstructionHAN Home Area NetworkHC Controller of a home area networkHetNet Heterogeneous NetworkHLPSL High Level Protocol Specifications LanguageHPEV hybrid Plug in Electric VehicleHVAC Heating, Ventilation and Air ConditionIAN Industry Area NetworkIBC Identity-Based CryptographyICT Information and Communication TechnologyID IdentityIDS Intrusion Detection SystemIPv6 Internet Protocol version 6IT Information TechnologyLEV Local Encoding VectorxvList of AcronymsLTR Long Term RefreshmentMBWA Mobile Broadband Wireless AccessMCEPAK Multilayer Consensus ECC-based Password Authenticated Key-exchangeMDMS Meter Data Management SystemMID Multicast Group IDMITM Man-in-the-Middle (attack)MGR Multicast Group ReceiverMGS Multicast Group SourceMMS Microgrid Management SystemMTR Medium Term RefreshmentMWM Mobile Work-flow ManagementNAN Neighbourhood Area NetworkNC Controller of a neighbourhood area networkNC Network CodingNIST National Institute of Standards and TechnologyNV End ValueOFMC On-the-Fly Model-CheckerOPF Optimal Power FlowPACGKA Password Authenticated Cluster-based Group Key AgreementPAKE Password Authentication Key ExchangePbKE Public Key (or Asymmetric) Encryption (system)PEV Plug-in Electric VehiclePKG Private Key GeneratorPKI Public Key InfrastructurexviList of AcronymsPLC Power Line CommunicationPrKE Private Key (or Symmetric) Encryption (system)PRNG Pseudo Random Number GeneratorPV PhotovoltaicQoS Quality of ServiceROI Return On InvestmentRSA Rivest, Shamir and AdlemanRSU Road Side UnitRT Real TimeRTU Remote Terminal UnitSAS Security and Authentication ServerSC Smart CardSCADA Supervisory Control And Data AcquisitionSG Smart GridSGCC Smart Grid Central ControllerSGKM Smart Grid Key ManagementSGMA Smart Grid Mutual AuthenticationSGS Smart Grid ServerSM Smart MeterSMK Source Multicast KeySN Serial NumberSRP Secure Remote Password (protocol)STR Short Term RefreshmentSV Seed ValuexviiList of AcronymsTOU Time Of UseTRNG True Random Number GeneratorTS Time StampV23PPA Vehicle To Third Party Privacy-preserved AuthenticationV2G Vehicle To Grid)V2GA Vehicle To Grid AuthenticationV2R Vehicle to RoadsideVANET Vehicular Ad-Hoc NetworkVIN Vehicle Identification NumberVT Valid TimeW2V2G Wind To Vehicle To GridxviiiAcknowledgementsI would like to acknowledge my appreciation for my supervisor, ProfessorVictor C.M. Leung for his technical guidance, his support, and advice duringmy PhD program. Without his style of supervising the candidates, I couldnot be where I am today.In addition, I would like to thank the committee members and examinersin the qualifying and final exams, for taking their time and for their construc-tive comments: Professor Ian Blake, Professor Konstantin Beznosov, Profes-sor Karthik Pattabiraman, Professor Jose Marti, Professor Juri Jatskevich,Professor Norm Hutchinson, Professor Vijay Bhargava, and Professor AshrafMatrawy.Also, I would like to extend my appreciation to my colleagues in theWiNMoS lab, and co-authors of my publications, as well as my family andmy friends for their help and their always support during this program.xixDedication- To Ava and HanaxxChapter 1Introduction andBackgroundThe rapid development of Information and Communication Technology (ICT)provides opportunities for a more pleasurable life style and more efficientsystems. A good portion of these systems, like Smart Grid (SG), or otherCyber- Physical Systems (CPSs), such as, electronic health-care system, aremulti-entity systems which consist of some sub-systems working together assystems of systems. In addition, new concepts and opportunities, such ascloud computing, provide better and more efficient service delivery for theICT department to manage and run their applications and systems moreefficiently and with a less investment and cost. Moreover, current enhance-ments in mobile devices contributes to smart applications running on smartdevices, which in some cases need to be run on the cloud as well. Todaymobile cloud computing has its own area in the ICT field is growing daily.Having these benefits makes ICT an interesting subject; however, it doescause many security and privacy issues as well. The users’ information ison the fly, or in some cases, the users do not have much control where theirinformation is being saved and backed up. As a result, the security andprivacy solutions and mechanisms should be revisited ensuring the new re-quirements are fully addressed. From a business point of view, the investorsmainly concentrate on efficiency and improving their profit margins. How-ever, they also need to pay enough attention to the security (and privacy).It is obvious that mostly nobody profits from security; and security (andprivacy) mechanisms are part of the system requirements and generally con-sidered as cost of a system. Therefore, mostly the intention is to decreasethe cost by designing a security mechanism that addresses the minimum re-quirements, or covers coming short (reasonable) future. For instance, eventhe governments data is being released after a period of time (e.g. 30-40years). The security mechanisms should be able to keep the data secure forthat specific period of time and duration. From this point of view, the aimin the security field is to make the provided mechanism as efficient and aslight as possible, and at the same time, meet the demands and requirements1Chapter 1. Introduction and Backgroundof the system and application.Another related area in the security field, which is its own area andfiled of research now-a-day, is privacy. Considering above discussion, thesedays because of the complexity design of the new systems, and utilizingdifferent new technologies, the users’ privacy gain more attention. This isusers concern to know and sometimes decide about the location, and evencountry, that their data and/or information is being kept, and who hasaccess to them. For instance in an old fashion ICT environment, a limitednumber of people could have access to the system and its data, and mostly itwas doable to track the accesses. However, when the users data, like photos,are being uploaded to the Cloud, the users cannot trace and/or monitor thedata movements like old days anymore.If we want to present an overall discussion, from a communication pointof view, when a user/entity wants to communicate with another user/entity/systemvia a platform/media or even a third party, the following steps can be con-sidered although it is not the only perspective:• Authentication: Firstly, an entity or a user should be introduced tothe one that wants to communicate (one-way authentication), or theentities need to recognize each other (mutual authentication).• Security key or key management (e.g. for encryption and/or signing):Normally most of the authentication protocols are tailored and endedwith an appropriate key construction mechanism. In fact, after theauthentication and in order to set up a secure channel, entities requirea key, for instance, to encrypt their data in communication and protectit from unauthorized access. Managing the key, between two entities ora group of entities that may require to communicate with each other,is our next step.• Maintaining user’s Privacy: Maintaining the encryption can protectthe data; however, cannot fully preserve the privacy of the users.Therefore, the mechanism and system should be designed somehowto preserve the privacy of the users as well, which is our final steps inthis thesis.In this thesis and following to the above steps, first of all we concentrateon increasing the efficiency of authentication scheme (Chapter 2) and keymanagement protocol. Then we study and provide two multi-entity keymanagement mechanisms (Chapter 3 and Chapter 4), and then finally moveto the privacy solutions (Chapter 5 and Chapter 6).21.1. Security BackgroundUnsecure Channel Attack Alice Bob Trent Oscar Figure 1.1: PbKE Main PartiesIn the following sections of this chapter, some of the standards and baseconcepts in each of the above mentioned areas are being discussed and brieflyreviewed.1.1 Security BackgroundFollowing the above discussion, most of this thesis in the Security field con-centrates on efficiency of the authentication and key management. Security,which is “safety, or freedom from worry,” can be introduced as a risk man-agement topic where “Risk = Asset * Vulnerability * Threat”. In theICT world, three policies are identified for the security such as Confidential-ity, Integrity, and Availability (CIA). Precisely, designing a security systemin ICT means providing required, e.g., mechanism to address any or all ofthese policies. Communication security can be divided tochannel securityand data security; however, “authentication and key management mech-anisms are the main parts of any security system in the ICT ”. The funda-mental technique used in the security mechanism is applied mathematics,or cryptography.1.1.1 Private and Public Key Encryption SystemsThere are two systems that make a message confidential between two par-ties, such as Private Key (or Symmetric) Encryption (PrKE) system, andPublic Key (or Asymmetric) Encryption (PbKE) system. The PrKE sys-tem requires only one key (called private key) to be shared by sender andreceiver. In fact, the sender encrypts the message with the shared key and31.1. Security Backgroundthe receiver decrypts the encrypted message with the same key. One of thewell-known solution to construct a symmetric key is proposed by Diffie andHellman (D-H) [2].On the other hand and in the PbKE system (Figure 1.1), two keys, apublic key and a private key are provided for each entity. The entity keepsthe private key in private and secure; however, the public key is definedto be accessible publicly. One of the well-known solutions to construct anasymmetric key is proposed by Rivest, Shamir, and Adleman (RSA)[3].Normally, in a practical PbKE system, a third party acts as a PrivateKey Generator (PKG) or Certificate Authority (CA) (Trent), e.g., issuesan individual certificate for each entity which includes private key of theentity, and is in charge of the entire key management process including thekey refreshment. When Bob wants to send a secure message to Alice toavoid intrusion from an intruder (Oscar), he encrypts the message usingAlices public key. On the other end, Alice decrypts the received encryptedmessage using her own private key. Furthermore, to protect the messageintegrity and origin, Bob signs the message using his own private key. Alicerefers to the Bobs public key for verifying the signature.1.1.2 Identity-Based CryptographyAs per above discussion, PbKE requires Alice and Bob to have access to eachothers public keys. To overcome this essential and primary communication,the IBC system (invented by Shamir [4]) distributes a unique function F (.)to all parties (i.e. a one-way hash function). As shown in (1.1), this functioncan be applied to each partys identity (ID) to obtain the partys public key.A party/entity ID can be e.g. party’s email address, phone number, IPaddress, or a combination of them. PKG selects a random number s andcalculates each party’s private key, using (1.2), and provides it to the partyvia a secure channel.PubK(ID) = F (ID) (1.1)PrvK(ID) = s× PubK(ID) = s× F (ID) (1.2)IBC from the weil pairingThree well-known pairing characteristics are bilinear, non-degenerate, andcomputable. Let G1 be an additive group, G2 be a multiplicative group ofa prime order q, and p be the group generator of G1. The discrete loga-rithm problem (DLP) for G1 and G2 is assumed to be enough hard. The41.1. Security Backgroundbilinear pairing map eˆ : G1 × G1 → G2 takes into account the followingcharacteristics:• Bilinear: eˆ should have the following properties:eˆ(q1Q1, q2Q2) = eˆ(Q1, Q2)q1q2 (1.3)eˆ(Q1 +Q2, Q3) = eˆ(Q1, Q3) . eˆ(Q2, Q3) (1.4)eˆ(Q1, Q2 +Q3) = eˆ(Q1, Q2) . eˆ(Q1, Q3) (1.5)∀ Q1, Q2 & Q3 ∈ G1 & ∀q1 & q2 ∈ Z∗q (1.6)• Non-degenerate: eˆ(P, P ) 6= 1, therefore P is a G2 generator.• Computable: There is a competent algorithm to compute:eˆ(Q1, Q2) subject to ∀ Q1 & Q2 ∈ G1As an IBC solution, the followings are steps of developed system by Bonehand Franklin [5]:Setup: Trent (PKG) chooses a secret value s ∈ Z∗q , calculates its own publickey as P0 = s.P , and makes P0 accessible by public (including Alice andBob). Subsequently, Trent picks three hash functions H1, H2 and H3, andthen forms system parameters set P̂ arm:H1 {0, 1}∗ → G1 (1.7)H2 : G2 → {0, 1}l, l = max(plain text) (1.8)H3 : G2 → Z∗q (1.9)P̂ arm = {eˆ, P,H1, H2, H3,G1,G2} (1.10)Note: The hash functions that we are referring to in our designs and pro-posed mechanisms can be any of the hash functions, e.g. SHA-1 [5]. Indeed,we only call hash functions in proposing our mechanism and use the char-acteristics of a hash function. Choosing the right and appropriate hashfunction depends on the application and system or environment that themechanism is being implemented and used.Alice and Bob will have access to set P̂ arm, and at the same time,they are capable of obtaining the Trents public key (P0). Also, for example,Alice applies H1 to ID of Bob (IDB) and extracts Bob’s public key PbKB =H1(IDB)).51.1. Security BackgroundPrivate key extraction: Trent calculates, for example, Alice’s private keyas PrKA = s.H1(IDA) and provides it only to Alice via a secure channel.Alice verifies her own private key as follows:eˆ(PrKA, P ) = eˆ(s.H1(IDA), P )= eˆ(H1(IDA), P )s= eˆ(H1(IDA), s.P )= eˆ(H1(IDA), P0) (1.11)Encryption and Decryption: Let us consider the situation that Bobfinds it necessary to sent message M ∈ {0, 1}l to Alice. He calculates Alice’spublic key (PbKA = H1(IDA)), chooses a random variable r ∈ Z∗q , and thencalculates U = r.P , and V = M ⊕H2(eˆ(PbKA, P0)r). Finally, he forwardsC = (U, V ) to Alice as an encrypted message of M . Alice employs her ownprivate key and decrypts the encrypted message M :V ⊕H2(eˆ(PrKA, U)) = V ⊕H2(eˆ(s.PbKA, r.P ))= V ⊕H2(eˆ(PbKA, P )rs)= V ⊕H2(eˆ(PbKA, s.P )r)= V ⊕H2(eˆ(PbKA, P0)r)= M ⊕H2(eˆ(PbKA, P0)r)⊕H2(eˆ(PbKA, P0)r)= M (1.12)Signature and Verification: Bob utilizes H3 and computes σ = H3(M)×PrKB to be his signature for message M , and consigns σ along with the mes-sageM to Alice. To verify signature σ, Alice checks if eˆ(H3(M).P0, H1(IDB)) =eˆ(P, σ) holds, where she follows:eˆ(P, σ) = eˆ(P, (H3(M).P rKB))= eˆ(P, s.PbKB)H3(M)= eˆ(P, PbKB)s.H3(M)= eˆ(H3(M).s.P, PbKB)= eˆ(H3(M).P0, P bKB)= eˆ(H3(M).P0, H1(IDB)) (1.13)Key Refreshment: Trent selects a new secret value s, and also recalculateshis own public key P0 as well as the entire parties’ private keys. He provideseach entity’s private key to the entity via the secure channel.61.1. Security Background1.1.3 Elliptic Curve CryptographyDue to the many benefits of elliptic curve cryptography (ECC) [6], it hasbeen used in various environments [1], especially where there are resourceconstraints [7–11]. One of the most important benefits of the ECC is provid-ing the same level of the security with a smaller key size. For instance, ECCwith 160 and 512 bit keys provide the same level of security as D-H, RSAor ElGamal [12] cryptography with 1024 and 15360 bit keys, respectively,which is much closer to the PrKE system key size. Table 1.1 presents morevalues for comparison, in key sizes as well as certificate sizes (bits). In thistable, we show a base for comparison, which the symmetric key size, whichcan be names as a target for the security level.In addition to addressing the resource constraint issue, ECC is also ben-eficial in enabling an efficient protocol that supports current and futuredevices with various levels of technology, which is important in emerg-ing SG systems. Generally, ECC is presented as an Elliptic Curve (EC)nodes/points (x, y) over Zp, via the following definition:y2 ≡ x3 + ax+ b mod pwhere : (x, y) ∈ Zps.t. : p > 3 (A large prime number)& a, b ∈ Zp & 4a3 + 27b2 6≡ 0 mod pThe National Institute of Standards and Technology (NIST) issued animplementer’s guide that specifies the EC Diffie-Hellman (ECDH) key-agreementschemes from NIST SP 800-56A, which aims at pair-wise key establishmentschemes using discrete logarithm cryptography. The document specifies theECs and domain parameters, key generation methods, the ECDH primitive,key derivation function, and other auxiliary functions that are necessary forECDH scheme implementations to be in compliance with SP 800-56A andSuite B [1].Table 1.1: NIST Guideline for Key and Certificate Size (bits) [1]Symmetric Key Size(Security Level)RSA and D-HKey SizeECC KeySizeRSA Certifi-cate SizeECC Certifi-cate Size80 1024 160 2048 193112 2048 224 4096 225128 3072 256 6144 257192 7680 384 15360 385256 15360 521 30720 52271.1. Security Background1.1.4 Review Some of the Definitions and AttacksAlthough various attacks identified already against the communication, weonly review some of them that are more relevant to the authenticationand/or key construction, along with the two properties, especially in thegroup key management, that are considered in this thesis.Social engineering attack: The attacker gains access to the systemsecrecy and confidential information, such as the server administrator pass-word, by somehow manipulating people who have access to that information.Brute-force attack: Brute-force attack, or exhaustive key search, canbe used against any encrypted data by systematically checking all possiblekeys until the correct key is found which may involve traversing the entiresearch space.Replay attack: A valid data transmission is maliciously or fraudulentlyrepeated or delayed, which can be carried out either by the originator or byan adversary who intercepts the data and retransmits it.Denial of Service (DoS) attack: An adversary fires several requestfor a service in the system/network to overwhelm the service provider. Eventhough the requests may not be qualified to be delivered, receiving andperforming the initial request can cause the entity to be over loaded.Man-in-the-Middle (MITM) attack: For example, in an open keyconstruction session, an adversary makes individual connections with thevictims and then relays and controls messages between them, where theybelieve that they are communicating directly to each other over a privateconnection. In this case, the adversary can intercept all messages and injectnew ones.Dictionary attack: Dictionary attack is similar to the brute-force at-tack. By preparing a list of possible values (for the key), by guessing oranalyzing the information that the victim may refer to for choosing theirkey/password. In fact, this attack aims at making the search space smallerthan the brute-force one. There are two models of the dictionary attack,based on the way an adversary performs it, such as on-line and off-linedictionary attacks.Unknown key share attack: When a key K in constructed betweentwo parties, Alice and Bob, Alice believes K is shared by Bob; however, Bobbelieves K is shared between Bob and somebody else.Denning-Sacco attack: If an intruder somehow finds a symmetric keyused in the authentication scheme, the intruder can find the origin datathat the found symmetric key is made by, such as an initial shared passwordbetween the parties.81.1. Security BackgroundKey privacy and insider attack: For example, in a key constructionprotocol, the middle nodes/parties that were in charge of relaying the mes-sages between two parties will gain access to the private key of the partiesby performing this attack.Ephemeral key compromise impersonation attack: In appositesite of the “Unknown key share attack”, if an adversary performs an off-line dictionary attack, brute-force, or even social engineering attack andobtains the initial password between parties, by performing this attack, theadversary will find the final constructed key, even after the fact.Forward and backward secrecies: Forward secrecy refers to means anew entity that joins a group should not gain access to the past information.On the other hand, if a member of the group leaves, they should not gainaccess to the future information, which is called backwards secrecy.1.1.5 Authentication and Key ManagementBy definition, authentication means binding an ID to a subject or principal.This can be accomplished by showing what the subject:(i) is capable of doing, e.g., performing a digital signature, or(ii) knows, e.g., a password, or(iii) possesses, e.g., a smart card, or(iv) has biometrically, e.g., fingerprintsMoreover, in a networking environment, nodes should follow a mutual au-thentication to establish a certain level of trust [1]. Then, parties need toset-up a secure communication channel, normally by employing a securitykey, to protect their data from accessing by unauthorized parties. Hence,the proposed mechanisms in this area normally come as a tailored solutionthat authenticates the parties followed by constructing a key and requiredkey management.In 2009, the IEEE 1363.2 standard [13] for password based public keycryptographic techniques was released. The standard specifies primitivesand schemes designed to utilize passwords and other low-grade secrets asa basis for securing electronic transactions. To be more precise, the stan-dard specifies the schemes for password-authenticated key agreement andpassword-authenticated key retrieval.Following are three well-known mechanisms that are treated in the lit-erature as the main references in the authentication and key management.91.1. Security BackgroundAlice Bob =   . 	 		St ep#IIIIV: 	?≠0  	= 	 		 = (|	 		\ 		|	 		)! = "  . ( 		) , !!"  	=  		$ = (|	 		\ 		|	 		): $?=%$ = &(|	 		\ 		|	 		)%$% = &(|	 		\ 		|	 		): %$?=%' = ((|	 		\ 		|	 		)III' = ((|	 		\ 		|	 		)Figure 1.2: PAKE Protocol: X.1035 StandardX.1035 standard (password authenticated key exchange - PAKE)The PAKE protocol presented in the X.1035 standard [14] presumes thattwo parties share a password pw. The four-phase mutual authentication pro-tocol defined in the X.1035 standard constructs a symmetric cryptographickey via D-H exchange by employing D-H values g and p and five sharedhash functions H1 − H5. Depicted in Figure 1.2, in the following phases,IDA and IDB are the IDs of two parties named Alice and Bob, respectively,P = (IDA|IDB|pw), and RA & RB are the respective random numberschosen by them:Step I Alice obtains X via (1.14) and forwards it to Bob:X = H1(P ).(gRA mod p) (1.14)On the other side, Bob extracts “gRA mod p” from X by (1.15):XH1(P )=H1(P ).(gRA mod p)H1(P )= gRA mod p (1.15)101.1. Security BackgroundStep II Bob computes Y and SB following (1.16) and (1.17), and sendsthem to Alice.Y = H2(P ).(gRB mod p) (1.16)SB = H3(P |gRA mod p|gRB mod p|gRARB mod p) (1.17)Alice also similarly obtains “gRB mod p” from Y per (1.18) and then calcu-lates SA per (1.19) for the verification.YH2(P )=H2(P ).(gRB mod p)H2(P )= gRB mod p (1.18)SA = H3(P |gRA mod p|gRB mod p|gRARB mod p) (1.19)Step III Alice computes TA via (1.20) and sends it to Bob.TA = H4(P |gRA mod p|gRB mod p|gRARB mod p) (1.20)Then, Bob calculates TB via (1.21) for the verification:TB = H4(P |gRA mod p|gRB mod p|gRARB mod p) (1.21)Step IV The verification of SA and SB and TA and TB by Alice and Bobmeans a mutual authentication derived by pw. Using the above values, Aliceand Bob can obtain the symmetric key K through (1.22):K = H5(P |gRA mod p|gRB mod p|gRARB mod p) (1.22)Secure remote password protocolThe Secure Remote Password (SRP) protocol [15] utilizes a predefined pass-word and the verifier to construct a key, which delivers most of the character-istics that are expected from an authentication scheme. SRP is a fast mutualauthentication scheme that uses the session key in the mechanism and resiststhe dictionary attacks. Furthermore, in the SRP protocol, compromising theserver does not make it easy to find the password, compromising the pass-word does not lead to revealing the past session keys (forward secrecy); andfinally, compromising the session key does not lead to compromising of thepassword.In SRP, depicted by Figure 1.3, the client initially enters a passwordand then the server computes a verifier from the password using a randomly111.1. Security Background𝐴, 𝐼𝐷 Alice/Client Bob/Server 𝑠𝑎𝑙𝑡, 𝐵 𝑠𝑎𝑙𝑡, 𝑣𝑒𝑟 = 𝐿𝑜𝑜𝑘𝑢𝑝(𝐼𝐷) 𝑘 = 𝐻(𝑁, 𝑔)  𝑏 = 𝑅𝑛𝑑 .  𝐵 = 𝑣𝑒𝑟 + 𝑘. 𝑔𝑏𝑚𝑜𝑑 𝑝  Step# I II III IV 𝑎 = 𝑅𝑛𝑑 . , 𝐴 = 𝑔𝑎 𝑚𝑜𝑑 𝑝  𝑀1  𝐻 𝐴, 𝑀1, 𝐾  ?= 𝑀2 𝑀2  SRP-6a 𝑘 = 𝐻(𝑁, 𝑔) 𝑢 = 𝐻(𝐴, 𝐵)  𝑥 = 𝐻(𝑠𝑎𝑙𝑡, 𝑝𝑤)  𝑆 = (𝐵 − 𝑘. 𝑔𝑥)(𝑎+𝑢𝑥) 𝐾 = 𝐻 𝑆  𝑀1 = 𝐻(𝐻 𝑁 ⊕ 𝐻 𝑔 , 𝐻 𝐼𝐷 ,                                    𝑠𝑎𝑙𝑡, 𝐴, 𝐵, 𝐾)  𝑢 = 𝐻(𝐴, 𝐵)  𝑆 = (𝐴 ∗ 𝑣𝑒𝑟𝑢)𝑏 𝐾 = 𝐻 𝑆  𝐻(𝐻 𝑁 ⊕ 𝐻 𝑔 , 𝐻 𝐼𝐷 ,                            𝑠, 𝐴, 𝐵, 𝐾)  ?=  𝑀1 𝑀2 = 𝐻(𝐴, 𝑀1, 𝐾)  V Figure 1.3: Secure Remote Password Protocolgenerated salt and then stores the client’s ID, salt and verifier in the serverdatabase. Subsequently, the client is authenticated to the server by provid-ing the password to the server, which computes the verifier again using thesalt stored against the client’s ID and checking it against the one stored inits database. Furthermore, each party generates a random number, then cal-culates the session key based on the password, verifier and random numbersas well as verifies the key utilizing a one-way hash function.SRP [15] (latest version 6a [16]), is an authentication and key-exchangeprotocol for secure password verification and session key generation over aninsecure communication channel. SRP utilizes Asymmetric Key Exchange(AKE) [15], and stores verifiers instead of the passwords. AKE uses a one-way (hash) function to compute the verifier and stores it in the server.Therefore, compromising the server and finding the verifier is not enough toobtain the key, since the password is still required.Burmester-Desmedt protocolThe “conference key system” proposed by Burmester and Desmedt [17],known as the BD protocol, is a protocol that addresses the symmetric keyconstruction for a group of users. This protocol consists of three steps.121.2. Privacy BackgroundConsider n parties:Ui, i = 1, 2, ..., nforming a cyclic group such that:Un+1 = U1I. Each member Ui generates a random value ri, computes Xi via (1.23)and broadcasts it.Xi ≡ gri mod p (1.23)II. After receiving the broadcast values by others in the previous step,each member (Ui) calculates Yi via (1.24), and broadcasts it:Yi ≡ (Xi+1Xi−1)ri mod p (1.24)III. Then assuming the values of the previous steps are received by all themembers, each member (Ui) calculates the shared key (Ki) via:Ki ≡ (Xi−1)n.ri .Y n−1i .Y n−2i+1 ...Yi−2 mod p (1.25)As can be seen from step III, the Kis of the nodes are the same, whichis called the shared (group) key K.1.2 Privacy BackgroundDue to the broadcast nature of wireless transmissions, an attacker can over-hear the communication and detect valuable information that can compro-mise the privacy of the clients. Even if an attacker cannot decode packetsor senders addresses due to packet encryption, they can correlate differentamounts of traffic transmitted by a user at different times using a modelof the users behaviour. Consequently, a well-defined privacy protection sys-tem is a preliminary demand in order to make SG ready for implementation[1, 18].Steganography: Steganography, started in 15th century, is a sub-divisionof the cryptography that deals with the privacy. It is a technique of com-munication that transfers the message embedded in a different object. Forinstance, during the cold-war, information was being transferred inside aperson’s eye in a picture, or inside the musical fonts, where nobody noticed131.2. Privacy Backgroundthem except the sender and receiver. This technique is being used morein the intelligent services although the concept is deeply about hiding theinformation, and can be used in communication, particularly in VoIP [19].Random path: Random path greatly reduces the chance of sourcesbeing identified. Even if an eavesdropper detects one packet of a sender, thenext packet is unlikely to follow the same path, thus rendering the previousobservation useless. Although the message delivery time using the randompath is a longer than the minimum-hop approach, it is still acceptable ifthe enhanced privacy preserving capability of the random path approach isconsidered. To implement the scheme, a technique called phantom routinghas emerged [20]. Although the scheme is robust, it involves a large over-head and may not withstand attacks under a collaborative adversary model.Privacy-aware parallel routing scheme is used to maximize the source trace-back time [21]. Packets from the same source are routed over different pathsto the destination, beside a weighted random stride routing to break theentire routing into strides. However, this scheme will not be effective inprotecting source privacy in case of a global eavesdropping adversary.1.2.1 Definition of PrivacyOne of the most famous and original definitions of the privacy that has alsobeen adopted by NIST [18] is “The right to be left alone”. Bob Blakleydefined it as “The ability to lie about yourself and get away with it” [22]. Inthis regard, Pfitzmann and Hansen provided six definitions in the privacycontext [23]:Anonymity: “Anonymity of a subject means that the subject is notidentifiable within a set of subjects, the anonymity set”. Anonymity, themost popular used term in the literature, aimed at making a party anony-mous from others, even a peer, which can be defined as Sender Anonymityand Receiver Anonymity.Unlinkability: Unlinkability means not being able to distinguish re-lationship between two items in a system. An item for instance can bea Smart Meter (SM), controller of a Home Area Network (HAN), BuildingArea Network (BAN) or Neighborhood Area Network (NAN), or aggregator.Undetectability: Undetectability refers to the existence of an entity,application or process being agnostic to the eyes of an observer.Unobservability: Unobservability means having characteristics of bothanonymity and undetectability. Unobservability is applicable when there isa relationship among the players, e.g., sending and receiving.Pseudonymity: “A pseudonym is an identifier of a subject which is141.2. Privacy Backgrounddifferent from the subject’s real name”. Pseudonym can be defined as per-son pseudonym, role pseudonym, relationship pseudonym, role-relationshippseudonym, transaction pseudonym, respecting the relationship the holder.Identity Management: Entities that follows pseudonymity approachhave multiple identities, based on one or some attributes of the entity. Man-aging the identities in terms of assigning and controlling them in a way thatmakes the item unidentifiable by any unauthorized party, is the task ofidentity management.1.2.2 Smart Grid Privacy ChallengesIn 2010, NIST released the guideline to cyber security of SG. Volume 2 of theguideline addresses the privacy, and identifies four categories of the privacy:Privacy of personal informationPersonal information of a customer implies to name, address, phone number,and similar attributes that yield identifying the customer, directly or indi-rectly, and with or without combination by other attributes of the customerthat are publicly available (e.g. roughly age or origin of nationality). It is aright of the customer to decide how and up to what extend her/his personalinformation is allowed to be shared by others, fully or partially [18].Privacy of the personPrivacy of the person infers to the persons body situation and requirements,which yields health and physical aspects of the body. The health issuesand body physical information as well as required treatments are part ofthe privacy of the person. Some of the smart medical devices are used inhome that their existence and operation pattern can yield health status ofthe customer [18].Privacy of personal behaviourThis category indicates a person right about his activities choices and keepsthem in private. For instance, a customer may have multiple vendors to re-ceive a specific service. So, it is the customer’s right to keep this informationand asks SG not to share them with others [18].151.3. Security AnalysisPrivacy of personal communicationThis category deals with control-free communication of a person with oth-ers. The control-free applies to undue surveillance, monitoring, or censor-ship. Since the communication between the customer and service provideris part of the SG context, it is the customers right to identify her/his levelof communication, without any controls of SG [18].1.3 Security AnalysisIn most of our work, we follow one, or both of the following approaches.1.3.1 Automated Validation of Internet Security Protocolsand Application - AVISPAIn this thesis, Automated Validation of Internet Security Protocols and Ap-plication (AVISPA) [24] software is used to simulate and analyze the pro-posed mechanisms. AVISPA is a software tool for the automatic verificationand analysis of Internet security protocols that is currently considered by theresearch community as one of the most trusted evaluation tools to analyzethe ability of a scheme or protocol to withstand different attacks.AVISPA integrates automatic security analysis and verification back-endservers like On-the-Fly Model-Checker (OFMC) and Constraint-Logic-basedAttack Searcher (Cl-AtSe). First of all, the mechanisms under examinationby AVISPA must be coded in the High Level Protocol Specifications Lan-guage (HLPSL) to be evaluated by the back-end servers. HLPSL is anexpressive, role-based formal language used to describe the details of theprotocol in question. Our HLPSL codes (see Appendix A) includes differ-ent sections used to model the roles of entities in a proposed solution, aswell as the role of the environment and the security goals that have to beachieved. We normally start with the original model already existing inthe AVISPA library, and then developed our HLPSL codes based on theproposed mechanism.1.3.2 Adversary ModelThe next tool to evaluate our mechanism is Adversary model. In our works,we consider Dolev-Yao model [25], which has different assumptions. The ad-versary controls the network completely, or even the adversary is the networkitself. Therefore an adversary can record, delete, replay, reroute, reorder,161.4. A Brief Introduction to Smart Gridand completely control the scheduling of messages. Furthermore, the hon-est parties receive/send the packets/messages only from/to the adversary.In addition the adversary is capable of selecting the required additionalinformation and receiver of the packets. Normally it is assumed that the ad-versary has information about other parties (their IDs) and also has accessto their e.g. public keys. In some cases, the adversary has access to privatekeys of a few of parties, also and if required, is capable to generate a validnonce. In case of the attacks like reply attack, the adversary can resendmany times the same message. The adversary is capable to try decryptingthe encrypted messages to perform attacks such as brute-force or dictionaryattacks.Our adversary models consists of four parts. (i) The first one shows theobjective of the adversary in which we clearly mention in each case specif-ically what is/are the objectives. Since we want to analyze our proposedmechanisms, normally we set the model to attack the mechanism from dif-ferent angles. (ii) Then we describe initial capabilities of the adversary,for instance, having knowledge about the topology, or public keys, or ourproposed mechanism. (iii) Then, we discuss capabilities during the at-tack of the adversary. For instance, and as per aforementioned Dolev-Yaomodel, the adversary can receive all messages and tries to decrypt them. (iv)Finally, we present the discussion part, to see if the adversary is capableof breaking our mechanism, and what the limits are.In some cases we provide two adversary models, including internal ad-versary and external adversary. In case of external adversary, normally weassume that our adversary is not one of the system or network parties, anddoes not have any valid key. In fact, the adversary is attacking the systemfrom outside. On the other side and in case of the internal adversary, weassume our adversary for instance has a full control on at least one of thesystem malicious parties. The malicious party has a valid e.g. private keyto be able to communicate securely with other parties including the secureserver (if there is one).1.4 A Brief Introduction to Smart GridAchieving a successful implementation of a High Tech Smart Grid (SG)will provide benefits like improvement in asset management and planning inproduction and distribution side, enhancement in managing risk of outage,and improve cost efficiency in electricity consumption side. Providing ahigh level of security is one of the most important and challenging topics171.4. A Brief Introduction to Smart Grid Figure 1.4: SG Power Bidirectional Flowsin the SG design, which has gained substantial attention in the researchcommunity [1].SG is a combination of different systems and sub-systems,and is vulnerable to various attacks that may cause different level of harmsto the devices and even society-at-large [26]. Since SG is moving the powergrid from a closed control system to one employing open IP networks [27],a variety of threats have been identified in the SG context, e.g., MITM,DoS, impersonation, which can affect the data integrity and authenticationof users and devices. Moreover, different viruses or attacks such as brute-force and dictionary attacks can target the data security and confidentiality.The Stauxnet worm is another example that can cause a significant impacton even national security [27]. Once an entry point is found, an intruderor a malicious node may perform different action to compromise the wholesystem. Since millions of homes are connected to an SG, the impact of suchDistribution Customer Service Provider Operation Market Transmission Bulk Generation Figure 1.5: SG Data Bidirectional Flows181.4. A Brief Introduction to Smart Gridattacks can cause a significant loss or harm on society, e.g., by causing ablackout, changing the customer billing information, or changing the pricinginformation sent to the customers [26–28].US Department of Energy (DOE) in Energy Data Book 2009 reportedthat residential, commercial and federal buildings use about 39% of U.S.primary energy consumption in 2006. Electricity is the main and fastestgrowing source of building energy consumed by about 74%. During last fewyears, attention to developing a new enhanced grid (SG) has been increased,to improve the power system efficiency, such as generation, transmission, dis-tribution, consumption and billing. In a traditional model, there are twomain flows: (i) Power flow from a provider to the customer, (ii) Data flowabout the metering and for billing purposes which is from a customer to theprovider. This data follow normally was/is in a long time bucket (monthly),and almost over an off-line communication. Furthermore, both mentionedflows are just unidirectional. Over years this model has changed and im-proved and then, Automated Meter Reader (AMR) system was developedwhich is mainly used in the developed areas.In an AMR system, which its name shows as well, metering data com-munication from the customers are automated. Also, some off-line or evenon-line information about the electricity price per week-day, and time of theday, is provided to the customers to manually make their decision aboutmanaging power usage in a better and more efficient way. However, someof the customers that may have power generation facility like Photovoltaic(PV), may have extra electricity and are willing to return (and sell) it backto the grid. In short, using the Advanced Metering Infrastructure (AMI)instead of the AMR system, target is providing a bidirectional flow of power(Figure 1.4) and data (Figure 1.5) [1].SG has gained attention from different parties comprises Governments,Market and Energy Providers, Society and Research Community (Figure 1.6).Government: SG for government is currently a national [1, 26, 29] andeven an international project which requires all resources collaboration, espe-cially in regards to standardizing [1, 26]. Most of the power energy providersuse national resources like fossil fuel-powered generating plants [1, 29], whichare hard or impossible to be replaced. Moreover, it is an interest for gov-ernments because of the global warming impact and emissions control [26]as well as society (businesses and individual) Security and Privacy.191.4. A Brief Introduction to Smart Grid Figure 1.6: SG Involved PartiesMarket and energy providers: They are involved to generate and trans-mit/distribute the energy in an efficient manner as well as manage/preventthe blackout risk. For instance, they need to use the consumers power usageand demand information in order to manage the system in operation side.So, they rely more on the customer data most likely in a live and on-timemanner, and make the data security more critical for them [30].Society: First of all, they have concern about national resources consump-tion. Secondly, they expect and require service delivery improvement onreceiving it on-time and with a low cost [26]. To address the security, theywant to make sure the new system is reliable enough and secure to be alwaysavailable. Since personal and business information can be discovered fromthe electricity usage, they need their privacy to be fully maintained.Research community: The whole SG project is still new and has manydifferent sections that require research. One of the approaches is increasinguse of ICT and new technology in SG to improve the power system fromall aspects [1, 26]. As McDonal et al. mentioned “it (Smart Grid) is anetwork of computers and power infrastructure that monitor and manageenergy usage”. Having more information technology (IT) in serving powersystem demands more research [26]. Furthermore, it is the research com-munity duty to design a secured and privacy-aware system to address otherparties concerns.1.4.1 SG System StructureSG system is supposed to provide appropriate and on-time information. Thisinformation plays the main role in improving live planning and scheduling,201.4. A Brief Introduction to Smart Gridcost efficient production and transmission and distribution as well as assetmanagement, for provider and distributor end; also using electricity in acost efficient fashion for customer end. In this part, we review some of theSG topologies suggested by research community.H. Gharavi et al. provided a Mesh Network Architecture model for thelast mile SG. This architecture has two mesh based domain. First domaincovers HAN including appliances and at least one Mesh-station with accesspoint (MSAP). One of the MSAP (can be Smart Meter or SM) duties is toact as an Access Point (AP) for HAN mesh network. Second domain handlesNAN mesh network that connects HANs domains to the AMI head-end viadata aggregation point (DAP) and Mesh-Relay-Station if needed. As theymentioned, the role of the second mesh network is to expand the coveragearea of the network by using multiple hops connection. Then, they proposedmultiple paths connection between each home SM and DAP. This is one ofthe latest proposal in this area that we found it more practical solution. Us-ing multi-hops model in NAN (from a meter to the aggregator) is reasonable;otherwise we need to have several collectors to cover our Metropolitan AreaNetwork (MAN). Furthermore, they used AODV for NAN routing protocoland provided a solution for path selection in a NAN domain [31]. Some ofthe papers provided sub-sections per physical location e.g. HAN, BAN, andHAN. M. M. Fouda et al. proposed model for HAN is almost a star topol-ogy, and their NAN topology is a Mesh based structure. Their HAN modeluses ZigBee and NAN uses WiMax connections including a base station toconnect BAN/HAN gateways to the NAN gateway. Their next step is com-munication between the NAN gateway and Control Centres in TransmissionCentres via local Distribution Centres [32].NIST is in developing process of the SG required standards and guide-lines. NIST followed two approaches of top-down and bottom-up, and de-veloped required standards for interfaces between domains (coming fromtop-down view). They identified seven domains (Figure 1.5), 46 actors, 130possible logical interfaces in 22 categories. They also mentioned 180 high-level security requirements in 19 groups.• Bulk Generation Domain: This domain developed energy from dis-tributed resources, which are usually connected to their local electricalloads. After answering local demand, extra energy flows into the gridthrough routers.• Transmission Domain: It is responsible to transmit the energy fromthe generation sources to the consumers.211.4. A Brief Introduction to Smart Grid• Distribution Domain: Routers track the demands changes to adaptthe energy distribution dynamically.• Operation Domain: It collects grid status such as the current resourcesenergy capacities and the current customers energy demands, in orderto optimize grid operations.• Market Domain: It gathers energy supply and demand informationfrom grid to balance supply and demand.• Customer Domain: Customers buys, and in case of generating energyfrom renewable resources, sells extra via grid to the service providers.• Service Provider Domain: This domain roll is buy and sell the energy.They deals with customers as well as energy provider sources.So far, NIST has covered cyber security strategy, logical architectureand interfaces, high-level security requirements, cryptography and key man-agement, privacy, vulnerability classes, bottom-up security analysis, R&Dthemes for cyber security, overview of standards, key power system usecases for security requirements. Encryption of critical security parametersare under developments by NIST [1]. Some of the organizations that de-velop related standards are: IEC Technical Committee 57 WG 15; ISO/IEC15408; ITU X.805; ANSI/ISA-99.00.01-2007; NIST 800 series (SP 800-82,SP 800-53); ANSI C12, IEEE 1402; NERC Critical Infrastructure Protection(CIP); European Energy Regulations CEER & ERGEG; Roadmap 2010-18by EEGI; IEEE P2030; IEC Global Standards and several IETF request forcomments (RFCs) [29, 32].1.4.2 Review Systems and ApplicationsLike any other system, SG currently uses, and potentially will use, someapplications and systems and subsystems. For instance, Supervisory Con-trol And Data Acquisition (SCADA), Energy Management Systems (EMS),Building Energy Management System (BEMS), Micro-grid ManagementSystem (MMS), Distributed Intelligent Energy Management System (DIMES),Vehicle To Grid (V2G), Wind To Vehicle To Grid (W2V2G), Demand SideManagement (DSM), Estate Estimator (ES), Automated Meter Reading(AMR), Advance Metering Infrastructure (AMI), Demand Response Man-agement (DRM), Meter Data Management (MDM), Cloud-based DemandResponse (CDR) [33], Automated Demand Response (ADR) [34], Feeder221.4. A Brief Introduction to Smart GridAutomation (FA) [34], Electric Vehicle (EV) [34], Mobile Work-flow Man-agement (MWM) [34], Notification [35], Analytics [35] and Photovoltaic(PV). In all of these systems and application, data security and customersprivacy should be addressed.1.4.3 PricingOne of the main advantage of using SG is giving opportunity to the cus-tomers to consume energy costs efficiently. There are two types of pricingtechniques called Time of Use (TOU) and Real Time (RT) [36]. In TOU,the price is set in a long forecast fashion before the time of use, like monthlyor even annually. Mainly, the historical data delivers a suggestion of thesame demand, and future known demand and development project as wellas other related data are utilized to have TOU. On the other hand, RT isan improved and more efficient technique for price delivery, an hour beforeusage for example. RT can only be delivered based on AMI technology.Furthermore, supporting “what-if” simulations can be performed only innew SG and AMI. In a “what-if” simulation, a customer may need to see theeffect of their decision before finalizing it. “What-if” simulation techniquescan be used by market and service providers to efficiently invest or run thesystems [35]. Price list and appropriate load balancing is one of the mainsubjects in the research community, in which the optimization techniqueplays a main role.1.4.4 Review Smart Grid Communications for OutsideHome (Except Customer Domain)In this part, we review some of the wireless and wired technology mainly foroutside of a home communications.Power line communication (PLC)In this technique, current power line infrastructure is used for communica-tion as well, which supports wide access and low costs. It can be used totransfer metering information from SM to the concentrators in SG infras-tructure. It is one of the initial solutions; there is quite a bit of literature inthis area, and some implementation. However, this solution has some disad-vantages, which mostly come from the nature of power lines. For example,a line is too noisy and bandwidth is low enough to increase the concernof some applications that required high rate [37]. Standard IEC 61334 hasbeen developed to cover this communication [38].231.4. A Brief Introduction to Smart GridDigital subscriber lines (DSL)Using DSL in most of the areas has been experienced. It is an already im-plemented infrastructure that uses wired phone network for communication.This solution provides a low cost and high bandwidth in a wide area thatmakes it an interesting solution for most of the current project. Although itsdisadvantage is the potential line down time and lake of required standardand distance dependency. It also requires installing the wired network inrural area, which forces line maintenance that increase the cost of solution[37].Fiber opticUsing fiber optic as the main network back bone has been around for manyyears, which provides a very high bandwidth and reliable communicationthat addresses most of the application requirement. However, it requiresinstallation in rural areas and maintenance, which makes it a costly solutionand techniques for SG [37]. It can be used in part of the SG network likeinside bulk generator domain, but may not be a good solution for all of thesections.Wireless lanWireless LAN has been used for a long time now and IEEE 802.11 standardbased model are studied, improved and developed during last decades. NISTalso recognized IEC 61850 for SG, which proposed Ethernet based commu-nication. Currently, both can provide a good and reliable basis for commu-nication in SG as per application requirement. Wireless can be used in SGand is able to provide different specifications: (i) Enhanced transformer dif-ferential protection, (ii) Redundant link for distribution automation system,(iii) Communication aided line protection, and (iv) Control and monitoringof remote DERs [37, 39].WiMAXWiMAX technology as part of IEEE 802.16 has been developed for MAN,which delivers a high bandwidth high distance coverage. The drawback ofusing WiMAX is its high implementation cost, since it requires WiMAXtower infrastructure. Literature recommends using this technology for com-munication between smart meters and the utility network. It can support241.4. A Brief Introduction to Smart Gridreal time pricing since, automated meter reading, and outage detection andresponses since has a high speed communication [39].CellularThe 3G/4G technology is the next suggestion for the SG communication,mainly for outside HAN up to utility station. The required infrastructurefor cellular network is already implemented and can cover most the areas;however, bandwidth and channel speed, channel security, call drop, andconnection cost are concerning. For instance, this technology has been sug-gested to be used for SCADA interference for remote distribution substationand monitoring and metering of remote DERs [39].MBWAMobile Broadband Wireless Access (MBWA) or MobileFi based on IEEE802.20, is a new technology that provides high speed bandwidth as well assupporting high mobility. For some of the SG application, such as plug-inelectric vehicles, wireless backhaul for SG monitoring, and SCADA systems,this technology has been suggested by literature [39].Digital microwaveThis technology can support point to point communication for SG applica-tions with a very long distance coverage (up to 60KM). For instance, it canbe used for transfer trips between DER and distribution substation feederprotection relay. It is capable of receiving data from Ethernet or ATM andtransmitting it as microwave radio, although it is vulnerable to interferenceand signal fading [39].1.4.5 Review Smart Grid Communications for Inside Home(Customer Domain)As one of the main seven domains of the SG system is the customer domain,we review some of the technologies that are proposed for communicationinside a HAN (or customer domain).BluetoothBluetooth is part of IEEE 802.15.1 that is being used in HAN devices. Itcan cover from 1m and up to 100m distance communication. Bluetooth has251.4. A Brief Introduction to Smart Gridall seven layers of OSI communication stack, although it does have a strongsecurity since has been designed to be a light weight technology [39].INSTEONINSTEON can cover up to 45m and up to 4 hops in a mesh based model.It uses the time slot synchronization scheme concept and nodes are allowedto transmit in certain time slots to avoid the collision. Devices can send orreceive, and they relay a received packet as long as not being the destination.It can handle unicast, multicast, and broadcast communications. To handleend-to-end reliability, INSTEON uses acknowledge (ACK) and NAK andfor security, can encrypt the messages. Although INSTEON specification isnot publicly available, it is an easy technology to be implemented [40].WavenisWavenis, which has physical, link and network layers, is designed to provideindoor and outdoor services. It covers up to 200m for indoor usages andup to 1000m for outdoors needs. It uses a TDMA mechanism for synchro-nized communication combining with carrier sense algorithm; it also usesCSMA/CA for non-synchronized scheme. Device connection is based on re-quired Quality of Service (QoS) defined by the node in time of connectingto the network. Nodes do not relay the packets and only communicate withthe root. Also, Wavenis uses several algorithm such as 3DES and 128 bitsAES encryptions for security. Currently millions of devices are producedusing this technology, although its specification are not publicly accessible[40].Z-WaveZ-Wave is a light weight technology designed for HAN and offices, has fivelayers such as physical, MAC, transfer, routing and application. It cancover up to 30m for indoor and up to 100m for outdoor communications. Itis mainly designed to handle controlling command, and devices can play tworolls of slave or controller. It can support up to 4 hops in a source routingbased, and can handle unicast, multicast, and broadcast communications.The mechanism used in MAC is CSMA/CA, ACK is used to provide end-to-end reliability, and for security, it uses 128 bits AES encryption [40].261.4. A Brief Introduction to Smart GridZigBeeThe best known technology in this area is ZigBee. It was designed for shortrange and low data rate application. It covers from 10-100m distance, andbased on topology, can handles 5, 10, or 30 hops. ZigBee follows IEEE802.15.4 standard and includes physical, MAC, network, and applicationlayers. Nodes in a ZigBee can be coordinator, router and end device, andcovered communications are unicast, multicast (application and networklayers), unicast and indirect accessing. MAC covers two access model such asbeacon-enabled assuming existence of a coordinator which generates beacon,and beacon-less that utilizes CSMA/CA. ZigBee technical information ispublicly accessible, and millions of devices are being produced based onZigBee or are planned to be produced for HAN (plan is about 30 millions innorth America). ZigBee handles up to 127 bytes packet size and, in termsof reliability, ZigBee takes advantage of ACK and duplicate packet control.For security, ZigBee supports integrity, confidentiality, access control andkey managemen [40].6LoWPAN6LoWPAN mainly takes advantages of ZigBee and IEEE 802.15.4 plus usesIPv6 technology. It is a light weight design for HAN compared to the originalIPv6 and covers IP, TCP and application layers as well. The beauty of it isits compatibility with internet commutation compared to ZigBee. Similarto ZigBee, 6LoWPAN specification is publicly accessible and in most of thefeatures are similar or an improved version over ZiGbee. For instance, it cancover between 10-100m (same as ZigBee), and supports unicast, multicast,broadcast, and IPv6 anycast. Devices can be edge router, mesh node, routerand host, with a maximum of 255 hops. The packet sizes can be up to 127bytes and uses TCP or UDP to provide reliability. In terms of security, ithandles integrity, confidentiality, access control; however, key managementis not yet supported [40].According to our study and the amount of efforts that are putting inplace to develop 6LoWPAN, there is a high chance for the adoption of thisprotocol, although current Smart Objects constraints may not allow the useof IPv6 at least yet.OthersSome of the other HAN technologies are HomePlug [38], HomePlug GreenPHY, PRIME and G3-PLC [37].271.4. A Brief Introduction to Smart Grid1.4.6 StandardsIn this part, we briefly review some the standards discussed by literatures[37, 38].IEC 61850 and UCA 2.0This standard is initially developed for intra-substation communication andcan also be used for metering application, as well as based on IEC 62445,for the communication between central controllers and substations.IEC 62056-21 / IEC 61107It has been developed to describe software protocols and hardware suitablefor data exchange with utility meters, which is widely used today.IEC 62056-31This standard is designed for remote and local meter reading, which supportof nearly 10 million already implemented devices in Europe.SMLIt is a communication protocol for data acquisition, which was designed tobe a simple and suitable for low power embedded devices.BACnetBuilding and Automation Control Networking (BACnet) is a system forHAN applications such as HVAC, security and lighting, as well as for com-munication of external application to the HAN system.1.4.7 Smart Grid Security and PrivacyIn genera, and like any other system, the main challenges of security includ-ing availability, integrity and confidentiality should be addressed by SG.Furthermore, privacy is the fourth SG security concern [26]. In this part,we study only IT domain security, includes IT-networks, IT-infrastructures,computers, applications and related peripherals. Here we study some of thesecurity and privacy related works in the literature. More is provided ineach chapter accordingly to the subject of the chapter.281.4. A Brief Introduction to Smart GridSG security conceptual designAMI needs two way communications versus one way communication of AMRsystem, although security and privacy should be addressed in all of them[29]. T. Zhen et al. presented a framework for information security basedon national (China) and international (Asian, US and European) standards.Their model is a closed loop includes three layers of Strategy, Managementand Technology [41]. Being a closed loop model expected to make the systemactive and dynamic and improving the security system. In overall design,this model has six blocks including Security Business, Security Management,Application Security, Data Security, Infrastructure Security and SecurityTechnical Measures.W. Yan-liang et al. proposed an architecture security model based on thecloud computing and cloud security. Main assumption in this model is usingcloud concept model to maintain power system information security as themain target. This model architecture has two sections of service and client[42]. R. Zhung et al. proposed three layers structuring of Device Layer,Network Layer and Service Layer for the SG. In service layer, they defineda metric named service security to evaluate potential network failure on thepower system. This metric is based on risk factors in availability, integrityand confidentiality for security (Privacy in not addressed) [43].Another conceptual framework is proposed by D. Wei et al. that is basedon having three layers system structure including power, automation andcontrol and security. This model has three main components such as securityagent, managed security switch and security manager, and has been designedto be a multi-layers IDS. They also mentioned that patches regarding newdetections should be transferred to the system via the public communication,which could be unsafe/unsecured for the security related information [44].R. Zerbst et al. proposed a zone principal based on Defense-in-Depthapproach, which is a computer standard, for security control principle. Thismodel has six zones: process, critical automation/basis control, critical oper-ation control/supervisory control, operation support/management, businessautomation/logistics and external partner/connections. This model empha-sized on addressing international, national, regional, and other related stan-dard based on these zones [45].SG security and privacy detail designThe main concern of M. M. Fouda et al. is attack in link-layer in ZigBeefor HAN, which covered the HANId conflict. In fact, HAN coordinator uses291.4. A Brief Introduction to Smart Gridmessage coming from the appliance that has received two messages fromtwo sources with the same HANId, and wants to detect the attack. In sucha case, the coordinator selects a new HANId and sends it to all of its ownnodes [32]. Finding the issue by appliances may not be possible, becauseappliances receive the packet and HANId that are coming from the sources,and are not able to recognize they are from more than one source. Secondly,if HANId is incremental, two HAN coordinators that their HANId were thesame may choose the same HANId again, unless they select it in a purerandom model.Z. Lu et al. described Denial-of-Service (DoS) attack as one of the attacksin the SG system. They introduced an index based on dividing traffic floodedby attacker to the total channel bandwidth to study system behaviour. Studyshows: Increasing intensity index affects delay performance very much unlessit gets close to one. In such a case, detection becomes a high risk. Decreasingpacket size in Distributed Network Protocol (DNP3) causes this protocolmore robust to the DoS attack. Making smaller packet size will cause moreoverhead, which is a delay root cause [46].Y. Wang et al. mentioned the most of the SG characteristics (in HANdomain) would be similar to the Wireless Sensor Network (WSN). Theysuggested most of the developments such as design in security can be trans-ferred to the SG. They prepared a list of differences including: deploymenttopology, data processing, energy less sensitive, remote maintenance andconfiguration, harsh environment conditions, reliability and latency Quality-of-Service (QoS) requirements, and high security requirement. Then, theydefined required security features of the WSN for the SG [47].The next idea uses certificate to secure data transmission between par-ties. It is to maintain the data communication Security and Privacy from anSM to the utility in high rate (every few minute) and low rate (every weekor month). Based on high-frequency ID and low frequency ID of each SM,two parts of ID profiles named personally identifiable SM and anonymousSM are introduced in this model, which are used to create Client Data Pro-file and Anonymous Data Profile. This model focused on implementationof such a service and used nonce, shared certification authority), electricalsignature and time stamp procedure [48]. This is a costly solution and mayneed modification per data required security.E. Aydey et al. proposed an authentication mechanism for the SG HANsection that covers three communication sections such as gateway-SM, smartappliances-HAN, and transient devices-HAN. They showed that their mech-anism has a low overhead and is good for the SG devices with resourceconstraint. However, they assumed all of the devices have pair-wise key301.5. Our Contributionwith a trust center. After sending authentication request to the trust cen-ter, this center creates and sends to the entire nodes one key per every twodevices communication link. To be more precise, one key between the SMand the gateway, and one key per appliance per connection to the SM andthe gateway. Also, cloud should keep all of these keys. This study requireseach node to have multiple keys only for authentication purposes. If a Tran-sit Device temporary visits a HAN other than its own HAN, new keys arerequired as well[49].1.5 Our ContributionThe above discussion is presented as an initial introduction to the securityand privacy challenges and research in this area. More discussion is deliv-ered at the beginning of each chapter to study about focus of the chapter.However, and as part of introduction, as it is shown in Figure 1.5, there aredifferent communications in the SG system, and at the different levels andsub-systems. There are enough study in the literature about the require-ments, and in this thesis, we only touched a few problems aligned with theNSERC research project that has funded this thesis.One of the main ingredients that the SG system works based on is livedata about the power consumptions, actual and/or planned, that needs to becollected. One side of these communications can be smart appliances insidethe homes, and other side can be up to the server located in the utilitynetwork. We address the security of these communications by providing ourefficient authentication and key management mechanism.In the SG system, collaboration between customers (or between the smallpower providers) in efficient electric power consumption (or provisioning)are required. They need to securely communicate to each other as part ofa group. We developed an efficient group key management that addressthe required secure group communications. In some situations, for instancein case of an emergency, or any other similar situation, smart appliancesinside a home needs to be controlled by SG controllers. These controllerscan be located at the HAN or SG central controller unit, or in between.The security of these controlling commands, and addressing the hierarchyauthority of the controllers is our next contribution.Preserving consumers’ privacy in the SG data communication is one ofthe key point to have the SG system ready and being accepted by the cus-tomers. Referring to our previous discussion, the users privacy has differentaspects and points of view. Electric Vehicles are one of the SG system311.6. Road Mapcomponents, which use as well as can carry the electric power and acts asa mobile storage in the SG context. However, one of the users concern istheir privacy that can be jeopardize by tracing of contact points of the userselectric vehicles to the grid.1.6 Road MapThe first part of the thesis, including the first three chapter, deals withthe security mechanism. Chapter 2 presents our authentication and keymanagement mechanisms for smart appliances and home gateway, e.g. smartmeter, as well as from the smart meter to the SG server located in theutility network, via NAN aggregators. We propose our efficient group keymechanism in Chapter 3. Our cluster based group key management can beused by a group of consumers on efficient power consumptions; or a groupof small supplier on efficient power provisioning. Our multilayer consensuspassword authenticated key exchange mechanism, which is based on ellipticcurve cryptography, is presented in Chapter 4.Then in the second part of the thesis, including five and six chapters,we focus on users’ privacy. In Chapter 5, we present our privacy preserv-ing mechanism for data communication in the SG network, which utilizesenhanced network coding. Then, we concentrate in the electric vehicle com-municating with the smart grid, via third party entities, such as powerstations. We provide a privacy-aware security solution in Chapter 6 as ourlast part of the thesis.As above steps shows, we concentrate more on customer domain of theseven SG domains (Figure 1.5), and customer relevant communication (fromand to a HAN). Although our group key management presented in Chapter 3can be implemented for, and used by, a group of providers too, again its mainfocus is customers. We try to look at the SG system from a customer pointof view, and even overs EV as a customer domain element.32Chapter 2Efficient AuthenticationSchema and KeyManagement ProtocolIn this chapter, concentration is on efficiency of authentication schema andkey management protocol, which are normally tailored together. As our casestudy, we presents our solution in the SG context. An efficient scheme is pro-posed that mutually authenticates an SM of a HAN and an authenticationserver in SG by utilizing an initial password, by decreasing the number ofsteps in the SRP protocol from five to three, and number of exchanged pack-ets from four to three. Furthermore, we propose an efficient key managementprotocol based on our Enhanced Identity Based Cryptography (EIBC) 1 forsecure SG communications using Public Key Infrastructure (PKI). Our pro-posed mechanisms are capable of preventing various attacks while reducingthe management overhead. The improved efficiency for key managementis realized by periodically refreshing all public/private key pairs as well asany multicast keys in all the nodes using only one newly generated functionbroadcast by the key generator entity.2.1 IntroductionNIST suggests using PKI to secure SG communications [1]. PKI [50] (andPKE) is briefly reviewed in Chapter 1. Our proposal facilitates secure andefficient authentication and key management on top of PKI.The customer’s side of an SG consists of HANs in customer premiseswhere smart appliances and controllers are connected to SMs, which formthe end-points of the AMI that provides two-way data communications be-tween SMs and the utility’s Meter Data Management Center. This workis focused on authentication and key management over the AMI. The AMI1H. Nicanfar and V.C.M. Leung, “EIBC: Enhanced Identity-Based Cryptography, aConceptual Design”, in Proc. IEEE SysCon, Vancouver, BC, Mar. 2012332.2. Related Workswill likely employ Internet Protocol version 6 (IPv6) technology in a meshbased topology [28]. Although PLC has gained much attention in Europe,in North America WMN is a more popular and dominant solution for theAMI [27].In [51], a verifier is utilized for key establishment, with the support of aserver as a trusted third party. Each party has an individual password andthe server holds the appropriate verifier. The entities establish temporarysession keys used to construct the final symmetric key in a protocol withfour phases.Contributions: In this chapter we propose a secure and efficient SG Mu-tual Authentication (SGMA) scheme and SG Key Management (SGKM)protocol. SGMA provides efficient mutual authentication between SMs andthe security and authentication server (SAS) in the SG using passwords; itreduces the number of steps in SRP from five to three and the number ofexchanged packets from four to three. SGKM provides an efficient key man-agement protocol for SG communications using PKI as specified by NIST [1];it employs our proposed EIBC scheme to substantially reduce the overheadof key renewals.Security analysis shows that these schemes are capable of preventing var-ious well-known attacks such as Brute-force, Replay, MITM and DoS. Fur-thermore, we reduce the network overhead caused by the control packets forkey management. The improved efficiency results from our key refreshmentprotocol in which the SAS periodically broadcasts a new key generation torefresh the public/private key pairs of all the nodes as well as any requiredmulticast security keys.2.2 Related Works2.2.1 EIBC: Enhanced Identity-Based CryptographyOur proposed EIBC [52] enhances IBC by making the private key refresh-ment more efficient and accommodating distribution and refreshment of anymulticast key needed in the network. The modifications to IBC are describedas follows.One-way/Hash function F (.)The static function F (.) in IBC is made dynamic in EIBC as function Fi(.).Precisely, PKG periodically generates and broadcasts function fi(.) that isapplied to Fi(.) to obtain Fi+1(.), which is the new one-way function of342.2. Related Worksthe system. In this case, all of the public keys and private keys are beingupdated. Each party updates the public key of any other party by applyingfi(.) to the current public key of that party. Also, each party uses fi(.) inthe private key refreshment algorithm that will be explained shortly. Theindex “i” represents the current state (called live in this chapter) of thesystem. {Fi+1(.) = fi+1(Fi(.)) (2.1a)PubKi(ID) = Fi(ID) (2.1b)System secret value sIn IBC, s is the product of a True Random Number Generator (TRNG)managed and kept secret by PKG. In EIBC, s is replaced by two values: sifrom (2.2a) is a non-shared TRNG value kept by PKG, and s˜i is obtainedfrom (2.2b) using a Pseudo Random Number Generator (PRNG) with pa-rameters a, b and modulus q, shared by all entities.si+1 = fi+1(si) (2.2a)s˜i+1 ≡ (a ∗ s˜i + b) mod q (2.2b)s.t. : i, a, b, q ∈ Z & s˜i ∈ Z∗qSeed and end valuesIn EIBC, some of the parameters have a Seed Value (SV) as well as anEnd Value (NV). For instance, PKG has “public key SV” (P˜ ubKiPKG) and“public key NV” (PubKiPKG). Moreover, each entity has a private key SV(P˜ rvKiA) and a private key NV (PrvKiA). PKG produces SVs of the keysvia (2.3a) and via (2.3b), and all entities perform (2.4a) and (2.4b) to obtainthe live NVs:Seed V alues : P˜ ubKiPKG = si.P˘iPKG (2.3a)P˜ rvKiA = si.Fi(IDA) (2.3b)End V alues : PubKiPKG = fi(s˜i).P˜ ubKiPKG (2.4a)PrvKiA = fi(s˜i).P˜ rvKiA (2.4b)352.2. Related WorksKey refreshment periodsIn EIBC, there are different values that need to be updated or refreshedfrom time to time, including fi(.), si, s˜i, and the PRNG parameters “a & b”.EIBC employs three timers for Short, Medium and Long Term Refreshments(STR, MTR and LTR) for the refreshment of these parameters.STR process PKG generates a new function fi+1(.) and makes it publiclyaccessible, along with a VT, which is the start time of moving to a new live(i → i + 1). At the time of VT, each party refreshes s˜i following (2.2b),updates Fi(.) via (2.1a) in order to have refreshed public keys of others.Also, the party refreshes the public key of PKG as per (2.5a) and (2.5b), aswell as its own private key based on (2.5c) and (2.5d), utilizing the updatedvalues of s˜i+1 and Fi+1(.):P˜ ubKi+1PKG = fi+1(P˜ ubKiPKG) (2.5a)PubKi+1PKG = fi+1(s˜i+1).P˜ ubKi+1PKG (2.5b)P˜ rvKi+1A = fi+1(P˜ rKiA) (2.5c)PrvKi+1A = fi+1(s˜i+1).P˜ rvKi+1A (2.5d)MTR process PKG renews the PRNG parameters “a & b” along with therequired VT, and shares them with all the parties to be used starting at VT.LTR process PKG reselects the system non-shared secret values, alongwith the system shared secret values, and updates one-way function Fi(.),in order to refresh all the keys, i.e., public and private keys of all parties.PKG also updates the private key of each party, and informs the party alongwith a VT via the secure channel.Note that the LTR process is similar to the IBC key refreshment process.As it has been analyzed in the [52], EIBC simultaneously improves keymanagement process overhead cost and system security level.Multicast group key supportTo support secure multicasting, EIBC incorporates two mechanisms to man-age the multicast group source/receiver key pair. Each multicast group isidentified by a Multicast Group ID (MID), which is used similar to ID ofan entity, to obtain Source Multicast Key (SMK) of the group via (1.1). At362.2. Related Worksthe same time each group has a Receiver Multicast Key (RMK) managedby SAS and obtained via (2.3b) and (2.4b). Each Multicast Group Source(MGS) entity receives the group’s SMK and RMK, and grants membershipto a Multicast Group Receiver (MGR) entity by sending RMK to the newMGR. So, MGS encrypts the messages by SMK, and a MGR uses RMK todecrypt the messages. In order to authenticate the source of a multicastpacket and because a SMK can be compromised, MGS signs the messagesusing its own entity (original) private key (PrvKiID).Furthermore, EIBC generates m˜i, similar to s˜i, using a Muticast GroupPseudo Random Number Generator with its own setup values “c & d” andinitial value m˜0. Receivers use m˜i to refresh RMK.2.2.2 SG Security Schemes in the LiteratureThe security scheme in [53] is aimed at data transfer via the PLC technologyfor SG communications. In this mechanism, the manufacturer of any device,e.g., meter, modem or aggregator, should obtain a certificate for the devicefrom the SG security server following the PKI approach, and embeds it inthe device. Then, each node/device utilizes its own public/private key pairto construct a shared symmetric key with the next node. In this system,the SG security server is involved in authentications of all the nodes in eachstage of the mechanism, which can be a heavy workload in the SG envi-ronment. Another concern about this proposal is the assumption that allthe manufacturers of the devices are fully trusted parties. Also, the sharedsymmetric key is chosen by one node and transferred to the peer encryptedwith the public key of the peer. Therefore, the proposed mechanism is vul-nerable to attacks, e.g., by malicious nodes that have obtained a certificateillegally, or devices from a rogue manufacturer.The use of symmetric keys for SG security is proposed in [54, 55], theformer based on the D-H algorithm, and the latter based on the ellipticcurve approach of the D-H algorithm; both adds a key verification step tothe pairwise key construction. Use of symmetric keys is vulnerable to MITMattacks, despite the verification phase. Furthermore, using symmetric keysfor communications over the entire SG system is not scalable due to thelarge number of devices and nodes. Consequently, PKI is recommended in[1] to secure SG communications.In order to decrease the cost of key distribution, the proposal in [56] re-quires all packets to be transferred through a server. Each source encryptsits packet with the public key of the server and sends it to the server. Then,the server uses its private key to decrypt the packet, and uses the public372.3. Smart Grid Mutual Authenticationkey of the destination to re-encrypt the packet and sends it to the desti-nation, e.g., a service provider. In an SG, this mechanism causes a veryhigh demand on the server to handle the decryption and re-encryption ofpackets and on the network to route each packet via the server. Thus, thecost of key distribution is lowered at the cost of a highly loaded server andincreased data packet communication load. Furthermore, this method doesnot preserve confidentiality of the packets since all packets are decrypted bythe server, which is not the end receiver. The mechanism presented in [57] isalso vulnerable to the MITM attack, although the authors mentioned thatit is safe against this attack. For instance an authenticated malicious nodecan perform the MITM attack. This scheme requires two hash functions,and needs a third party in the key construction process, in initializing thekey construction as well as the key verification.Using IBC to secure vehicle-to-grid communications over SG is proposedin [58]. The authors mainly focused on the key management, and theyprovide a one-way authentication for authenticating the vehicles to the grid.Using biometrics is proposed in [59] for the authentication of users in SG.The author suggested that their proposal addresses the user privacy issuein SG communications [59], although the need to collect users’ fingerprintinformation can raise overall user privacy concerns.Authors of [60] studied the approaches of having a Unified Key Manage-ment Function (UKMF) and Dedicated Key Management Functions (DKMF)or a hybrid of the two for different applications in SG. They showed that us-ing UKMF is more efficient, and furthermore, they suggested an ExtensibleAuthentication Protocol based mechanism to be used in SG.Our work is built on top of PKI, the preferred method to secure SGcommunications, and provides secure and efficient mechanisms for initialauthentication and key generations and updates.2.3 Smart Grid Mutual Authentication2.3.1 System SetupWe concentrate on data communications over the AMI outside of the HANdomain, which includes an SAS that is charged with supporting the requiredauthentication and key management mechanisms. We also cover the keymanagement for unicast, multicast and broadcast communications that maybe needed to support any application over SG. Our assumptions are asfollows:382.3. Smart Grid Mutual AuthenticationSecurity ServerControllerAggregatorFigure 2.1: Smart Grid Topology for AMI• Nodes are connected in a WMN, with requires unicast technology sup-port for the multi-hop communications.• Each node has a unique ID (most likely an IPv6 address), which maybe manually assigned to the node by a technician at set up time.• Each SM has a unique serial number SN embedded by the manufac-turer, and an initial secret password pw loaded by the installing tech-nician, for authentication purposes. On the other hand, SAS holds theappropriate verifier ver and salt for the SM, in support of the SRPalgorithm.• Each node is initially loaded with the H(.) function, and values “g & p”to be used in the SRP algorithm, which can be loaded by the technicianat set up time, or at manufacturing.• Nodes are all synchronized in time, and the newly installed SM wouldbe able to synchronize itself with others using a suitable synchroniza-tion system, which design is outside of the scope of this chapter.392.3. Smart Grid Mutual Authentication• SAS is responsible for the authentication as well as the key manage-ment mechanisms.The system topology is depicted by Figure 2.1, which is based on [31]. Re-ferring to our discussion in Section I, when a new SM is installed, it mutuallyauthenticates itself with the SAS, and receives its private key from the SASas well.Definition:Let us define system state (i, j):• Dimension i: Represents the index, also referred as live, of systemfunctions fi(.) and Fi(.) as well as random values si and s˜i.• Dimension “j”: Represents index of PRNG set up values “aj & bj”used in (2.2b), which are shown only by “a & b” for simplicity.2.3.2 Mutual Authentication SchemeDepicted by Figure 2.2, our SRP-6a based mutual authentication schemeconsists of following three steps:Step INew SM, sm, selects a random value Rsm and calculates:Gsm = gRsm mod pThen, SM sends Gsm along with its own SNsm and IDsm to the SAS.Step IISAS performs the following steps upon receiving the packet from SM in StepI:• SAS lookups values “ver & salt” associated with SNsm.• SAS computesk = H(N, g), and picks random values Rsas.402.3. Smart Grid Mutual AuthenticationSt ep#IIIIIISM SAS,  =  	 =  ,  	,  =  . = . 	 +  	 =   ,  = ( . ") 	, $ =  % =   ⊕  , , $, '( ,  ,  , ) (*,+) =,, -* , .* , ̃* , )0$1*,2, + , 0+ , 3,%3, 3,)$1 * = * ∗ .* '( ,) = (35, ) *,+ , )$1*) =  ,  	,  =   , 6 =  , 7 = ( − . 9)(:,"9)	, $ =    ⊕  , , $, '( ,  ,  , ?=%)$* = -* ̃* , )$1*,)0$* = -* ̃* , )0$1*,) = (35, 3<, ,, 2, '( , '(=>?)@"ABC) ,, @DEBC:(@"ABC) ), ,%,B ) ,, @DEBC(B ) ),'(, =  . ,  = : 	 		Figure 2.2: Smart Grid Mutual Authentication (SGMA)• SAS calculatesGsas = k.ver + gRsas mod pu = H(Gsm, Gsas)• SAS computesS = (A ∗ veru)RsasK = H(S)and verifier value “M” as:M = H((H(N)⊕H(g)), H(IDsm, SNsm), salt, Gsm, Gsas,K)• Furthermore, SAS computes the private key SV of SM, P˜ rvKiSM , andforms the system parameter set for SM.• Finally, SAS sends values “salt, Gsas & M” along with the encryptedand signed parameters set of the system to SM.412.4. Smart Grid Key Management ProtocolStep IIISM performs the following steps when it receives the packet sent by SAS inStep II:• SM calculates:k = H(N, g)u = H(Gsm, Gsas)• SM computes:x = H(salt, pw)S = (Gsas − k.gx mod p)(Rsm+u.x)• Then, SM calculates K:K = H(S), and then verifies K based on the received M by comparing it with:H((H(N)⊕H(g), H(IDsm, SNsm), salt, Gsm, Gsas,K)• If the verification condition holds, SM is assured that the symmetrickey K shared with the server is valid. So, SM is able to decryptreceived values, as well as is capable of checking the signature.• Finally, SM obtains its own private key and sends an encrypted andsigned acknowledgement to the SAS.Note that by this point, SM and SAS are mutually authenticated to eachother, and SM has received system parameters as well as its own privatekey.2.4 Smart Grid Key Management ProtocolOur proposed SGKM is based on EIBC. Thus far, nodes have the appro-priate private-public keys to be used for unicast and node-to-node securecommunications based on PKI. In this section, we introduce our key re-freshment mechanism as well as solutions for the required multicast andbroadcast keys.422.4. Smart Grid Key Management Protocol2.4.1 Key RefreshmentReferring to the EIBC mechanism presented in Section 2.2.1 and [52], thesystem needs to set the values of three timers STR, MTR and LTR. Valuesof these timers are transferred as parts of the system parameter in Step IIof the authentication process described above.Short term refreshment processAs depicted by Figure 2.3, the system regularly runs this process to movethe system state from (i, j) to (i+ 1, j) based on the value of STR.Figure 2.3: Broadcasting an Encrypted and Signed Packet in STRSAS duties SAS first generates a new function fi+1(.) according to thenew system state “i + 1”. Then, SAS prepares a packet Pti+1STR containingthe fi+1(.) function, Time Stamp (TS) of producing the fi+1(.), Valid Time(V T ) of the current system state dimension i and its new value “i + 1”.Then, SAS applies the original H(.) function to its own live public key toobtain a symmetric key Ki,j via (2.6):Ki,j = H(PubKiSAS) (2.6)Note: We describe more about Ki,j at the end of this section, since we usethis technique to handle the broadcasting key in the broadcast key manage-ment part.Finally, SAS encrypts the Pti+1STR packet utilizing the Ki,j key, and broad-casts it along with the STR control command CSTR. SAS also signs thesevalues with its own live private key in order to provide source authentication.432.4. Smart Grid Key Management ProtocolSMs duties As soon as any of the SMs receives the broadcast informationidentified by CSTR, uses the live public key of SAS to verify the signature. Ifthe signature is valid, SM calculates the symmetric key Ki,j following (2.6)and decrypts the received packet Pti+1STR. Then, SM verifies the receivedsystem state “i + 1” as part of the packet to make sure it is one after thecurrent state. Furthermore, to prevent the replay attack, SM checks that TSis more than the V T received in the previous STR refreshment command.Finally, prior to V T , SM utilizes fi+1(.) to refresh the appropriate keys using(2.5a)-(2.5d) by following the steps in the short period refreshment processof EIBC, and starts using them by V T .Medium term refreshment processThe system runs the medium term refreshment process presented in Fig-ure 2.4 to change the system state from (i, j) to (i, j+ 1) based on the valueof MTR.Figure 2.4: Broadcasting an Encrypted and Signed Packet in MTRSAS duties Referring to EIBC, SAS first generates a new pair of PRNGparameters “aj+1 & bj+1” for the new system state (i, j + 1). Then, SASprepares a packet Ptj+1MTR containing the “aj+1 & bj+1” values, Time StampTS of the packet, Valid Time V T of the new setup values plus the newsystem state “j + 1”. Then, SAS applies the original H(.) function to itsown live public key to obtain a symmetric key Ki,j (2.6). Finally, SASbroadcasts the encrypted packet Ptj+1STR utilizing the Ki,j key, along withthe MTR control command CMTR. SAS also signs this packet with its ownlive private key in order to maintain source authentication.442.4. Smart Grid Key Management ProtocolSMs duties When a SM receives the broadcast information identified byCMTR, it obtains the live public key of SAS to verify the signature. If thesignature is valid, SM calculates the symmetric key Ki,j following (2.6), anddecrypts the received packet Ptj+1MTR. Then, SM makes sure the system state“j + 1” is one after the current one (j), and checks TS to prevent a replayattack. Finally, starting by V T , SM updates its s˜i parameters according to(2.2b).Long term refreshment processBased on the value of LTR, the system runs the long term refreshmentprocess as shown in Figure 2.5 to go from the (i, j) state to the (0, 0) state.SAS needs to regenerates the system parameters as well as the private keyof each node and inform them one by one.Figure 2.5: Unicasting an Encrypted and Signed Packet in LTR2.4.2 Multicast Key MechanismSMK is used by a group source to encrypt the multicast packets. Further-more, RMK is used by all group receivers to decrypt the messages that areencrypted by SMK. Our assumptions are:• The multicast group is source based, and joining is initiated by thereceiver.452.4. Smart Grid Key Management Protocol• Each group is identified by a unique MID.• SAS is in-charge of the multicast group key management.Beside the SMK and RMK keys, each group also has a public/private keypair that is used in the multicast join algorithm. Similarly and by utilizingMID, system manages this key pair based on (2.3a), (2.3b), (2.4a) and (2.4b).For the SMK and RMK keys, we define multicast group state (k & l) ina manner similar to the (i & j) state. Furthermore, “gk(.) & Gk(.)” similarto the “fi(.) & Fi(.)” functions, and finally “mk & m˜k” along with “cl & dl”are similar to the “si & s˜i” and “aj & bj” items in our original system designfor the unicast communication.Gk+1(.) = gk+1(Gk(.)) (2.7a)mk+1 = gk+1(mk) (2.7b)m˜k+1 = cl ∗ m˜k + bl (2.7c)SMKk = Gk(MID) (2.7d)RMKk = (m˜k, (mk ∗Gk(MID)) (2.7e)Establishing a multicast group(i) An MGS that wants to form a multicast group sends a request to SAS.(ii) SAS provides MGS with the group initial parameters set consisting of{MID, m˜0, RMK0 & G0} along with the private key SV of the groupper (2.3b) and (2.4b) based on MID. (iii) MGS picks “c0, d0 & g0(.)” andcompletes the group parameter set for the multicast group (0, 0) state. Oncethe multicast group is established by MGS, MID is made publicly accessibleby the parties that want to join. Note that MGS is in-charge of generatingthe gk(.) function in each state.Joining multicast groupThe join algorithm, as presented in Figure 2.6, consists of the followingsteps:Join request (Step I) The new MGR applies the current system statefunction Fi(.) to MID to obtain the public key via (2.1b). Then, MGRbroadcasts its join request encrypted by the public key of the group, includ-ing its own ID.462.4. Smart Grid Key Management ProtocolMGR MGSSt ep#IIIBroadcastingUnicastingUnicastingIII	 , 	, =, , 	 , 	, , , ,  ., ! . , ", #$ , %$&!'()=, , 	 , 	, ,,  ,  ., ! . , ", #$ , %$)	 , 	,, , "Figure 2.6: Joining a Multicast GroupGrant membership (Step II) Since only MGS has private key of thegroup, only MGS can decrypt the packet and replies with the membershipgrant, which consists of the group parameter set “ m˜k, RMKk, Gk+1, gk+1, cl, dl”,and at the same time, sends the gk+1(.) to the entire (current) group mem-bers to support forward secrecy. For the source authentication purposes,MGS signs this packet with its own private key.Acknowledgement of membership (Step III) Firstly, MGR verifiesthe signature, and then accepts the information and joins the group if it isa valid one. Then, MGR sends an acknowledgement to the source notifyingthe source that MGR has successfully joined the group.Key refreshment processThe reasons for the key refreshments in case of multicasting situation aredifferent than the aforementioned unicast situation and consist of two cases:(i) a member joining or leaving causes the system to refresh the keys inorder to maintain forward and backward secrecy, and (ii) providing overall472.5. Security and Performance Analysismulticast key secrecy. However, we define and use a similar algorithm inboth cases. To be more precise, each multicast group has timers similar tothe unicast case, which are set by the system administrator as per groupestablishment purposes and application requirements. Referring to the uni-cast timer refreshment processes, we only describe relevant points of themulticast timers refreshment.• For multicasting forward and backward secrecy concerning the re-ceivers join/leave situation, we follow the short term refreshment pro-cess.• MGS is in-charge of generating and distributing the new gk+1(.) ina manner similar to the short term key refreshment, and proceedingfrom the (k, l) to (k + 1, l) state.• MGS is in-charge of distributing the m˜k set up values “cl+1 & dl+1”addressing in a manner similar to the medium term key refreshment,moving from the (k, l) state to the (k, l + 1) state.• SAS is in charge of the long term key refreshment process, movingfrom the (k, l) state to the (0, 0) state. SAS provides appropriateparameters including keys to the MGS, and then MGS unicasts themto the members utilizing their unicast public/private pair key.2.4.3 Broadcast Key MechanismReferring to our unicast medium term key refreshment process, we applythe system original H(.) function to the public key of SAS to obtain a sym-metric key. Since the public key of SAS is dynamic and changes periodicallyaccording to the fi(.) function and state of the system, only the parties au-thenticated by the SAS, who receive their key management service from theSAS, have the live public key of SAS.2.5 Security and Performance AnalysisIn this section, we evaluate the security of our proposed SGMA and SGKMmechanisms using the AVISPA security analyzer. Furthermore, we reviewthe adversary models including adversary interests and capabilities to attackthe system. Then, we review the system security against attacks. At theend of this section, we verify the overhead cost reduction of our proposal.482.5. Security and Performance Analysis% OFMC              % Version of 2006/02/13        SUMMARY                SAFE               DETAILS                BOUNDED_NUMBER_OF_SESSIONS     PROTOCOL                              /ubc/ece/home/vl/grads/hasennic/Desktop/avispa-1.1/testsuite/results/SGAS6.if                   GOAL                 as_specified             BACKEND                OFMC               COMMENTS             STATISTICS               parseTime: 0.00s             searchTime: 23.32s            visitedNodes: 0 nodes           depth: 1000000 plies               (a) OFMCSUMMARY                SAFE                               DETAILS                BOUNDED_NUMBER_OF_SESSIONS       TYPED_MODEL                            PROTOCOL                             /ubc/ece/home/vl/grads/hasennic/Desktop/avispa-1.1/testsuite/results/SGAS6.if                    GOAL                 As Specified                             BACKEND                CL-AtSe                              STATISTICS                               Analysed   : 1956 states           Reachable  : 1956 states           Translation: 1.16 seconds          Computation: 7285.36 seconds      (b) ATSEFigure 2.7: AVISPA Results2.5.1 Formal Validation Using Software Tool: AVISPAThe results of the evaluation presented in Figure. 2.7a and 2.7b show thatour proposed mechanism is secure and safe from attacks. To be more precise,the symmetric key that we prepare at the end of our authentication to beused by SAS to send the system parameters to SM is a valid and safe key.The system parameters consists of the PRNG and its setup values “a & b”,as well as the private key SV of SM. Furthermore, SM is capable of findingthe public key of SAS, and sends acknowledgement back to SAS, which issecure as well.2.5.2 Adversary ModelsSince we may have different situations for an adversary, we describe twoscenarios addressing the adversary’s different objectives and initial knowl-edge. In the first scenario, the adversary does not have control on any party;however in the second scenario, the adversary has full control on one of theSMs (i.e., there exists a malicious SM).492.5. Security and Performance AnalysisFirst scenarioObjectives The adversary wants to gain access to the system resources,like SAS or any of the SMs, and wants to be able to decrypt and encryptthe messages. Other possible objectives of the adversary are performing aDoS attack against SAS, or compromising the SAS.Initial capabilities The adversary knows the IDs of all of the parties,as well as initial H(.) function and “g & p” values in SGMA. Also, theadversary knows in detail the design of SGMA, and can make or have avalid serial number.Capabilities during the attack During the attack, the adversary is ableto receive the entire SMs and SAS communications, encrypted and unen-crypted packets. If the adversary is able to steal the private key of anyvictim SM, it will be able to decrypt the encrypted packets sent to the SM,and impersonate the SM in sending packets with forged signatures of theSM. Therefore, the adversary will be able to send incorrect pricing informa-tion to the SM, take control of the smart appliances attached to the SM,modify billing information, etc. The adversary will also be able to mount aDoS attack by sending multiple authentication requests to the SAS.Discussion: An adversary forging an SM’s signature to mount a DoSattack on the SAS by sending multiple authentication requests (Step IIIin Figure 2.2) to SAS. As soon as SAS receives the requests, it checks itsdatabase for the (ver, salt) pair associated with each request. Incorrector missing values of (ver, salt) cause the SAS to drop the request and ig-nore subsequent requests from the SM once a number of requests have beendropped.If the adversary initiates the request with valid ID & SN that have beenstolen from a SM, SAS may find the (ver, salt) values and process the requestby sending the response back to SM, and goes to the next step of SGMA.Since the adversary does not have the appropriate password, s/he is notable to obtain the key and decrypt the packets. However, SAS will leavethe session open. Note that SAS sends a time stamp (TS1) among otherinformation in Step II of SGMA. SAS can close the session if the appropriateacknowledge is not being received within a certain time period (e.g. sessionexpiry time). Furthermore, to prevent DoS attack in Step I, SAS can limitthe number of the authentication requests it process within a given timeframe. So, sending a large number of requests does not harm the SAS.502.5. Security and Performance AnalysisThe adversary may try to perform a replay attack by forwarding a previ-ous acknowledgement from the SM to the server. This solution does not helpthe adversary since the acknowledgement should be encrypted and signedutilizing the valid and appropriate system public and private keys. Also,the acknowledgement consists of the time stamp and ID of SM, which is notthe valid one for the authentication session of the adversary.The next option for the adversary is performing a brute-force attack andobtaining access to the encrypted packets. Normally, brute-force attack istime consuming, based on size of the key that packets are encrypted with.If the attacking time takes more than the session expiry time, the attackwill not cause any issue. In the worst situation, the adversary can move tothe on-line dictionary attack to speed up, or performs an off-line dictionaryattack and find the session key, and finally obtain an expired private keyfor a not valid SM. However, the adversary would gain access to the systemparameters, and if SAS has not run the key refreshment process yet, theadversary can keep going making the system parameters valid and fresh. Insummary, by using any of the aforementioned attacks, the adversary is notable to compromise the server, since the adversary can only communicatewith others, and only if the other parties send information to the maliciousnode, the adversary would be able to decrypt the packets. Furthermore,since SGMA uses a hash function, our authentication provides forward se-crecy, and the adversary is not able to find out the original password.To perform a MITM attack as another option for the adversary, theadversary may receive the first packet generated by a victim SM and changethe value of Gsm. However, the adversary is not able to decrypt the secondpacket coming from the server, because the adversary needs the passwordof the victim to obtain the symmetric key K.The other option is compromising the server by social engineering. Com-promising the server does not give the adversary access to the passwords ofSMs since SAS only keeps the verifier (and salt). However, if SAS recordsand keeps the private keys of the nodes (to be more precise, the private keySVs), the adversary will have private keys of the entire SMs. This attackis costly and unfortunately works in almost most of the situations. If SASonly generates the private keys and does not log them, to some extent thiswill prevent the attack from harming the previous generated keys. However,the adversary will be able to attack the new SMs. The best solution to pre-vent this attack is improving the server security well enough, for instanceby changing the server password more often.512.5. Security and Performance AnalysisSecond scenarioObjectives Similar to the previous scenario, the adversary wants to gainaccess to the system resources, like SAS or any of the SMs. The adver-sary would like to decrypt and encrypt the messages. Other objectives ofthe adversary may include performing a DoS attack against the SAS, orcompromising the server or any of SMs.Initial capabilities Similar to the previous scenario, the adversary knowsthe IDs of all the parties, the system parameter H(.) function and “g & p”values regarding SGMA, as well as the detail design of the SGMA protocol.Furthermore, the adversary has a valid password to start SGMA, and byproceeding with the SGMA protocol, the adversary has a valid private keyand all of the system parameters like Fi(.).Capabilities during the attack During the attack, the adversary isable to receive the entire SMs and SAS communications, encrypting anddecrypting packets. Since the adversary has a valid private key of a SM,the adversary is able to decrypt and encrypt packets to and from the SM.For instance, the adversary can change the HAN commands, price list, ormeter/billing information.Discussion: In this situation, the adversary has full control of a mali-cious SM, in other words the adversary is a valid SM. Therefore, the adver-sary can rerun SGMA to be authenticated, and some-how perform a DoSattack. However, the adversary has only one password, and can resend thesame ID and SN of victim SM to initiate a session, and in the worst casecauses one open session.The previous discussion about analyzing the adversary behaviour is validin this scenario as well. The only differences are having valid system param-eters like PRNG. Generally speaking, being in this scenario does not helpan adversary to improve the chance of a successful attack. For instance, theadversary can run a brute-force attack by having a valid private key andcommunicate with others to obtain their private keys by brute-force. In thiscase, off-line dictionary can work because the adversary has the system pa-rameters, like fi(.) and PRNG, and can find the live private key. However,just by performing one LTR process by SAS, the system can prevent theadversary from continuing the successful attack.522.5. Security and Performance Analysis2.5.3 Other Security CharacteristicsAs per our design, a mutual authentication is performed since SAS needsto know the password verifier, and on the other side, SM needs to knowthe password. Both ends require one of these values to calculate the sessionkey. In terms of attacks resilience, we refer to the discussion in the previoussubsection, about the most well-known attacks such as brute-force, DoS,replay, on-line and off-line dictionary and MITM attack, which cover partsof the attacks resilient summary as presented by Table 2.1. We also refer tothe above section about the social engineering attack that may work partiallyon the server; however, compromising one SM does not help the adversaryto attack the whole system. In Table 2.1 we compare our mechanism withfive of the schemes described in literature review section, which includemechanisms for authentication and/or key construction. Since author of[56] proposed using PKI and aimed at reducing the number of certificates(or issued private keys), the proposed mechanism in [59] suggests usingusers’ biometric parameter (fingerprint) for authentication and presentedresearch in [60] does not have detail design of the authentication and/or keyconstruction, therefore we did not include them in this table.Table 2.1: Summary of Resilience to the AttacksAttack [53] [54] [55] [57] [58] OursSocial engineering 6 6 6 6 6 4 & 6Brute-force 6 4 4 4 6 4Replay 4 4 4 4 4 4DoS 6 6 6 6 6 4MITM 4 6 6 6 4 4On-line dictionary 4 4 6 6 6 4Off-line dictionary 6 4 4 4 6 4Unknown key share 4 4 4 4 4 4Compromised impression 4 4 4 4 & 6 4 4Denning-Sacco 6 4 4 4 6 4Key privacy & insider 4 6 4 4 6 4Ephemeral key compromiseimpersonation6 4 6 6 6 4Unknown key-share attack The second packet of the authenticationscheme presented in Figure 2.2 is encrypted by symmetric key K. Encryp-tion of this packet by SAS shows SAS has the key, and decryption the packetby SM and acknowledging the SAS proves that SM has the key as well.532.5. Security and Performance AnalysisCompromised impression resilience Referring to our analysis at thebeginning of this section, finding the private key of any SM does not helpan intruder to obtain the private key of any other node or SAS.Denning-Sacco attack resilience If an intruder somehow finds a sym-metric key used in the authentication scheme, since the key is the productof a hash function, which is a one-way function, the intruder would notbe able to find the original password or the verifier. Furthermore, findinga private key does not help the adversary to find a symmetric key of theauthentication session.Privacy and insider attack resilience Since our scheme is based onPKI, each private key is known only by the owner (and maybe the server).Other nodes know only the public keys of all the nodes, which in fact isrequired by them to communicate with each other. Even if other nodes inbetween relay the packets, since the packets are encrypted and signed, theycannot have access to the private key of the source or destination nodes.Ephemeral key compromise impersonation Suppose an adversaryperforms an off-line dictionary attack or brute-force or even social engineer-ing attack and obtains the password of a SM. Because the password is onlyone of the values required for the session key construction, the adversarystill is not able to find the session key, or the private key.2.5.4 Performance AnalysisConsider the topology shown by Figure 2.1. Suppose SAS wants to refreshthe keys of all the SMs. Compared to the original PKI, the IBC approachyields a better performance in the overhead cost, as we have discussed inprevious sections. Therefore, we only compare our proposal with an SG thatuses the IBC approach to secure data exchanges.We assume that on average, each SM is connected to “Hsm > 1” neigh-bours (dimension of SM), and the average hop counts between SAS and anySM is equal to Lsas (Length of SAS network). Moreover, we define bwl asthe bandwidth (BW) of each link required per key distribution while the to-tal network BW to refresh all the keys is BWnet. To compare the delay, wedefine dh as the delay/time required by each hop (or link) to deliver/processa packet, and Dnet to be the total system delay/time to refresh all the keys.For simplicity, we assume SAS generates same packet sizes in STR, MTRand LTR. Since the LTR process is similar to the key refreshment process542.5. Security and Performance Analysisin the original IBC, we use it as our bench mark in this study. In order toshow the improvement of SGKM employing EIBC, we assume the followingrelations exists between values of the timers:MTR = ms ∗ STR , ms > 1 (2.8a)LTR = lm ∗MTR , lm > 1 (2.8b)LTR = ls ∗ STR , ls > 1 (2.8c)ls = lm ∗ms (2.8d)The total network required BW and applicable delay by each key re-freshment process are as follow:Dnet(LTR) = dh.(Hsm +Lsas∑v=2v.Hv−1sm ) (2.9a)BWnet(LTR) = bwl.Lsas∑v=1(v.Hsm + v − 1).Hvsm (2.9b)Dnet(STR) = dh.(1 + 2.dh) (2.9c)BWnet(STR) = 2.bwl.Hsm.HLsassm − 1Hsm − 1 (2.9d)In (2.9a)-(2.9d), we assume that in each STR (and MTR) process, 50%of the nodes broadcast concurrently, and in the LTR process, SAS processesHsm SMs at the same time.By a reasonable estimation, we have:FD(Lsas, Hsm) =Dnet(LTR)Dnet(STR)≈∑Lsasv=2 v.Hv−1sm2.Lsas(2.10)FBW (Lsas, Hsm) =BWnet(LTR)BWnet(STR)≈∑Lsasv=1 (v.Hv+1sm )2.HLsassm(2.11)FD in (2.10) represents the relationship between the delays of the keyrefreshment processes, while FBW in (2.10) demonstrates their required net-work bandwidth. Although these two quantities depend on the networktopology, they are always greater than one.Table 2.2 illustrates a few examples of FD and FBM based on Hsm andLsas. As the table shows, the values increase with Hsm and Lsas. Note552.5. Security and Performance AnalysisTable 2.2: FD and FBM Based on Hsm and LsasHsm Lsas FD(Lsas, Hsm) FBM (Lsas, Hsm)3 5 54.6 10.133 10 14024 21.373 20 8.45E+08 43.8753 40 3.00E+08 88.874 5 159.2 12.454 10 1.69E+05 25.784 20 1.50E+11 52.444 40 2.00E+23 105.785 5 371 14.845 10 1.19E+06 30.475 20 1.18E+13 61.725 40 1.13E+27 124.22that STR (and MTR) processes are run more frequently in our mechanismcompared to LTR, whereas in the original IBC (and PKI), the key renewal(similar to LTR) process are run at almost the same rate as STR in ourmechanism. For example if “Hsm = 4” and “Lsas = 40”, the system requiresless than 1% bandwidth to distribute the private keys following SGKM,compared with IBC/PKI. The time required for key distribution is reducedto “5E − 24” of the LTR delay. The data in Table 2.2 along with the aboveexamples clearly shows that the proposed mechanism is much more efficientand greatly reduces the key refreshment delays compared to the original IBCor PKI mechanisms.Overall analysisIn our design, we take advantage of the SRP, PKI and IBC approaches.Each one brings some benefits to our proposed mechanisms. Besides, ourenhancement of each mechanism has improved the overall benefits to thesystem.Firstly, we have reduced the required number of packets in our authen-tication scheme. To be more precise, we reduced the number of packetsneeded for mutual authentication from four to three. Furthermore, in thethree packets, the entire set of system parameters are delivered as well asthe private key of the new SM. Our analysis shows that SGMA is fast androbust and secure.Secondly, implementing the private key cryptography system in a dis-tributed environment causes providing a symmetric key between every twonodes that need to communicate to each other. Moreover, increasing thenumber of nodes that want to communicate with a single node requires that562.5. Security and Performance Analysisthe node keeps and manages a large number of keys (one per peer node),which is the case in the SG context. However, PKI requires only one keypair per entity in spite of a larger key size. In fact, while a node has its ownprivate/public key pair, it is sufficient for the node and others to exchangesecure communications.Also, since IBC reduces the public key distribution overhead in PKI,we take advantage of this technique in our design. Furthermore, we havedesigned EIBC, an improved version of the IBC, and utilized it in SGKM.The most important benefit of using EIBC in this design is reduction of theprivate key distribution and refreshment overhead. In EIBC, most of thekey refreshments are accomplished by the PKG broadcasting a packet to allnodes instead of unicasting one packet to each node, which yields substantialreduction in the system overhead cost. Indeed, broadcasting is used in twoout of three key refreshment processes (STR and MTR), while unicastingis used in the LTR refreshment process, which is run much less frequentlythan the STR and MTR processes.CostIn order to have the above mentioned benefits of our solution:1. the server (PKG) needs to generate a hash function fi(.) periodically2. the entire parties need to be synchronized3. at each point of time and in order to have new public keys of theparties, each entity need to apply the new hash function fi(.) to theprevious hash function Fi(.) to obtain Fi+1(.), and then calculate thenew public keys4. each entity needs to run the PRNG and also using fi(.) to obtain itsown new private keyHowever, considering the benefits of our proposal, the above costs areacceptable, especially for a dense network with so many entities. Also, asper our proposal and role of function fi(.) that is mainly used to obtainFi+1(.) out of Fi(.), this function (fi(.) ) can be in any even simple formatto improve the cost of our proposal.57Chapter 3Password AuthenticatedCluster-Based Group-KeyAgreementSeveral multi-party systems supporting group- and cloud-based applicationshave been proposed, e.g. in the context of SG. An important requirementof these systems is that the devices/parties need to communicate with eachother as members of a group. In this chapter, we present an efficient group-key (GK) management scheme aimed at securing the group communica-tions, for instance, from the utility to appliances and smart meters locatedin different homes. Our scheme is based on the X.1035 PAKE protocol stan-dard, and also follows the cluster-based approach to reduce the costs of theGK construction and maintenance for large groups. Our protocol enablessecure communications utilizing any communication technology. The pro-posed scheme supports forward and backward secrecy, and is more efficientin comparison with other GK mechanisms in the literature.3.1 IntroductionA key motivation of the SG is that ICT technologies can support the use ofdynamic pricing to counteract the inefficiency of engineering and operatinga power grid based on the peak demand of consumers. A price increasein the peak-hours of power demand is one of the tools that providers canuse to encourage consumers to shift their demand to the off-peak hours[61]. Therefore, different applications and ICT systems are emerging tosupport the consumers’ needs to manage their energy demand in a smartway and even in real-time. Also, SG will integrate small power producers,which highlights the need for multi-party communications over the SG [62].Different applications that require multi-party interactions in the SG contextto address a variety of the customer needs have been reviewed in [63].As shown by Figure 3.1, a typical SG links a group of consumers to a583.1. IntroductionTransmission & Distribution Consumers Group Producers Group Smart Grid Figure 3.1: Consumers Group and Producers Group in Different Smart GridDomainsgroup of producers. The power generated by the producers is sent to theSG to be delivered via the transmission and distribution domains of the SGto the customers. The producers need to communicate with each other as agroup, to balance their power generation in order to reach a better ReturnOn Investment (ROI) for their assets. In the customers’ domain, the devicessuch as smart appliances or SMs need to communicate with each other aspart of a group, to balance their demands in order to take advantage ofthe best/lowest price. For instance, the plug-in electric vehicles in differenthomes in a NAN can schedule their charging time to achieve a flat powerdemand.Generally speaking, in order to have the benefits of the smart consump-tion and/or generation, devices/parties are required to communicate witheach other as part of a group, to balance their resources and/or demands.While these group-based applications can be centralized or distributed, dis-tributed ones are more efficient since the parties can locally make decisions.Most of these communications are many-to-many, e.g., in [64] and [33], andwithout any doubt, having a symmetric GK is the best solution to securethe communications.Contribution: In this chapter, we propose the Password AuthenticatedCluster-based Group-Key Agreement (PACGKA) protocols to manage thesecurity of group communications in SG to support multi-party applications.PACGKA extends the PAKE protocol to construct and manage a GK amonga cluster of devices, utilizing a pre-shared password for authentication.593.2. Literature Review3.2 Literature ReviewIn most of the existing solutions for construction of symmetric keys betweentwo or more parties, the D-H protocol [2], or a D-H based protocol is used.Research and proposals on GK construction/management are mainly in twocategories. In the first category, the GK is generated and managed by acentral authority/controller. In the second category, the GK is constructedby participation of all the group members.The first category is mainly motivated by multicast communications,which may have one source or one core node that handles data distributionto all the other nodes. The central controller generates and distributesthe key between the receivers. The main problem in this category is in theefficiency and robustness of the key distribution and refreshment, along withthe handling of membership changes (join and leave). There are differentsolutions in the literature for this category, most of which use the concept ofstructuring and forming the group in a tree topology [65] [66]. Since thesesystems use a central entity for the key management, they are vulnerable toa single point of failure. Although they are efficient in managing the join andleave of nodes/members, mostly the data needs to be partially decrypted byeach node before being forwarded to the downstream nodes.On the other hand, the second category is mainly motivated by many-to-many communications. They try to address the key construction in adistributed fashion by having participations of the entire membership. Theyare based either on the D-H or the BD protocol, with different techniquesadded to improve the key construction from the security and/or efficiencypoints of view.The group PAKE protocol [67] assumes that each user has an individualpassword shared with the server. This design dictates having multiple pass-words saved in a server, which decreases the efficiency of the system. TheBD protocol is extended in [68] to address the failure of the group mem-bers as well as the size of the messages that are transferred between themembers. The proposal assumes having authenticated links between themembers, and constructs the key during two rounds in a ring-based group.The GK construction in [69] is aimed at small groups of entities. It assumesthat each user has a workstation as well as a mobile device. The users meeteach other while they carry their mobile devices. The mobile devices setupan initial shared value that they use in the workstations to communicatewith each other.The protocol presented in [70] is an extension of the existing protocolcalled S-3PAKE, both of which construct the GK assuming the existence603.2. Literature Reviewof a server. The protocol of [70] increases the number of members of thegroup from three to n. In both protocols, the server plays the main roleby receiving messages from all members and then responds to the members.Since the server needs to provide services to the entire membership and isinvolved in all the steps in the interaction, the protocol is vulnerable to thesingle point of failure.By utilizing Exclusion Basis Systems (EBS) and Ciphertext-Policy Attribute-Based Encryption (CP-ABE) techniques in [71], a GK management for largescale systems is proposed. It provides an EBS-Based protocol that supportsforward/backward secrecy relative to the join/leave process, and resilience tocollusion attacks. Instead of using a clustering approach, it uses CP-ABE tohandle large groups, which is more useful for the multicast communications.IBC is used in [72] to design a GK agreement for multicast communi-cations. The design maintains forward secrecy and integrity, and is devel-oped for a dynamic environment. The system requires a group leader withwhom each member communicates to prepare the shared values for the keyconstruction. Although the process consists of two rounds, in each roundcommunication with the leader is required. The protocol proposed in [73]is based on identities and do not require certificates. The protocol startsby each member choosing a random number and sending it to other mem-bers. Then, the results of the second round calculations are broadcast to allthe members. The members are able to compute the GK after the secondround. Similar to many other proposals, this protocol relies on broadcastingdata/messages to others, which may not be robust for large groups.Several IBC-based GK agreement protocols are evaluated in [74]. More-over, a survey on security of group communications is presented in [75]. Abrief survey on cluster-based GK Agreement (GKA) protocols for wirelesssensor networks is presented in [76], differentiated into infrastructure-basedand infrastructure-less networks. The infrastructure-based protocols stud-ied include the Hierarchical Key Agreement Protocol, GKA protocol forCircular Hierarchical Group, Password-Based GKA protocol for Hierarchi-cal Group and AP-1 which is a cluster-based GKA protocol based on theconstant round multi-party dynamic key agreement protocol. The surveyshows that the best performance is delivered in a system with equal clustersize and a small number of layers.The proposal in [77] provides a GK management for the advanced distri-bution automation system of SG, which is based on a three-tier tree struc-ture and decentralized architecture. In [54], firstly a SG gateway constructsa symmetric key with each SM based on a D-H algorithm. Then, the gate-way multiplies the symmetric keys to form a GK, and finally, sends the GK613.2. Literature Reviewusing the symmetric keys to the SMs.The tree concept is used in the key management proposal in [78] to coverunicast, multicast and broadcasting keys for the SG, in which the multicastkey is close to our design. The design is based on a binary tree in whicheach node uses two hash functions to calculate secret values of the treenodes, which requires knowing the entire tree construction. Due to the highresource consumption and overhead cost, it may not be suitable for the SGwith many nodes.Discussion: Generally speaking, the mechanisms that are based onthe BD protocol may suffer from the following weaknesses: (i) Some ofthem rely on a server, which makes them vulnerable to a single point offailure. (ii) Mostly they use broadcasting to distribute the key constructionmessages, which lack robustness as the messages may not be received by allthe members. Even if they include a verification step to address this issue,it makes the algorithm time consuming and increases the system overhead.The problem is worsened in a large group with a long distance betweennodes, or if the Internet is used for the communications.Thus, to overcome the aforementioned issues, especially the second (ii)problem, we propose to unicast the messages in the PACGKA protocol pre-sented in this chapter, which is based on the PAKE protocol in the X.1035standard. As we will show in Section 3.5, an approach based on the BDprotocol would be less efficient as it requires a larger number of messages inthe protocol operation.pw1IDiIDFigure 3.2: Single Cluster (Ring-Based) Structure623.3. PACGKA-I Protocol for Single Cluster3.3 PACGKA-I Protocol for Single ClusterThe PACGKA protocol for a single cluster (PACGKA-I) is presented inAlgorithm 1 for constructing and verifying a shared value, and calculatingthe GK. The mechanism constructs the shared value in two rounds involving2×n− 1 messages. PACGKA-I consists of the protocol for forming the GKand the auxiliary protocol for key maintenance. As shown in Figure 3.2, weassume the members’ IDs form a cyclic group.To describe the protocol based on Figure 3.2, consider a group with fourparties ID1, ID2, ID3 & ID4, which are preloaded with the g, p & H(.)parameters. They also receive a shared password pw from the system alongwith the required system parameters such as number of entities (n = 4) inthe group (ring/cluster) plus IDs of the neighbours (prior & next). The pro-tocol use a message vector M that has (n−1) fields (three in this example).3.3.1 Group Key ConstructionFirst roundWe run the protocol starting from ID1.Note: For encryption of the message vector M , the parties simply multiplyeach field of the M to the forward session key Pk+. Thus for decryption,the parties only need to divide the fields of the received vector M to thebackward session key Pk−.ID1: First, ID1 generates random value r1, computes initial value and loadsthe M.[1] to begin with. Then, ID1 calculates the backward and forwardsession keys with ID4 and ID2, which are given by P1− and P1+, encryptsM with P1+, and sends it to ID2.r1 = Rand(.) , M.[1] ≡ gr1 mod pP1− = H(ID4|pw|ID1)P1+ = H(ID1|pw|ID2)ID2: ID2 generates random value r2 and also computes the backward andforward session keys P2− and P2+. Then, ID2 receives M and decrypts itwith P2−. Note that P2− = H(ID1|pw|ID2) = P1+. Then, ID2 updates M633.3. PACGKA-I Protocol for Single ClusterAlgorithm 1 PACGKA-I: Group-key Formation for a Single-cluster GroupDefine:n : Total number of members, where “n+ 1 ≡ 1” and “−1 ≡ n”.g & p : D-H algorithm parameters.H(.) & pw : Shared Hash function, & shared password.M : An n− 1 element message vector; M.[k] is kth field of the M .IDk : ID of the kth party.Rand(.) : Random number generator function.rk & SVk : Random value and final shared value of IDk.Pk+ & Pk− : Forward & backward session keys of the kth party.EK(X) & DK(X) : Encryption & decryption of X with the K key.Vi− & Vi+ : Verifier for the previous and next parties.FS(.) & FR(.) : Background functions to send and receive messages.Algorithm:First round: ID1 to IDn−1r1 ← Rand(.)M.[1]← gr1 mod pP1− = H(IDn|pw|ID1)P1+ = H(ID1|pw|ID2)MyEncM ← EP1+ (M)FS(MyEncM → ID2)for i = 2→ n− 1 dori ← Rand(.)Pi− = H(IDi−1|pw|IDi)Pi+ = H(IDi|pw|IDi+1)FR(MyEncM ← IDi−1)M ← DPi− (MyEncM)for j = i→ 2 doM.[j]←M.[j − 1]ri mod pend forM.[1]← gri mod pMySnd← EPi+ (M)FS(MySnd→ IDi+1)end forSecond round: IDn and ID1 to IDn−1FR(MyEncM ← IDn−1)M ← DPn− (MyEncM)SVn ←M.[n− 1]rn mod pfor j = n− 1→ 1 doM.[j]←M.[j − 1]rn mod pend forVn+ ← H(pw|M.[n− 1]|SVn) {Verifier for the next party}MyEncM ← EPn+ (M) {n+ 1 ≡ 1}FS((MyEncM, Vn+)→ ID1)for i = 1→ n− 1 doFR((MyEncM, Vi−)← IDi−1)M ← DPi− (MyEncM)SVi ←M.[n− 1]ri mod pif Vi− == H(pw|M.[n− 1]|SVi) thenGKi ← H(pw|SVi)elsereturn Error : V erification failedend iffor j = n− 1→ i+ 1 doM.[j]←M.[j − 1]ri mod pend forVi+ ← H(pw|M.[n− 1]|SVi)MyEncM ← EPi+ (M)FS((MyEncM, Vi+)→ IDi+1)end for643.3. PACGKA-I Protocol for Single Clusterand finally, encrypts it with P2+ and sends it to ID3.r2 = Rand(.)P2− = H(ID1|pw|ID2)P2+ = H(ID2|pw|ID3)M.[2] ≡M.[1]r2 mod p ≡ gr2r1 mod pM.[1] ≡ gr2 mod pID3: Similarly, ID3 generates random value r3 and also computes the back-ward and forward session keys P3− and P3+. Then, ID3 receives M anddecrypts it with P3−. Then, ID3 updates the vector M and finally encryptsit with the forward key P3+ and sends it to ID4.r3 = Rand(.)P3− = H(ID2|pw|ID3)P3+ = H(ID3|pw|ID4)M.[3] ≡M.[2]r3 mod p ≡ gr3r2r1 mod pM.[2] ≡M.[1]r3 mod p ≡ gr3r2 mod pM.[1] ≡ gr3 mod pSecond roundThis round starts with ID4.ID4: Similar to ID3, firstly ID4 generates random value r4 and computesthe backward and forward session keys P4− and P4+. Then, ID4 receivesM and decrypts it with P4−. ID4 (last member of the cyclic group) now isable to calculate its shared value SV4. Then, ID4 updates M and computesthe GK as well as a verifier for the next party (ID1). Finally, ID4 encryptsM with P4+ and sends it along with the verifier to ID1.r4 = Rand(.)P4− = H(ID3|pw|ID4)P4+ = H(ID4|pw|ID1)SV4 ≡M.[3]r4 mod p ≡ gr4r3r2r1 mod p (3.1)M.[3] ≡M.[2]r4 mod p ≡ gr4r3r2 mod pM.[2] ≡M.[1]r4 mod p ≡ gr4r3 mod pM.[1] ≡ gr4 mod pV4+ = H(pw|M.[3]|SV4)GK4 ← H(pw|SV4) (3.2)653.3. PACGKA-I Protocol for Single ClusterID1: First of all, ID1 receives M and decrypts it with P1−. Then, ID1calculates its shared value (SV1 = SV4) and then verify it versus the receivedverifier V F1− (= V F4+) from ID4. Assuming the verification holds positive,ID1 is assured that its shared value is the same as the one that ID4 has.Then, ID1 updates M and also calculates a verifier V F1+ for the next party.ID1 finally encrypts M with P1+ and sends it along with the verifier to ID2.SV1 ≡M.[3]r1 mod p ≡ gr4r3r2r1 mod p (3.3)V1−?⇐==⇒ H(pw|M.[3]|SV1)M.[3] ≡M.[2]r1 mod p ≡ gr4r3r1 mod pM.[2] ≡M.[1]r1 mod p ≡ gr4r1 mod pV1+ = H(pw|M.[3]|SV1)GK1 ← H(pw|SV1) (3.4)ID2: Similarly, ID2 receives M and decrypts it with backward session keyP2−. Then, ID2 calculates its shared value (SV2 = SV1) and then verifiesit versus the received verifier V F2− (= V F1+) from ID1. If the verificationholds positive, ID2 is assured that its shared value is the same as the onethat ID1 has, which is the same as the shared value of ID4. Then, ID2updates M and also calculates a verifier V F2+ for the next party. ID2finally encrypts M with P2+ and sends it along with the verifier to ID3.SV2 ≡M.[3]r2 mod p ≡ gr4r3r2r1 mod p (3.5)V2−?⇐==⇒ H(pw|M.[3]|SV2)M.[3] ≡M.[2]r2 mod p ≡ gr4r2r1 mod pV2+ = H(pw|M.[3]|SV2)GK2 ← H(pw|SV2) (3.6)ID3: ID3 receives M and decrypts it with P3−. Then, ID3 calculates itsshared value and then verifies it versus the received verifier V F3− (= V F2+)from ID2. Assuming the verification holds positive, ID3 is assured that itsshared value is the same as the one that ID2 has, which is the same as theshared value of ID1 and ID4. ID3 is the last party that was supposed tocalculate the shared value. The only step left is verifying it for the ID4.Therefore, ID3 calculates a verifier V F3+ and sends it to ID4.SV3 ≡M.[3]r2 mod p ≡ gr4r3r2r1 mod p (3.7)V3−?⇐==⇒ H(pw|M.[3]|SV3)V3+ = H(pw|M.[3]|SV3)GK3 ← H(pw|SV3) (3.8)663.3. PACGKA-I Protocol for Single ClusterID4: Finally, ID4 only needs to check the verification value. The positiveverification result assures that ID4 has the same shared value that ID3 has.V4−?⇐==⇒ H(pw|M.[3]|SV4)Note: Note that the group members have the same shared value and canbe seen by (3.1), (3.3), (3.5) and (3.7). Therefore, the GKis are the same,which are shown by (3.2), (3.4), (3.6) and (3.8).3.3.2 Key MaintenanceKey refreshmentTo improve and guarantee/increase the secrecy of the GK, PACGKA-I re-freshes the key periodically. In order to do this, we propose setting up atimer to initiate and trigger the refreshment process. Note that the timervalue that determines how often the key is refreshed depends on the appli-cation as well as the size of the group. Therefore, we propose the followingGroup Key Reconstruction (GKR) process for PACGKA-I: the system con-troller distributes a new password along with the start and expiry times tothe entire group members to construct the new GK.Join and leave processIn the case of a new node joining the existing group, or an existing nodeleaving the group, the controller performs GKR to support the forward andbackward secrecies.Malicious behaviour of a nodeIn case one of the group members begins behaving maliciously, the maliciousnode is removed from the group. In PACGKA-I, the system controller relieson both peer neighbours of the malicious node to vote jointly to identifythe misbehaving member. In this case, they directly send a unicast messagevia the secure channel to the system controller. Subsequently, the systemcontroller invokes the GKR algorithm for the group while excluding themalicious one. If a group of nodes decide to behave maliciously, they mostprobably will be able to attack the system; however, it will be a costly attacksince a group of nodes are required.673.4. Cluster-based Mechanism: PACGKA-II Protocol3.4 Cluster-based Mechanism: PACGKA-IIProtocolIn this section, we present an efficient multi-cluster GK management mecha-nism, PACGKA-II, which is based on the single cluster algorithm presentedin Section 3.3. This scheme is motivated by the fact that in the case of a largegroup, the PACGKA-I protocol becomes time consuming as the nodes shouldperform many polynomial and arithmetic operations. Although SG systemsare mostly static with low occurrences of node joining or leaving, securityconsiderations dictate running GKR every so often for key refreshment. Toovercome the latency issue, we propose using a clustering approach.3.4.1 Clustering SchemeWe define our clustering scheme following the presentations in Section 3.2and [76]. Consider a group with N members. We divide the group into nclusters with no more than m members in each cluster, where:N ≤ m× n (3.9)An example of the clustering scheme is depicted by Figure 3.3. Weidentify each cluster by:Clstru , u = 1, ..., npw1upw2upw4upw2uClstr1uClstr33u1u MCHC 3uClstr3ujMC4uClstrFigure 3.3: Multi Cluster Ring-Based Structure683.4. Cluster-based Mechanism: PACGKA-II ProtocolFurthermore, members of the uth cluster are denoted by:MCuk , k = 1, ...,mOne of the cluster members acts as the cluster representative, or clusterhead, and is denoted asHCu for the uth cluster. The cluster heads/representativesform a core ring/sub-group consisting of all the cluster heads, given byC − Clstr.Note that finding the right value for m (or n) is an optimization problemand can be formed based on the criteria that are important for the systemand the application, and we leave this task to the administrator of thesystem. For instance, the problem can be formed to minimize the numberof operations, or the delay of the key formation process, or any other systemparameter or security measures. Indeed, the problem should address theapplication, system, resources and security aspects. After presenting ourprotocol, we will give an example of this problem to find the optimum valuesof n and m.3.4.2 The Logic of the Multi-cluster Group Key MechanismOverall, PACGKA-II follows a similar concept as PACGKA-I. In fact, PACGKA-II can be considered as an extended version of PACGKA-I. The main stepsof the PACGKA-II protocol are as follows:I. Dividing the main group to clusters Clstru.II. Nominating one party per cluster as the cluster head HCu to representthe cluster.III. Forming the core cluster consisting of all the cluster heads. Note thateach cluster head is a member of two sub-groups: the cluster it isrepresenting and the core cluster.IV. The protocol starts by sending a password pw to the core cluster/sub-group.V. Each cluster head picks a password pwu, sends it to its own clustermembers to construct a GK using PACGKA-I within the cluster.Note that, since the cluster head is a member of the cluster it is rep-resenting, at the conclusion of PACGKA-I, it has the GK of the sub-group (sub-GK) SGu. Also, the cluster head has the shared value that693.4. Cluster-based Mechanism: PACGKA-II Protocolthe members of the sub-group used to obtain sub-GK. Let us call thisshared value the “sub-group shared value” Gu.{Gu ≡ g∏mj=1 ruj mod p (3.10)SGu = H(Gu|pwu) (3.11)VI. Using the password received in Step IV, the members of the core clusterrun PACGKA-I to construct the shared value HSVu and GK KGroup,taking the sub-group shared value (from Step V) as the random valueof the cluster head (Gu).{HSVu ≡ g∏ni=1Gi mod p (3.12)KGroup = H(HSVu|pw) (3.13)VII. The cluster head distributes the GK KGroup to the cluster utilizingsub-GK SGu for encrypting the GK.3.4.3 Key MaintenanceAll of the situations that require key maintenance as explained in Section 3.3regarding single cluster GK formation are applicable to the multi-clusterGK formation as well. To handle the key refreshment, we need to rerun thecomplete PACGKA-II protocol. However, for situations such as a memberjoining or leaving, and detection of a malicious node, we propose a differentsolution. If a member joins the group, the new member should join oneof the clusters, so it can be considered as a sub-group event. If one of thecluster members becomes malicious or leaves the cluster, again it can beconsidered as a sub-group event, unless the malicious node, or the node thatis leaving the group is a cluster head, in which case we call it a cluster headevent.Sub-group eventLet us assume that the event occurs inside the uth cluster. In this case, thecluster head HCu reselects a password pwu and shares it with its clustermembers. Then, the cluster members of the Clstru performs PACGKA-I to form sub-GK. Then, the cluster heads perform Steps VI and VII ofPACGKA-II. In fact, the other sub-groups do not need to reconstruct theirsub-GK, and the cluster heads can still use the prior values. Finally, thecluster heads inform their cluster members about the new GK.703.4. Cluster-based Mechanism: PACGKA-II ProtocolCluster head eventIn this case, either a cluster head is malicious or it leaves the group. Firstly,a new cluster head for that cluster needs to be chosen, and secondly, theGK should be constructed by performing PACGKA-II completely.3.4.4 Size of the ClustersAs shown above, PACGKA-II involves running PACGKA-I in two rounds,once around each cluster and then around the core cluster. Here we illustratethe optimization of the size of the clusters with respect to the delay, byformulation the delay expression and then minimizing it. Table 3.1 showsour parameters.Table 3.1: Parameters of the Cluster Size ProblemParameter DescriptionN Total number of the members in the groupm Number of the members per clustern Number of the clusters (sub-groups)dˆ Party processing time including message deliveryDˆ Delay of the GK constructionWe assume equal “party processing time including message delivery”values (dˆ) for each party, and equal size of the clusters. Our problem isminimizing the “delay of the GK construction” (Dˆ), which can be formulatedas follows: {Min Dˆ = dˆ+ dˆ+ (2m− 1)dˆ+ (2n− 1)dˆ+ dˆS.t : m× n ≥ NIn the above problem formulation, each term in the right hand side of thedelay equation respectively represents the delay of:• Distributing password within the core cluster.• Distributing password within each sub-group.• Sub-GK construction.• GK construction within the core cluster.• Distributing the GK inside the clusters.713.5. Security and Performance AnalysisTo solve this problem, we simplify it and rewrite as follows:{Min Dˆ = (2m+ 2n+ 1)dˆS.t : m× n ≥ NDˆ is a convex function, which has a minimum. We solve the problem in theborder of m×n = N , and calculate the first derivative respect to n in orderto find the optimal value:m× n = N → m = NnDˆ = (2n+2Nn+ 1)dˆ∂Dˆ∂n= (2− 2Nn2)dˆ = 0→ m = n =√NTherefore, the best performance of the protocol and the minimum delayhappens when m = n =√N .3.5 Security and Performance AnalysisTo analyze and evaluate the security of the PACGKA protocols, we considerthe Dolev-Yao approach [79].                 % OFMC               % Version of 2006/02/13       SUMMARY                SAFE               DETAILS                BOUNDED_NUMBER_OF_SESSIONS     PROTOCOL              /ubc/ece/./hasennic/Desktop/avispa   -1.1/testsuite/results/SGGK4.if                    GOAL                as_specified            BACKEND                OFMC               COMMENTS              STATISTICS               parseTime: 0.00s           searchTime: 0.06s           visitedNodes: 12 nodes        depth: 11 plies                          (a) OFMCSUMMARY                SAFE                               DETAILS                BOUNDED_NUMBER_OF_SESSIONS       UNTYPED_MODEL                           PROTOCOL              /ubc/ece/./hasennic/Desktop/avispa  1.1/testsuite/results/SGGK4.if                     GOAL                  As Specified                            BACKEND                CL-AtSe                              STATISTICS                                Analysed   : 69 states        Reachable  : 14 states        Translation: 0.02 seconds       Computation: 0.00 seconds     (b) ATSEFigure 3.4: AVISPA Results723.5. Security and Performance Analysis3.5.1 Formal Validation using Software ToolWe develop our analysis for a group consisting of four members, correspond-ing to the example in Section 3.3. The simulation results presented by Fig-ure 3.4a and Figure 3.4b show that the GK constructed by the PACGKAmechanism is secure and safe to be used by the members of the group.Although the system controller has provided the shared password, it doesnot have access to the GK. We assume this entity is trusted and does notperform any attacks like MITM.3.5.2 Adversary ModelObjective• Gaining access to the system resources, like a SM or an appliance.• Performing a MITM attack to gain access to the GK, or a sub-GK.Initial capabilities• The adversary has complete knowledge about the topology and theexact address/ID of each party.• The adversary has access to the system hash function H(.) and g & pused in our protocol.• The adversary knows the detail design of the PACGKA mechanism(PACGKA-I and PACGKA-II protocols).Capabilities during the attack• The adversary receives the entire encrypted and unencrypted (plain)data in different stages of the key formation, or later on and duringthe using of the GK.• If the adversary gains access to any password (core cluster, or any othersub-group cluster), she/he will attempt to perform a MITM attack.• If the adversary gains control to a malicious node, she/he can performDoS by joining and leaving continuously.733.5. Security and Performance AnalysisDiscussionWe assume cluster heads and cluster members receive the appropriate pass-word via a secure channel. Therefore, if the adversary finds out the passwordof a cluster after completion of the initial sub-GK formation (PACGKA-Iprotocol), the adversary cannot gain any further information since the pass-word is not being used any more. Similarly, if the adversary by performingany attack like brute-force or off-line dictionary obtains the shared passwordof the core cluster after the GK construction, this information is useless forthe adversary since the key is formed and the password is like a one-timepassword. Thus there is resilience against Ephemeral key compromise im-personation. However, if the adversary finds/steals the password before thekey formation process starts in any level such as in a cluster (PACGKA-I& PACGKA-II) or in the core cluster (PACGKA-II), she/he can take ad-vantage of this password by performing a MITM attack. As long as theGK is valid without any changes, the adversary can use it. However, theGKR process changes the key completely. Thus, key refreshment by GKRperiodically should be considered as a requirement for the system.Moreover, our adversary can compromise the server by for instance socialengineering attack. Consequently, the adversary can send the new passwordto the cluster head and dictates them to re-construct the GK. Although weimproved the process of the key formation by using the clustering approach,it can harm the system resources. On the other hand, the adversary can par-ticipate in the key formation and gain access to the GK easily. Performingsocial engineering attack against the server is possible in any system andenvironment. The only solution to prevent this attack is having a strongsystem security management procedure. Generally speaking, although tech-nically feasible, the social engineering attack should be a very expensiveattack. Therefore, the best solution is increasing the cost of the attack, inorder to make it unattractive for the adversary.3.5.3 Attack AnalysisBased on aforementioned discussion about the adversary, plus the PACGKAassumptions in Section 3.3 (i.e., parties are already authenticated to thesystem and have valid security system and key management to be able tohave a secure communication), Table 3.2 analyzes the resilience of PACGKAagainst different well-known attacks.743.5. Security and Performance AnalysisUnknown key-share attack In our proposed mechanism, all of the par-ties should participate in the key formation and the verification steps. In-deed, the key is formed in a consensus manner with commitments of theentire membership. Thus, our protocol guarantees that if one of the mem-bers has the key, its neighbours have it as well.Denning-Sacco attack resilience Due to using hash functions in thefinal key calculation steps in the sub-GK or in the final step of the GK (andverification steps), finding a sub-GK or a GK does not help adversary togain access to the cluster or cluster head initial passwords.Table 3.2: PACGKA Attacks Resilience SummaryAttack ResilienceSocial engineering attack 4 & 6Brute-force attack 4Replay attack 4DoS attack 4MITM attack 4On-line dictionary attack 4Off-line dictionary attack 4Unknown key share attack 4Denning-Sacco attack 4Ephemeral key compromise impersonation 43.5.4 Overhead AnalysisFollowing our discussions in Section 3.2, in a BD-based mechanism, the mes-sages are supposed to be distributed to the entire membership. The originalconcept is to broadcast the messages to the group members, although it maynot be possible in all cases. One may consider broadcasting the message inthe overlay layer; however, in the lower layer the messages are transferredby unicast communications. Moreover, it may be possible to broadcast themessages only to a small group within a short distance. Thus, making surethat the messages reach the destinations can cause extra overheads. Missingany message by any member causes failure on the algorithm.Let us assume that we have a group with n members, all in one cluster.We assume the following scenarios:1. BD protocol based model: The messages of each member in the firstround should be delivered to two members (2 × n messages), and inthe second round, to all the members (n × (n − 1) messages), whichtotally is n× (n+ 1) messages.753.5. Security and Performance Analysis2. PACGKA: We require 2× n− 1 message delivery (including the veri-fication).Regardless of the n value, the second scenario has a smaller number ofmessage deliveries. If we increase the n value to a high value, the secondscenario requires about 2/n times the number of message deliveries in thefirst scenario.3.5.5 Implementation ConsiderationsAny application that requires a GK can use the PACGKA protocol. Sincewe use the clustering, the method is scalable and can be easily imple-mented based on different system specifications. Same as any other se-curity system, the strength of the key required to achieve certain the se-curity/confidentiality level depends on its size. We do not specify the keysize or the time period of the key refreshment process, and leave them to bedefined by the system administrator. Furthermore, while we propose thata group can be divided to the clusters, the number of clusters and size ofeach cluster are also parameters to be determined by the system adminis-trator. For instance, the administrator may define each NAN as a cluster,and choose the NAN controller to act as the cluster head. Indeed, these setup values are driven by the application and system conditions. The detailanalysis of the application and system resources helps the administrator ofthe system to identify the key size, as well as the size of the g & p parametersused in the PACGKA key construction mechanism.CostIn our proposal, leaving a non-head cluster entity from a cluster has a lowcost, since only the shared value of that cluster needs to be recalculated.However, if a cluster head leaves, the entire algorithm needs to be rerun,and a new group key should be calculated. Even if we don’t cluster theentities, and mostly in a group key mechanism that the group key is beingcalculated by participation and coordination of the entities, a similar thingsneeds to be done. Moreover, if we use the central model, in which an entityacts as group head to generate the group key, the group head needs toregenerate the group key and share it with the remaining of the entities.Furthermore, the other cost of our proposal is calculating the size of theclusters, as well as forming the clusters. Therefore, entities need to knowwhere they are standing, and what are the previous and next entities. In763.5. Security and Performance Analysisaddition, each entity needs to know for how long needs to wait for the nextvalue to be received.Considering the benefits of our proposal, which are described in abovementioned sub-sections, the costs of using the mechanism worth it, sincein any other group key mechanism, especially if the forward and backwardsecrecies need to be maintained, a similar cost in applied.77Chapter 4Multilayer ConsensusECC-Based PasswordAuthenticated Key-ExchangeProtocolThis chapter aims at providing a key agreement protocol for SG to copewith access control of appliances/devices located inside a HAN by a setof controllers outside the HAN. The commands/packets initiated by thecontrollers in crisis cases should be delivered fast and immune from any in-terruption. The HAN controller, which acts as a gateway, should not causeany delay by decrypting and re-encrypting the packets, nor should it hasany chance to modify them. Considering the required level of security andquality of service, we design our protocol with an ECC approach. We im-prove and implement the PAKE protocol in two steps. First, we propose anauxiliary mechanism that is an ECC version of PAKE, and then extend itto a multilayer consensus model. We reduce the number of hash functionsto one, and utilize a primitive password shared between an appliance andHAN controller to construct four valid individual consensus and authenti-cated symmetric keys between the appliance and upstream controllers byexchanging only 12 packets.4.1 IntroductionOur proposal is a key agreement protocol for secured access control in a hier-archical architecture for the SG communication infrastructure with differentlayers between smart appliances in users’ premises and upstream controllersof the HANs, BANs, NANs and SG Central Controllers (SGCC), which arelocated in distribution networks or substations [80]. Typically, the HANcontroller is a SM that serves as the gateway to the user’s premise. Sucha protocol provides a secured means for controllers upstream of the HAN784.1. IntroductionFigure 4.1: Required Symmetric Keyscontrollers to access and control the smart appliances in users’ premises,e.g., to modify the thermostat setting of the homes heating, ventilation andair condition (HVAC) systems when a brown-out is impending. This studyis independent of the technologies used for the SG communications; i.e., ourwork is equally applicable whether PLC or wireless technologies are used inany of the layers.Various existing controlling commands that may be sent to a smart ap-pliance from outside the HAN have been considered in [81]. For instance, aNAN controller (located outside a HAN) may supervise electric charging ofa plug-in electric vehicle (PEV) located inside the HAN. Also, in the caseof a disaster or an emergency, SGCC may need to remotely turn off low-priority high-demand appliances. In such operations, the HAN controllersshould not interfere with and delay such commands by decrypting and re-encrypting the corresponding packets. Therefore, we need to address theappropriate secrecy level in the SG control system design while providingthe quality of service (QoS) required in terms of keeping the command-response delay within an acceptable limit.Contributions: In this chapter, we present two protocols. The first oneis an auxiliary model of an ECC based PAKE protocol (EPAK protocol) thatcan be used in any environment and application. The second one, which794.2. Literature Reviewis our main work, is a Multilayer Consensus EPAK (MCEPAK) protocoldeveloped for communications in the SG control system.The scope of the work is shown in Figure 4.1, which addresses communi-cations in up to four layers between a home appliance AN , HAN controllerHC , BAN controller BC , NAN controller NC and SGCC CC . We considerthe SG controllers with the hierarchical architecture share common secretsand are designed to be trust-worthy to each other. Precisely, we assume thatcontrollers have a pre-established trust relationship; i.e., they are already au-thenticated to the upstream and downstream controllers if any, and are ableto communicate with the neighbours in a secure fashion. When a smart ap-pliance joins a HAN, it also needs to share a common secret (assumed to bea simple password) with the HAN controller for it to be trusted in the HAN.The question is how to extend this trust to multiple controllers in a secureand efficient manner. Moreover, our proposal addresses the requirementthat each controller needs to set up a secure and private communicationchannel with AN , with any controllers in between simply acting as a partof the communication connection without participating in the security op-erations. Based on assumption of sharing a primitive password by AN andHC , we derive four individual consensus password-authenticated symmetrickeys between AN and the upstream controllers.4.2 Literature ReviewIn [82], a light-weight and robust PAKE for smart card (SC) is presented,which identifies and delivers an entity-server mutual authentication. Thescheme supports only one SC per device and requires SC management. Fur-thermore, each SC is only utilized for two-party authentication, which limitsits usefulness in SG. In [83], a three steps PAKE protocol is presented toresist dictionary, password compromise impersonation and ephemeral keycompromise impersonation attacks, and to supply forward secrecy. Themechanism presented in [84] reduces the number of required hash functionswhile changing the parameters accordingly, which is a concept that we usein our design.The ECKE-1 protocol [7] improves on the previous proposals in theconstruction of a mutual authenticated shared symmetric key between twoparties, utilizing EC techniques. The ECKE-1 mechanism uses three pointmultiplications and two field multiplications along with twice applicationsof a hash function. Author of [8] provided a password based remote au-thentication scheme for SC based on ECDH. The model aims at providing804.3. EPAK: ECC-Based Password Authenticated Key-exchange Protocola lightweight solution for devices with limited resources, which eliminatedneeds to keep the password table in server side in order to reduce the sideeffect of compromising the server. Also, the mechanism presented in [9]concentrated on two-party key designed for sensor networks that containlow-resource devices with a heterogeneous large-scale deployment, based onEC and key management based on AVL tree. The next two-party ECDHbased mechanism is ECKE-1N presented in [10], which improves ECKE-1 byconstructing the key via 2.5 point multiplications, one field multiplicationand twice hash function applications. Later on, EECKE-1N [11] further im-proves ECKE-1N by constructing the key via only one point multiplicationand one field multiplication to construct the two-party key.Although the above mechanisms are designed efficiently and follow ECDH,mostly they use a predefined private and public key, which requires the sup-port of certificates issued by a certificate authority. In this work, we designan ECC-based model of the PAKE protocol (as in X.1035 standard) calledEPAK, which uses only a predefined password and delivers an improvementon ECKE-1N and EECKE-1N mechanisms. We utilize EPAK as our auxil-iary protocol for our main MCEPAK protocol.4.3 EPAK: ECC-Based Password AuthenticatedKey-exchange ProtocolIn this section, we present the EPAK protocol, which is designed as an ECCversion of the PAKE protocol presented in the X.1035 standard.Table 4.1: EPAK ParametersParameter Descriptiona and b Two field elements that define the equation of EC.p The field size.G An ECC point that generates the subgroup of order n.n The order of the point G.h The order of EC divided by n.xW and yW Two elements of the finite field of size p (in the range of [0, p− 1]),which are the x and y coordinators of point W .dW Private key of party W , which are integers in range [2, n− 1].QW Public key of party W .SW and TW Verifiers generated by party W .U = Eke (V ) U is encryption of V using key ke.V = Dkd (U) V is decryption of U using key kd.814.3. EPAK: ECC-Based Password Authenticated Key-exchange ProtocolLet us consider key agreement between Alice and Bob utilizing a pre-shared password pw. Similar to the X.1035 standard, we define P =(IDA|IDB|pw). Furthermore, we assume that both parties have knowledgeof the EC parameters set {a, b, p,G, n, h} and hash function H˜. Table 4.1presents the list of parameters and their definitions used in our design.4.3.1 Description of EPAK ProtocolShown by Figure 4.2, the EPAK protocol has the following steps:Step IAlice Let us assume that Alice is the initiator. She picks a random numberdA ∈ [2, n− 1] (as her private key) and multiply it to the group generator Gto obtain her public key QA via (4.1) and an appropriate EC point (xa, ya)via (4.2). Finally, she computes H˜(P ) to obtain a symmetric key with whichAlice Bob = . 		 ,  =  = () St ep#IIIIV ,  = () 	,  =  = .  = .  . 		,  =  =  |||: ?="III = () 	 ,  =  =  . 		,  =  = .  = . . 		,  =  =  ||| = () " =  |	|	|	" =  |	|	|	: "?="# =  	 	 	|||| # =  	 	 	||||Figure 4.2: ECC-Based PAKE (EPAK) Protocol824.3. EPAK: ECC-Based Password Authenticated Key-exchange Protocolshe encrypts QA as X via (4.3) and sends it to Bob.QA = dA.G (4.1)(xa, ya) = QA (4.2)X = EH˜(P )(QA) (4.3)Bob Upon receiving packet X from Alice, Bob uses H˜(P ) to decrypt Xand obtain QA following (4.4), and the appropriate EC point (xa, ya) alignedwith the QA value shown by (4.2).QA = DH˜(P )(X) (4.4)Step IIBob Bob picks a random number dB ∈ [2, n− 1] (as his private key) andmultiplies it to the group generator G to obtain his public key QB via (4.5).He also calculates the appropriate EC point (xb, yb) aligned with the QBvalue based upon (4.6):QB = dB.G (4.5)(xb, yb) = QB (4.6)Then, he multiplies his private key to the Alice’s public key to obtain sharedvalue QAB through (4.7), and finds appropriate EC points (xab, yab) asper (4.8). Then, he computes SB for the verification of having the val-ues QA, QB & QAB through (4.9), and finally, uses H˜(P ) to encrypt QBvia (4.10), and sends it to Alice.QAB = dB.QA = dB.dA.G (4.7)(xab, yab) = QAB (4.8)SB = H˜(P |ya|yb|yab) (4.9)Y = EH˜(P )(QB) (4.10)Alice Alice uses H˜(P ) to decrypt Y and obtains QB through (4.11),and also computes the appropriate EC point (xb, yb) aligned with the QBgiven by (4.6). Then, she multiplies her private key to Bob’s public key(QB) to obtain shared value QAB via (4.12), followed by (xab, yab) givenby (4.8). Finally, she computes SA for verification of having the values of834.3. EPAK: ECC-Based Password Authenticated Key-exchange ProtocolQA, QB & QAB through (4.13). If the verification holds, she can be surethat Bob has the required values.QB = DH˜(P )(Y ) (4.11)QAB = dA.QB = dA.dB.G (4.12)SA = H˜(P |ya|yb|yab) (4.13)Step IIIAlice Alice needs to make Bob assure that she has the values as well.Therefore, she performs (4.14) to calculate TA out of QA, QB & QAB, andsends it to Bob.TA = H˜(P |xa|xb|xab) (4.14)Bob On the other side, Bob calculates TB via (4.15) and compares it withTA. If the verification holds, Bob is assured that Alice has the requiredvalues as well.TB = H˜(P |xa|xb|xab) (4.15)Step IVSo far, both parties have the required parameters and have verified eachother. Finally, they perform (4.16) to calculate the shared symmetric key.KAB = H˜(xa|xb|xab|P |ya|yb|yab) (4.16)4.3.2 A few Comments About the EPAK ProtocolIn the first verification initiated by Bob (SB & SA), we use only x coordinates(and P ). Furthermore, in the second verification initiated by Alice (TA &TB), only y coordinates are used (and P ). However, in the final step andfor calculating the symmetric key K, we have a combination of all valuesconsisting of x and y coordinates as well as the initial password and identitiesof the parties (as part of the P ).Thus far, we have defined neither the mechanism of U = EH˜(P )(V ) norV = DH˜(P )(U) in the aforementioned design. Since V is a point in the formof (xv, yv), for instance to encrypt this pair, we can multiply each coordinateby H˜(P ):CT :{xu = H˜(P ).xvyu = H˜(P ).yv844.3. EPAK: ECC-Based Password Authenticated Key-exchange ProtocolConsequently, on the other side we need to divide them by the H˜(P ) andobtain the original values:PT :xv =xuH˜(P )=H˜(P ).xvH˜(P )= xvyv =yuH˜(P )=H˜(P ).yvH˜(P )= yv4.3.3 Brief Analysis of the EPAK ProtocolComparing to the previous models, we eliminate the fixed initial privatekey. To be more precise, each party chooses a random number to be theprivate key per session. Also, our mechanism constructs the key only viaone multiplication given by (4.7)/(4.12), and one hash function for the keyin (4.16). In fact, other times that hash function is utilized are for verifi-cation purposes; this is an add-on to the ECKE-1N and EECKE-1N proto-cols. Furthermore, other multiplications in (4.10) and (4.11) are for encryp-tion, whereas exchanged packets are not encrypted at all in ECKE-1N andEECKE-1N.    ↔  ↔  ↔  ↔ 111122223333456791011124455667889Iteration I:Iteration II:Iteration III:Iteration IV:Figure 4.3: Four Keys Construction Based on PAKE or EPAK854.4. Multilayer Consensus ECC-Based Password Authenticated Key-exchange Protocol4.4 Multilayer Consensus ECC-Based PasswordAuthenticated Key-exchange ProtocolReferring to our previous discussion, our objective is a mutual password-based authenticated key agreement between an appliance AN and the con-trollers HC , BC , NC and CC , resulting in an individual key between theappliance and each one of the upper layer controllers. Based on Figure 4.1,we need four symmetric keys. Our model based on PAKE protocol pre-sented in X.1035 standard (or EPAK in Section 4.3) is shown in Figure 4.3.In this abstract model and for each key, we need to have a predefined sharedpassword between the two involved parties (appliance and one of the con-trollers). We will show that our approach decreases the number of packetsand improves the security of the design. In this section, we extend our EPAKprotocol in order to address the SG requirements, based on the EPAK pro-tocol, using the same notations as presented in the previous sections. Theappliance AN knows at least the ID of the HAN and can obtain ID of theHC . Also via our four-phase mechanism, AN gains access to information ofthe other controllers. We assume:• AN and HC share a predefined secret password pw.• The ECC parameter set {a, b, p,G, n, h} and H˜(.) are known andshared by all parties.• Controllers HC , BC , NC & CC have already been authenticated tothe upstream and downstream controllers, if any, and can have securecommunications with them.• Controllers are trusted parties that form parts of and are controlledby the grid domain; the appliance belongs to the customer domain,and is controlled by the customer.• The following symmetric keys already exist:– khb: Shared between HC and BC .– kbn: Shared between BC and NC .– knc: Shared between NC and CC .Note: Although the secure channels that we assume to already exist be-tween the controllers may not be certain, we need to trust it, otherwise“we would be unable to ever get any work done” [85]. Furthermore, the864.4. Multilayer Consensus ECC-Based Password Authenticated Key-exchange Protocoltrust assumption is especially feasible in the multilayer architecture of SGcontrollers [80] considered in this chapter.Furthermore, we introduce a new vector V̂ (entities identifications set),which carries the IDs of the entities involved in our protocol as a part of theinformation exchanged between them. Our four-phase MCEPAK protocoldepicted in Figure 4.4 consists of the following steps.   						 , , , , , , 115678910124321Figure 4.4: MCEPAK Protocol Phases and PacketsPhase I: Initial FlowIn MCEPAK, AN initiates the keys establishment process:First packetFirstly, AN follows (4.17) to utilize the initial password pw shared by HCto calculate temporary key ktah.ktah = H˜(IDA|pw|IDH) (4.17)AN also picks a random number dA ∈ [2, n − 1], then computes QAH via(4.18) and appropriate coordinates (xa, ya) given by (4.19).QAH = dA.G (4.18)(xa, ya) = QAH (4.19)874.4. Multilayer Consensus ECC-Based Password Authenticated Key-exchange ProtocolThen, AN puts its own ID in field A of V̂ given by (4.20). Finally, AN formspacket PAH by QAH and V̂ all encrypted by the ktah key as per (4.21), andthen sends the packet to HC .V̂ .[A]← IDA (4.20)PAH = Ektah(QAH , V̂ ) (4.21)Second packetFirst, HC calculates temporary key ktah by performing (4.17), and decryptsreceived packet from AN by way of (4.22) to obtain QAH and V̂ .(QAH , V̂ ) = Dktah(PAH) (4.22)Then, HC picks a random number dH ∈ [2, n−1] and computesQHB through(4.23).QHB = (QAH).dH = (dA.G).dH = dA.dH .G (4.23)(xhb, yhb) = QHB (4.24)Then, HC puts its own ID into field H of V̂ by way of (4.25), and alsocomputes pwb via (4.26).V̂ .[H]← IDH (4.25)pwb = H˜(ktah|IDB) (4.26)Finally, HC dispatches V̂ along with QHB and pwb to BC , all encryptedwith the khb shared key following (4.27).PHB = Ekhb(QHB, V̂ , pwa) (4.27)Third packetFirst, BC obtains QHB, V̂ and pwb by decryption of the received packetPHB from HC via (4.28):(QHB, V̂ , pwb) = Dkhb(PHB) (4.28)Then, BC chooses random number dB ∈ [2, n − 1] and computes QBNthrough (4.29):QBN = (QHB).dB = (dA.dH .G).dB = dA.dH .dB.G (4.29)(xbn, ybn) = QBN (4.30)884.4. Multilayer Consensus ECC-Based Password Authenticated Key-exchange ProtocolThen, BC copies its own ID into the V̂ field B in (4.31), and computes pwnvia (4.32). Finally, BC forwards V̂ , QBN and pwn to NC , all encrypted withthe predefined shared key of kbn through (4.33).V̂ .[B]← IDB (4.31)pwn = H˜(pwb|IDN ) (4.32)PBN = Ekbn(QBN , V̂ , pwn) (4.33)Fourth packetFirstly, NC follows (4.34) to obtain QBN , V̂ and pwn from the packet PBNreceived from BC :(QBN , V̂ , pwn) = Dkbn(PBN ) (4.34)Then, NC chooses random number dN ∈ [2, n−1] to obtain QNC via (4.35).QNC = (QBN ).dN = (dA.dH .dB.G).dN = dA.dH .dB.dN .G (4.35)(xnc, ync) = QNC (4.36)Then, NC updates V̂ field N with its own ID as depicted by (4.37), alsocomputes pwc through (4.38).V̂ .[N ]← IDN (4.37)pwc = H˜(pwan|IDC) (4.38)Finally, NC forms packet PNC out of V̂ , QNC and pwc as shown by (4.39),encrypts it by knc, and forwards it to CC .PNC = Eknc(QNC , V̂ , pwc) (4.39)Phase II: Response FlowThis flow starts with CC replying to the fourth packet above.Fifth packetFirst, CC obtains the QNC , V̂ and pwc values by decryption of the packetPNC received from the NC following (4.40).(QNC , V̂ , pwc) = Dknc(PNC) (4.40)894.4. Multilayer Consensus ECC-Based Password Authenticated Key-exchange ProtocolThen, CC extracts ID of any of the controllers (if needed) as well as ID ofthe appliance IDA from V̂ (V̂ .[A]), and also calculates ktca through (4.41).Beside, CC inserts its own ID into field C of V̂ as presented by (4.42).ktca = H˜(IDC |pwac|IDA) (4.41)V̂ .[C]← IDC (4.42)Then, CC picks a random number dC ∈ [2, n − 1] to obtain QC and QCCfollowing (4.43) and (4.44) respectively.QC = dC .G (4.43)QCC = (QNC).dC = (dA.dH .dB.dN .G).dC = dA.dH .dB.dN .dC .G(4.44)(xc, yc) = QCC (4.45)Then, CC obtains coordinates (xc, yc) as shown by (4.45) and (xnc, ync)as depicted by (4.36), and then computes SCN via (4.46) for verificationpurpose.SCN = H˜(ktca|ync|yc) (4.46)Finally, CC follows (4.47) to form PCN from SCN , QC and V̂ , in which CCencrypts the packet by knc as shown in (4.47).PCN = Eknc(SCN , QC , V̂ ) (4.47)Sixth packetFirst, NC decrypts the packet received from CC to obtain the SCN , QC andV̂ values following (4.48). Then, NC calculates ktna through (4.49).(SCN , QC , V̂ ) = Dknc(PCN ) (4.48)ktna = H˜(IDN |pwan|IDA) (4.49)Then, NC utilizes its own random number dN (fourth step) to calculate QNvia (4.50), and QNC via (4.51). Then, NC follows (4.52) to calculate SNBfor the verification purpose.QN = dN .G (4.50)QNC = (QC).dN = (dC .G).dN = dN .dC .G (4.51)SNB = SCN ⊕ H˜(ktna|ybn|ync) (4.52)Finally, NC forms PNB out of SNB, QN , QNC and V̂ , and encrypts thepacket by kbn as shown in (4.53) to be sent to the BAN controller (BC).PNB = Ekbn(SNB, QN , QNC , V̂ ) (4.53)904.4. Multilayer Consensus ECC-Based Password Authenticated Key-exchange ProtocolSeventh packetFirst, BC obtains the parameters SNB, QN , QNC and V̂ as presented by(4.54) by decrypting packet received from NC . Then, BC calculates the ktbakey via (4.55).(SNB, QN , QNC , V̂ ) = Dkbn(PNB) (4.54)ktba = H˜(IDB|pwab|IDA) (4.55)Then, BC uses its own random number dB (third step) to obtain the QBvia (4.56), QBN through (4.57) and QBNC via (4.58).QB = dB.G (4.56)QBN = (QN ).dB = (dN .G).dB = dB.dN .G (4.57)QBNC = (QNC).dB = (dN .dC .G).dB = dB.dN .dC .G (4.58)Then, BC obtains coordinates (xnc, ync) and (xbn, ybn) as shown by (4.36)(4.30) respectively, and calculates SBH through (4.59) for verification.SBH = SNB ⊕ H˜(ktba|yhb|ybn) (4.59)Finally, BC forms PBH packet by SBH , QB, QBN , QBNC and V̂ , encryptedby knc as shown in (4.60), and sends the packet to HC .PBH = Ekhb(SBH , QB, QBN , QBNC , V̂ ) (4.60)Eighth packetFirst, HC decrypts the packet received from BC and obtains SBH , QB, QBN ,QBNC and V̂ as depicted by (4.61). Then, HC calculates ktha through (4.62).(SBH , QB, QBN , QBNC , V̂ ) = Dkhb(PBH) (4.61)ktha = H˜(IDH |pwah|IDA) (4.62)Then, HC utilizes its own random number dH (second step) to computeQH via (4.63), QHB through (4.64), QHBN via (4.65) and QHBNC through(4.66).QH = dH .G (4.63)QHB = (QB).dH = (dB.G).dH = dH .dB.G (4.64)QHBN = (QBN ).dH = (dB.dN .G).dH = dH .dB.dN .G (4.65)QHBNC = (QBNC).dH = (dB.dN .dC .G).dH = dH .dB.dN .dC .G (4.66)914.4. Multilayer Consensus ECC-Based Password Authenticated Key-exchange ProtocolHC obtains coordinates (xbn, ybn) and (xhb, yhb) as depicted by (4.30) and(4.24), respectively, and then computes SHA using (4.67) for verification.SHA = SBH ⊕ H˜(ktha|ya|yhb) (4.67)Finally, HC forms PHA packet out of SHA, QH , QHB, QHBN , QHBNC andV̂ , encrypted by ktha as shown by (4.68), and sends the packet to AN .PHA = Ektha(SHA, QH , QHB, QHBN , QHBNC , V̂ ) (4.68)Phase III: VerificationAppliance (ninth packet)In this phase, AN verifies the received values and dispatches the confirma-tions to the upstream controllers. First, AN computes the ktha temporarykey via (4.62), to decrypt the received packet PHA from HC in order toobtain SHA, QH , QHB, QHBN , QHBNC and V̂ following (4.69).(SHA, QH , QHB, QHBN , QHBNC , V̂ ) = Dktha(PHA) (4.69)Then, AN utilizes its own random number dA (first step) to calculate QHBvia (4.70), QBN through (4.71), QNC via (4.72) and QCC through (4.73),which are shared by HC , BC , NC and CC , respectively.(QH).dA = (dH .G).dA = dA.dH .G = QHB (4.70)(QHB).dA = (dH .dB.G).dA = dA.dH .dB.G = QBN (4.71)(QHBN ).dA = (dH .dB.dN .G).dA = dA.dH .dB.dN .G = QNC (4.72)(QHBNC).dA = (dH .dB.dN .dC .G).dA = dA.dH .dB.dN .dC .G = QCC (4.73)Then, AN uses the above shared values to obtain coordinates (xc, yc), (xnc, ync),(xbn, ybn) and (xhb, yhb) as shown in (4.45), (4.36), (4.30) and (4.24), respec-tively. Then, AN utilizes the coordinates and performs (4.46), (4.52), (4.59)and (4.67) to substantiate SHA. If the verification holds, AN proceeds to thenext step. Note that, since AN has pw, it is able to obtain pwb, pwn & pwcbased upon (4.26), (4.32) & (4.38). Finally, AN generates four values TAHvia (4.74) for HC , TAB through (4.76) for BC , TAN via (4.78) for NC andTAC through (4.80) for CC , as verifiers of the shared values, and forwards924.4. Multilayer Consensus ECC-Based Password Authenticated Key-exchange Protocolthem to HC .TAH = H˜(ktah|xa|xhb) (4.74)ktab = H˜(IDA|pwab|IDB) (4.75)TAB = H˜(ktab|xhb|xbn) (4.76)ktan = H˜(IDA|pwan|IDN ) (4.77)TAN = H˜(ktan|xbn|xnc) (4.78)ktac = H˜(IDA|pwac|IDC) (4.79)TAC = H˜(ktac|xnc|xc) (4.80)HAN controller (tenth packet)HC receives the above substantiation values and then verifies TAH basedupon (4.74). If the verification holds, HC relays the other values to BC .BAN controller (eleventh packets)BC receives the above values and then verifies TAB following (4.76). If theverification holds, BC relays the other values to NC .NAN controller (twelfth packets)NC receives the eleventh packet and then verifies TAN through (4.78). If theverification holds, NC relays the other values to CC .SGCC controllerCC receives the twelfth packet and then verifies TAC via (4.80).Phase IV: Keys CalculationThus far, all parties have their verified shared values. Finally, they cangenerate their appropriate symmetric keys per (4.81), (4.82), (4.83) and(4.84).AN & HC : KHA = H˜(xa|xhb|ktha|ktah|ya|yhb) (4.81)AN & BC : KBA = H˜(xhb|xbn|ktba|ktab|yhb|ybn) (4.82)AN & NC : KNA = H˜(xbn|xnc|ktna|ktan|ybn|ync) (4.83)AN & CC : KCA = H˜(xnc|xc|ktca|ktac|ync|yc) (4.84)934.5. Analysis4.5 AnalysisSince the proposed MCEPAK protocol is based on ECC, X.1035 standardand D-H algorithm, it inherits most of their benefits. In this section, westudy and model the adversary, analyze the security of the system mainlyin terms of different attacks, and evaluate the security of the keys. Toanalyze and evaluate the security of our proposed protocol, we follow theDolev-Yao approach [25]. In the Dolev-Yao model, the adversary is capableof recording, deleting, re-playing, re-routing, re-ordering and re-schedulingthe messages. All of the messages generated by the honest parties are sentto the adversary, and the honest nodes receive the messages only from theadversary. Also, we analyse the protocol mechanism from the system andnetwork overhead point of views.4.5.1 Adversary ModelsWe consider two models for internal and external adversaries.Internal adversaryIn this model, our adversary is one of the trusted parties that has becomemalicious.Objective The objectives of the adversary are (i) Gaining access to thesystem resources such as the appliance or any of the controllers, (ii) Per-forming a MITM attack to gain access to any of the keys.Initial capabilities The adversary has complete knowledge about thetopology and the exact address/ID of each party. Furthermore, the ad-versary knows the detail design of the key agreement mechanism and hasaccess to the system parameters required for the key agreement. Dependingon which one of the involved parties is the malicious one, the adversary’sknowledge in each case is listed in Table 4.2.Capabilities during the attack The adversary receives the encryptedand unencrypted (plain) data in different stages of the keys agreement, orlater on during the using of the key. In case of having control on a controller,the adversary will attempt to perform a MITM attack. She/He can destroythe packets and cause failure in one of the verification phases that yields re-initiation of the key agreement protocol, which is essentially a DoS attack.944.5. AnalysisTable 4.2: Internal Adversary KnowledgeParty KnowledgeAN The initial shared password pw.HC pw and shared symmetric key with BCBC Shared symmetric keys with HC and with NCNC Shared symmetric keys with BC and with CCCC Shared symmetric key with NCFurthermore in case of a malicious AN , the adversary can perform DoSattack by initiating the key agreement protocol continuously.Discussion Referring to the assumptions of the MCEPAK protocol, con-trollers are fully trusted parties as parts of the SG domain, and they arecontrolled/setup/managed by the grid administrators. Even a HAN con-troller, which is usually a SM that also acts as a gateway, is not undercustomer control. Therefore, initially they follow the steps of the algorithmand do not show any misbehaving action. Also, the administrator of the SGmonitors them to protect the SG from any malicious controller. So, dealingwith malicious controllers is beyond the scope of this chapter.However, a malicious AN can perform a DoS attack easily, for instanceby failing the verification phase. To prevent it, the system can define a limitof the key agreement sessions per appliance in each period of time. If aftera number of tries, still the appliance could not finish the process, it meansthat either the node is malicious or the initial password between AN and HCdoes not match. Therefore, the system stops the appliance and cancels itsfuture tries. Having said this, the attack can be detected at, e.g., HC levelas long as AN uses the same ID. Initiating the key construction sessions bydifferent IDs is another option for AN to perform DoS attack against theHAN controller. In this case, HC can limit the number of open sessions inthe HAN domain to prevent such an attack.External adversaryIn this model, the adversary is not any of the involved parties, and performsattacks from outside of the controllers and appliance set.Objective (i) Gaining access to the system resources, like any of the con-trollers or AN . (ii) Performing a MITM attack to gain access to any of the954.5. Analysissymmetric keys. (iii) Performing a DoS attack to overload the system (anyof the controllers).Initial capabilities Similar to the internal model, the external adversaryhas complete knowledge about the topology and the exact address/ID of theparties. The adversary also knows the detail design of our mechanisms.Capabilities during the attack The adversary receives the encryptedand unencrypted (plain) packets during and after the key agreement process.Discussion Since our adversary receives all the packets, in order to gainaccess to the system resources, like AN , she/he can perform a brute-forceattack to find out the pre-shared password between the appliance and theHAN controller. Brute-force attack is a time consuming attack, and thepassword is used only during the first few packet delivery between the twoparties (AN and HC). Furthermore, we use a hash function to combine thepassword and random numbers to construct the key. Therefore, our model(similar to PAKE protocol) has the forward secrecy characteristic. Havingsaid this, finding the password does not help the adversary to figure outor calculate any of the symmetric keys. The same situation is applicableto any of the original keys between the controllers. Indeed, obtaining anyof the shared keys between the controllers does not help the adversary tocalculate the constructed symmetric key after the fact. This is because thepackets exchanged by our mechanism do not include all the items requiredfor the key calculation. Besides, the aforementioned discussion shows thatan adversary cannot perform a successful MITM attack.To perform a DoS attack and overload the system (any controller), ouradversary should initially run a spoof attack to masquerade one of the par-ties as well as performing a brute-force or dictionary attack to steal theshared key between the party and its neighbour. Then, she/he should man-age sending the key agreement packets to the neighbour to perform the DoSattack. Even if the adversary is able to manage these attacks, the systemcan limit the number of requests from any ID for the key construction andprevents this scenario. Any misbehaviour can be monitored by other con-trollers, where an intrusion detection system like [86] would help in thisregard.964.5. Analysis4.5.2 Security AnalysisConsensus key establishmentReferring to the key construction (4.81), (4.82), (4.83) and (4.84), we needcontribution of other downstream controllers for each controller. For in-stance in the case of KCA as per (4.84), we utilize (xc, yc) that containsrandom numbers chosen by CC & AN as well as random numbers of HC ,BC & NC (4.44). Similarly, KNA (4.83) uses random variables NC & AN aswell as HC & BC (4.35). Furthermore, AN verifies the received shared valuesall at the same time by checking SHA. Therefore, if any of the controllersdoes not cooperate on the key constructions, none of the parties would havean appropriate key.Mutual authenticationThe utilization of password pw provides a mutual authentication betweenAN and HC . Furthermore, since pw is a part of the pwb, pwn & pwc calcula-tions that are used by other controllers for the verification and key formation,the mutual authentication is endorsed on the entire key-set.Hierarchical/Conditional key formationAN needs to establish a symmetric key shared by HC in order to establisha key with any of the higher layers controllers. Furthermore, all of the keyconstruction are initiated by AN and are forwarded to HC as a gateway. Tobe more precise, only the downstream (and not the upstream) controllersrandom numbers are required by each controller.Replay attackLike D-H algorithm, since MCEPAK utilizes random numbers and hashfunctions to establish the keys, it delivers the replay attack resilience.Key privacy and insider attack resilienceDepicted by (4.81)-(4.84), each key is only known by AN and the corre-sponding controller. For instance, KNA is only known by AN and NC ,which supports the key privacy. Other controllers in-between only attendin the key construction; however, they do not gain access to any data to beused to decrypt the messages.974.5. AnalysisOff-line guessing attack resilienceAn eavesdropper may perform an off-line dictionary attack over passwordpw by having access to the H˜ (4.18) and obtains access to QA; nevertheless,based on ECC-CDH (Elliptic Curve Cryptography Cofactor Diffie-Hellman)assumption [6], s/he is not able to find dA. As a result, the adversary doesnot have complete information and data to compute any of the keys.Denning-Sacco attack resilienceIf an eavesdropper gains access to H˜(IDi|pwx|IDj), still she/he is not ableto obtain pwx value used in the key establishment. Furthermore, she/he isnot able to guess H˜(IDk|pwy|IDl) where i 6= k & j 6= l & ∀x, y.Compromised impression resilienceReferring to our adversary models as well as (4.81)-(4.84), finding any of thekeys does not enable an intruder to obtain any other controllers key.Ephemeral key compromise impersonationEven if an adversary finds any of the pwu passwords, she/he is not able tocalculate QAz since she/he does not have access to the random number dA.Also, QAz is required by the her/him to obtain KzA (z is a controller).Unknown key-share attackSHA assures AN that the controllers have the required parameters to calcu-late the keys. On the other hand, parameters TAH , TAB, TAN & TAC assurethe controllers that AN has the required values. So, if a controller is ableto perform the key formation, the appliance would be able to do it too, andwise versa.MITM attackPer the aforementioned discussion on the adversary models, since all ofthe packets between AN & HC are encrypted by pw based temporary keysktaZ , MCEPAK enjoys MITM attack resilience. Also, the communicationsbetween the controllers required for key formation are secured by the pre-liminary keys of the controllers.984.5. Analysis4.5.3 Formal Validation Using Software ToolWe apply AVISPA to analyse appropriate shared keys of the five entitiesAN , HC , BC , NC and CC . Simulation results presented in Figure 4.5a andFigure 4.5b show that the symmetric keys constructed by our mechanismare secure and safe to be used by the system entities.% OFMC               % Version of 2006/02/13       SUMMARY                SAFE               DETAILS                BOUNDED_NUMBER_OF_SESSIONS     PROTOCOL                              /ubc/ece/home/vl/grads/hasennic/De  sktop/avispa-           1.1/testsuite/results/MCEPAK.if                    GOAL                  as_specified           BACKEND                OFMC               COMMENTS              STATISTICS               parseTime: 0.00s           searchTime: 0.03s           visitedNodes: 5 nodes         depth: 2 plies          (a) OFMCSUMMARY              SAFE                               DETAILS                BOUNDED_NUMBER_OF_SESSIONS       TYPED_MODEL                           PROTOCOL              /ubc/ece/home/vl/grads/hasennic/De  sktop/avispa-           1.1/testsuite/results/MCEPAK.if                    GOAL                  As Specified                           BACKEND                CL-AtSe                             STATISTICS               Analysed   : 3 states         Reachable  : 1 states         Translation: 0.00 seconds       Computation: 0.00 seconds     (b) Cl-AtSeFigure 4.5: AVISPA ResultsThe evaluation program and AVISPA related HLPSL codes for the ses-sion, environment and goal sections, as well as each party HLPSL relatedcodes are presented in Appendix A.4.5.4 Performance AnalysisLow implementation costLet us consider the following two scenarios:• Sen.1: AN establishes an individual symmetric key by each controller,following the PAKE or EPAK protocols.• Sen.2: AN follows MCEPAK protocol.An overall comparison between the two scenarios is presented by Ta-ble 4.3. Based on Figure 4.3, Sen.1 performs four iterations to constructfour symmetric keys between appliance AN and the upstream controllers.994.5. AnalysisTable 4.3: Overhead ImprovementScenario HashFunctionPassword Phase RandomnumberTransferred packetbetween entitiesSen.1 5 4 16 8 30Sen.2 1 1 4 5 12Improvement 80% 75% 75% 37.5% 60%Also, referring to Sections 4.2 and 4.3, one password between AN and thecontroller is required for each key agreement. Furthermore, Sen.1 proceedsduring 4 × 4 = 16 phases and requires five hash functions, while Sen.2 hasonly four phases and needs only one hash function and one password. Interms of random numbers, in Sen.1 two random numbers per key are re-quired, and in total eight random numbers are needed. On the other hand,Sen.2 requires only five random numbers. Also, Sen.1 transfers three pack-ets per iteration and in total needs 3+6+9+12 = 30 packets to be delivered.In contrast, Sen.2 needs three packets per phase for a total of 3 × 4 = 12packets.Fast packet deliveryPacket delivery between AN and HC are the same for both scenarios, al-though MCEPAK provides a faster packet delivery between AN and theupper-layer controllers for regular communications. Let us define t0 as therequired time for the encryption or decryption process at each party, whichis assumed to be the same. Let us consider the following two scenarios:• Sen.3: System has one symmetric key per layer. If a packet is en-crypted by controller BC to be sent to AN , HC should decrypt it bythe key between BC & HC , and then encrypts it again by the keybetween HC & AN . Finally, the packet can be decrypted by AN usingthe shared symmetric key between HC & AN .• Sen.4: System provides a shared symmetric key between BC & AN .Therefore, the packet that needs to be sent by BC to AN , needs to beencrypted and decrypted once (by BC & AN ).Table 4.4 presents the required time in each case by each controller, andalso presents the time saving (improvement).1004.5. AnalysisTable 4.4: Improvement of Encryption/Decryption TimeScenario AN ↔ HC AN ↔ BC AN ↔ NC AN ↔ CCSen.3 2× t0 4× t0 6× t0 8× t0Sen.4 2× t0 2× t0 2× t0 2× t0Improvement 0% 50% 66.67% 75%Note: An analysis and evaluation on EPAK protocol (cost of key agree-ment) in comparison to the literature is presented at the end of Section 4.3as well.CostAlthough there are many benefits of using our proposal, as we discussedabout them in above subsections, the controllers need to make sure that theyreceive the packets on time. In fact, the entire controllers should participatein the key calculations. Somehow, we need to trust that the entities willdo their duty. Furthermore, fast responding to the mechanism is anotherrequirement. In fact, the initial password shared between an appliance andHAN controller is not too strong, and only is set up to construct a key in ashort time and quick, to prevent attacks such as MITM. If entities delay themechanism, an adversary can attack the mechanism by e.g. brute-forcingthe password, and perform the attack.101Chapter 5Maintaining Privacy byUsing Enhanced NetworkCodingIn this chapter, we consider the privacy aspect of users in SG system andprovide a mechanism that utilizes the advances in network coding to main-tain data privacy. We address privacy issues associated with gatheringmetering information of clients in a SG system. In SG systems, wirelessmulti-hop communications are mainly used to gather metering informationthrough exchanging data and control messages between SMs and the utility.We argue that any communication paradigm used in a SG should supportall aspects of privacy such as anonymity, unlinkability, unobservablity, andundetectablity. We propose innovative schemes for traffic routing and en-cryption that benefit from the enhanced network coding technology. Notethat we use a selective network coding as well as a clustering the topology.These two features enhance our proposal comparing to a full network codingmechanism.5.1 IntroductionDifferent communication technologies have been proposed for the AMI suchas PLC and wireless communication [27]. As per our previous discussionin previous chapters, in North America, wireless multi-hop communicationtechnologies (e.g., ad-hoc and mesh networks) are proposed to be used forexchanging data and control messages over the AMI between SMs or gate-ways of HANs and the utility [28, 31, 87–89]. In this case, data traffic istransmitted from a SM to the utility and vice versa over multi-hop wirelesslinks with intermediate network nodes forwarding traffic (Figure 5.1).Privacy in the SG is identified as one of the biggest concern by theresearch community, considering the uncertainty in the environment [90].Although it may be tempting to try to patch existing protocols such as ran-1025.1. IntroductionData collectorHAN SMNeighborhood subnetworkFigure 5.1: Smart Grid Network Architecturedom paths and anonymous routing to provide some level of privacy [91], theprivacy of the users in the SG system needs to consider more precise specifi-cations such as anonymity, unobservability, unlinkability, and undetectabil-ity. This requires different designs of traffic routing in order to meet therequired privacy properties. For example, when using anonymous routingprotocols, an adversary may detect data traffic generated by an individualsmart meter to infer information about appliances existed in a HAN (bymonitoring trends of power consumed by different appliances), and informa-tion about behavior of the users (by monitoring amount of power usage inthe HAN). Although a trivial scheme that generates dummy packets maysolve the unobservability problem, it fails to address anonymity, unlinkabil-1035.2. Backgroundity and undetectability while introducing high amount of the overhead tothe system. We refer to the Pfitzmann-Hansen definitions of the privacy[92], which we describe in Chapter 1.Contribution: Our proposed schemes address the problem of preservingprivacy of users in a SG system by maintaining all necessary features re-quired for privacy in such a system including anonymity, unlinkability, un-detectability and unobservability communications.None of the existing schemes in the literature simultaneously addressall these properties together. We identify five privacy measures for theCPS communication such as hiding source, destination, path, traffic volumeand content. We address this problem using an enhanced network codingtechnique. Our proposed schemes basically benefit from the capability ofthe network coding in encoding transmitted linear combination of packets.5.2 BackgroundNetwork coding has been widely used to improve the robustness and band-width efficiency of multicast routing in special network topologies. However,the inherit feature of packet encryption in the network coding can be ex-ploited to provide privacy for users in a SG. Furthermore, the distributednature of the network coding increases its robustness against possible at-tempts of attackers. The simplest coding scheme is linear coding [93, 94].Linear network coding treats a block of data as a vector over a certain basefield of coefficients. Each intermediate node performs a linear transformationand achieves a linear combination of the incoming edges before deliveringthem to the next node(s).Network coding is used in communication to target maximizing through-put, minimizing energy per bit and Minimizing delay [95]. A linear combi-nation of received packets at the encoding nodes is transmitted with a linearcoding coefficient vector or Local Encoding Vector (LEV). The Global En-coding Vector (GEV) is used to form the transfer matrix for the entiresystem. Practical instances of the network coding constitute the following:(i) Random coding [96] which allows the encoding to be done in a distributedfashion, (ii) Packet tagging of each packet with LEV allows the decoding tobe done in a distributed manner, and (iii) Buffering which is required forasynchronous packet arrivals and departures with arbitrarily varying rates,delay, and loss.1045.2. BackgroundFigure 5.2: Matrix of TransferLet us assume an acyclic network (V,E, c) with unit capacity edgesc(e) = 1 for all e ∈ E. Let x1, x2, ..., xh be the h packets that our graph,from an over all point of view, wishes to carry. Bringing the coefficients ofall nodes v ∈ V into account and in short, if we assume an “h× h” model,(5.1) shows the relationship between received packets (yis) and sent packets(xis). Matrix T presented by (5.2) is called transfer matrix of the network,therefore, receiver(s) can use (5.3) to extract the original xi out of yi. Tis based on each node coefficient and should be an invertible matrix, whichhaving a random coefficient guarantees that.y1...yh =t1(e1) . . . th(e1)... . . . ...t1(eh) . . . th(eh)×x1...xh (5.1)T =t1(e1) . . . th(e1)... . . . ...t1(eh) . . . th(eh) (5.2)y1...yh = T ×x1...xh⇒x1...xh = T−1 ×y1...yh (5.3)Depicted by Figure 5.2, and since transfer matrix T is not fix due todynamic and randomness of the coefficients, a receiver requires to calculateT−1 each time based on received tags. To improve the calculations of (5.3),1055.3. Related Work[97] proposes using sub-graph in order to handle different sources’ trafficsto different destination. More specifically, the main graph is divided toparallel sub-graphs, and packets from a source to a destination traverse inonly one sub-graph. The aim in [98] is finding the minimum cost multicastsub-graph, where delay values associated with each link, limited buffer-sizeof the intermediate nodes and link capacity variations over time are takeninto account.5.3 Related WorkIn [99], the CPS is studied as a combination of multiple fields of science suchas computing, communication and control systems. The author comparedthe evolution of the CPS to the Internet, and provided some applications ofthe CPS in real world, e.g. smart grid for the power sector. He also men-tioned that privacy should be preserved by the CPS: “These CPSs will haveembedded and distributed intelligence, operating dependably, securely, safely,and efficiently in real time, while satisfying privacy constraints”. The au-thor also presented advances of the CPS, such as fully autonomous vehicles,smart power grids and extreme-yield agriculture, as well as the impact ofthe CPS on society and education.The work in [100] considers the case of smart grid as an application ofthe CPS, which is related to the scope of our work in this chapter. The re-search work presented in [101] considers security of the smart grid. Authordiscussed the security aspects of the cyber-physical controls required to sup-port the smart grid, which takes into account the power application. Theyanalyzed the security from the risk point of view, and address the securityconcerns in control systems of the generation, transmission and distributionof the power in the smart grid. Furthermore, they studied the security ofthe infrastructure support and devices as well as security management andintrusion detection systems, followed by list of research challenges in thisarea. In this chapter, however, we focus on the privacy aspect of the SGsystem. To the best of our knowledge, we are the first to propose compre-hensive schemes to address all features required to preserve privacy of clientsin a smart grid system.The scope of the work in [102] is the SG as well, in which the authorspresented a security-oriented cyber-physical state estimation system. Theirproposed system identifies the compromised set of hosts in the cyber networkand the maliciously modified set of measurements obtained from power sys-tem sensors, at each time instant. They used the concept of the IDS, which1065.3. Related Workutilizes stochastic information fusion algorithms and merges sensor informa-tion from both the cyber and electrical infrastructures. The innovation oftheir proposed work is using the IDS system to monitor the cyber infras-tructure for malicious or abnormal activity, in conjunction with knowledgeabout the communication network topology.M. Stegelmann et al. proposed a scheme, wherein smart meter sendsthe metering data to a local aggregator, and then the aggregator applies theanonymity before sending the data to service providers. Although data forthe billing is not anonymous, the same data is anonymous when it is sent tothe service provider for the planning [103]. However, this scheme providesonly source anonymity in portion of the data deliveries. The presentedsystem in [104] aimed at anonymity of the SMs by combining the datacollected by each SM with an ortho code, in a ring architecture, to theutility via an aggregator. The utility, without realizing the identificationof each SM, can obtain the meters by summation information processed byaggregator. As the authors mentioned as well, they only provided anonymityof the sender (SM).A Secured routing protocol for ad-hoc network is presented in [105],which enables anonymity of the source, destination and path. In this pro-tocol, a source initiates and broadcasts a path request including a path se-quence number and the encrypted destination address. The relay nodes onlyrebroadcast the path request after recording it. The destination respondsback (unicast) to the path request, and nodes along the path reserve thepath by matching information about the previous and next hops. However,this protocol is vulnerable to the flow tracing attack.In [106], a network coding based scheme is used for privacy preserving,which extends the work in [105] by providing source anonymity. The schemeforwards a random-based linear vector encrypted GEV at each intermediatenode in which only the destination is capable of decrypting the GEV. Thereceiver has to undergo the decryption of the tags, forming transfer matrix,and heavy process of the reverse matrix calculation. The scheme presentedin [107] also utilizes network coding to support security and privacy.In [108], the linear network coding is used to maintain privacy of themobile nodes in a wireless mesh network environment. The proposed mech-anism is aimed at flow untraceability and movement untraceability of thenodes. However, the proposal mainly pay attention to the flow of the infor-mation of the mobile nodes, and does not preserve anonymity of the nodes,especially when an attacker is listening to the first mesh router that receivesthe data/packet from the mobile node.The proposal scheme in [109] aimed at flow anonymity of the data to1075.4. System Designprovide the anonymity of the communicating parties by tacking advantageof mixing characteristic of the coding. Although the scheme concentrates onanonymity of the source and destination by hiding the flow identifies causesby mixing the flows, it does not address other aspects of the privacy.5.4 System DesignIn this section, we first describe our assumptions. Then we present ourproposed enhanced network coding mechanism and describe our privacy-preserving scheme.5.4.1 Assumptions and System SetupOur assumption are as follows:• Public key encryption system that has a PKG responsible for the keymanagement.• Nodes have already performed an authentication scheme. They havealso received their private key as well as the system parameters fromthe PKG.• Topology is almost static: For instance in case of the SG, the maximummovement of nodes are within a HAN, although the SM of the HANis static.Figure 5.3: Matrix of Transfer, With Sub-graphs1085.4. System Design• A SG server, which can be in charge of the PKG duties as well, isaware of the topology and graph of the network.5.4.2 Enhanced Network CodingAs shown in Figure 5.3, the system administrator divides the main topol-ogy/graph G into m sub-graphs SubGi (he may consider the proposed solu-tion in [98] for sub-graphing) and forms sub-graphs set S˜ubGS such that:S˜ubGS = {SubGi| i = 1, 2, ...,m} (5.4a)G =m⋃i=1SubGi =⋃SubGi∈S˜ubGSSubGi (5.4b)In each sub-graph SubGi, system administrator selects ns nodes to bethe network coding nodes, which perform the network coding activities suchas encoding. Furthermore, system administrator nominates one of the nodesto be head cluster of the sub-graph, which can be shown by HCi.We consider transfer matrices set T˜ S, which Ti represents transfer matrixof SubGi such that:T˜ S = {Ti|i = 1, 2, ...,m} (5.5)Similarly, we consider inverse of transfer matrices set T˜RS, which TRirepresents inverse of the transfer matrix of the sub-graph SubGi, such that:T˜RS = {TRi|i = 1, 2, ...,m} (5.6)Furthermore, we introduce a new parameter “αi” as follows:αi ={1 , data crosses SubGi (5.7a)0 , data does not cross SubGi (5.7b)Finally, we define “h × h” transfer matrix T̂ which converts an in-put data matrix X̂ =[x1 x2 ... xh]Tto the output data matrix Ŷ =[y1 y2 ... yh]T, following (5.8a) and (5.8b).T̂ =∏Ti∈T˜ S & αi=1Ti , i = 1, 2, ...,m (5.8a)Ŷ = T̂ × X̂ (5.8b)1095.4. System DesignSimilarly and at the receiver side, (5.9a) and (5.9b) are used to decodeX̂ out of Ŷ . Note that T̂R = T̂−1.T̂R =∏Ti∈T˜ S & αi=1T−1i , i = 1, 2, ...,m=∏TRi∈T˜RS & αi=1TRi , i = 1, 2, ...,m (5.9a)X̂ = T̂R× Ŷ (5.9b)5.4.3 Privacy-Preserving SchemeReferring to Section 5.2, a receiver requires the LEVs of a graph (over whichthe data has passed through) in order to compute the transfer matrix. In alinear network coding, there are two parameters that can be changed, suchas network topology (path) and coefficient factors (LEVs). One solution ishaving one of these two values to be fixed and the other one changes dynam-ically (or, in some cases both of them can be dynamic). To be more precise,we can keep the topology (path) static, and randomly choose the coefficients,which in this case the coefficients information should be transferred (somehow, and securely) to the receivers to make the receiver capable of decodingthe data. On the other hand, we can fix the coefficients and randomly choosethe path, which in this case information about the path, or the network cod-ing nodes (that have performed network coding operation/encoding), shouldbe transferred to the receiver.Note that LEV is a function of the coefficient factors [95]. Without lossof generality:Ti = Function(LEVSubGi) , i = 1, 2, ...,m (5.10)Since we keep the sub-graph structure fix, only knowing coefficients ismissing to compute the transfer matrix(ces) of the sub-graphs, which theserver is capable of doing it. From an abstract point of view, in our system,we keep the topology, nodes coefficients and structure of the sub-graphs fix,although the sub-graphs that the data is crossing is being selected randomly.Our mechanism phases are as follows:Phase I: setupFirstly (Algorithm 2), PKG provides a One-Way hash function Fcoef (.) tothe nodes. Each node applies Fcoef (.) to its own private key to obtain its1105.4. System DesignAlgorithm 2 System SetupDefine:PrvKIDj : Private key of node IDj .CoefIDj : Coefficient factor of node IDj .PKG : Private Key Generator.Fcoef (.) : Shared hash function.SubGi : “ith” sub-graph in sub-graph set S˜ubGS.Ti : Transfer matrix of the sub-graph SubGi.T˜RS : Set of inverses of transfer matrices of the sub-graphs.Algorithm:PKG← IDjPKG : (PrvKIDj , Fcoef (.) , i)→ IDj {PKG calculates the private key}Coefj ← Fcoef (PrvKIDj ) {Perform by PKG and IDj}S˜ubGS = {SubGi| i = 1, 2, ...,m} {Defined by system administrator}PKG← S˜ubGS {Receive from the system administrator}T−1i ← Ti ← (SubGi , Coefj s.t. IDj ∈ SubGi) {Performed by PKG}T˜RS = {T−1i |i = 1, 2, ...,m} = {TRi|i = 1, 2, ...,m}T˜RS → Destinationcoefficient (5.11):Node Coefficient = Fcoef (Node PrivateKey) (5.11)In a PKI-based system, only PKG and each node know the private keyof the node. System administrator provides all information about the topol-ogy and graph consists of the participating nodes in each sub-graph to PKG.PKG calculates Ti and T−1i of each SubGi and provides the T−1i s to a des-tination.Note that a private key can be considered as a random-based secret valuemanaged by PKG. For instance, in an IBC approach, like [52], the privatekey of a node is multiplication of a secret random value generated by PKGand the public key of the node. Since the coefficient is a function of theprivate key (5.11), the randomness is implied for the coefficient as well, andreferring to [95], Ti is invertible.Since Fcoef (.) is a One-Way function, even if any of the receivers actsmaliciously, an attacker would not be able to utilize matrix T−1i and performsa reverse operation to obtain the private keys of the nodes. We discuss moreabout this in Section 5.5. Furthermore, a private key is a dynamic value[110], therefore, transfer matrices Ti (and T−1i ) are also dynamic. Note thatthe PKG is responsible to maintain and update the matrices and informingthe receivers, for instance in case of the SG, the SG servers, which collectthe data, should be notified by this server (PKG).1115.4. System DesignAlgorithm 3 Generating and Sending the PacketsDefine:PubKIDa : Public key of node IDa.PrvKIDa : Private key of node IDa.NSGIDs : Set of next optional sub-graphs to the destination for sender IDs.eek(.) : Encrypting with key ek.signek(.) : Signature of data using key ek.X : “1× h” size matrix of plain packets to be sent.X̂ : “1× h” size matrix of encrypted packets to be sent.TAG : “m” bit size vector; each bit represent one sub-graph.IDTAG : A nonce value represents the identification of the TAG.Fnc(k) : A nonce generator function in “k” bits size.Algorithm:{IDs chooses one SGi out of N˜SGIDs with an equal probability}MyNSG← Random(N˜SGIDs ) Random choosing a sub-graph out of N˜SGk setTAG← Fnc(m) {Encryption of the tag. “m” is total number of sub-graphs}IDTAG ← Fnc(m) {Choosing a nonce vale for the tag identification}DataH ← (IDs, IDr, TAG, IDTAG) {Data header}SgnH ← signPrvKIDs (DataH) {Signing the data header}{IDs encrypts data (packet by packet) using public key of the receiver}for (l = 1→ h) doX̂.[1, l]← ePubKIDr (X.[1, l]) {Encryption}end for(X̂, ePubKIDr (DataH), SgnH, TAG, IDTAG) → MyNSG {Sending encrypted data, dataheader, signature of the header, TAG and IDTAG to the next sub-graph}Phase II: generating and sending the packetsPresented by Algorithm 3, a sender chooses a nonce and assigns it to theTAG, and a nonce random identity for the TAG, which we show it asIDTAG. Then, the sender chooses one of the adjacent sub-graphs withequal probability to send the data. Then, the sender forms the data headerincluding the nonce values and address of the receiver. Furthermore, thesender signs the header with its own private key in order to preserve thesource authentication as well as the data header integrity. Finally, the sendersends the encrypted data (packets) and data header, signature of data headerand plain form of the tag and its ID to the next sub-graph toward thereceiver.Note: TAG is an array that traverses with the data. Each bit of the TAGrepresents αi of a sub-graph ((5.7a) and (5.7b)). To be more precise, theith bit of the array is converted to one if the data passes through SubGi.Therefore, initially TAG consists of only zeros (TAG = 0). Since TAGis sent in a plain format, we load it with a nonce value, and forward thenonce (encrypted) to the destination. Then, in each sub-graph, the head1125.4. System Designcluster only reverses the value of the ith bit. In other words, we XORthis bit with αi. Consequently, at the destination only needs to XOR theresult with the original nonce value to decrypt the tag and obtain list of thesub-graphs that the data has passed through. Comparing to the networkcoding operation, especially at the receiver, changing one bit per sub-graphis negligible overhead added cost by our mechanism.Note: Referring to our discussion in Section 5.2 about the network coding,normally the coefficient that each network coding node use to handle thecoding process, needs to be sent to the receiver for encoding process (byreceiver). In our design, we eliminate sending this overhead data (coeffi-cients) in cost of sending the tag and tag identity. In fact, tag ID is similarto the flow ID that is being used by the network coding, and our additionaloverhead cost is the tag itself. The overhead cost of sending the tag is muchless than sending the coefficients, since in network coding there is one coef-ficient per network coding node, and we only have one tag from source todestination.Algorithm 4 Relaying the PacketsDefine:NSGi : A set of next optional sub-graphs to the destination for “ith” sub-graph.Ŷi : Input “1× h” size data matrices at sub-graph SubGi.X̂i : Output “1× h” size data matrices at sub-graph SubGi.Algorithm:SubGi ← (Ŷi, DataH, SngH, TAG, IDTAG) {Receiving data, data header, signature, tag andtag ID}if ((Looks up IDTAG) == NO) thenX̂i ← SubG Function(Ŷi) {The result of SubGi internal process}SHFTαi ← 2i−1 {Shift “αi” to the “ith” bit position}TAG← (TAG ⊗ SHFTαi) {Record “αi” into TAG}Records IDTAGend ifMyNSG← Random(NSGk) {Choosing SubGk out of N˜SGk set}(X̂i, DataH, SngH, TAG, IDTAG)→ MyNSG {Sending data, tag, tag ID and data header tothe next sub-graph}Phase III: relaying the packetsAs it is shown in Algorithm 4, we consider a situation that our data isentering to the SubGi. The data passes through SubGi concerning thedefined connections and coefficient values of the nodes (network coding nodesare already identified by the administrator). The head cluster of the sub-graph needs to record αi into TAG by changing the ith bit of TAG. Similar1135.4. System Designto the previous step (sending data), the head cluster of the sub-graph SubGirandomly selects one of its neighbour sub-graphs to transfer the data totoward the receiver.Note: Since the next sub-graph is chosen randomly, the data may get en-tered to the same sub-graph more than once. In order to prevent this loopingsituation, the identity of the tag (IDTAG) is referred by the header of thesub-graph (HCi). Indeed, HCi keeps a record of the IDTAG that is pro-cessed by the sub-graph, in addition to IDs the sub-graphs that it is receivedfrom and is sent to, for some time in order to prevent processing it twice.The reasonable expiry time of keeping the record can be same as SMs pe-riodic collecting time, e.g. 15 minutes. In this case, the assumption is thatthe data will be received and decoded by the receivers during 15 minutes.Therefore, first of all, HCi does not lead the processed (coded) informationto be sent to the same sub-graph that is coming from. Secondly, if it receivesthe same data (IDTAG) from another sub-graph, it will forward the dataas-is and without coding it again, to the next randomly chosen sub-graphexcluding the sub-graphs that are received from as well as the data has beensent previously to. It is obvious that in a worse case scenario, the data willreach the destination after being processed by the entire sub-graphs onlyonce.Phase IV: receiving and decoding the packetsPresented by Algorithm 5, when a receiver receives the data:• Utilizes its own private key to decrypt the header to obtain addressesof the sender and receiver, and the nonce.• Referring to the sender address, verifies the signature, and if it is valid,XORes the nonce with the received tags for decryption.• Referring to the bit values of TAG, selects T−1i (TRi) of sub-graphsthat data has passed through, and multiplies them together to obtainthe reverse value of the path transfer matrix T̂RS via (5.9a).• Obtains original packets sent by the sender via (5.9b).1145.5. System EvaluationAlgorithm 5 Receiving and Decoding the PacketsDefine:T̂ : Transfer matrix from source to destination.T̂R : Inverse of the transfer matrix from source to destination.y & x : Received packet and sent packet.Ŷ : Matrix of the received packets with size of “1× n”.X̂ : Matrix of the sent packets with size of “1× n”.eek(.): Encrypting with key ek.ddk(.): Decrypting with key dk.Algorithm:Receiver ← (Ŷ , DataH, SgnH, TAG, IDTAG) {Receiving packets, data header, signature, tagand tag ID}OrgNonceEnc← DataHOrgNonce← dPrvKIDr (OrgNonceEnc)Verify Sgn {If verification result is positive, proceed}TAG← (TAG⊗OrgNonce) {XOR with the original nonce for decryption}T̂R← I {I is identical matrix}for (i = 1→ m) doif (TAG.[i] == 1) thenT̂R← (T̂R× TRi)end ifend forX̂ ← T̂R× Ŷfor l = 1→ h doX.[1, l]← dPrvKIDr (X̂.[1, l]) {Decryption}end for5.5 System EvaluationIn this section, we present our analysis from privacy and system performancepoint of views. First we propose two adversary models, then compare ourdelivered privacy factors comparing to the literature, and finally in the com-munication and network performance subsection, we discuss complexity andreliability of our design.5.5.1 Adversary ModelsWe refer to Dolev-Yao model [25] to design our two adversary models in-cluding external and internal adversaries, in case of the SG system.External adversaryIn this case, the adversary is an external party and is not an entity of thesystem.1155.5. System EvaluationObjectives The adversary objective is obtaining information about theHAN occupancy and its resident behaviour.Initial capabilities The adversary knows the detail information aboutthe initial security system as well as our proposed privacy mechanism. Forinstance, the adversary knows public keys of the entire parties and has thedetail knowledge about the network topology, graph and sub-graphs. Fur-thermore, the adversary knows the detail design of our mechanism includingalgorithms shown by Algorithm 2-5. Finally, the adversary has enough tech-nical knowledge and is fully-equipped to be able to listen to the channelsand analyze the traffic.Capabilities during the attack The adversary receives all of the packetsentering to a HAN (SM of the HAN) and departure from the HAN. Beside,the adversary can listen to the channel of any other entity of the system likePKG and any destination, to collect their receiving data.Note: By using the term data, we mean and refer to the exact data that isin the channels (encrypted and/or encoded).Discussion: Refer to our assumption, a HAN gateway (SM) acts asrelay node in a mesh-based topology. We also implement and perform en-hanced network coding that mixes the packets utilizing sub-graphs. Sincesource and destination addresses are encrypted inside the header, our schemedelivers the anonymity and undetectability, which yields to unobservability.If the adversary listens to entering and departing data from a HAN, he doesnot gain any useful information, since the entering packets plus HAN packetare encoded into one packet, which hides the HAN packet. If the origin of apacket is an appliance, listening to the channel does not help the adversaryto obtain anything about the existence of the appliance (undetectability overappliances). In the proposed schemes in the literature (Section 5.1), he canunderstand HAN is generating a packet by listening to the first node, so,mostly those schemes only make a private path.The packets entering a SM to be relayed, also do not have the source ad-dress, and are entering to the sub-graphs randomly. Therefore, the adversarycannot trace back the packets or monitor flow of the data, so unlinkabilityis delivered since he cannot observe direction of the data.Last position for the adversary is at receiver side and listening to the re-ceiving data. Considering above discussion about the hidden address of thereceiver, he only obtain the flow of information to the destination. Indeed,1165.5. System Evaluationsince the data travels through random chosen sub-graphs to reach the desti-nation, he cannot trace back the data. Consequently, our scheme maintainsanonymity and unlinkability here too.Note that in any of the above situations, gaining access to TAG does nothelp the adversary. Indeed, encoding TAG with a random nonce makes sub-graphs capable of inserting αi without decoding TAG. He does not obtainanything by having an encoded TAG, even at the first or last sub-graphs.Internal adversaryAdversary is an internal party, e.g., he has access to one of the HANs andcan particularly monitor gateway of the HAN or analyze the gateway infor-mation.Objectives Gaining access to the neighbour HANs information by receiv-ing their data for relay.Initial capabilities The malicious node is already authenticated and re-ceives the system parameters and its own private key, so our adversary hasthese information.Capabilities during the attack The malicious node is under control ofthe adversary and performs the Algorithm 4.Discussion: Having access to a malicious node only improves the ad-versary situation on modifying its HAN data. The relay nodes only mix thepackets and do not perform any encryption and decryption. Furthermore,the data that he receives does not show any sign of the source or destina-tion. Consequently, his capability and behave is almost same as the previousscenario.Table 5.1: Delivery of the Privacy MeasuresScheme [91] [103] [105] [106] [107] [104] [111] [112] OursAnonymity 4 6 & l 4 4 4 4 l l 4Unlinkability l 6 & l l l l 4 6 l 4Undetectability 6 6 l l l 6 6 6 4Unobservability 6 6 6 6 6 6 6 6 41175.5. System Evaluation5.5.2 Privacy Performance AnalysisReferring to Sections 5.2 and 5.3 as well as our proposal in Section 5.4,Table 5.1 presents performance of our scheme comparing to the discussedschemes in Section 5.1. We consider two types of the attackers such as aneighbour and a relay node. Some of the schemes may deliver the anonymityin case of relay nodes; however, the data is not anonymous for a neighbour.We also use the following symbols to describe each deliverable:• “6”: Does not deliver the measure.• “l”: Delivers the measure only against relay nodes.• “4”: Delivers the measure against all nodes.5.5.3 Communication and Network Performance AnalysisIn this subsection, we provide an analysis and evaluation on the aspects ofprobability of success and complexity as well as intrusion success likelihood,and reliability for the proposed approach. Throughout the discussion weconsider a square grid network topology. The communication performanceevaluation of our proposed coordinated method is evaluated against therandom network coding approach of [113] where authors claim a throughputperformance gain over no coding. However, while there are advantages tonetwork coding approaches, the success of these methods highly depends onthe characteristics of topology. In this method, nodes continuously replicateand forward messages to newly discovered nodes.ComplexityOne of the overheads with the network coding is that nodes must have theprocessing capability to perform arithmetic operations over finite fields inreal time. This processing will determine whether a decoded content chunkis innovative and makes a decision to either encode, forward, or decode. Theprocessing complexity involved in operations over fields depends on the sizeof each generation h, and size of the field n. It takes O(h2) operations in F2nfor linear operations with generations of size h. Multiplications and inver-sions over field F2n is of complexity O(n2). Furthermore, matrix inversionsand Gaussian elimination to solve the system takes O(h3).As shown in Figure 5.4, the cost of computing in our method is lowersince the transfer metric at the receiver is implied and need not to be recal-culated every interval. The computational cost in our algorithm is reduced1185.5. System Evaluation0 5 10 15 20 25 30 35 40050100150200250300Number of nodesCompuation cost  Base caseOur methodFigure 5.4: Cost of Computingbecause enhanced network coding is performed on a selected set of nodeswithin each cluster.ReliabilityOur method aims at minimizing the number of nodes that shall perform thenetwork coding operations. Therefore, we can take advantage of opportu-nities for fixed the network coding where possible. It is intuitive that asthe system size increases, random network coding on large number of nodecompromise the overall computational complexity and degrades the overallprobability of success.The probability that a random network coding problem is solvable de-pends on whether the global coding vector has a full rank. If the coefficientsare randomly chosen from a field Fq, then probability for a generation to beinvalid is at most |T ||q| . The extension of the Schwartz-Zippel theorem yieldsthe probability of success at each random coded node as follows:Pr(success) = (1− |T |q)where Pr(success) is the probability of success within the cluster of randomnetwork coding. The following theorem from [96] states the probability ofsuccess by a valid network code.Theorem 5.5.1 The probability of a random network code with coefficients1195.5. System Evaluationfrom field Fq being valid and being successfully decoded in a multicast con-nection problem with |T | number of receivers and |S| number of sources is(1 − |T |q )η where q > |S| and η is the number of intermediate links withassociated random coefficients.As depicted by Figure 5.5, in contrast to the base case scenario, whererandom network coding is used, our proposed method utilizes a fixed networkcoding approach where the coefficients are dependent on the private key.Therefore, the uncertainty about the existence of a solution for the systemis being resolved.0 5 10 15 20 25 30 35 400.80.820.840.860.880.90.920.940.960.981Number of nodesProbability of success  base case − 1 receiverbase case − 2 receiverbase case − 3 receiverbase case − 4 receiverour methodFigure 5.5: Probability of SuccessCostIn our mechanism, security server responsible for the private key generation,is in charge of calculating the transfer matrices as well as their inverses. Also,the inverse matrices should be transfered to the receivers. Finally and ineach iteration and receiving the coded data, each receiver needs to multiplyinverse matrices of the subnets that the data has been transfered. However,comparing to calculating the entire matrix of transfer for the entire network,and solving the network coding problem, our proposal costs less.120Chapter 6Privacy PreservativeContext-Aware SecuritySolution for Mobile DevicesThe technology, security and privacy requirements of the electric vehicle(EV) in the SG context, especially when the EV acts as mobile power stor-age, have gained much attention from the research community and marketrecently. This role of the EV is motivated by the increase in capacity of thepower storages in the EV. In this chapter, first we present different situationsthat an EV can be in the SG system and their privacy issues. In fact weconsider different contexts of an EV in the SG, and our mechanism preservesprivacy in all of the contexts. We provide two authentication schemes, firstone between the EV and a trusted SG server directly, and second one via anon-trusted third party entity with a robust privacy-preserving agenda.6.1 IntroductionThe growth of interest in EVs and implementation of the SG introduces anew collaborative domain in transportation and resource management. Inthe SG system, EVs, PEVs or hybrid PEVs (HPEV), receive charging powerfrom the SG network. However, EVs have recently gained attention aboutusing the battery power stored in the EV as a SG mobile power storage thatcan saves and carries the power energy. Since the EV is mobile, it can storethe power in one location and return the surplus back to the grid in anotherlocation (we will describe different situations that an EV can be in the SGsystem in Section 6.2).Although bringing ICT to grid infrastructure [1] and new concepts like“Electric Vehicle as Power Energy Storage” are aimed at improving thepower grid consumption and provision, they can be successfully supportthe new SG system implementation as long as the security and privacyconcerns of the stockholders, especially consumers, are appropriately and1216.2. Problem Definitionfully addressed [114, 115]. The survey presented in [116] describes charginginfrastructure and PHEV/PEV batteries, intelligent energy management,vehicle-to-grid (V2G) and its communication requirements. In [117], someof the vulnerabilities and security concerns of the infrastructure for PEVare reviewed. Han et al. [118] proposed a method to estimate the achiev-able power capacity for practical V2G services. In [119], a managementsystem was presented. It defined a temporary energy buffer that facilitatesincreased utilization of alternative energy sources. In this system EVs can beconsidered as distributed auxiliary batteries to support energy grids eitherin household domain or in a local energy network.Contribution: Our first contribution is a mutual authentication schemebetween the EV and the SG server that is followed by registration and bind-ing of the EV to a person/owner who is held accountable for the power costs.The second one is a privacy-preserving communication mechanism which uti-lizes the concept of pseudonymous communication to hide the identity of theEV (and its owner) from any third party in the SG system. For instance,a power station operator in case of receiving (buying) and returning back(selling) the power energy to the grid.The mechanism that we propose as V23PPA (vehicle to third partyprivacy-preserved authentication) assumes that originally the EV and util-ity server are authenticated using the V2GA (vehicle to grid authentication)scheme, which will be elaborated more in Section Problem DefinitionBased on the seven domains structure model presented in [1] and Chapter 1(in 1.4.1), electric power is delivered to the customer area (where the EV isnormally residing) via the distribution network. However, an EV can be inany of the six locations shown in Figure 6.1, which are referred as ChargingPoints (CPs):I. HAN: The EV is charging while connected inside the residence of theEV owner, as part of the HAN.II. BAN: The EV is charging inside the building complex in which theowner resides, which is equipped with a BAN.III. Host: The EV is connected to the power plug of a home other than theEV owner’s residence (e.g. the owner is a guest and visiting a friend).1226.2. Problem DefinitionHANBAN IANStationHostPublicDistributionFigure 6.1: Charging Points in Smart GridIV. Industry Area Network(IAN): The EV is being charged inside the com-mercial (industrial) building where the owner is working and the com-pany is providing the power charging services, so the EV is connectedto IAN.V. Public: Any public infrastructure that provides the power chargingservice to the visitors of the entity. For instance, a host commercialbuilding, a public parking spot or a shopping mall.VI. Station: Any third party power station that the EV can plug andreceive the power energy.Table 6.1: Power and Service ChargeSituation Service Credit Power Charge DebitI NIL Smart GridII Building Smart GridIII Host HostIV NIL/Company CompanyV Entity/Service provider Entity/Service providerVI Station Smart Grid1236.3. Literature ReviewIn any of the use cases that there is a need to give or take power to/fromEVs with authentication, there exists a transaction of charging or debitingthe EV owner’s account. For instance, when the EV receives the power froma host home, the host’s account is initially charged; however, the chargeshould be forwarded to the EV (owner’s account) and credited back to thehost’s account. Table 6.1 presents the appropriate account that in eachsituation should be accessed.When a person buys an EV, or somehow becomes in-charge of the EV,she/he needs to register the EV in the SG system. In order to perform thisregistration, the EV needs to (mutually) authenticate itself to the sever. Inthe first part of our proposal, we state the vehicle to grid authenticationscheme that covers this requirement. Referring to our discussion about thepower charging of the EV as well as the concept of using the EV as SGpower storage, the second part of our proposal is a mechanism for vehicle tothird party privacy-preserving communication/authentication scheme. Thethird party is an entity that provides the power charging services, e.g. astation or a host home. The V2GA mechanism refers to the vehicle iden-tification number (VIN) of the EV for identifying the EV; however, theV23PPA mechanism utilizes the pseudonym of the EV along with identitymanagement service provided by SG server in order to provide anonymityin communication. In fact, the SG back end, i.e. utility server, (trustedentity) is the only entity that can manage and map the user’s identity andpseudonyms to manage user account. The presented pseudonym identityof the vehicle is changing for any entity that the EV is being connected towhich includes any scenario such as charging or returning to the grid. Assoon as the EV leaves the entity (CP), the pseudonym is expired and a newone (which only the EV and the utility server are aware of it) will be used.6.3 Literature ReviewIn [120], authors concentrated on security in Vehicular Ad-Hoc Network(VANET) by using pseudonyms and determining their expiration times.In [121], the anonymity and unlinkability of vehicles is studied, in whichthe role of battery information and how it can influence vehicle mixing isstudied. The suggested model reduces the amount of transmitted data, aimsat anonymity for tracking protection. The methods presented in [122] and[58] are aimed at hiding the identity of the vehicle by using a pseudonymousidentity; however, the pseudonym is fixed (for 24 hours). Therefore, if anintruder can physically obtain the real identity of the EV once and prepare1246.3. Literature Reviewa mapping between the real identities and pseudonyms, he can still attackthe privacy of the vehicles by tracking the pseudonyms.Using IBC is proposed in [123] for designing an authentication schemefor the EV although their scope is the VANET platform. In this work, theauthors have used the pseudonym of the EV for the authentication, wherethe pseudonym has an expiry date. The issue of having an expiry date is, forinstance in our scope, that the EV may require to contact two third partiesduring the period that the pseudonym is not expired yet. Therefore, duringthat period, the EV can be traced via tracing the pseudonym. A similarwork is presented in [77] that uses IBC as well as pseudonym of the EV inVANET. Similar to the previous design in [123], this methods has an expirytime for the private key, which has the same issue as [123]. In [124] theauthors proposed to use the standard Authorization, Availability, Account-ability (AAA) infrastructure and Extensible Authentication Protocol (EAP)protocol for authentication and key management. Their method is proposedfor VANETs with intermittent connectivity. The contribution in [124] is touse pre-arrival authentication to Road Side Units (RSUs). The mobile nodeuses EAP-Transport Layer Security (EAP-TLS) to authenticate itself themost probable contacted RSUs in future. However the mechanism to findthe next RSU in the future has not been discussed. Moreover, the EAP pro-tocol needs several message exchanges and therefore is not very compatiblemethod for dynamic networks like VANET.In [125], a method for batch authentication and key exchange (ABAKA)between the vehicle and service providers is proposed. The focus in thiswork is to reduce the delay imposed by authentication and key exchangemechanism in order to minimize the security cost over the short-lived wire-less connectivity between moving vehicles and RSU. To provide anonymity,ABAKA also uses pseudonym IDs which are generated by the tamper proofon-board device. However, to verify a message, CP needs to know the secretkey of the on-board device. This key is supposed to have been placed inthe on-board unit during initial phase and is known to CP. Assuming thatthis value is uniquely dedicated to a vehicle, by using a pseudonym (whichprovides anonymity about the vehicle’s identity), it is not clear how the CPis able to verify the message with the matching secret value for that car.The authors in [126] proposed PAAVE, an anonymous authenticationmechanism in VANETs which considers Vehicle to Roadside (V2R) com-munication authentication using smart cards in vehicles. They have usedPbKE system in which the public key for every vehicle is signed by trustedauthority before being saved inside the vehicle. Their approach covers V2Rcommunication only. PAAVE is designed to provide anonymity for user but1256.4. Proposaltraceability is not addressed. Since the public key for vehicle is constant, athird party can trace the previous locations of a vehicle.Implementing the privacy preserving mechanism that deals with hidingthe footprint of the vehicle, especially when the vehicle is allowed to havemultiple identity, may lead to performing a Sybil attack by a maliciousEV, which is the scope of the work presented in [127]. However, in ourmechanism the EV can have a maximum of two identity (a real identity anda pseudonym) at each time, which prevents the attacker from performing aSybil attack.6.4 ProposalLet us consider the topology shown in Figure 6.2, and four shown states forthe EV:I. This the first time that an EV connect to the SG system, when the EVand SG server (SGS) perform a mutual authentication process.II. The EV connects to an entity, like a third part power station, (CP) toreceive the power from.SGSStation iStation jData Center214On the roadArea A3Figure 6.2: Electric Vehicle Communication with CP1266.4. ProposalIII. The EV is disconnected from the CP entity and is on the road beforeconnecting to another CP to receive (or deliver) the electric power.IV. The EV connects to the next CP for service.In this part, first we introduce our V2GA scheme that is designed forthe first state, followed by V23PPA mechanism that covers the second, thirdand fourth states.6.4.1 V2GA SchemeOur authentication scheme (V2GA) between the EV and SGS is presented inFigure 6.3. The V2GA scheme, which is an SRP based protocol, is designedhaving into account the following assumptions:A.1. When the owner of the EV receive the vehicle, she/he should registerthe EV to the SG system. In this stage, the owner should give her/hisrequired information along with the VIN of the EV to the SGS.A.2. The owner also keys in a simple (secret) password to the SGS as wellas the EV.ܸܫ ாܰ௏,ܣ ܽ ൌ ܴ݊݀ Ǥ ǡ ܣ ൌ ݃௔݉݋݀݌ Step# I II III ݒ݁ݎǡ ݏ݈ܽݐ ൌ ܮ݋݋݇ݑ݌ ܸܫ ாܰ௏ ݇ ൌ ܪ ݌ǡ ݃ ܾ ൌ ܴ݊݀ Ǥ ܤ ൌ ݇Ǥ ݒ݁ݎ ൅ ݃௕݉݋݀݌ݑ ൌ ܪ ܣǡ ܤ ܵ ൌ ܣ כ ݒ݁ݎ௨ ௕ܭ ൌ ܪܽݏ݄ ܵ ܯ ൌ ܪሺܪ ݌ ْܪ ݃ ǡܪ ܸܫ ாܰ௏ ǡ  ݏ݈ܽݐǡ ܣǡ ܤǡ ܭሻ ܲݎܭ଴ா௏ ൌ ݏ כ ܪ ܸܫ ாܰ௏ ݏ݈ܽݐǡ ܤǡܯǡ݁௄ ܨሺǤ ሻǡ ܲݎܭ଴ா௏ ǡ ܵ݅݃݊ ௉௥௄ೄಸೄ ܨ Ǥ ǡ ܲݎܭ଴ா௏  ݇ ൌ ܪ ݌ǡ ݃ ݑ ൌ ܪሺܣǡ ܤሻݔ ൌ ܪܽݏ݄ ݏ݈ܽݐǡ ݌ݓ ܵ ൌ ሺܤ െ ݇Ǥ ݃௫ሻሺ௔ା௨௫ሻܭ ൌ ܪܽݏ݄ ܵ ܪሺܪ ݌ ْܪ ݃ ǡܪ ܸܫ ாܰ௏ ǡݏ݈ܽݐǡ ܣǡ ܤǡ ܭሻ ǫൌܯ݌ݓ௡௘௪ ൌ ܪ ܣǡ ܤǡ ܭ ܣܿ݇ ൌ ܨ ݌ݓ௡௘௪  ܣܿ݇EV SGS Figure 6.3: Authentication Between EV and SG Server1276.4. ProposalA.3. The EV is equipped with a temper-proof device that can support thesecurity mechanism, e.g, by keeping the private key of the EV safe.A.4. The EV is equipped initially with the system parameters “g & p” aswell as the hash function H(.) for the SRP-based calculation.A.5. There are communication technology supports for communications be-tween the EV and SG server.A.6. ID of the SG servers (SGS) is known by the EV.A.7. The duties of the PKG is assigned to the SGS.A.8. As presented in Figure 6.2, the entities that play the role of the SGS,shared their data by saving them in the cloud, e.g. a data center.A.9. The system follows IBC and the public key and private key of eachentity can be calculated by (1.1) and (1.2).Our mutual authentications steps including the initial step are as follows:PreparationFollowed by entering the password pw by the owner of the EV, the connectedSGS picks a random value salt and calculates the verifier ver as per (6.1)and saves it in the database of the SGSs, located in the data center, asrecord of the EV consists of the VIN and the salt.ver = gH(salt,pw) mod p (6.1)Initialization step (I)The EV picks a random number A, calculates “a = gA mod p”, and sends aalong with its VIN to the SGS.SGS response step (II)SGS looks up the database and obtains the ver and salt aligned with thereceived VIN. Then, the SGS follows the tasks shown in Figure 6.3, and alsocalculates the original private key of the EV following the IBC technique, inwhich s is the secret value of the system, kept by the SGSs. The SGS sendsthe private key along with the salt, B and M to the EV while encrypts theprivate key with the constructed key K and signs them with its own private1286.4. Proposalkey. Note that, as per Figure 6.3, the SGS also sends system parameterset Parm(V INEV ) prepared for the EV, e.g. including the hash functionPsd(.), which we will use them for the authentication of the EV and thirdparties as part of the V23PPA mechanism (will be described shortly). Theentire secret values, as per our above mention assumption, will be saved inthe temper-proof device of the EV.Final step (III)First of all, the EV applies the hash function H(.) to ID of the SGS toobtain public key of the SGS and verifies the signature. Then, the EVcalculates the shared key K utilizing the received values salt and B, andverifies the key K based on received M from the SGS. Then, the EV decryptsthe received encrypted private key from the SGS using K. Beside, the EVcalculates the new password pwnew as “pwnew = H(A,B,K)”, applies thereceived function Psd(.) to obtain the Ack as “Ack = Psd(pwnew)” andsends it to SGS to verify finishing the algorithm. Note that, SGS is capableof calculating the values pwnew and Ack.Since the EV is a mobile node and for any reason may lose the connection,or its private key gets expired, therefore, the EV utilizes the new passwordpwnew and performs the V2GA protocol for the re-authentication. Also, theSGS reselects a saltnew and calculates the new verification value vernew via(6.1), and then saves them in the database for the next time authenticationof the EV.Table 6.2: DefinitionsItem DescriptionSGS Smart Grid Server.H(.) System one-way hash function for public key creation.Psd(.) One-way hash function for Pseudonymous creation ID.CPk Identification Number of the kth CP.V INj Vehicle Identification Number of the jth EV.PubK0j Master Public Key of the EV V INj .PrvK0j Master Private Key of the EV V INj .i The security state of the EV V INj , i = 1, 2, ....aj & bj PRNG Parameters of the EV V INj .Parm System parameter set.IDij ith Pseudonym (ID) of the EV V INj .PubKij ith Pseudonymous Public Key of the EV V INj .PrvKij ith Pseudonymous Private Key of the EV V INj .Crdtj The Credit Value of the EV V INj .1296.4. Proposal6.4.2 V23PPA SchemeAs the result of performing the V2GA mechanism, the EV has received itsprivate key and is able to communicate with any node. Indeed, all an EVneeds is the ID of the party, which calculates the public key of the party/nodevia (6.3) to establish a secure communication. In order to preserve theprivacy in this mentioned communication, we propose that the EV uses itspseudonym instead of its real identity (VIN). The parameters used in ourdesign are presented by Table 6.2. Our assumptions are as follows, basedon the involved parties in the system presented in Figure 6.2, which can beconsidered as part of the initialization phase of the system:B.1. There are communication technology supports for communications be-tween the SG server and CP, e.g. station, wired or wireless, betweenEV and SG server (wireless) as well as between EV and the chargingpoint (most likely wired).B.2. The system follows IBC in which the public key and private key of eachentity can be calculated by (1.1) and (1.2).B.3. The duties of the PKG is assigned to the SG server. ID of the SGserver (SGS) is known by the parties (The SGS that covers the area).B.4. Each CP has an ID (CPk) that is known by the SGS as well as by theEV that wants to be connected to the CP entity.B.5. The initial authentication has been already done, and each CP hasreceived the required system parameters and its own private key.To describe the mechanism, let us consider four stages presented in theFigure 6.2. Without loss of generality and refer to our discussion in Sec-tion 6.1, we consider the sixth situation of the EV (EV to Power StationCommunication) as per Table 6.1, which will cover other situations as well.First stage: registration of the EVIn this stage, the initial authentication is done between the EV and SGserver in its area, via V2GA scheme. Following to the initial authentication,the electric vehicle V INj receives the required system parameters (Parm),as per (6.2).Parm = {Psd(.), P rvK0j , aj , bj , P rvK1j , Crdtj} (6.2)1306.4. ProposalTable 6.3: Smart Grid Server DatabaseVIN salt ver EV State aj bj Pseudonym Credit ValueV IN1 salt1 ver1 i1 a1 b1 IDi11 Crdt1V IN2 salt2 ver2 i2 a2 b2 IDi22 Crdt2... ... ... ... ... ... ... ...V INn saltn vern in an bn IDinn Crdtn... ... ... ... ... ... ... ...An EV follows (1.1) to calculate public key of any party, including theSG server and each station (CP), e.g. CPk, that the EV wants to havecommunication with. In this system, the public key of the EV follows (6.3)aligned with the private key (6.4) that SGS generates for the EV.PubK0j = H(V INj) (6.3)PrvK0j = s× PubK0j = s×H(V INj) (6.4)The SGS entity also calculates the first pseudonym of the EV via (6.5)and then calculates the first pseudonymous private key of the EV as per(6.7) which is aligned with the EV first pseudonymous public key (6.6).SGS keeps these information in the database, as it is shown in Table 6.3, tobe used by other SGSs as well.ID1j = Psd(aj × V INj + bj) (6.5)PubK1j = H(ID1j ) (6.6)PrvK1j = s× PubK1j = s×H(ID1j ) (6.7)Second stage: EV and CP communicationThe first time that the EV communicates to a CP/station, it follows (6.5)to calculate its first pseudonym in order to introduce itself to the CP. Then,the EV pseudonymous private key is used by the EV to sign the requestwhile the CP follows (6.6) to obtain the pseudonymous public key of theEV to verify signature of the EV. At this state, the CP does not know thestate of EV (i). Indeed the CP/station only receives ID of the EV that ispseudonym of the EV.1316.5. Analysis and EvaluationAs soon as the massage consists of the EV pseudonym is received by theSGS, the SGS searches its database and obtains the real VIN. Then, SGSsends the credit of the EV to the CP (station) to make the CP and EVable to manage their required steps to charge the EV or receive the powerfrom the EV. The entire communications between the EV and CP are basedon the pseudonym of the EV. Note that in these communication the IBCsystem is used. Finally, the CP will let the SGS know the EV credit changes,in which the SGS will update its database accordingly.Third stage: on the road, between two CPsWhen the EV leaves a CP, updates its pseudonym and its public key for thenext connection point (CP). Precisely, if the EV state is i, the EV as wellas the SGS calculate the next pseudonym of the EV via (6.8).IDi+1j = Psd(aj × IDij + bj) (6.8)Furthermore, SGS calculates the new pseudonymous private key of theEV via (6.10) to be sent to the EV via the secure channel supported by theEV public/private key pair.PubKij = H(IDij) (6.9)PrvKij = s× PubKij = s×H(IDij) (6.10)Fourth stage: EV and next CP communicationThis stage is similar to the second stage, indeed, only the state of the systemis changed from i to “i+1”. Similarly, the EV uses its current pseudonym asID to contact to the new CP, in which has its current pseudonymous privatekey (state “i+ 1”) for the secure communication.6.5 Analysis and EvaluationIn this section, we analyze our design by reviewing the security and privacyattacks against our mechanisms. Furthermore, we evaluate the secrecy ofthe mechanism utilizing AVISPA, followed by studying the overall cost ofthe mechanism to analyze its performance.1326.5. Analysis and Evaluation6.5.1 Privacy CharacteristicsIn comparison to references models presented in Section 6.3, although thepseudonym and private key are proposed in [122] (and [58]), they only re-freshed the pseudonym and private key once a day (every 24 hours). There-fore, the adversary is able to trace the victim EV path (footprint) duringone day. Also, using the proposed model in [128] has the pre-assumptionof trusted station, which is not valid. The trust of the station needs to beanalyzed and managed e.g. based on proposed model in [129]. Stationsare only service providers that deliver the power receiving and charging theEVs although are not as secure/trusted as the SG back end infrastructure.Even if by establishing the rules and regulations to enforce them to keep thecustomer information private, still the leakage of the customer informationis the customers’ concern. In fact, letting the third party to have privateinformation of the customer decreases the cost of the social engineering at-tack, which can be easily performed by an adversary.6.5.2 Analyzing the AttacksOur V2GA mechanism has inherited the security features of the SRP pro-tocol, which is secure versus most of the well-known attacks. For instance,since we use the verifier in the V2GA mechanism, it helps preventing theunknown key share attack. Also, using the verifier and salt make our mech-anism secure versus the man-in-the-middle (MITM) attack as well as com-promised impression attack. Also the packets in step II, which delivers theprivate key to the EV, is encrypted that makes the mechanism secure versusKey privacy & insider attack. Since all the time, the entity use a randomnumber, the mechanism is secure versus reply attack, and by assuming therandom key has an enough bit size, the mechanism is secure versus brute-force, on-line dictionary and off-line dictionary attacks. Finally, since wehash the password to obtain the verifier, and then hash the random valuesand other exchanged items as per V2GA mechanism, steps, the mechanismis secure versus denning-sacco as well as ephemeral key compromise imper-sonation attacks.Theorem 6.5.1 The main privacy attack as per our scope is tracing theEV, which the V23PPA mechanism is secure versus this attack.Proof Tracing the EV can be done only via the real identity of the vehicle.Referring to a pseudonym of the EV does not give any information since1336.5. Analysis and Evaluationit is the product of a hash (one-way) function. Therefore, the attackercannot obtain the past pseudonym. Furthermore, the next pseudonym is theproduct of the current pseudonym in combination with two other parameter“aj & bj” that are only known by the EV and SGS. Therefore, the attackeris not able to calculate the next pseudonym neither. Consequently, knowingonly one pseudonym does give any information to the attacker about thepast and next pseudonyms, and therefore the attacker is not able to tracewhere the EV was and/or will be. As a result, the mechanism is secureversus this attack.6.5.3 Formal Validation Using Software ToolIn this analysis, first we evaluate the V2GA mechanism, and then use the thepassword generated as the result of the first round, and re-authenticate theparties. The result of the evaluation are presented in Figure 6.4a and 6.4b,which evaluate the secrecy of the mechanism. Furthermore, the requiredHLPSL codes are shown in Appendix A.6.5.4 Cost AnalysisPrivacy is one of the major concerns of the SG implementation, in all levels.In fact, it does not matter how much the new smart power grid, SG, canbe efficient and save money in customer and/or providers side, as long as% OFMC               % Version of 2006/02/13       SUMMARY                SAFE               DETAILS                BOUNDED_NUMBER_OF_SESSIONS     PROTOCOL              /ubc/ece/home/vl/grads/hasennic/   Desktop/avispa-1.1/testsuite/    results/PEV-Final.if                        GOAL                  as_specified           BACKEND                OFMC               COMMENTS              STATISTICS               parseTime: 0.00s           searchTime: 0.79s           visitedNodes: 51 nodes        depth: 6 plies                          (a) OFMCSUMMARY                SAFE                               DETAILS                BOUNDED_NUMBER_OF_SESSIONS       TYPED_MODEL                           PROTOCOL                               /ubc/ece/home/vl/grads/hasennic/   Desktop/avispa-1.1/testsuite/    results/PEV-Final.if                         GOAL                  As Specified                            BACKEND                CL-AtSe                              STATISTICS                               Analysed   : 28 states        Reachable  : 18 states        Translation: 94.52 seconds       Computation: 0.02 seconds     (b) ATSEFigure 6.4: AVISPA Results1346.5. Analysis and Evaluationthe privacy concerns of the stockholders are not fully addressed, the societydoes not accept the SG implementation. In our proposed mechanism, weonly keep two private keys in the EV each time, which makes it efficientfrom the capacity and resource point of view. Also, in each state changing,the EV needs to run a hash function once (Psd(.)), and the SGS needs torun two hash functions (Psd(.) & H(.)), once each, that are the cost ofour mechanism. Although this is an efficient mechanism and system, andefficiency should be addressed all the time, the privacy cannot and shouldnot be sacrificed as cost of the efficiency and improvement.6.5.5 Summary of Security AnalysisOur proposed V2GA mechanism efficiently authenticates the EV to SGS ina mutual fashion, to register the EV based on the real identity of the EV.From then, the EV communicates with any CP for receiving or returning thepower station utilizing its dynamic pseudonym. The pseudonym is refreshedby any connection of the EV to a plug, e.g. a station, which prevents aneavesdropper/attacker to trace the EV. The used pseudonym by the EV ineach CP can be mapped to the real entity of the EV only by the EV andSGS. Precisely, since we use a hash function to obtain the new pseudonymfrom the current one, and the hash function is a one-way function, theadversary cannot find the past pseudonym. On the other hand, since the newpseudonym is application of the hash function on a pseudo random numbergenerator with seed value of the real identity of the EV, the adversary isnot able to calculate the future pseudonym neither. The pseudonym of theEV is only valid and active between each two plugs (CPs), which shows ourmechanism fully delivers forward and backward secrecies.6.5.6 Other BenefitsOne of the problems that motivated the researchers to propose a privacy-preserving mechanisms for EV in the context of SG is monitoring status ofthe battery of the EVs in an area to manage participation of the EVs inpower distribution in the area. Indeed, it schedules the returning the powerback to the grid and/or schedules charging the EV, normally as part of anoptimization problem. For instance our references in this thesis such as [118],[121], [130], [122] and [58], dealt with this problem, which we have reviewpartially in this chapter. Our mechanism indeed responds to this problemas well. To be more precise, the monitoring agent/application collects theinformation, which consists of the location, ID and status of the battery1356.5. Analysis and Evaluationof the EVs. An EV in our proposed system, and between every two sta-tions/plugs, uses pseudonym instead of the VIN. Therefore, the informationcollected by the monitoring system is based on the pseudonym. In case ofdirecting an EV to a CP to returns the power back to the grid, the EV willrefresh its pseudonym after leaving the station, and will starts using the newpseudonym from that point of view in communication with the monitoringentity as well. Hence the monitoring agent is not able to trace the vehiclesince there is no connection between the new and old pseudonyms of theEV from the monitoring entity point of view. Consequently, our proposedmechanism maintains the privacy of the EVs in this application.136Chapter 7Conclusion and FutureWorksReferring to Chapter 1, this thesis is aimed at improving the efficiency ofauthentication and key management, and brought into account the privacyof the users.7.1 ConclusionUnderstanding the smart grid concept is related to the accuracy of informa-tion about the power consumption, actual and planned, by the consumers.This data needs to be collected for billing purposes and efficient power pro-visioning. In Chapter 2 we addressed this requirement by providing effi-cient and secure authentication and key management mechanisms tailoredfor communication between smart appliances and smart meters, as well asbetween smart meters and smart grid server in utility network.In order to efficiently plan and consume (generate) the power by cus-tomers (suppliers), they need to collaborate with each other as a group. Tomake this communication secure, having a group key management is essen-tial. In Chapter 3 we addressed this requirement by providing an efficientcluster-based group key mechanism that handles forward and backward se-crecies.The smart grid system needs to send some controlling commands bysmart grid controllers to the smart home appliances. These controllers canbe located in different layers, such as the home level, building level, neigh-bourhood level, and central smart grid controller unit level. Although theyall can send the controlling commands, in case of emergency to turn theappliances off, the hierarchy should be preserved between them as well. InChapter 4 we presented our multi-layer key mechanism that maintains thisrequirement efficiently.The second part of this thesis concentrated on privacy, compared to thefirst that was mainly about the security. Although the power consumption1377.2. Suggested Future Worksinformation is essential in the smart grid system, and mostly are encryptedto secure them, the user information can be traced from even encrypted datathat jeopardizes user privacy. In Chapter 5 we utilized the enhanced networkcoding for this purpose and provided our privacy preserved mechanism. Ourproposed design preserves anonymity, unlinkability, unobservablity, and un-detectablity in collecting power consumption information in the AdvancedMetering Infrastructure.One of the smart ideas in the smart grid system, motivated by increas-ing capacity of the power storages in electric vehicles, is using the electricvehicles as mobile power storages. There are different options for an electricvehicle to plug in and receive/return the power from/to the grid, which aremostly owned by third parties, who could be untrusted, or at least curi-ous, and want to trace the electric vehicle. Maintaining the user privacy inthis situation was the aim of our proposal presented in Chapter 6, our lastchapter of the thesis.7.2 Suggested Future WorksIn addition to the contributions that have been conducted during this disser-tation, which was mainly founded by NSERC Smart Grid research projectat UBC, the following directions and steps are suggested:I. Cryptography: Initially we enhanced the identity based cryptography(IBC) and provided a conceptual solution called enhanced IBC (EIBC).The proposed mechanism is used in our other work, for instance ourproposal in Chapter 2. However, more improvement and works can bedone in this area, and a detail design of the mechanism in mathemat-ics needs to be conducted. EIBC can improve the key managementvery well, as it has shown partially in Chapter 2 and related pub-lished papers as well. We even proposed a solution based on EIBC inInformation-Centric Networking also 2. After a few tests and re-design,EIBC showed its benefits very well, and it can be developed more tobe used in other applications and areas.II. Our design presented in Chapter 2, efficient authentication and keymanagement mechanisms, mainly developed for a mesh topology net-work used in the smart grid system. After detail design of the EIBC2H. Nicanfar, P. TalebiFard, C. Zhu and V.C.M. Leung, “Efficient Security Solutionfor Information-Centric Networking”, in Proc. IEEE SymCPS, Beijing, China, Aug. 20131387.2. Suggested Future Works(our above mentioned suggestion), the design of our mechanisms pre-sented in Chapter 2 can be revisited and improved. Moreover, as it canbe seen from our publications supporting Chapter 2, we proposed twodesigns, one for inside a home and another one for outside the home(the one for outside of the HAN is discussed in this thesis). A trustmodel around smart meter (or a home gateway) can be added to thesetwo designs, and make a more enhanced and completed design thatcovers from a home appliances up to the utility server.III. The group key protocol proposed in Chapter 3 can be extended to beelliptic curve cryptography (ECC) based design and to be more efficientand to have other benefits of the ECC based approaches as well. Forinstance, especially in a light and efficient communication and to use asmaller key size, the ECC based design can be more fit to address theefficiency.IV. The multi-layer ECC based design presented in Chapter 4 is a com-pleted and detail proposal. All can be added to improve it, is to run atest for instance in a test bed facility, and as per outcome, modify andimprove the design accordingly.V. Using other techniques from other areas, such as network coding (NC),to improve or even maintain a security (and privacy) related solutionis an interesting approach. The reason is that e.g. in case of usingNC; the NC area by itself is improving and has its own benefits incommunication. So, applying it to a security and/or privacy mecha-nism, as we used in Chapter 5, will deliver an enhanced solution, whichwill maintain better network performance and enhancement (becauseof NC itself) as well as preserve security/privacy requirements. Weprovided two mechanisms that use NC. One addresses privacy, as itis described and presented in Chapter 5, and the second one providessecurity3. To be more precise, our second work focused on confiden-tiality of data transmission. In fact, we only provided the initial work,and more improvement needs to be added to make the second one acompleted work as well. Both of the works can be much improved byapplying new enhancements coming from the NC development area.VI. In Chapter 6, we presented our privacy preservative security solution3H. Nicanfar, A. Alasaad, P. TalebiFard and V.C.M. Leung, “Network Coding BasedEncryption System for Advanced Metering Infrastructure”, in Proc. IEEE ICCCN, Nas-sau, Bahamas, July 20131397.2. Suggested Future Worksfor mobile devices, which in the chapter, we presented our solution forpower electric vehicles in the SG context. We also presented our appliedsolution in mobile devices in the heterogeneous network (Hetnet) as persupporting papers of the chapter4. Now-a-day, the privacy is a seriousconcern of the users and society as well as governments (Chapter 1).The proposed solution can be more enhanced by design a privacy-aware secure mechanism to manage credits between the entities, leveraging the electronic money concept. Also the communicationsbetween an electric vehicle and smart grid server (trusted entity) aftereach connection with a contact point can be improved.7.2.1 Future Technology and our MechanismsMost parts of our contributions in this thesis are about the efficiency. Al-though the new technology can solve e.g. the smart meters or appliancesissues in terms of limited computing capacity, our mechanism still can beused in other areas such as sensor networks or Internet of things. In fact, inany environments that entities have low computing capacities, our efficientmechanisms will be good answer to the computing constraints.4H. Nicanfar, J. Hajipour, F. Agharebparast, P. TalebiFard and V.C.M. Leung,“Privacy-Preserving Handover Mechanism in 4G”, in Proc. IEEE CNS, Washington, DC,Oct. 2013140Bibliography[1] NIST Smart Grid, Cyber Security Working Group, “Introduction toNISTIR 7628 Guidelines for Smart Grid Cyber Security,” Guideline,Sep. 2010. [Online]. Available:[2] W. Diffie and M. Hellman, “New directions in cryptography,” IEEETransactions on Information Theory, vol. 22, no. 6, pp. 644–654, 1976.[3] R. Rivest, A. Shamir, and L. Adleman, “A method for obtaining digi-tal signatures and public-key cryptosystems,” Communications of theACM, vol. 21, no. 2, pp. 120–126, 1978.[4] A. Shamir, “Identity-based Cryptosystems and Signature Schemes,”in Advances in CryptologyCRYPTO 1984. Springer, 1984, pp. 47–53.[5] D. Boneh and M. Franklin, “Identity-based encryption from the Weilpairing,” in Advances in CryptologyCRYPTO 2001. Springer, 2001,pp. 213–229.[6] A. Koblitz, N. Koblitz, and A. Menezes, “Elliptic curve cryptography:The serpentine course of a paradigm shift,” Journal of Number Theory,vol. 131, no. 5, pp. 781–814, 2011.[7] M. Strangio, “Efficient diffie-hellmann two-party key agreement pro-tocols based on elliptic curves,” in ACM symposium on Applied com-puting. ACM, 2005, pp. 324–331.[8] A. Muniyandi, R. Ramasamy et al., “Password based remote authen-tication scheme using ecc for smart card,” in International Conferenceon Communication, Computing & Security. ACM, 2011, pp. 549–554.[9] H. Boumerzoug, B. Amar Bensaber, and I. Biskri, “A key managementmethod based on an avl tree and ecc cryptography for wireless sensornetworks,” in 7th ACM symposium on QoS and security for wirelessand mobile networks. ACM, 2011, pp. 57–62.141Bibliography[10] S. Wang, Z. Cao, M. Strangio, and L. Wang, “Cryptanalysis and im-provement of an elliptic curve diffie-hellman key agreement protocol,”IEEE Commu. Letters, vol. 12, no. 2, pp. 149–151, 2008.[11] E. Yooni and K. Yoo, “A new elliptic curve diffie-hellman two-partykey agreement protocol,” in 7th International Conference on ServiceSystems and Service Management (ICSSSM). IEEE, 2010, pp. 1–4.[12] T. ElGamal, “A public key cryptosystem and a signature scheme basedon discrete logarithms,” in Advances in Cryptology. Springer, 1985,pp. 10–18.[13] “IEEE Standard Specifications for Password-Based Public-Key Cryp-tographic Techniques,” IEEE Std 1363.2-2008, 2009.[14] “Password-authenticated key exchange (PAK) protocol,” Telecommu-nication Standardization Sector of International TelecommunicationUnion (ITU-T), Recommendation X.1035,.[15] T. Wu et al., “The secure remote password protocol,” in InternetSociety Symposium on Network and Distributed System Security, 1998.[16] ——, “SRP-6: Improvements and Refinements to the Secure RemotePassword Protocol,” P1363.2 working group,.[17] M. Burmester and Y. Desmedt, “A secure and efficient conferencekey distribution system,” in Advances in CryptologyEUROCRYPT’94.Springer, 1995, pp. 275–286.[18] NIST Smart Grid, Cyber Security Working Group, “Guidelines forSmart Grid Cyber Security: Vol. 2, Privacy and the Smart Grid,”Guideline, Aug. 2010. [Online]. Available:[19] Y. Huang, S. Tang, and J. Yuan, “Steganography in inactive framesof voip streams encoded by source codec,” IEEE Transactions on In-formation Forensics and Security, vol. 6, no. 2, pp. 296–306, 2011.[20] P. Kamat, Y. Zhang, W. Trappe, and C. Ozturk, “Enhancing source-location privacy in sensor network routing,” in 25th IEEE Interna-tional Conference on Distributed Computing Systems (ICDCS 2005).IEEE, 2005, pp. 599–608.[21] H. Wang, B. Sheng, and Q. Li, “Privacy-aware routing in sensor net-works,” Computer Networks, vol. 53, no. 9, pp. 1512–1529, 2009.142Bibliography[22] B. Blakley, “What is Privacy, Realy?” Digital ID World, Presentation,Oct. 23, 2006. [Online]. Available: is privacy.html.[23] A. Pfitzmann and M. Hansen, “A terminologyfor talking about privacy by data minimization:Anonymity, unlinkability, undetectability, unobservability,pseudonymity, and identity management,” Terminology v0.34.pdf, Aug. 2010, v0.34.[Online]. Available: v0.34.pdf[24] “AVISPA-Automated Validation of Internet Security Protocols,”2006. [Online]. Available:[25] D. Dolev and A. Yao, “On the security of public key protocols,” IEEETransactions on Information Theory, vol. 29, no. 2, pp. 198–208, 1983.[26] P. McDaniel and S. McLaughlin, “Security and privacy challenges inthe smart grid,” IEEE Security & Privacy, vol. 7, no. 3, pp. 75–77,2009.[27] Z. Fan, P. Kulkarni, S. Gormus, C. Efthymiou, G. Kalogridis,M. Sooriyabandara, Z. Zhu, S. Lambotharan, and W. H. Chin, “SmartGrid Communications: Overview of Research Challenges, Solutions,and Standardization Activities,” IEEE Commun. Surveys & Tutorials,vol. 15, no. 1, pp. 21–38, 2013.[28] J. Wang and V. Leung, “A survey of technical requirements and con-sumer application standards for ip-based smart grid ami network,”in International Conference on Information Networking (ICOIN).IEEE, 2011, pp. 114–119.[29] T. M. Chen, “Survey of cyber security issues in smart grids,” CyberSecurity, Situation Management, and Impact Assessment II; and Vi-sual Analytics for Homeland Defense and Security II (part of SPIEDSS 2010), pp. 77 090D–1, 2010.[30] P. D. Ray, R. Harnoor, and M. Hentea, “Smart power grid security: Aunified risk management approach,” in Security Technology (ICCST),2010 IEEE International Carnahan Conference on, 2010, pp. 276–285.[31] H. Gharavi and B. Hu, “Multigate communication network for smartgrid,” Proceedings of the IEEE, vol. 99, no. 6, pp. 1028–1045, 2011.143Bibliography[32] M. Fouda, Z. Fadlullah, and N. Kato, “Assessing attack threat againstzigbee-based home area network for smart grid communications,” inInternational Conference onComputer Engineering and Systems (IC-CES). IEEE, 2010, pp. 245–250.[33] H. Kim, Y. Kim, K. Yang, and M. Thottan, “Cloud-based demandresponse for smart grid: Architecture and distributed algorithms,”in IEEE International Conference on Smart Grid Communications(SmartGridComm). IEEE, 2011, pp. 398–403.[34] A. Patel, J. Aparicio, N. Tas, M. Loiacono, and J. Rosca, “Assessingcommunications technology options for smart grid applications,” inSmart Grid Communications (SmartGridComm), 2011 IEEE Inter-national Conference on. IEEE, 2011, pp. 126–131.[35] S. Karnouskos, “Crowdsourcing information via mobile devices as amigration enabler towards the smartgrid,” in Smart Grid Communi-cations (SmartGridComm), 2011 IEEE International Conference on.IEEE, 2011, pp. 67–72.[36] M. Alizadeh, A. Scaglione, R. J. Thomas, and D. Callaway, “Informa-tion infrastructure for cellular load management in green power de-livery systems,” in Smart Grid Communications (SmartGridComm),2011 IEEE International Conference on. IEEE, 2011, pp. 13–18.[37] V. C. Gungor, D. Sahin, T. Kocak, S. Ergut, C. Buccella, C. Cecati,and G. P. Hancke, “Smart grid technologies: communication tech-nologies and standards,” Industrial informatics, IEEE transactionson, vol. 7, no. 4, pp. 529–539, 2011.[38] K. De Craemer and G. Deconinck, “Analysis of state-of-the-art smartmetering communication standards,” in Proceedings of the 5th YoungResearchers Symposium, 2010.[39] P. P. Parikh, M. G. Kanabar, and T. S. Sidhu, “Opportunities andchallenges of wireless communication technologies for smart grid appli-cations,” in Power and Energy Society General Meeting, 2010 IEEE.IEEE, 2010, pp. 1–7.[40] C. Gomez and J. Paradells, “Wireless home automation networks:A survey of architectures and technologies,” IEEE CommunicationsMagazine, vol. 48, no. 6, pp. 92–101, 2010.144Bibliography[41] T. Zhang, W. Lin, Y. Wang, S. Deng, C. Shi, and L. Chen, “The designof information security protection framework to support smart grid,”in Power System Technology (POWERCON), 2010 International Con-ference on, Oct 2010, pp. 1–5.[42] W. Yanliang, D. Song, L. Wei-Min, Z. Tao, and Y. Yong, “Researchof electric power information security protection on cloud security,”in International Conference on Power System Technology (POWER-CON). IEEE, 2010, pp. 1–6.[43] R. Zhang, Z. Zhao, and X. Chen, “An overall reliability and securityassessment architecture for electric power communication network insmart grid,” in Power System Technology (POWERCON), 2010 In-ternational Conference on, Oct 2010, pp. 1–6.[44] D. Wei, Y. Lu, M. Jafari, P. Skare, and K. Rohde, “An integratedsecurity system of protecting smart grid against cyber attacks,” inInnovative Smart Grid Technologies (ISGT). IEEE, 2010, pp. 1–7.[45] J. Zerbst, M. Schaefer, and I. Rinta-Jouppi, “Zone principles as cybersecurity architecture element for smart grids,” in IEEE PES Inno-vative Smart Grid Technologies Conference Europe (ISGT Europe).IEEE, 2010, pp. 1–8.[46] Z. Lu, X. Lu, W. Wang, and C. Wang, “Review and evaluationof security threats on the communication networks in the smartgrid,” in MILITARY COMMUNICATIONS CONFERENC (MIL-COM). IEEE, 2010, pp. 1830–1835.[47] Y. Wang, W. Lin, and T. Zhang, “Study on security of wireless sensornetworks in smart grid,” in 2010 International Conference on PowerSystem Technology, 2010, pp. 1–7.[48] C. Efthymiou and G. Kalogridis, “Smart grid privacy via anonymiza-tion of smart metering data,” in First IEEE International Conferenceon Smart Grid Communications (SmartGridComm). IEEE, 2010,pp. 238–243.[49] E. Ayday and S. Rajagopal, “Secure, intuitive and low-cost deviceauthentication for smart grid networks,” in IEEE Consumer Com-munications and Networking Conference (CCNC). IEEE, 2011, pp.1161–1165.145Bibliography[50] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, andW. Polk, “Internet X. 509 public key infrastructure certificate andcertificate revocation list (CRL) profile,” 2008.[51] Z. Zhang and Q. Zhang, “Verifier-based password authenticated keyexchange protocol via elliptic curve,” in IEEE International Con-ference on Information Theory and Information Security (ICITIS).IEEE, 2010, pp. 407–410.[52] H. Nicanfar and V. C. Leung, “EIBC: Enhanced Identity-Based Cryp-tography, a Conceptual Design,” in IEEE InternationalSystems Con-ference (SysCon). IEEE, 2012, pp. 1–7.[53] S. Kim, E. Kwon, M. Kim, J. Cheon, S. Ju, Y. Lim, and M. Choi, “ASecure Smart-Metering Protocol Over Power-Line Communication,”IEEE Transactions on Power Delivery, vol. 26, no. 4, pp. 2370–2379,2011.[54] J. Kamto, L. Qian, J. Fuller, and J. Attia, “Light-weight key distribu-tion and management for advanced metering infrastructure,” in IEEEGLOBECOM Workshops (GC Wkshps). IEEE, 2011, pp. 1216–1220.[55] F. Zhao, Y. Hanatani, Y. Komano, B. Smyth, S. Ito, and T. Kam-bayashi, “Secure authenticated key exchange with revocation for smartgrid,” in IEEE PES Innovative Smart Grid Technologies (ISGT).IEEE, 2012, pp. 1–8.[56] X. He, M. Pun, and C. Kuo, “Secure and efficient cryptosystem forsmart grid using homomorphic encryption,” in IEEE PEIS nnovativeSmart Grid Technologies (ISGT). IEEE, 2012, pp. 1–8.[57] J. Xia and Y. Wang, “Secure Key Distribution for the Smart Grid,”IEEE Transactions on Smart Grid, vol. 3, no. 3, pp. 1437–1443, 2012.[58] H. Tseng, “A secure and privacy-preserving communication protocolfor v2g networks,” in IEEE Wireless Communications and NetworkingConference (WCNC). IEEE, 2012, pp. 2706–2711.[59] Q. Gao, “Biometric authentication in Smart Grid,” in InternationalEnergy and Sustainability Conference (IESC). IEEE, 2012, pp. 1–5.[60] S. Das, Y. Ohba, M. Kanda, D. Famolari, and S. Das, “A key man-agement framework for ami networks in smart grid,” IEEE Commu-nications Magazine, vol. 50, no. 8, pp. 30–37, 2012.146Bibliography[61] J. Wang, M. A. Biviji, and W. M. Wang, “Lessons learned from smartgrid enabled pricing programs,” in Power and Energy Conference atIllinois (PECI), 2011 IEEE. IEEE, 2011, pp. 1–7.[62] Z. Vale, H. Morais, and H. Khodr, “Intelligent multi-player smart gridmanagement considering distributed energy resources and demand re-sponse,” in Power and Energy Society General Meeting, 2010 IEEE.IEEE, 2010, pp. 1–7.[63] E. Heiskanen and K. Matschoss, “Exploring emerging customer needsfor smart grid applications,” in Innovative Smart Grid Technologies(ISGT Europe), 2011 2nd IEEE PES International Conference andExhibition on. IEEE, 2011, pp. 1–7.[64] S. Rusitschka, K. Eger, and C. Gerdes, “Smart grid data cloud: Amodel for utilizing cloud computing in the smart grid domain,” inFirst IEEE International Conference on Smart Grid Communications(SmartGridComm). IEEE, 2010, pp. 483–488.[65] Y. L. Sun and K. R. Liu, “Analysis and protection of dynamic member-ship information for group key distribution schemes.” IEEE Transac-tions on Information Forensics and Security, vol. 2, no. 2, pp. 213–226,2007.[66] D. Choi, H. Kim, D. Won, and S. Kim, “Advanced key-managementarchitecture for secure scada communications,” Power Delivery, IEEETransactions on, vol. 24, no. 3, pp. 1154–1163, 2009.[67] G. Yao, H. Wang, and D. Feng, “A group pake protocol using dif-ferent passwords,” in International Conference on Networks Security,Wireless Communications and Trusted Computing (NSWCTC), vol. 1.IEEE, 2009, pp. 270–273.[68] S. Jarecki, J. Kim, and G. Tsudik, “Flexible robust group key agree-ment,” Parallel and Distributed Systems, IEEE Transactions on,vol. 22, no. 5, pp. 879–886, 2011.[69] Y.-H. Lin, A. Studer, H.-C. Hsiao, J. M. McCune, K.-H. Wang,M. Krohn, P.-L. Lin, A. Perrig, H.-M. Sun, and B.-Y. Yang, “Spate:small-group pki-less authenticated trust establishment,” in Proceed-ings of the 7th international conference on Mobile systems, applica-tions, and services. ACM, 2009, pp. 1–14.147Bibliography[70] M. Wang, J. Pan, and J. Wang, “Password-based group authenti-cated key exchange protocol: From 3-party to group,” in InternationalConference on Network Computing and Information Security (NCIS),vol. 1. IEEE, 2011, pp. 239–241.[71] Y. Chen and G. Yang, “Efficient and secure group key managementbased on EBS and attribute encryption,” in IEEE International Con-ference on Computer Science and Automation Engineering (CSAE),vol. 2. IEEE, 2011, pp. 661–665.[72] N. Mailloux, A. Miri, and M. Nevins, “Forward secure identity-basedkey agreement for dynamic groups,” in Ninth Annual InternationalConference on Privacy, Security and Trust (PST). IEEE, 2011, pp.102–111.[73] J. Teng and C. Wu, “A provable authenticated certificateless groupkey agreement with constant rounds,” Journal of Communicationsand Networks, vol. 14, no. 1, pp. 104–110, 2012.[74] E. Konstantinou, E. Klaoudatou, and P. Kamparmpakis, “Perfor-mance evaluation of id-based group key agreement protocols,” inAvailability, Reliability and Security (ARES), 2011 Sixth InternationalConference on. IEEE, 2011, pp. 377–384.[75] P. Sakarindr and N. Ansari, “Survey of security services on groupcommunications,” Information Security, IET, vol. 4, no. 4, pp. 258–272, 2010.[76] E. Klaoudatou, E. Konstantinou, G. Kambourakis, and S. Gritza-lis, “A survey on Cluster-Based Group Key Agreement protocols forWSNs,” IEEE Communications Surveys & Tutorials, vol. 13, no. 3,pp. 429–442, 2011.[77] Z. Sun and J. Ma, “Efficient key management for advanced distribu-tion automation system,” in 2nd IEEE International Conference onNetwork Infrastructure and Digital Content. IEEE, 2010, pp. 794–798.[78] J. Kim and H. Choi, “An efficient and versatile key management pro-tocol for secure smart grid communications,” in IEEE Wireless Com-munications and Networking Conference (WCNC). IEEE, 2012, pp.1823–1828.148Bibliography[79] D. Dolev and A. Yao, “On the security of public-key protocols,” IEEETransactions Information Theory, vol. 29.[80] M. Fouda, Z. Fadlullah, N. Kato, R. Lu, and X. Shen, “Towards alight-weight message authentication mechanism tailored for smart gridcommunications,” in IEEE Conference on Computer CommunicationsWorkshops (INFOCOM WKSHPS). IEEE, 2011, pp. 1018–1023.[81] Q. Li and G. Cao, “Multicast authentication in the smart grid withone-time signature,” IEEE Transactions on Smart Grid, vol. 2, no. 4,pp. 686–696, 2011.[82] W. Juang, S. Chen, and H. Liaw, “Robust and efficient password-authenticated key agreement using smart cards,” IEEE Transactionson Industrial Electronics, vol. 55, no. 6, pp. 2551–2556, 2008.[83] D. Xiao-fei, M. Chuan-gui, and C. Qing-feng, “Password authenticatedkey exchange protocol with stronger security,” in First InternationalWorkshop on Education Technology and Computer Science (ETCS),vol. 2. IEEE, 2009, pp. 678–681.[84] L. Liu and Z. Cao, “Improvement of one password-based authenti-cated key exchange protocol,” in Second International Symposium onInformation Science and Engineering (ISISE). IEEE, 2009, pp. 372–375.[85] C. Hauser, “Trust research to address uncertainty in security forthe smart grid,” in IEEE PES Innovative Smart Grid Technologies(ISGT). IEEE, 2012, pp. 1–2.[86] P. Jokar, H. Nicanfar, and V. C. M. Leung, “Specification-based In-trusion Detection for Home Area Networks in Smart Grids,” in IEEESmartGridComm, Brussels, Belgium, Oct. 2011.[87] P. Kulkarni, S. Gormus, Z. Fan, and F. Ramos, “Ami mesh networksapractical solution and its performance evaluation,” IEEE Transactionson Smart Grid, vol. 3, no. 3, pp. 1469–1481, 2012.[88] Z. Fan, P. Kulkarni, S. Gormus, C. Efthymiou, G. Kalogridis,M. Sooriyabandara, Z. Zhu, S. Lambotharan, and W. H. Chin, “Smartgrid communications: Overview of research challenges, solutions,and standardization activities,” Communications Surveys & Tutori-als, IEEE, vol. 15, no. 1, pp. 21–38, 2013.149Bibliography[89] A. Rossello-Busquet, “G. hnem for AMI and DR,” in InternationalConference on Computing, Networking and Communications (ICNC).IEEE, 2012, pp. 111–115.[90] J. Shi, J. Wan, H. Yan, and H. Suo, “A survey of cyber-physicalsystems,” in International Conference on Wireless Communicationsand Signal Processing (WCSP). IEEE, 2011, pp. 1–6.[91] V. Mohanty, D. Moliya, C. Hota, and M. Rajarajan, “Secure Anony-mous Routing for MANETs Using Distributed Dynamic Random PathSelection,” Intell. and Security Informatics, pp. 65–72, 2010.[92] A. Pfitzmann and M. Hansen, “A terminology for talking aboutprivacy by data minimization: Anonymity, unlinkability, unde-tectability, unobservability, pseudonymity, and identity management,”URL: http://dud. inf. tu-dresden. de/literatur/Anon Terminology v0,vol. 34, 2010.[93] S. Li, R. Yeung, and N. Cai, “Linear network coding,” IEEE Trans-actions on Information Theory, vol. 49, no. 2, pp. 371–381, 2003.[94] R. Koetter and M. Me´dard, “An algebraic approach to network cod-ing,” IEEE/ACM Transactions on Networking, vol. 11, no. 5, pp. 782–795, 2003.[95] P. A. Chou and Y. Wu, “Network coding for the internet and wirelessnetworks,” IEEE Signal Processing Magazine, vol. 24, no. 5, pp. 77–85,2007.[96] T. Ho, M. Me´dard, R. Koetter, D. R. Karger, M. Effros, J. Shi, andB. Leong, “A random linear network coding approach to multicast,”IEEE Transactions on Information Theory,, vol. 52, no. 10, pp. 4413–4430, 2006.[97] P. Bao-xing, Y. Lu-ming, W. Wei-ping, and X. Xiao, “Linear NetworkCoding Construction for Multi-Source Multicast Network,” in FirstInternational Workshop on Education Technology and Computer Sci-ence (ETCS), vol. 3. IEEE, 2009, pp. 114–118.[98] H. Ghasvari, M. Raayatpanah, B. Khalaj, and H. Bakhshi, “Optimalsub-graph selection over coded networks with delay and limited-sizebuffering,” IET Commun., vol. 5, no. 11, pp. 1497–1505, 2011.150Bibliography[99] R. Rajkumar, “A Cyber–Physical Future,” Proceedings of the IEEE,vol. 100, no. 13, pp. 1309–1312, 2012.[100] H. Li, L. Lai, and H. Poor, “Multicast routing for decentralized controlof cyber physical systems with an application in smart grid,” IEEEJournal on Selected Areas in Communications, vol. 30, no. 6, pp. 1097–1107, 2012.[101] S. Sridhar, A. Hahn, and M. Govindarasu, “Cyber–physical systemsecurity for the electric power grid,” Proceedings of the IEEE, vol.100, no. 1, pp. 210–224, 2012.[102] S. Zonouz, K. M. Rogers, R. Berthier, R. B. Bobba, W. H. Sanders,and T. J. Overbye, “SCPSE: Security-Oriented Cyber-Physical StateEstimation for Power Grid Critical Infrastructures,” IEEE Transac-tions on Smart Grid, vol. 3, no. 4, pp. 1790–1799, 2012.[103] M. Stegelmann and D. Kesdogan, “GridPriv: A Smart Metering Ar-chitecture Offering k-Anonymity,” in IEEE 11th International Con-ference onTrust, Security and Privacy in Computing and Communi-cations (TrustCom). IEEE, 2012, pp. 419–426.[104] S. Li, K. Choi, and K. Chae, “An enhanced measurement transmissionscheme for privacy protection in smart grid,” in Information Network-ing (ICOIN), 2013 International Conference on. IEEE, 2013, pp.18–23.[105] X. Lin, R. Lu, H. Zhu, P.-H. Ho, X. Shen, and Z. Cao, “ASRPAKE: Ananonymous secure routing protocol with authenticated key exchangefor wireless ad hoc networks,” in IEEE International Conference on-Communications (ICC). IEEE, 2007, pp. 1247–1253.[106] Y. Fan, Y. Jiang, H. Zhu, J. Chen, and X. S. Shen, “Network codingbased privacy preservation against traffic analysis in multi-hop wirelessnetworks,” IEEE Transactions on Wireless Communications, vol. 10,no. 3, pp. 834–843, 2011.[107] J. Wang, J. Wang, C. Wu, K. Lu, and N. Gu, “Anonymous commu-nication with network coding against traffic analysis attack,” in IEEEINFOCOM. IEEE, 2011, pp. 1008–1016.[108] J. Wang, K. Lu, J. Wang, and C. Qiao, “Untraceability of mobiledevices in wireless mesh networks using linear network coding,” inINFOCOM, 2013 Proceedings IEEE. IEEE, 2013, pp. 270–274.151Bibliography[109] F. Atya, A. Osama, T. ElBatt, and M. Youssef, “On the flowanonymity problem in network coding,” in Wireless Communicationsand Mobile Computing Conference (IWCMC), 2013 9th International.IEEE, 2013, pp. 225–230.[110] H. Nicanfar, P. Jokar, K. Beznosov, and V. C. M. Leung, “Efficient Au-thentication and Key Management Mechanisms for Smart Grid Com-munications,” accepted for publication in IEEE Systems Journal, Jan.2013.[111] J. Wang, K. Lu, J. Wang, and C. Qiao, “Untraceability of mobiledevices in wireless mesh networks using linear network coding,” inINFOCOM, 2013 Proceedings IEEE, 2013, pp. 270–274.[112] A. O. Fathy Atya, T. ElBatt, and M. Youssef, “On the flow anonymityproblem in network coding,” in Wireless Communications and MobileComputing Conference (IWCMC), 2013 9th International, 2013, pp.225–230.[113] C. Gkantsidis and P. Rodriguez, “Network coding for large scale con-tent distribution,” in INFOCOM 2005. 24th Annual Joint Conferenceof the IEEE Computer and Communications Societies. ProceedingsIEEE, vol. 4. IEEE, 2005, pp. 2235–2245.[114] H. Khurana, M. Hadley, N. Lu, and D. Frincke, “Smart-grid securityissues,” IEEE Security & Privacy, vol. 8, no. 1, pp. 81–85, 2010.[115] NIST Smart Grid, Cyber Security Working Group, “Guidelines forSmart Grid Cyber Security: Vol. 1, Smart Grid Cyber SecurityStrategy, Architecture, and High-Level Requirements,” Guideline,Aug. 2010. [Online]. Available:[116] W. Su, H. Eichi, W. Zeng, and M. Chow, “A survey on the electrifi-cation of transportation in a smart grid environment,” IEEE Trans-actions on Industrial Informatics, vol. 8, no. 1, pp. 1–10, 2012.[117] H. Chaudhry and T. Bohn, “Security concerns of a plug-in vehicle,”in IEEE PES Innovative Smart Grid Technologies (ISGT). IEEE,2012, pp. 1–6.[118] S. Han, S. Han, and K. Sezaki, “Estimation of Achievable Power Ca-pacity From Plug-in Electric Vehicles for V2G Frequency Regulation:Case Studies for Market Participation,” IEEE Transactions on SmartGrid, vol. 2, no. 4, pp. 632–641, 2011.152Bibliography[119] J. Keiser, J. Glass, N. Masuch, M. Lutzenberger, and S. Albayrak, “Adistributed multi-operator W2V2G management approach,” in IEEEInternational Conference on Smart Grid Communications (Smart-GridComm). IEEE, 2011, pp. 273–278.[120] A. Adigun, B. Amar Bensaber, and I. Biskri, “Proof of concept ofa security based on lifetime of communication’s pseudonyms for theVANETs,” in Proceedings of the second ACM international symposiumon Design and analysis of intelligent vehicular networks and applica-tions. ACM, 2012, pp. 111–114.[121] M. Stegelmann and D. Kesdogan, “Location privacy for vehicle-to-grid interaction through battery management,” in Ninth InternationalConference on Information Technology: New Generations (ITNG).IEEE, 2012, pp. 373–378.[122] Z. Yang, S. Yu, W. Lou, and C. Liu, “P2: Privacy-preserving commu-nication and precise reward architecture for V2G networks in smartgrid,” IEEE Transactions on Smart Grid, vol. 2, no. 4, pp. 697–706,2011.[123] J. Sun, C. Zhang, Y. Zhang, and Y. Fang, “An identity-based securitysystem for user privacy in vehicular ad hoc networks,” Parallel andDistributed Systems, IEEE Transactions on, vol. 21, no. 9, pp. 1227–1239, 2010.[124] J. Martinez, P. Ruiz, and R. Marin, “Impact of the Pre-AuthenticationPerformance in Vehicular Networks,” in Vehicular Technology Confer-ence Fall (VTC 2010-Fall), 2010 IEEE 72nd. IEEE, 2010, pp. 1–5.[125] J. Huang, L. Yeh, and H. Chien, “ABAKA: An Anonymous BatchAuthenticated and Key Agreement Scheme for Value-Added Servicesin Vehicular Ad Hoc Networks,” Vehicular Technology, IEEE Trans-actions on, vol. 60, no. 1, pp. 248–262, 2011.[126] V. Paruchuri and A. Durresi, “PAAVE: Protocol for Anonymous Au-thentication in Vehicular Networks using Smart Cards,” in GlobalTelecommunications Conference (GLOBECOM 2010), 2010 IEEE.IEEE, 2010, pp. 1–5.[127] S. Chang, Y. Qi, H. Zhu, J. Zhao, and X. Shen, “Footprint: DetectingSybil Attacks in Urban Vehicular Networks,” Parallel and DistributedSystems, IEEE Transactions on, vol. 23, no. 6, pp. 1103–1114, 2012.153[128] H. Guo, Y. Wu, F. Bao, H. Chen, and M. Ma, “UBAPV2G: A UniqueBatch Authentication Protocol for Vehicle-to-Grid Communications,”IEEE Transactions on Smart Grid, vol. 2, no. 4, pp. 707–714, 2011.[129] A. Boukerche and X. Li, “An agent-based trust and reputation man-agement scheme for wireless sensor networks,” in Global Telecommu-nications Conference, 2005. GLOBECOM’05. IEEE, vol. 3. IEEE,2005, pp. 5–pp.[130] Y. Ota, H. Taniguchi, T. Nakajima, K. Liyanage, J. Baba, andA. Yokoyama, “Autonomous Distributed V2G (Vehicle-to-Grid) Satis-fying Scheduled Charging,” IEEE Transactions on Smart Grid, vol. 3,no. 1, pp. 559–564, 2012.154Appendix AAVISPA codesIn this appendix, we present the detail of AVISPA codes for each of oursimulations, in High Level Protocol Specification Language (HLPSL).A.1 Related HLPSL Codes of SGMA andSGKM: Chapter 2The HLPSL codes for AVISPA to define the SM and SAS roles are presentedin Figure. A.1 and A.2, respectively. Also, the required session and environ-ment HLPSL codes are shown in Figure A.3. Note that since AVISPA doesnot support arithmetic operations, we have used instead the “xor & exp”(raise to power) operators besides other security functions. The xor oper-ator is used for the mod 2 “+ & −” (addition and subtraction) operationsrequired for the authentication algorithms.155A.1. Related HLPSL Codes of SGMA and SGKM: Chapter 2role sgas_Init (SM,SAS :  agent,              PW :  symmetric_key,            Hsh :   hash_func,             G,N :   text,              Snd,Rcv : channel(dy))            played_by SM                def=                   local   State :    nat,             Rsm :   text,             Salt :    protocol_id,            PubKsm, PubKsas:  public_key,            FFi, Ffi :   hash_func,            STi, SNsm, Gsm, Gsas, Ver, K0, K, M1, M2, M, Ru, X, S0, S1, S2, S :  message                       const   sec_init_Si, sec_init_K :  protocol_id                            init  State := 0                                  transition                                   1. State = 0   /\ Rcv(start) =|>    % start             State':= 2  /\ Rsm' := new()    % R_sm = Rnd(.)         /\ SNsm' := new()    % SN_sm = Rnd(.)         /\ Gsm' := exp(G,Rsm')    % Gsm = g^R_sm                       /\ Snd(SM.Gsm'.SNsm')   % Sending ID_sm, g^R_sm, SN_sm                        2. State = 2 /\ Rcv(Salt'.Gsas'.FFi'.STi') =|>   % Receiving Salt, B, Encrypted F_i(.) & State i with K       State':= 4  /\ K0':= Hsh(N.G)    % k= hash(N,g)         /\ Ru':= Hsh(Gsm.Gsas')   % u= hash(A,B)         /\ X':= Hsh(Salt'.PW)    % x= hash(salt, pw)        /\ Ver' := exp(G,X')     % ver = g^x          /\ S0' := xor(Gsas',Hsh(K0'.Ver'))  % g^b + k.g^x - k.g^x = g^b        /\ S1' := exp(S0',Rsm)    % (g^b)^a = g^ab        /\ S2' := exp(exp(S0',Ru'), X')   % ((g^b)^u)^x = g^bux       /\ S' := xor(S1',S2')    % S = g^ab xor g^bux                       /\ K' := Hsh(S')     % K = hash(S)                       /\ witness(SM,SAS,k1,K')   % Checking K                         /\ secret(K',sec_init_K,{SM,SAS})  % Checking K                         /\ M1' := xor(Hsh(N),Hsh(G))   % M1 = hash(N) xor hash(g)                     /\ M2' := Hsh(xor(SM,SNsm))   % M2 = hash(ID xor SN)                      /\ M' := Hsh(M1'.M2'.Salt.Gsm.Gsas'.K') % M = hash(M1,M2,salt,A,B,K)       /\ STi' := {STi'}_inv(K')    % Decrypting i with K       /\ FFi' := {FFi'}_inv(K')    % Decrypting F_i with K       /\ PubKsas' := FFi(SAS)   % PubK_sas = F_i(ID_SAS)                       /\ Snd({STi'}_inv(PubKsas'))   % sending i uncrypted by PubK_sas                    /\ witness(SM,SAS,si1,STi')   % Checking state i                        /\ secret(STi',sec_init_Si,{SM,SAS})  % Checking state i                          2. State = 4   /\ Rcv(M) =|>      % receiving hash(M)           State' := 6                                 /\ request(SM,SAS,k2,K)   % Checking K                         /\ request(SM,SAS,si2,STi)   % Checking state i                        end role                Figure A.1: Chapter 2: Smart Meter (SM) HLPSL Codes156A.1. Related HLPSL Codes of SGMA and SGKM: Chapter 2%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%                   role sgas_Resp (SAS, SM:  agent,                  Ver :   message,                Salt :   protocol_id,                Hsh :   hash_func,                G,N :   text,                 Snd, Rcv :   channel(dy))                                            played_by SAS                                def=                   local State :  nat,                  Rsas :    text,             FFi, Ffi :   hash_func,            PubKsm, PubKsas :  public_key,            Resi, Resj, STi, SNsm, Ru, M1, M2, M, K0, K, Gsm, Gsas, X, S0, S1, S :  message                       const  sec_resp_Si, sec_resp_K :  protocol_id                             init  State := 1                                 transition                                  1. State = 1   /\ Rcv(SM.Gsm',SNsm') =|>       % A and g^a            State':= 3  /\ K0' := Hsh(N.G)     % k = hash(N,g)        /\ Rsas' := new()     % b = Rnd()         /\ Gsas' := xor(exp(G,Rsas'),Hsh(K0'.Ver))  % B = g^b + k.g^x       /\ Ru' := Hsh(Gsm'.Gsas')        % u = hash(A,B)        /\ S0' := exp(Gsm',Rsas')      % (g^a)^b = g^ab        /\ S1' := exp(exp(Ver,Ru'),Rsas')     % ((g^x)^u)^b = g^bux       /\ S' := xor(S0',S1')        % S = g^ab xor g^bux                      /\ K' := Hsh(S')     % K = hash(S)                       /\ M1' := xor(Hsh(N),Hsh(G))   % M1 = hash(N) xor hash(g)                     /\ M2' := Hsh(xor(SM,SNsm'))   % M2 = hash(ID xor SN)                      /\ M' := Hsh(M1'.M2'.Salt.Gsm'.Gsas'.K')  % M = hash(M1,m2,salt,A,B,K)      /\ STi' := new()        % State i         /\ PubKsas' := FFi(SAS)    % PubK_sas = F_i(ID_sas)       /\ Snd(Salt.Gsas'.{FFi}_K'.{STi'}_K')  % sending salt,B                      /\ witness(SAS,SM,k2,K')    % Checking K         /\ secret(K',sec_resp_K,{SM,SAS})   % Checking K                          2. State = 3   /\ Rcv({Resi'}_inv(PubKsas)) =|>     % receiving state i           State':= 5  /\ witness(SAS,SM,si2,Resi')   % Checking state i                       /\ secret(Resi',sec_resp_Si,{SM,SAS})  % Checking state i         /\ Snd(M)       % sending M                        /\ request(SAS,SM,si1,Resi')   % Checking state i                       /\ request(SAS,SM,k1,K)    % Checking K                                         end role                                 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%  Figure A.2: Chapter 2: Server (SAS) HLPSL Codes157A.1. Related HLPSL Codes of SGMA and SGKM: Chapter 2%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%                   role session(SM,SAS : agent,                          PW :   symmetric_key,                      Salt :   protocol_id,                       Hsh :   hash_func,                       G,N :   text)             def=                                     local  SndSM, RcvSM, SndSAS, RcvSAS :  channel (dy)                              composition                          sgas_Init(SM,SAS,PW,Hsh,G,N,SndSM,RcvSM)  /\                     sgas_Resp(SAS,SM,exp(G,Hsh(Salt.PW)),Salt,Hsh,G,N,SndSAS,RcvSAS) % x = hash(Salt, pw) & Ver = g^x                   end role                                 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%                   role environment()                                 def=                   const  si1, si2, k1, k2 :  protocol_id,             sm, sas, intruder :  agent,              kab, kai, kbi :   symmetric_key,           s_ab,s_ai,s_bi :  protocol_id,            hsh :    hash_func,            g, n :    text                              intruder_knowledge = {i, kai, kbi, s_ai, s_bi}                             composition                    session(sm,sas,kab,s_ab,hsh,g,n)             /\ session(sm,intruder,kai,s_ai,hsh,g,n)            /\ session(sas,intruder,kbi,s_bi,hsh,g,n)                            end role                                 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%                     goal                                      secrecy_of  sec_init_Si, sec_init_K, sec_resp_Si, sec_resp_K                              authentication_on k1                  authentication_on k2                                   authentication_on si1                  authentication_on si2                              end goal                                %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%                  environment()               Figure A.3: Chapter 2: Session and Environment HLPSL Codes158A.2. Related HLPSL Codes of Group Key: Chapter 3A.2 Related HLPSL Codes of Group Key:Chapter 3The following are the HLPSL codes of entities of Chapter 3, Group Keymechanism. Figure A.15 presents the evaluation program and AVISPA re-lated HLPSL codes for the session, environment and goal sections. Also,HLPSL codes of the four entities A, B, C, and D roles are shown in Fig-ure A.10, A.12, A.14 and A.8, respectively.%% PROTOCOL*: SGGM              %%HLPSL:                role session (A,B,C,D: agent, G: text, Hsh: hash_func,               Kab,Kbc,Kcd,Kda: symmetric_key, Pw: symmetric_key)                     def=                    local   SA,RA,SB,RB,SC,RC,SD,RD: channel(dy)                            composition                          sgsk_1(D,A,B,G,Hsh,Kda,Kab,SA,RA,Pw)  /\                  sgsk_2(A,B,C,G,Hsh,Kab,Kbc,SB,RB,Pw)  /\                  sgsk_3(B,C,D,G,Hsh,Kbc,Kcd,SC,RC,Pw)  /\                  sgsk_4(C,D,A,G,Hsh,Kcd,Kda,SD,RD,Pw)        end role                %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%       role environment() def=                                const  gk_ab, gk_bc, gk_cd, gk_da  : protocol_id,       gk_ba, gk_cb, gk_dc, gk_ad  : protocol_id,       a,b,c,d          : agent,        kab,kbc,kcd,kda    : symmetric_key,      kai,kia,kbi,kib,kci,kic,kdi,kid : symmetric_key,              pw       : symmetric_key,      g               : text,        hsh                : hash_func                        intruder_knowledge  = {a,b,c,d,kai,kia,kbi,kib,kci,kic,kdi,kid}                       composition                                session(a,b,c,d,g,hsh,kab,kbc,kcd,kda,pw)        end role                %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%       goal                   % secrecy_of GK              secrecy_of sec_GK_AB, sec_GK_BC, sec_GK_CD, sec_GK_DA,          sec_GK_AD, sec_GK_BA, sec_GK_CB, sec_GK_DC                      % authentication                authentication_on gk_ab              authentication_on gk_ba              authentication_on gk_bc              authentication_on gk_cb              authentication_on gk_cd              authentication_on gk_dc              authentication_on gk_da              authentication_on gk_ad            end goal                %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%       environment()               Figure A.4: Chapter 3: Main HLPSL Codes159A.2. Related HLPSL Codes of Group Key: Chapter 3%% PROTOCOL*: SGGM              %%HLPSL:                role sgsk_1 (D,A,B  : agent,             G  : text,             Hsh  : hash_func,            Kda,Kab  : symmetric_key,            Snd,Rcv : channel(dy),            Pw  : symmetric_key)                         played_by A                                def=                   local  State      : nat,            Ra           : text,            Gd,Gcd,Gbcd  : message,      % in      Gbcda,GK   : message,      % mine     Ga,Gda,Gcda  : message,      % out          ST_DA,ST_AB  : message      % verifiers                      const sec_GK_AB, sec_GK_AD : protocol_id                            init  State := 0                                 transition                                 1. State = 0  /\ Rcv(start) =|>     % start          State':= 1 /\ Ra' := new()    % a          /\ Ga' := exp(G,Ra')   % g^a                      /\ Snd(A.{{Ga'}_Kab}_Pw.B)  % send:g^a                s1                   2. State = 1 /\ Rcv(D.{{Gd'}_Kda.{Gcd'}_Kda.{Gbcd'}_Kda}_Pw.A) =|>             % receive: g^d, g^cd, g^bcd      State':= 2 /\ Gda' := exp(Gd',Ra)   % g^da          /\ Gcda' := exp(Gcd',Ra)   % g^cda          /\ Gbcda' := exp(Gbcd',Ra)  % g^bcda           /\ Snd(A.{{Gda'}_Kab.{Gcda'}_Kab}_Pw.B)% send: g^da, g^cda      /\ GK' := Hsh(Pw.Gbcda')   % group key: ash(pw,g^abcd)     /\ ST_AB' := Hsh(Pw.Gcda'.Gbcda') % A<-->B:hash(pw,g^cda,g^abcd)    /\ ST_DA' := Hsh(Pw.Gbcd'.Gbcda') % A<-->D:hash(pw,g^bcd,g^abcd)            /\ witness(A,B,gk_ab,GK')  % Checking group key with B     /\ secret(GK',sec_GK_AB,{A,B}) % Checking group key with B             /\ witness(A,D,gk_ad,GK')  % Checking group key with D     /\ secret(GK',sec_GK_AD,{A,D}) % Checking group key with D s5                   3. State = 2   /\ Rcv(D.ST_DA.A) =|>    % receive verifier from D      State':= 3  /\ Snd(A.ST_AB.B)    % send verifier to B                   /\ request(A,B,gk_ba,GK)   % Checking group key with B                  /\ request(A,D,gk_da,GK)   % Checking group key with D s9 end role                %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%       Figure A.5: Chapter 3: First Entity HLPSL Codes160A.2. Related HLPSL Codes of Group Key: Chapter 3%% PROTOCOL*: SGGM              %%HLPSL:                role sgsk_2 (A,B,C   : agent,               G   : text,               Hsh  : hash_func,              Kab,Kbc  : symmetric_key,             Snd,Rcv  : channel(dy),               Pw   : symmetric_key)                          played_by B                                def=                   local State   : nat,            Rb         : text,            Ga,Gda,Gcda  : message,     % in       Gcdab,GK   : message,     % mine      Gb,Gab,Gdab  : message,     % out           ST_AB,ST_BC  : message     % verifiers                       const sec_GK_BC, sec_GK_BA : protocol_id                            init  State := 0                                transition                                 1. State = 0 /\ Rcv(A.{{Ga'}_Kab}_Pw.B) =|> % receive: g^a         State':= 1 /\ Rb' := new()    % b                       /\ Gb' := exp(G,Rb')   % g^b                      /\ Gab' := exp(Ga',Rb')   % g^ab         /\ Snd(B.{{Gb'}_Kbc.{Gab'}_Kbc}_Pw.C) % send: g^b, g^ab     s2                   2. State = 1 /\ Rcv(A.{{Gda'}_Kab.{Gcda'}_Kab}_Pw.B) =|>% receive: g^da, g^cda      State':= 2  /\ Gdab' := exp(Gda',Rb)   % g^dab          /\ Gcdab' := exp(Gcda',Rb)  % g^cdab           /\ Snd(B.{{Gdab'}_Kbc}_Pw.C)  % send: g^dab        /\ GK' := Hsh(Pw.Gcdab')   % group key: hash(pw,g^abcd)     /\ ST_BC' := Hsh(Pw.Gdab'.Gcdab') % B<->C: hash(pw,g^dab,g^abcd)    /\ ST_AB' := Hsh(Pw.Gcda'.Gcdab') % B<->A: hash(pw,g^cda,g^abcd)                 /\ witness(B,C,gk_bc,GK')  % Checking group key with C     /\ secret(GK',sec_GK_BC,{B,C}) % Checking group key with C                  /\ witness(B,A,gk_ba,GK')  % Checking group key with A     /\ secret(GK',sec_GK_BA,{B,A}) % Checking group key with A s6                   3. State = 2   /\ Rcv(A.ST_AB.B) =|>    % receive verifier from A      State':= 3  /\ Snd(B.ST_BC.C)    % send verifier to C       /\ request(B,C,gk_cb,GK)   % Checking group key with C                  /\ request(B,A,gk_ab,GK)   % Checking group key with As10 %                 end role                %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%       Figure A.6: Chapter 3: Second Entity HLPSL Codes161A.2. Related HLPSL Codes of Group Key: Chapter 3%% PROTOCOL*: SGGM              %%HLPSL:                role sgsk_3 (B,C,D   : agent,                    G   : text,                    Hsh  : hash_func,              Kbc,Kcd  : symmetric_key,             Snd,Rcv  : channel(dy),              Pw   : symmetric_key)                          played_by C                                def=                   local State    : nat,             Rc   : text,             Gb,Gab,Gdab : message,     % in        Gdabc,GK  : message,     % mine       Gc,Gbc,Gabc : message,     % out             ST_BC,ST_CD : message     % verifiers                       const sec_GK_CD, sec_GK_CB : protocol_id                            init  State := 0                                 transition                                 1. State = 0 /\ Rcv(B.{{Gb'}_Kbc.{Gab'}_Kbc}_Pw.C) =|> % receive: g^b, g^ab     State':= 1  /\ Rc' := new()    % c                      /\ Gc' := exp(G,Rc')   % g^c                      /\ Gbc' := exp(Gb',Rc')   % g^bc                      /\ Gabc' := exp(Gab',Rc')  % g^abc         /\ Snd(C.{{Gc'}_Kcd.{Gbc'}_Kcd.{Gabc'}_Kcd}_Pw.D)             % send: g^c, g^bc, g^abc     s3                   2. State = 1 /\ Rcv(B.{{Gdab'}_Kbc}_Pw.C) =|>  % receive: g^dab        State':= 2  /\ Gdabc' := exp(Gdab',Rc)  % g^abcd         /\ GK' := Hsh(Pw.Gdabc')   % group key:hash(pw,g^abcd)     /\ ST_CD' := Hsh(Pw.Gabc.Gdabc') % C<->D: hash(pw,g^abc,g^abcd)    /\ ST_BC' := Hsh(Pw.Gdab'.Gdabc') % C<->B: hash(pw,g^dab,g^abcd)    /\ Snd(C.ST_CD'.D)    % send verifier to D                   /\ witness(C,D,gk_cd,GK')  % Checking group key with D     /\ secret(GK',sec_GK_CD,{C,D}) % Checking group key with D                  /\ witness(C,B,gk_cb,GK')  % Checking group key with B     /\ secret(GK',sec_GK_CB,{C,B}) % Checking group key with B s7                   3. State = 2   /\ Rcv(B.ST_BC.C) =|>    % receive: hash(hash(g^abc),1)     State':= 3  /\ request(C,D,gk_dc,GK)   % Checking group key with D     /\ request(C,B,gk_bc,GK)   % Checking group key with Bs11 %                 end role                %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%       Figure A.7: Chapter 3: Third Entity HLPSL Codes162A.2. Related HLPSL Codes of Group Key: Chapter 3%% PROTOCOL*: SGGM              %%HLPSL:                role sgsk_4 (C,D,A  : agent,                  G  : text,             Hsh  : hash_func,            Kcd,Kda  : symmetric_key,           Snd,Rcv  : channel(dy),            Pw  : symmetric_key)                           played_by D                               def=                   local State       : nat,            Rd        : text,            Gc,Gbc,Gabc : message,    % in         Gabcd,GK  : message,    % mine       Gd,Gcd,Gbcd : message,    % out       ST_CD,ST_DA : message    % verifiers                       const sec_GK_DA, sec_GK_DC  : protocol_id                            init  State := 0                                 transition                                 1. State = 0 /\ Rcv(C.{{Gc'}_Kcd.{Gbc'}_Kcd.{Gabc'}_Kcd}_Pw.D) =|>            % receive: g^c, g^bc, g^abc       State':= 1 /\ Rd' := new()    % d                 /\ Gd' := exp(G,Rd')   % g^d            /\ Gcd' := exp(Gc',Rd')   % g^cd            /\ Gbcd' := exp(Gbc',Rd')  % g^bcd             /\ Gabcd' := exp(Gabc',Rd')  % g^abcd        /\ Snd(D.{{Gd'}_Kda.{Gcd'}_Kda.{Gbcd'}_Kda}_Pw.A)              % send: g^d, g^cd, g^bcd      /\ GK' := Hsh(Pw.Gabcd')   % group key: hash(pw,g^abcd)     /\ ST_DA' := Hsh(Pw.Gbcd'.Gabcd') % D<->A: hash(pw,g^bcd,g^abcd)    /\ ST_CD' := Hsh(Pw.Gabc'.Gabcd') % D<->C: hash(pw,g^abc,g^abcd)                 /\ witness(D,A,gk_da,GK')  % Checking group key with A    /\ secret(GK',sec_GK_DA,{D,A}) % Checking group key with A                  /\ witness(D,C,gk_dc,GK')  % Checking group key with C     /\ secret(GK',sec_GK_DC,{D,C}) % Checking group key with C s4                                    2. State = 1   /\ Rcv(C.ST_CD.D) =|>    % receive verifier from C      State':= 2  /\ Snd(D.ST_DA.A)    % send verifier to A      /\ request(D,A,gk_ad,GK)   % Checking group key with A                  /\ request(D,C,gk_cd,GK)   % Checking group key with C s8                  end role                %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%       Figure A.8: Chapter 3: Forth Entity HLPSL Codes163A.3. Related HLPSL Codes of MCEPAK: Chapter 4A.3 Related HLPSL Codes of MCEPAK:Chapter 4The following are the HLPSL codes of entities of Chapter 4, ECC basedmulti-layer key construction mechanism. Figure A.15 presents our evalua-tion program and AVISPA related HLPSL codes for the session, environ-ment and goal sections. Also, HLPSL codes of the appliance is shown inFigure A.10 while HLPSL codes of the controllers roles are shown in Fig-ure A.11, A.12, A.13 and A.14.role session (A,H,B,N,C: agent, G: text, Hsh: hash_func,                 Khb,Kbn,Knc: symmetric_key, Pwd: symmetric_key)     def=                    local   SA,RA,SH,RH,SB,RB,SN,RN,SC,RC: channel(dy)                           composition                                          sk_1(A,H,B,N,C,G,Hsh,SA,RA,Pwd)  /\                   sk_2(A,H,B,N,C,G,Hsh,Khb,SH,RH,Pwd)  /\                   sk_3(A,H,B,N,C,G,Hsh,Khb,Kbn,SB,RB)  /\                   sk_4(A,H,B,N,C,G,Hsh,Kbn,Knc,SN,RN)  /\                   sk_5(A,H,B,N,C,G,Hsh,Knc,SC,RC)         end role                %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%       role environment() def=                                const k_ah, k_ab, k_an, k_ac    : protocol_id,           k_ha, k_ba, k_na, k_ca    : protocol_id,             a,h,b,n,c           : agent,              khb,kbn,knc       : symmetric_key,            kai,kia,khi,kih,kbi,kib,kni,kin,kci,kic : symmetric_key,            pwd        : symmetric_key,            g                 : text,              hsh                 : hash_func                       intruder_knowledge  = {a,h,b,n,c,kai,kia,khi,kih,kbi,kib,kni,kin,kci,kic}                      composition                                session(a,h,b,n,c,g,hsh,khb,kbn,knc,pwd)                         end role                %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%       goal                                    % secrecy_of GK                secrecy_of sec_K_AH, sec_K_HA, sec_K_AB, sec_K_BA,          sec_K_AN, sec_K_NA, sec_K_AC, sec_K_CA                          % authentication                authentication_on k_ah               authentication_on k_ha               authentication_on k_ab               authentication_on k_ba               authentication_on k_an               authentication_on k_na               authentication_on k_ac               authentication_on k_ca                              end goal                %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%       environment()               Figure A.9: Chapter 4: Main HLPSL Codes164A.3. Related HLPSL Codes of MCEPAK: Chapter 4role sk_1 (A,H,B,N,C  : agent,                      G   : text,                  Hsh   : hash_func,                 Snd,Rcv  : channel(dy),                 Pwd   : symmetric_key)                          played_by A               def=                   local State       : nat,            Ra           : text,    % Random variable     TKah    : symmetric_key,  % temp key A  H      TKab    : symmetric_key,  % temp key A  B      TKan    : symmetric_key,  % temp key A  N      TKac    : symmetric_key,  % temp key A  C      Xah    : message,    % out       Yh,Yhb,Yhbn,Yhbnc : message,    % in        Xhb,Xbn,Xnc,Xcc  : message,    % mine       Kh,Kb,Kn,Kc  : message     % keys                         const sec_K_AH, sec_K_AB, sec_K_AN, sec_K_AC : protocol_id                         init  State := 0                transition                                 1. State = 0   /\ Rcv(start) =|>     % start          State':= 1  /\ Ra' := new()     % a          /\ Xah' := exp(G,Ra')   % g^a         /\ TKah' := Hsh(A.Pwd.H)   % Temp key         /\ TKab' := Hsh(TKah'.B)   % Temp key         /\ TKan' := Hsh(TKab'.N)   % Temp key         /\ TKac' := Hsh(TKan'.C)   % Temp key                      /\ Snd(A.{Xah'}_TKah'.H)   % send to h: g^a  s1                      2. State = 1  /\ Rcv(H.{Yh'}_TKah.{Yhb'}_TKah.{Yhbn'}_TKah.{Yhbnc'}_TKah.A) =|>              % receive: g^h, g^hb, g^hbn , g^hbnc     State':= 2  /\ Xhb' := exp(Yh',Ra)   % g^ah        /\ Xbn' := exp(Yhb',Ra)   % g^ahb              /\ Xnc' := exp(Yhbn',Ra)   % g^ahbn               /\ Xcc' := exp(Yhbnc',Ra)   % g^ahbnc        /\ Kh' := Hsh(Xhb'.TKah.TKab.Xah) % Shared key A  H       /\ Kb' := Hsh(Xbn'.TKab.TKan.Xhb') % Shared key A  B       /\ Kn' := Hsh(Xnc'.TKan.TKac.Xbn') % Shared key A  N       /\ Kc' := Hsh(Xcc'.TKac.TKac.Xnc') % Shared key A  C                    /\ witness(A,H,k_ah,Kh')   % Check shared key with H      /\ secret(Kh',sec_K_AH,{A,H})  % Check shared key with H                   /\ witness(A,B,k_ab,Kb')   % Checking shared key with B    /\ secret(Kb',sec_K_AB,{A,B})  % Checking shared key with B                     /\ witness(A,N,k_an,Kn')   % Checking shared key with N    /\ secret(Kn',sec_K_AN,{A,N})  % Checking shared key with N             /\ witness(A,C,k_ac,Kc')   % Checking shared key with C    /\ secret(Kc',sec_K_AC,{A,C})  % Checking shared key with C             /\ request(A,H,k_ha,Kh')   % Checking shared key with H             /\ request(A,B,k_ba,Kb')   % Checking shared key with B    /\ request(A,N,k_na,Kn')   % Checking shared key with N    /\ request(A,C,k_ca,Kc')   % Checking shared key with C  end role                Figure A.10: Chapter 4: HLPSL Codes of New Appliance (AN )165A.3. Related HLPSL Codes of MCEPAK: Chapter 4role sk_2 (A,H,B,N,C  : agent,             G   : text,                  Hsh   : hash_func,                 Khb   : symmetric_key,                Snd,Rcv   : channel(dy),                 Pwd   : symmetric_key)                          played_by H                                def=                   local State       : nat,            Rh         : text,            TKah    : symmetric_key,  % Temp key A  H     TKab    : symmetric_key,  % Temp key A  B     Temp1   : message,    % temp       Xah    : message,    % in        Xhb    : message,    % out       Yb,Ybn,Ybnc  : message,    % in        Yh,Yhb,Yhbn,Yhbnc : message,    % out       Kh    : message    % key                         const sec_K_HA  : protocol_id                             init  State := 0                                 transition                                 1. State = 0   /\ Rcv(A.Temp1'.H) =|>              State':= 1  /\ TKah' := Hsh(A.Pwd.H)    % receive from A: g^a%      /\ Xah' := {Temp1'}_TKah'  % Temp key A  H        /\ Rh' := new()    % h                       /\ Xhb' := exp(Xah',Rh')   % g^ah         /\ TKab' := Hsh(TKah'.B)   % Temp key A  B        /\ Snd(H.{TKab'}_Khb.{Xhb'}_Khb.B) % send to B: g^ah                       2. State = 1   /\ Rcv(B.{Yb'}_Khb.{Ybn'}_Khb.{Ybnc'}_Khb.H) =|>            % receive fron B: g^b , g^bn , g^bnc       State':= 2  /\ Yh' := exp(G,Rh)    % g^h              /\ Yhb' := exp(Yb',Rh)   % g^hb              /\ Yhbn' := exp(Ybn',Rh)   % g^hbn              /\ Yhbnc' := exp(Ybnc',Rh)  % g^hbnc         /\ Snd(H.{Yh'}_TKah.{Yhb'}_TKah.{Yhbn'}_TKah.{Yhbnc'}_TKah.A)         % send to A: g^h , g^hb , g^hbn , g^hbnc    /\ Kh' := Hsh(Xhb.TKah.TKab.Xah) % Shared key A  H      /\ witness(H,A,k_ha,Kh')   % Check shared key with A     /\ secret(Kh',sec_K_HA,{H,A})  % Check shared key with A                  /\ request(H,A,k_ah,Kh')   % Check shared key with A                                    end role                Figure A.11: Chapter 4: HLPSL Codes of Home Controller (HC)166A.3. Related HLPSL Codes of MCEPAK: Chapter 4role sk_3 (A,H,B,N,C  : agent,                 G   : text,                  Hsh   : hash_func,                Khb,Kbn   : symmetric_key,                Snd,Rcv   : channel(dy))                        played_by B                                def=                  local State      : nat,            Rb        : text,            TKab   : symmetric_key,    % Temp key A  B   TKan   : symmetric_key,    % Temp key A  N   Xhb    : message,      % in     Xbn    : message,      % out     Yn,Ync   : message,      % in     Yb,Ybn,Ybnc  : message,      % out     Kb    : message      % key                       const sec_K_BA  : protocol_id                            init  State := 0                                transition                                1. State = 0  /\ Rcv(H.{TKab'}_Khb.{Xhb'}_Khb.B) =|>               % receive from H: g^ah     State':= 1  /\ Rb' := new()    % b                     /\ Xbn' := exp(Xhb',Rb')  % g^ahb          /\ TKan' := Hsh(TKab'.N)  % temp key A  N         /\ Snd(B.{TKan'}_Kbn.{Xbn'}_Kbn.N)% snd to N: g^ahb                   2. State = 1  /\ Rcv(N.{Yn'}_Kbn.{Ync'}_Kbn.B) =|>                % rcve from N: g^n , g^cn     State':= 2 /\ Yb' := exp(G,Rb)  % g^b             /\ Ybn' := exp(Yn',Rb)  % g^bn             /\ Ybnc' := exp(Ync',Rb)  % g^bnc         /\ Snd(B.{Yb'}_Khb.{Ybn'}_Khb.{Ybnc'}_Khb.H)           % send to H: g^b , g^bn , g^bnc      /\ Kb' := Hsh(Xbn.TKab.TKan.Xhb)  % Shred key A  B               /\ witness(B,A,k_ba,Kb')  % Check shred key with A     /\ secret(Kb',sec_K_BA,{B,A})% Check shred key with A    /\ request(B,A,k_ab,Kb')  % Check shred key with A  end role               Figure A.12: Chapter 4: HLPSL Codes of Building Controllers (BC)167A.3. Related HLPSL Codes of MCEPAK: Chapter 4role sk_4 (A,H,B,N,C  : agent,                 G   : text,                  Hsh   : hash_func,                Kbn,Knc   : symmetric_key,                Snd,Rcv   : channel(dy))                         played_by N                                def=                  local State      : nat,            Rn        : text,            TKan   : symmetric_key,  % Temp key A  N     TKac   : symmetric_key,  % Temp key A  C     Xbn    : message,    % in       Xnc    : message,    % out       Yc    : message,    % in       Yn,Ync   : message,   % out       Kn    : message    % key                        const sec_K_NA   : protocol_id                           init  State := 0                                transition                                1. State = 0   /\ Rcv(B.{TKan'}_Kbn.{Xbn'}_Kbn.N) =|>             % receive from B: g^ahb      State':= 1  /\ Rn' := new() % n                         /\ Xnc' := exp(Xbn',Rn') % g^ahbn         /\ TKac' := Hsh(TKan'.C) % temp key A  C        /\ Snd(N.{TKac'}_Knc.{Xnc'}_Knc.C)             % send to C: g^ahbn                      1. State = 1 /\ Rcv(C.{Yc'}_Knc.N) =|> % rcve frm C: g^c      State':= 2 /\ Yn' := exp(G,Rn)  % g^n                    /\ Ync' := exp(Yc',Rn)   % g^cn            /\ Snd(N.{Yn'}_Kbn.{Ync'}_Kbn.B)               % send to B: g^n , g^cn     /\ Kn' := Hsh(Xnc.TKan.TKac.Xbn)   % Shred key A N              /\ witness(N,A,k_na,Kn')   %Check shred key with A     /\ secret(Kn',sec_K_NA,{N,A}) %Check shred key with A           /\ request(N,A,k_an,Kn')   %Check shred key with A  end role               Figure A.13: Chapter 4: HLPSL Codes of Neighbourhood Controller (NC)168A.3. Related HLPSL Codes of MCEPAK: Chapter 4role sk_5 (A,H,B,N,C  : agent,                 G   : text,                 Hsh   : hash_func,                Knc   : symmetric_key,               Snd,Rcv  : channel(dy))                        played_by C                               def=                  local State      : nat,            Rc        : text,           TKac   : symmetric_key, % Temp key A  C    Xnc    : message,   % in       Yc    : message,   % out       Xcc    : message,   % mine       Kc    : message    % key                        const sec_K_CA : protocol_id                            init  State := 0                               transition                                1. State = 0  /\ Rcv(N.{TKac'}_Knc.{Xnc'}_Knc.C) =|>          % receive from N: g^ahbn      State':= 1  /\ Rc' := new()    % c                    /\ Yc' := exp(G,Rc')   % g^c                    /\ Xcc' := exp(Xnc',Rc')  % g^ahbnc        /\ Snd(C.{Yc'}_Knc.N)     % send to N: g^c      /\ Kc' := Hsh(Xcc'.TKac'.TKac'.Xnc')               % Shared key A  C             /\ witness(C,A,k_ca,Kc')               % Checking shared key with A     /\ secret(Kc',sec_K_CA,{C,A})             % Checking shared key with A                /\ request(C,A,k_ac,Kc')               % Checking shared key with A end role               Figure A.14: Chapter 4: HLPSL Codes of Central Controller (CC)169A.4. Related HLPSL Codes of Privacy-Preserved Security Solution: Chapter 6A.4 Related HLPSL Codes of Privacy-PreservedSecurity Solution: Chapter 6Figure A.15 shows the evaluation program and HLPSL codes for the session,environment and goal sections. In addition, HLPSL codes of the server andEV are shown in Figure A.16, Figure A.17 respectively.%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%              role session(EV,SGS : agent,           PW   : symmetric_key,          Salt  : protocol_id,          H   : hash_func,          G,P   : text)        def=                             local SndEV,RcvEV,SndSGS,RcvSGS: channel (dy)                     composition                      pev_Init(EV,SGS,PW,H,G,P,SndEV,RcvEV)  /\                pev_Resp(SGS,EV,PW,Salt,H,G,P,SndSGS,RcvSGS)                end role                        %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%               role environment()          def=                           const k11,k12,k21,k22 : protocol_id,        ev,sgs,I  : agent,         kab,kai,kib  : symmetric_key,        s_ab,s_ai,s_ib  : protocol_id,        hsh   : hash_func,        g,p   : text                       intruder_knowledge = {i, kai, kib, s_ai, s_ib}       composition               session(ev,sgs,kab,s_ab,hsh,g,p)        /\ session(ev,i,kai,s_ai,hsh,g,p)        /\ session(i,sgs,kib,s_ib,hsh,g,p)                   end role                         %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%                  goal                              secrecy_of sec_init_K1, sec_resp_K1, sec_init_K2, sec_resp_K2                    authentication_on k12             authentication_on k11                          authentication_on k22             authentication_on k21                      end goal                         %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%                          environment()                       Figure A.15: Chapter 6: Main HLPSL Codes170A.4. Related HLPSL Codes of Privacy-Preserved Security Solution: Chapter 6%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%                         role pev_Resp (SGS, EV : agent,                PW1   : symmetric_key,               Salt1  : protocol_id,               H   : hash_func,                G,P   : text,                Snd, Rcv : channel(dy))           played_by SGS        % smart grid server                     def=                   local  State   : nat,               SGSr1, SGSr2 : text,              Salt2   : protocol_id,             EVg1, SGSg1, U1, Ver1, S1, K0, K1, M1  : message,          EVg2, SGSg2, U2, Ver2, S2, K2, M2  : message,          PW2, PW3  : symmetric_key                              const sec_resp_K1, sec_resp_K2  : protocol_id                            init  State := 0                                  transition                                   1. State = 0  /\ Rcv(EV.EVg1') =|>      % ID_EV and A (g^a)          State':= 1 /\ K0' := H(P.G)      % k = hash(p,g)          /\ SGSr1' := new()     % b = Rnd()           /\ Ver1' := exp(G,H(Salt1.PW1))   % ver = g^x           /\ SGSg1' := xor(exp(G,SGSr1'),H(K0'.Ver1')) % B = g^b + k.g^x          /\ U1' := H(EVg1'.SGSg1')           % u = hash(A,B)          /\ S1' := exp(exp(Ver1',U1'),SGSr1')  % ((g^x)^u)^b = g^bux                    /\ K1' := H((exp(EVg1',SGSr1')).S1')   % K = hash(g^ab , g^bux)                    /\ M1' := H((xor(H(P),H(G))).(H(xor(EV,PW1))).Salt1.EVg1'.SGSg1'.K1')              % M = hash(M1,M2,salt,A,B,K)        /\ Snd(Salt1.{SGSg1'}_(exp(G,H(Salt1.H(EV.PW1))))) % sending salt,B                    /\ witness(SGS,EV,k12,K1')                           /\ secret(K1',sec_resp_K1,{EV,SGS})                             2. State = 1  /\ Rcv(M1) =|>       % A and g^a           State':= 3 /\ PW2' := H(EVg1.SGSg1.K1)                /\ Snd(H(PW2'))                             /\ request(SGS,EV,k11,K1)                              3. State = 3  /\ Rcv(EV.EVg2') =|>      % A and g^a           State':= 4 /\ Salt2' := new()     % New salt = Rnd()          /\ SGSr2' := new()     % b = Rnd()           /\ Ver2' := exp(G,H(Salt2'.PW2))   % ver = g^x           /\ SGSg2' := xor(exp(G,SGSr2'),H(K0.Ver2')) % B = g^b + k.g^x          /\ U2' := H(EVg2'.SGSg2')          % u = hash(A,B)          /\ S2' := exp(exp(Ver2',U2'),SGSr2')  % ((g^x)^u)^b = g^bux                    /\ K2' := H((exp(EVg2',SGSr2')).S2')   % K = hash(g^ab , g^bux)                    /\ M2' := H((xor(H(P),H(G))).(H(xor(EV,PW2))).Salt2'.EVg2'.SGSg2'.K2')              % M = hash(M1,M2,salt,A,B,K)        /\ Snd(Salt2'.{SGSg2'}_(exp(G,H(Salt2'.H(EV.PW2))))) % sending salt,B                    /\ witness(SGS,EV,k22,K2')                           /\ secret(K2',sec_resp_K2,{EV,SGS})                             4. State = 4  /\ Rcv(M2) =|>                   State':= 5 /\ PW3' := H(EVg2.SGSg2.K2)                /\ Snd(H(PW3'))                             /\ request(SGS,EV,k21,K2)                            end role                                 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%        Figure A.16: Chapter 6: HLPSL Codes of Smart Grid Server171A.4. Related HLPSL Codes of Privacy-Preserved Security Solution: Chapter 6%%  HLPSL:                role pev_Init (EV,SGS  : agent,                PW1   : symmetric_key,               H   : hash_func,                G,P   : text,                Snd,Rcv  : channel(dy))                            played_by EV        % electric vehicle                       def=                   local State   : nat,                 EVr1, EVr2  : text,              Salt1, Salt2  : protocol_id,             EVg1, SGSg1, X1, Ver1, U1, S1, K0, K1, M1  : message,         EVg2, SGSg2, X2, Ver2, U2, S2, K2, M2   : message,         PW2, PW3  : symmetric_key                             const sec_init_K1, sec_init_K2  : protocol_id                             init  State := 0                                 transition                                  1. State = 0  /\ Rcv(start) =|>                 State':= 1 /\ EVr1' := new()    % a = rand()            /\ EVg1' := exp(G,EVr1')   % A = g^a                       /\ Snd(EV.EVg1')      % sebding A and ID_EV to SGS                       2. State = 1  /\ Rcv(Salt1'.{SGSg1'}_(exp(G,H(Salt1'.H(EV.PW1))))) =|>            State':= 2 /\ K0' := H(P.G)     % k= hash(p,g)           /\ U1' := H(EVg1.SGSg1')   % u= hash(A,B)           /\ X1' := H(Salt1'.PW1)   % x= hash(salt, pw)           /\ Ver1' := exp(G,X1')    % ver = g^x            /\ S1' := xor(SGSg1',H(K0'.Ver1'))  % g^b + k.g^x - k.g^x = g^b                    /\ K1' := H((exp(S1',EVr1)).(exp(exp(S1',U1'),X1'))) % K = hash(g^ab , g^bux)                   /\ M1' := H((xor(H(P),H(G))).(H(xor(EV,PW1))).Salt1'.EVg1.SGSg1'.K1')            % M = hash(M1,M2,salt,A,B,K)         /\ PW2' := H(EVg1.SGSg1'.K1')                           /\ Snd(M1')                               /\ witness(EV,SGS,k11,K1')                           /\ secret(K1',sec_init_K1,{EV,SGS})                            3. State = 2  /\ Rcv(H(PW2)) =|>                 State':= 3                    /\ request(EV,SGS,k12,K1)                /\ EVr2' := new()                 /\ EVg2' := exp(G,EVr2')                           /\ Snd(EV.EVg2')                                4. State = 3  /\ Rcv(Salt2'.{SGSg2'}_(exp(G,H(Salt2'.H(EV.PW2))))) =|>            State':= 4 /\ U2' := H(EVg2.SGSg2')   % u= hash(A,B)           /\ X2' := H(Salt2'.PW2)   % x= hash(salt, pw)           /\ Ver2' := exp(G,X2')    % ver = g^x            /\ S2' := xor(SGSg2',H(K0.Ver2'))  % g^b + k.g^x - k.g^x = g^b                    /\ K2' := H((exp(S2',EVr2)).(exp(exp(S2',U2'),X2'))) % K = hash(g^ab , g^bux)                   /\ M2' := H((xor(H(P),H(G))).(H(xor(EV,PW2))).Salt2'.EVg2.SGSg2'.K2')             % M = hash(M1,M2,salt,A,B,K)         /\ PW3' := H(EVg2.SGSg2'.K2')                           /\ Snd(M2')                               /\ witness(EV,SGS,k21,K2')                           /\ secret(K2',sec_init_K2,{EV,SGS})                             5. State = 4  /\ Rcv(H(PW3)) =|>                 State':= 5                 /\ request(EV,SGS,k22,K2)            end role                Figure A.17: Chapter 6: HLPSL Codes of Electric Vehicle172


Citation Scheme:


Citations by CSL (citeproc-js)

Usage Statistics



Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            async >
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:


Related Items