A consumption authenticator based mechanism for Time-Of-Use smart
meter measurements verification Sergio Camara1,2,a, Raphael Machado2,b and Luiz F.R.C. Carmo1,2,c 1
Federal University of Rio de Janeiro, Rio de Janeiro, Brazil
2
National Institute of Metrology, Quality and Technology, Av. Nossa Senhora das Graças, 50, Xerem, Duque de Caxias, 25250-020, Rio de Janeiro, Brazil a
[email protected],
[email protected],
[email protected]
Keywords: Security; Legal Metrology; Smart meters; Time-Of-Use; ECPVS signature.
Abstract. Energy meters have become smart and functionally powerful over time. Still many concerns about the correctness of their behavior are raised by society and the effort involved on new smart meters type approval are growing huge. Aiming at establishing trust on the smart meter, this paper proposes a consumption authenticator which can be read from the meter's display and verifiable by the user. This authenticator is generated inside a secure device, placed on the metering module, using ECPVS signature scheme providing partial message recovery. Since our approach considers different Time-Of-Use scenarios, a composing technique for the authenticator's embedded message is presented. Our concerns are the necessary data for validating Time-Of-Use rates measurement values and the final size of the message. Introduction In early 2000, Brazil took its first step towards smart meters by adopting a new meter type, called Centralized Measurement System (CMS), which has been specifically designed to reduce the rate of non-technical losses due to energy theft. The CMS architecture determined that the metering modules were no longer individually located in each residence, but grouped into a hub, usually positioned on the power pole. Each metering module is associated with their respective display device, located on the customer's residence, where energy consumption values are updated constantly through wireless communication [1]. The addition of new software features caused many meters to behave inappropriately over time, presenting typical flaws associated with software bugs. This growing complexity of the meter architecture and embedded software presented a new challenge to the Brazilian metrology authority: how to validate and trust a meter solution as the type approval process became more and more laborious to achieve? This paper proposes to reduce the amount of metrologically relevant software by digitally signing the information as close as possible to the point of “consolidation of measurement data”. Once such data is signed, any further manipulation would be detectable so that elements of software and hardware that processes the measurements data no more needed to be metrologically validated. We additionally consider a very practical assumption: the consumption authenticator must be read from the display and transcribed by the user for integrity verification of the measurement data. Such aspect considers a low cost solution for the verification process, once the user does not need to use a second device that communicates with the meter to download the authenticator. The proposal focuses specifically on Time-Of-Use (TOU) scenario and establishes a technique for composing such authenticator. Related Work In Germany, the evaluation process of smart meters is made based on the guidelines from WELMEC and PTB (Physikalisch-Technische Bundesanstalt), the German National Metrology Institute. In addition to the meters, the german metering infrastructure has one more element, a smart
meter gateway, which comprises related features to information security, in particular, confidentiality features [2]. So, by separating the particularities of the measuring instruments from the security functions, the gateway can be submitted for Common Criteria evaluations according to an appropriate Protection Profile. Other solutions for smart meters security are being proposed making use of cryptographic modules integrated to the metering architecture. In Feller et al. [3], a compact TPM version is implemented, which consumes fewer resources and requires a minimum set of commands. This cryptographic module is integrated into the device and provides intellectual property protection, correct metering behavior and secure firmware update. Infineon, a semiconductor manufacturer, has developed the UMF11x0 chipset family for smart meters which can be connected to a smartcard and a hardware security module. This architecture comprises functions for symmetric encryption (AES-128/256) and Public-Key Infrastructure, cryptographic keys protection and true random number generator. Besides the above-mentioned works, which are also concerned about security and behavior correctness of smart meters, to the best of our knowledge, the present work is the first one proposing a practical data integrity verification procedure that could be done by a TOU smart meter user. Problem Definition Software embedded in the smart meters cannot be assumed as trustable, that is, there is no guarantee that it will behave correctly or it will be the exactly the same software validated by the Legal Metrology Authority during type approval. The Legal Metrology Authority is aware that smart meters could be modified at a later time by consumers, manufacturers or utility companies to act maliciously due to their own interests, like earning more money. Conventional non-TOU meters only measure total electricity consumption, so the utility company, for instance, could employ a malicious behavior that increments the cumulative kWh register a little faster than normal to take advantage of the extra fake consumption for each month. Still, TOU meters could be adulterated in a subtler way ‒ some small percentage of cheapest electricity rates consumption could be added to peak rates registers in order to generate more expensive billing values, while keeping the total electricity consumption unchanged. So, for Time-Of-Use scenario validation, a consumption verification mechanism must assure consumption values at each rate. Beyond that, if this mechanism is not aware of the time rates, that it is our case, it must consolidate some necessary data for this purpose and make available this information for the end user, as an authenticator code. For reasons of no need for other devices to communicate with the meter, the consumption authenticator will be shown in its own display. This condition stipulates restrictions about the size, integrity and authenticity of this authenticator: it must be shorten as possible and cannot be counterfeited by other devices. In short, our efforts concentrate on describing this mechanism, on how it consolidates the necessary data for validating TOU consumption values and how the authenticator could be shorten. Proposal The purpose of this work is the creation of a mechanism to establish reliability on the generated data by a Time-Of-Use smart meter to all stakeholders - the consumer, the utility and the Legal Metrology Authority. Particularly, for the Legal Metrology Authority, this mechanism can be useful to easy the type approval process of smart meters. The mechanism proposed is based on a trusted hardware that we call Trusted Metering Module. The TMM is a custom cryptographic module, acting as a “root of trust”, coupled to the beginning of the legally relevant chain of the smart meter in order to store critical data and pass it forward digitally signed as the consumption authenticator. By definition, legally relevant elements are the measuring chain participants that are directly involved or, in any way interfere, in the process of capturing, processing and publication of the results to the end user [4].
We call the Measurement Verification Process (MVP) the process by which a consumer can check the integrity of the metering information. The MVP consists basically of the transcription of relevant data from billing or meter’s display into a computer system, followed by the execution of a verification algorithm, which validates whether the consumption values are reliable or not. The inputs required by the system are: the consumption authenticator, the Time-Of-Use rates configuration and consumption values, and the TMM public-key. Trusted Metering Module. The TMM is a cryptographic chip also capable of performing custom procedures and storing values of consumed energy. Its internal components are: the processor, the program code, the execution engine, protected memory (to store the cryptographic keys), persistent memory (to store the values of power consumption), the signing and encryption engine, the hash engine and the Real Time Clock. The TMM has two data inputs: one connected to an Analog/Digital converter of the metering module, receiving data from voltage and current from the phases of the electrical circuit, and other for clock synchronization, which can be corrected by the meter application, restricted by the maximum error expected in one year. The Real Time Clock must be accurate, with a tolerance below 5 ppm (parts per million). In principle, no other input is considered for any purpose, so that potential vulnerabilities to be exploited are minimal. In protected memory, TMM stores a unique private key, hardware-generated at manufacture time, along with its public key. This key pair is based on elliptic curves. Also, a calendar is hold in protected memory. TMM converts the data from voltage and current to kilowatt-hour values. That said, TMM can calculate and record the accumulated total energy values by fixed periods of one hour duration (for instance, 11:00:00h - 11:59:59h). So, there are 24 registers storing accumulated consumption values from the installation time of the meter till present moment. Besides these, there is one more register for recording off-peak values consumed on all weekends and holidays. This is how TMM handles Time-Of-Use rates. In fact, TMM is not aware of the TOU rates configuration, so TMM must always keep all the registers updated for correctly composing the consumption authenticator, which we will by now call it Distributed Consumption Authenticator. Distributed Consumption Authenticator. Technically, the DCA authenticator is a base64-encoded ECPVS signature (Elliptic Curve Pintsov-Vanstone Signature). Since ECPVS scheme, specified in ISO/IEC 9796-3:2006, allows small digital signatures ‒ about six times smaller than RSA and half of the size of ECDSA ‒ giving partial or total message recovery, these characteristics fits ideally to DCA authenticator requisites. One actual application example for this scheme is the use of ECPVS signatures on Digital Postage Marks [5]. An ECPVS signature is represented by (r, s), s being the cryptography overhead and r being the recoverable message, the DCA-message. DCA-message Composition For choosing the appropriate number of bits for each data in DCA-message, we will take into consideration the following assumptions: (i) the maximum monthly energy consumption of a residence is 4.000 kWh. In Brazil, the monthly consumption is way below this, therefore we are considering the vast majority of customers’ classes, and (ii) the maximum life time of a smart meter is 20 years. In this case, we also considered a reasonably high value according to the life span of an electronic meter, which is about 12 years. According to recommended digital signature algorithms and hash functions in FIPS (Federal Information Processing Standard) issued by NIST [6], the domain parameters we will use for the signing process of DCA authenticator are: (i) 224-bit Elliptic Curve over finite prime field, (ii) SHA-224 Hash Function and (iii) Three-key Triple DES Encryption and Decryption cipher.
The DCA-message must contain sufficient data to be able to validate the display kWh values according to Time-Of-Use rates. Since the TMM is not aware of the specified time rates defined by the electricity agency or the power company, the DCA-message shall, in some way, represent the registers values from the TMM in order to make possible the Measurement Verification Process. Once, to the best of our knowledge, all existing Time-Of-Use rates consider the range between 11:00 p.m. and 5:59 a.m. as off-peak, so our first manipulation is to sum all of their corresponding 7 register values to the off-peak block representation (reserved before only for weekends and holidays) and, then, reduce the final size of DCA-message. For the remaining registers, we will use the following explained technique. Modulus Counters Technique. This technique establishes that the register value, Vali, is represented in DCA-message by a sequencial counter that increments as long as Vali is incremented, however restricted by the integer interval [0, 2k-1], k < 16. So, let k be the number of bits for representing the register values, and Repi calculated by the following formula: Repi = Vali mod 2k.
(1)
Therefore, this technique implements some logical compression on data stored in TMM. In fact, this compression algorithm is asymmetric, as long as the time expended for recovering the compressed data can be much larger than compression time, this depending on k. Another concept used is the interval between the lower and the higher register value on each Time-Of-Use rate (Intervalmax = Valmax - Valmin). As Intervalmax grows bigger over time and due to a brute-force part in the decompression algorithm for finding the original values, decompressing process could also grow huge. The maximum time we assume for decompression is about one minute, although this is not a requirement but it is only a reasonable choice. For determining a suitable number of bits for Repi and find the best trade-off between the time for decompression against total size of the DCA-message, for each k ϵ [8, 14] and for each Intervalmax ϵ [1.000, 20.000] was simulated 100 DCAs on the TOU rates configuration of the Ontario Energy Board [7]. The simulation was held on a PC, Intel Q6600 CPU 2.40GHz, 8GB RAM. The generated DCA authenticators and the Modulus Counters Technique were implemented in C++ language. From the simulation results, we shall consider for decompression time below one minute, k = 11 allowing Intervalmax = 6.000 kWh (19 seconds, average) and k = 12 allowing Intervalmax = 13.000 kWh (46 seconds, average). So, calculating DCA-message size for k = 11, it will gives us 239 bits, while, for k = 12, the size would be 256 bits. However, as long as the signing process must pad the embedded message to match the size of the symmetric cipher's block size, that being 3DES, the message for k = 11 will be padded till 256 bits, so k = 12 is preferred by allowing a greater Intervalmax value. For k = {8, 9, 10}, Intervalmax allowed is very short and decompression could take a lot of time as cumulative consumption values rise through the years, and for k = {13, 14}, the DCA-message size would be 320 bits. So, after all, k = 12 was chosen for having best trade-off between time decompression and message size. Therefore, by the Modulus Counters Technique, the final size of the DCA authenticator (r, s) is 32 + 28 = 60 bytes, resulting in 80 base64-encoded characters. The 256-bit DCA-message is composed as the following: 1. Sum of off-peak rates (including 11h-5:59h): 20 bits; 2. The 17 representation of registers values (Rep6 – Rep22): 12 bits for each representation; 3. Hash of the concatenated 17 registers values (Hashabs): 32 bits; Decompression Algorithm. In Measurement Verification Process, the decompression algorithm recovers the original data from the representations in DCA-message. This algorithm shall operate as the following: 1. Compute list lValCandi of all possible candidates for Repi, i ϵ [6, 22];
2. Compute all combination of elements from (lValCandi, … lValCandi+j), where this group belongs to one TOU rate and the sum of their elements is equal to this TOU rate value inputted. Add this combinations to lSeqCandrate (Candidate Sequence list by rate); 3. Include the combination of all lSeqCandrate to lSeqComb; 4. Calculate Hash() for all element in lSeqComb; 5. When there is a successful match with Hashabs, the original values (Vali) were found. When the original values are recovered and the cryptography overhead is successfully verified, this means that the measurements values inputted are validated. Security Analysis For any attempt by the consumer, the meter or the utility company of counterfeiting the DCA authenticator (presenting more kWh on peak rates, for instance), the attacker must be aware that all the following DCAs must be coherent with DCAs verified before, as it carries some accumulated data. The probability of counterfeiting is inversely associated to the size of private key and hash function used for signing, along with the known redundancy on the embedded message. Availability attacks, when the authenticator is not shown in display, could be easily detected by the user. The cryptographic overhead in the ECPVS signature could also be shorten, however this implicates on changing the size of keys used for signing. For instance, ECC-160 keys would generate an overhead of 20 bytes. Although, according to NIST, 160-bits elliptic curves based keys are disallowed after 2013 [6]. Conclusion In this work, we presented a proposal that provides behavior reliability and authenticity of the smart meter data for the customer and the utility company. Besides that, it can be used to easy the effort in the process of smart meters type approval by the Legal Metrology Authority and, as a consequence, mitigates some risks associated with opening and storing proprietary source code. The proposal considers different Time-Of-Use rates scenarios and was achieved by a secure hardware mechanism and a consumption authenticator. This authenticator is displayed by the smart meter for each consumption values update and carries necessary data for verifying the measurements taken. We showed that, with some logical data compression, by now, we could get an 80-caracter consumption authenticator, allowing transcription by the user. One idea considered for future work is a “relative” DCA authenticator, where it could validate smart meter measurements considering smaller periods of time based on another DCA collected before. References [1] D. Boccardo et al., in: Software evaluation of smart meters within a Legal Metrology perspective: A Brazilian case, ISGT Europe (2010). [2] BSI: Technische Richtlinie BSI TR–03109 (Germany 2011). [3] T. Feller et al., in: Tinytpm: A Lightweight Module Aimed to IP Protection and Trusted Embedded Platforms, IEEE International Symposium HOST’11 (2011). [4] Inmetro: Regulation nº 011 (National Institute of Metrology, Quality and Technology, Brazil 2009). [5] Certicom: Code and Cipher. Certicom’s Bulletin of Security and Cryptography (2004). [6] E. Barker and A. Roginsky: NIST Special Publication 800-131A (USA 2011). [7] On http://www.ontarioenergyboard.ca/OEB/Consumers/Electricity/Electricity+Prices.
