I have started a project that involves tinkering with what some would possibly call a "smart meter", but I believe the proper noun would be an "AMR" or, "Automatic Meter Reading" meter. This project started mainly out of my curiosity in how digital metro-logy works, but also out of my curiosity in "smart grid" security in general. This project is in no way intended to commit "theft of service", nor help anyone else commit such acts. For obvious reasons, I don't plan on posting any intricate details on this blog, and all the code and tools I have wrote up to this point will be on a private git server until I decide when (if ever) I will make them public.
Metro-logy History:
Now, with that out of the way, I'm going to go over some quick history about utility meters in general so that people can have a general idea for why new meters are being developed. Most people remember the old electro-mechanical meters with the spinning dials. These generally worked by having a dial turn at varying speed, depending on how many kW/h (kilowatt hours) were being used, and this in turn turned other gears and gave a readout for a meter reader person to physically come on to your property to check. After this, some calculations were done based on the previous month numbers and they were able to determine how many kilowatt hours were used at your residence.
One of the downfalls of this type of meter was that it was time consuming, costly, and a bit of a hazard for a meter reader to have to physically get out of the vehicle and walk to each and every house directly. On top of that, some of the meters were designed with ferrous metals, which allowed a magnet to be placed on the front of the meter to slow down the spinning dial, which would report a lower kW/h usage, and thus rip the utility company off by cutting the price on your bill. Eventually they started to build the meters with non-ferrous metals, but there was also another "hack" which involved placing a meter inside the meter base inverted, or, turned upside down, which would sometimes cause the spinning dial to move backwards. This allowed one to "roll-back" their reported usage, and thus, again, ripping off the utility company.
Now, this is where AMR became practical. AMR uses a few different communication methods, usually they use either cellnet, ISM band unlicensed RF (radio frequency), and sometimes they even use newer technology like broadband over powerlines. The idea here is that the utility company can remotely gather utility usage information by driving by, or even have it sent to their sub station. These meters are usually digital in nature and this is the type of meter we will be focusing on with this particular project. The AMR meters are usually a one-way communication. Generally these meters just broadcast data at a specified interval for the meter readers to pick up on.
The "smart meters" came into existence mainly to build on top of AMR. Some form of AMR is usually built into every smart meter, but smart meters take it a step further. The smart meters usually allows the customers themselves access to the meter reading data, along with the ability to provide customers with a "time-of-use" utility pricing rate. This allows customers more control over when, and how they use utilities, and it allows "peak use" pricing. There are certain times of the day that put more strain on a utility system, and for this, they usually want to charge higher prices. This also makes it possible for people to actually save on their utility bill too by using this same pricing scheme. The way it works is simple, if it costs 10 cent for 1kW/h during the hours of 7am-5pm and it in turn costs 25 cent per kW/h from 5pm on to 7am and someone decides to use more during the 7am-5pm time, then they in turn save more money, as opposed to the utility company just charging the 25 cent at all times during the day. Smart meters also sometimes have more sophisticated functionality, but this is the bigger part of the idea.
Inside the Itron Centron C1SR:
First of all, Itron seems to have a few patents going on with their meters, and one of their ideas is to have boards built on top of their meter core. They usually call these add-on boards "personality modules". What this means is that if they happen to come up with a new module that a utility company sees fit to update to, all they have to do is change out the interchangeable personality module by just removing it, and the base and all of its components stay the same.
This meter core is under some pretty thick plastic, and is kind of hard to remove without breaking.
Meter Core:
The green thing you see in the picture is a metro-logy board, but I call it the motherboard.
Motherboard:
I'm still doing research on this board, but I have mapped out quite a few pins, but the main chip contains no public datasheet that I could find, so at this point, all I can do is speculate for the most part. What I do know is that the board connects by a "slip connector" over the pads (the ones in the far left of the picture).
What this board (likely) does:
Measure line voltage (Should be in the 240v range)
Measure reference voltage
Check energy flow direction (to make sure meter is not inverted)
Energy pulse data
Check line frequency (to make sure it's 50HZ, or 60HZ, respectively)
This board also has an IR LED (Infra Red Light Emitting Diode) that I suspect is used to calibrate the meter, because it seems to blink once for every 1 kW/h used. The way I suspects that this works is that they have an already calibrated "machine" that probably contains some sort of photo-diode that hooks to the top, and the machine draws exactly 1 kW/h of electricity, and the meter probably plugs directly into the machine, and it changes some kind of calibration setting in order to get the meter tuned in to reading 1 kW/h precisely as 1 kW/h.
The motherboard communicates to the daughter board through the slip connector it seems. The daughter board seems to house most of the "main components".
Daughter-board Front:
Daughter-board Back:
Some of the main components on this board consist of an ATmega MCU, a serial SPI EEPROM, a JTAG header (more on this later), an inversion/shake sensor, and a few other things. The radio itself looks to use the sub-GHZ range, more specifically, the 910-920 MHZ ISM band range. The radio appears to use FSSS (Frequency Hopping Spread Spectrum) as opposed to DSSS (Direct Sequence Spread Spectrum), and I was in fact able to pick up some activity with a hacked IM-ME pager using the spectrum analyzer. On the back of the motherboard there is an LCD header, and what looks to be 4 pins. The 4 pins appear to be the endpoint connector for a "resetting machine" that might, or might not, be able to reprogram the device also. What I do know is that the resetting machine is able to reset usage data, and tamper evidence data (more on this later too.)
What is done so far:
Most of the processing is done on this daughter board, and with some soldering, and code that I've written, I was able to dump the SPI EEPROM, the main program flash, the internal EEPROM, and also re-enable the JTAG port, and also turn on on-chip debugging, as well as have write access to all of the above. I've mapped out where a lot of the hardware and external stuff physically connects on to the MCU. I've also done some reverse engineering on the code that actually runs on the unit, and have made my own code that runs on the unit in the form of a "hello world" that works by printing the text out of the UART port.
Hello World Demo:
I have also managed to build an exact copy of the original firmware into an assemble-able form so that I can readily use the IDE to step through the code with JTAG debugging enabled, and also so I can readily make any changes I see fit to the code without doing any "patching", which makes testing things a lot easier. For now, the rest of this aspect of the project is mainly just figuring out what the code is doing, and also looking for any major security flaws I can find.
Security:
At this point, I'm not really in a position to be speaking on actual security of the meter, as there does not appear to be much. But as far as making headway on reverse engineering the system, I've been able to progress along pretty well. First off, one should know that there is in fact an external "security tamper seal" that you must take off in order to actually get into the meter. This seal is fragile, but with enough care, one could remove the seal, and also put it back on without much evidence left behind.
One of the other security features is the inversion/shake sensor. Apparently the way this works is that there is some contacts with what I assume to be a metal ball inside a canister. This is hooked to the MCU and is able to determine if someone has shaken the unit, or turned it upside down. The shaking of the unit along with a power outage reports as a "meter removal", where as a no shaking power outage is registered as just a power outage. The inversion detection also taps on the tamper counter. All of these signals are transmitted over RF to the meter reader when they check your meter. One could just as easily do some wiring in order to trick the meter into thinking that it's always turned upright and is never shaken, but in order to do that, you would need to remove the meter itself, which would set off at least 1 tamper signal.
The tamper signal register looks to be 4 bits wide, and accounts for 0-3 tamper evidence counts on each tamper tag (meter removal, and inverted meter) it might be theoretically possible to bypass and reset these 2 tamper evidence counters if you know how many times they have been set off, and through some complicated form of using binary arithmetic in order to cause the 4 bit number to "roll over" by doing different wiring with the sensor and such, until both of them roll back to 0, and have the sensor wired to no longer detect any of the above ones afterward (remember, there is a difference between the shake/power out, and inversion, so the sensor would have to be temporarily wired to mimic both until they reset, unless the whole register gets counted, in which case you could use the lower or upper half of 2 bits in order to make it reset.)
The MCU and external EEPROM at this point do not look to be properly protected, as I've been able to read and write to both of the chips, as well as readily map out traces and such to find where they go. So far I have not found any major vulnerabilities (well, ones that I consider to be major), but the fact that I was able to figure any of this out, and get the code to the point that I actually have it able to be rebuilt into a modifiable code base, means that under physical attack, the meter isn't very secure (for what it's worth, I don't think Itron, or anyone else ever claimed that it was.)
And... Closing...:
I still have a bunch more to figure out about the meter at this point, I just thought I would make a post about it at its current stage, maybe there is some interest out there for this kind of thing, and there does not seem to be much information on these types of things. Hopefully I'll know more in the coming months and I'll be able to get to a point where I can program an IM-ME to be able to do meter reading functions, and other things, but, until then, I guess I'll have to just keep researching. :)
