Prepaid Electricity Meter Fraud

New attack:

Criminals across the UK have hacked the new keycard system used to top up pre-payment energy meters and are going door-to-door, dressed as power company workers, selling illegal credit at knock-down prices.

The pre-paid power meters use a key system. Normally people visit a shop to put credit on their key, which they then take home and slot into their meter.

The conmen have cracked the system and can go into people’s houses and put credit on their machine using a hacked key. If they use this, it can be detected the next time they top up their key legitimately.

The system detects the fraud, in that it shows up on audit at a later time. But by then, the criminals are long gone. Clever.

It gets worse:

Conmen sell people the energy credit and then warn them that if they go back to official shops they will end up being charged for the energy they used illegally.

They then trap people and ratchet up the sales price to customers terrified they will have to pay twice ­ something Scottish Power confirmed is starting to happen here in Scotland.

Tags: , , , ,

Posted on September 21, 2010 at 1:42 PM • 66 Comments

Comments

atis • September 21, 2010 2:24 PM

Recently I have been visiting UK and found those power meters surprising.

They had paper cards with magnetic strip, as I understand card is used only once because place I stayed had several of them laying around power meter.

It would be possible to have cards cloned to another used card, so apparently card should contain only ID and meter should have some sort of closed circuit communications back to power company.

Harrow. • September 21, 2010 2:40 PM

@Sweeney: (Makes the old way of putting the pennies into the gas meter look good!)

Is that what that was? My father told me it was my piggy bank!

-Harrow.

Jack • September 21, 2010 3:06 PM

Another possibility: the hack works, the electricity company can’t detect it and this story is a social countermeasure.

Here in the UK we have a TV license, a mandatory annual fee for any household with a TV. We have long been warned that there are “detector vans” capable of determining whether a TV is being used in a property. The BBC have never explained how they detect a TV and have been exempted from the Freedom of Information Act on the grounds that revealing what is actually inside the van would diminish the deterrent effect. A cynical man might suggest that the detector van is something of a hollow threat.

http://www.theregister.co.uk/2008/10/27/beeb_tvdetector_secrets/

somebloke • September 21, 2010 4:42 PM

From the linked report:

“It must be made clear that using these illegal devices is a criminal offence.

Users may not fully appreciate this but should ask themselves – if something seems like to good a deal it most probably is.”

Surely that’s a typo?!?

Technical details would be useful. What constitutes a ‘hacked key’? There appears to be little technical detail (presumably so that everyone else doesn’t start doing it themselves!)

Gary • September 21, 2010 5:51 PM

TV detection vans work on the basis of Van Eck phreaking. Wikipedia suggests they work on LCD as well as CRT, but doesn’t mention plasma TVs.

In practice though, they often just went around to places without a TV licence on the basis that most houses have a TV.

Imperfect Citizen • September 21, 2010 7:15 PM

@John Hardin LOL!!
It could be worse, at least they aren’t hell’s grannies going door to door beating people up for tea money and yarn for the crochet.

caf • September 22, 2010 12:47 AM

Jack’s explanation has the ring of truth about it. Consider: If the power meters were “online” devices, then the hack wouldn’t work; ergo the power meters are likely offline devices. If they’re offline devices, then there doesn’t appear to be a vector to detect the attack.

Nick P • September 22, 2010 1:58 AM

Very poor security controls + offline operation = something less than newsworthy for security engineers and admins. Simply following best practices could have beaten this scheme. One such best practice is having offline devices authenticate data using a digital signature and a hard-coded public key. There are so many cheap crypto-capable boards out there that there’s little excuse these days, especially considering the costs of compromise. I think that simple public-key trick would have defeated schemes like this entirely. A processor like MIT’s Aegis could also help in similar future scenarios.

RobertT • September 22, 2010 2:47 AM

@NickP
I have not read all the details of the hack BUT for offline payment cards it is very difficult to get around the need for a single shared secret. even if it is simply for mutual authentication.

It is true that the stored data could be encrypted with a two key crypto system but this does not necessarily prevent the hack because it appears they are selling / using a card based upon an official original card.

The easiest hack of this kind is to simply prevent the on chip EEPROM being written, so they buy an official card, destroy the EEPROM write circuit, and use it on lots of meters. hence the need to go door to door. It could also be a cloned card, but that is a little harder, because you now need to get the cloned chips manufactured.
Since the meters cannot communicate with each other, they have no way of knowing that the cloned card is being used in multiple locations.

Ideally the meter should not add the value until it verifies that the card has subtracted the value (i.e. decremented the on chip EEPROM) but some simple changes to the code can make this communication happen with the RAM rather than the EEPROM. (BTW Most modern payment cards can prevent this by encrypting RAM data differently from EEPROM data)

I assume that the end user will not be able to add value to the cloned card (hundreds of people turning up with the same card ID is a little obvious), so they would need to officially add vale to their old card which would raise the issue “how they got the last $50” I assume the card has a record of the meter reading and corresponding last payment. The error probably gets picked up the second value add after the hacked card is used.

Mike Harrison • September 22, 2010 2:57 AM

I’m in the prepaid electricity industry, but not in Europe. We typically use STS/IEC-62055-41 token based meters as well as AMI. No actual details of what happened, so I can only make some guesses:

It’s a “two way” token carrier key. At some point you take your key back to a vending point, which sends a total kWh reading upstream. They see your meter shows a usage of X, you have only paid for Y, you owe the difference. Detecting the fraud is easy, and may include a signature (ID) of the original token generation if it is a clone of some valid master key. Most meters of this type can also export entered tokens, which can be checked against the master system to make sure they match. Such tokens are typically encrypted and valid only for a specific meter and date range, although exceptions exist and may be the exploit.

Two-way communications (aka AMI) meters are more expensive and have communications infrastructure costs beyond “token meters”, and have their own issues/attack vectors. They are not a cure-all, but they do address other issues. The issue here is unique in “non-technical losses” in that normal decent good customers that didn’t really think they were doing anything wrong ended up in trouble.

bob • September 22, 2010 4:10 AM

“In practice though, they often just went around to places without a TV licence on the basis that most houses have a TV.”

Never had a TV, get hassled by door-to-door warden types on a fairly regular basis but have never seen a van.

Ayo • September 22, 2010 4:49 AM

People could top up illegally and then ‘misplace’ their cards and have the energy company issue another card as replacement. Breakdowns like this always happen when appropriate procedures/processes are not implemented or people are given the incentive to bypass implemented processes.

Autolykos • September 22, 2010 6:58 AM

The trick with those Detector-Trucks is old – older than TV even. The Nazis drove around with trucks that had antennas on top and claimed they could find out if someone was listening to foreign radio. Quite a lot of people probably believed this, so the broadcasting companies also found this trick useful (the German GEZ also does this – oh the irony).

NobodySpecial • September 22, 2010 9:55 AM

TV detector vans detect the LO frequency in the tv tuner, so don’t care what kind of display you use.
However a recent BBC program revealed that they only had 8 active vans for the whole country and the triangulation process was very slow. So most of the vans were just dummies that dropped off a bunch of inspectors with a list of addresses of people without a licence – although the dummy vans had the same antennae on top.

James • September 22, 2010 12:34 PM

Yes, detecting the Local Oscillator is a good way, although it can probably be defeated if you line your house with a metal to create a faraday cage. Clearly this is a bit overkill and I think it will be cheaper just to pay.
I do believe the vans also go about with luck. Lets face it, most people have TVs and those who don’t pay have a higher likelyhood they’re stiffing the government.

Nick P • September 22, 2010 4:47 PM

@ RobertT

Good info. I think I wasn’t clear about how my scheme would be used, so I’ll give some specifics for you to review. The private key would be held by the utility company to sign a particular credit. The public key would be in the meters, probably with one of the cheap crypto-chips protecting & using it. The physical key would simply contain a digitally signed piece of data with any critical information: the meter that should receive it; the owner’s ID, if any; the amount of electricity purchased; timestamp. Modifications to the physical key wouldn’t help, as the signature and data wouldn’t match. I would probably make the input non-DMA, as well. This makes the meter itself and the private key the target, with the meter more likely to be targeted.

At this point, one can use tamper-resistant design with tight integration of control and security functions. I’m not saying it would be “secured,” but might be made harder to attack. But my scheme to digitally sign the credits and verify them at the meter should beat any attacks on the physical key because it’s treated as an untrusted storage medium. What do you think of this scheme with the extra detail?

Also, I’m a system designer who lets other people do low-level hardware implementation details. This means I welcome any insights on securing the meter from attack. I’m also curious if it would be possible to integrate control of the electricity and the security functions on the same chip. I guess I’m looking for a way to keep the most basic hardware hackers from bypassing the security function and just telling the meter: give them electricity. Any ideas?

RobertT • September 22, 2010 10:28 PM

Problems with your proposal
1) you can’t limit the customer to using ONLY the initially issued smart card that is associated with their meter. Basically people loose these things, renters move and take cards with them. So EVERY offline payment system, MUST work with a generic card purchased at an appropriate store.

2) Because of the requirements in 1) a cloned card with a certain credit must work everywhere. The details of the crypto (two key, single key, elliptic, whatever are irrelevant), because the perp does not alter the information on the card, to create value, rather he exactly copies the good cards information, including the encrypted value.
Usually to do this exact copy of a card, the hacker needs to gain direct write access to the EEPROM using a test mode. and needs to change the cards own ID to match the cloned cards ID.

As I said earlier, the easiest hack is to buy a good card and just to kill the EEPROM write circuits. This is detectable / correctable at the system level, but that assumes the meter system person actually knows how to correctly program secure software…..

3) Fixes. All fixes for this problem require that a valueless card be inserted into the electricity meter and have the meter sign the cards info so that the value subsequently added can be uniquely created for this meter. Unfortunately this is a two step procedure for the end customer and is is therefore unpopular. An alternative is to have the meter display an ID which can be written down and entered when the credit is purchased. Unfortunately this puts people in the crypto loop, so this system is prone to error.

Other fixes:
If the generic card has a serial number, which cannot be faked, than even a hacker with access to the correct cards cannot clone a card. Most payment card ID’s have lock bits that theoretically prevent them being reprogrammed BUT…

New solutions:
To achieve this “unfakeable” card ID payment card makers are trying to use fundamental physical differences in the construction of the chips to create unique ID’s. The hackers get around this by changing their clone cards program to query a ROM location for the ID rather than reading the card ID, so the ROM gets programmed with the unfakeable ID of a good card, and so the game continues…

Ultimately the security of the card / payment system depends on protecting a secret, it might be a “key” or a methodology, but IMHO the best security ultimately rests in the undocumented steps that protect the stored key information.

Tamper resistance:
All new electricity meters have tamper resistance built-in, usually this is done by sensing both Active and Neutral current and comparing the two.

Unfortunately without a return comms channel, the meters knowledge that it has been tampered with is of very little value too the electricity provider.

Wil • September 23, 2010 3:34 AM

regards detector vans tangent: read Spycatcher, it discusses how MI5 discovered you could even detect what frequencies a receiver was listening too by blasting and listening too the howl

its all tempest, so yes detector vans do work. If they are used as much as their owners would like us to imagine is another thing, of course.

Clive Robinson • September 23, 2010 10:35 AM

@ RobertT, Nick P,

The problem boils down to a trade off in what can be done and the costs. The fact that it’s an off line system means it’s always going to be a bust and there is no way to stop it.

If you think about it, the simplest way around Smart meter security is not to use the silly thing in the first place, just appear to be using it.

That is you put a small load on the consumer side of the meter, then disconnect the meter from the consumer unit (fuse board). You then find an appropriate point in the distribution side to take a spur to your consumer unit…

The utility company can with time detect this due to taking the total load at the substation and comparing it to the total readings from all the meters (but low usage used to get missed in the +-5% meter acuracy).

That is the simplest bottom line attack you have to defend against no mater what you do to the meterit cannot currently be stoped.

The next step up for the attacker and virtualy undetectable by the utility company is to drill a hole through a party wall and spur of your neighbours consumer ring. That way the meter readings tie up. Your neighbur will notice it if you are silly and “cain it” but not otherwise.

In this case the utility company does not care one jot as they are getting the money due…

So the only thing of interest to the utility company is what the price of the “secure meter” is over the cost of the “insecure meter” and how does it compare to the losses from bypassing the meter.

That would be the bottom line if it was not for Bl**dy Stupid Politicos. They want smart meters so they can jump on the “green band wagon” without speending any tax money (as they’ve blown it all on bribing voters and schommozing the banks).

So the master plan is to force the meters in by legislation and get the poor consumer to pay for it.

This is a massive eye wateringly bright big fat mouth watering wet dream for the utility companies. Because you dear consumer will have to pay for a meter you most certainly don’t want and the utilities will profit by it with multiple tarrifs with all sorts of different rates and confusion.

Think how mobile phone companies exploit those who just want a simple service, as the lowest level of what the utilitis hope to achive, all in the name of “saving the planet”. And you won’t have a choice because if you object to the plan you are obviously a “filthy no good planet wreaker hell bent on consuming the scant natural resources for the perverted pleasure of creating polution to poison all the little children etc etc.”

For the Politicos and the utilities it’s a certain winner as for us consumers grit your teeth and bend over to have your wallet extracted the hard way without the benifit of either pain killers or lubricant…

Nick P • September 23, 2010 3:48 PM

@ Clive Robinson

Stealing from the neighbors being the best, but least ethical, of your ideas. The idea can be (and is for some people) extended to water and WiFi.

@ RobertT & Clive

“1) you can’t limit the customer to using ONLY the initially issued smart card that is associated with their meter. Basically people loose these things, renters move and take cards with them. So EVERY offline payment system, MUST work with a generic card purchased at an appropriate store.”

Decent point. I had a hell of a reply for you too. I spent an hour designing an online smart meter system that used signed messages stored on untrusted cards along with a message revocation list at utility side to provide the security with no usability loss for customers. After I wrote up two great systems with tons of capabilities, I came up with a radical idea that seems so good I deleted all the other stuff. My online meter would handle energy credits with excellent security, but in the US I think this radical approach might deserve consideration. (And folks, you saw it here first!)

RADICAL APPROACH I JUST BRAINSTORMED (very abstracted)

In the US, we typically get our electricity turned on, use as much as we like, then pay the bill the next month. We might even get an extra month with penalties. If we don’t pay enough after a certain period of time, they send a guy to cut it off by physical interaction with the meter. Activation has a delay and requires physical interaction with the meter. This leads me to think of a simpler automated design which doesn’t [apparently] suffer from credit reuse attacks because it doesn’t use them, while using an untrusted card to transport critical data. Here’s the 50 mile overview:

  1. The meter denies electricity to the house by default.
  2. User supplies a card that tells the meter to turn on and stay on until a set date and time. (usually 1 or 2 months in future)
  3. After that period, the meter kills the power. (Except to the meter of course 😉
  4. When a user pays their bill, their card is updated with a signed message containing a new cutoff date for their meter.
  5. The user inputs this data to the meter. The meter validates it, then sets the cutoff time to the one on the card.

In this system, default deny is used to force authorization. The utility just sends the machine a cutoff date tied via a unique ID to that specific machine. By not adding or removing anything, along with the unique ID, we don’t have to worry about replay or reuse attacks. Entering that code/card would just further ensure their power was cut off. This system is fundamentally simpler than credit based systems and is compatible with existing US usage and billing methods. What do you guys think about THAT one? Just so original, simple and probably easy to implement. Here it is a bit more precisely.

RADICAL SMART METER SYSTEM SPECIFICATION (offline version)

1A. Meter Requirements
1-1. Controls flow of electricity into home.
1-2. Receives input in form of card. (Maybe serial port for field personnel.)
1-3. Internally possesses a unique meter ID.
1-4. Validates input by checking format, meter ID and signature.
1-5. If input is valid, sets internal cutoff date to date on card. Notifies success or fail code.
1-6. Has accurate internal clock or way to deal with drift.
1-7. Security Policy: Cut off electricity at the set time.
1-8. Log and report the amount of electricity used in trusted way.

1B. Meter Functions
1-1. Activate or disable mechanism to allow electricity to flow.
1-2. Read data on card via non-DMA interface.
1-3. Hash the data and verify the signature w/ utility public key. Public key is hardwired to the system or stored on a cryptoprocessor. Check for proper format. If properly formatted, check that unique meter id in signed data matches the meter at the person’s house.
1-4. Set internal cutoff date to date on card. Notify via outputs of success or failure w/ fail code. If the cutoff date is stored on untrusted storage, sign it and verify it during system boot. If verification of internal cutoff date ever occurs, kill electricity and notify via fail code.
1-5. Many clock implementation strategies.
1-6. The security kernel will be invoked regularly. The security kernel executes the security policy: If TodaysDateAndTime < CutoffDateAndTime, allow electricity. Enable or disable electric flow as needed.
1-7. If its not an online system, customer inserts their card into the device. Device gets electricity usage, timestamps it, signs it with private key, and loads info on card. Private key is hardcoded to chip or stored on a cryptoprocessor.

2A. Utility Requirements
2-1. Keep records that associate customers and meters with homes [via addresses and such].
2-2. Collect the usage data and bill customers for usage data.
2-3. Upon satisfactory payment, determine new cutoff date.
2-4. Generate signed data containing the meter’s unique id and new cutoff date. Meter ID is stored in the customer’s billing records.
2-5. Put signed data on customer’s card.

2B. Utility Functions
2-1. Identify customer with traditional information gathering processes, associate meter ID at address to customer record, and issue card & credentials.
2-2. Collect Usage Data
2-2-1. Copy data from customer’s card.
2-2-2. Hash it and verify the signature using database of meter public keys.
2-2-3. Check for proper format. Check timestamp for recency, reject according to company policy. Verify meterID from card matches meterID on file for customer.
2-2-4. If validated, send the usage data to the billing system.
2-2-5. Give customers a bill in some way.
2-3. Billing system generates a new cutoff date and puts it on the bill. It will be applied after payment.
2-4. Customer pays. Retrieves the meterID and new cutoff date. Hashes & signs it.
2-5. Signed data is sent to the card reader/writer, which puts the data on the card.

  1. Card Requirements
    3-1. Stores a few KB of data.
    3-2. Industry standard durability.
    3-3. Non-DMA interface. (Prob magstripe.)
    3-4. Cheap.

(Note: See how unimportant the card is? Users might be provided with a backup during account setup to use interim until they get a new one.)

Assurance Arguments

  1. The security policy and enforcement mechanism prevent electricity from being used past the cutoff date.
  2. The only user activity at the meter is setting a new cutoff date.
  3. Due to digital signatures, the utility provider must authorize any cutoff date change.
  4. The user can only forge usage information by subverting the meter. (Random audits, internal tests and [more] secure chips help prevent this.)
  5. Reuse of a card at either end can’t help the customer cheat the electric company due to timestamps & the non-additive nature of the scheme.
  6. The security relevant functions are simple enough to verify and verified components exist to implement them.

Hopefully a slam dunk of offline meter system design without a security flaw. (I probably shouldn’t have opened my mouth there…) The system is also simple enough to be formally verified to high assurance standards. Anyone doubting that should look at BLACKER: it was a complex VPN & authorization system that got Orange Book A1 rating using 1980’s engineering & verification technology. Our capabilities have advanced considerably since then. There’s also plenty of COTS components to implement this scheme, including a plethora of cheap cryptoprocessors designed to resist tampering & side channel analysis. The system also further backs up my claim that N increase in security/assurance doesn’t imply N decrease in usability. It’s extremely usable: both usage reporting and setting new cutoff date are done by the user hitting a button, using the card and seeing an OK message. Interaction with utility regarding card data can be done at utility’s office, at a kiosk, or over the internet using PC software and a card reader/writer attached to their PC. USB would be easier but poses security & assurance issues. I’ve considered a dongle or something, but I’m trying to keep it relatively simple.

So, what do you guys think about this radical little scheme? If it passes analysis, I should probably patent it. (Note: I explicitly reserve copyright on the ideas in this post, just in case…).

Werner • September 23, 2010 4:15 PM

You can generalize the idea. Instead of putting a credit on the card, you put a limit against cumulative use, be it time (as in your example) or total consumption.

Total consumption would have the advantage that you don’t need to match consumption with time.

Activating a new card would require synchronization with the meter, but you could work around this by having an “emergency credit system” that gives a small additive credit (like the current cards) but that can only be invoked every so often.

By the way, if the meter can write the current cumulative consumption to the card, you don’t need online reporting either. The customer will bring a recent meter reading each time they recharge.

  • Werner

RobertT • September 23, 2010 8:44 PM

@NickP
Interesting, but I think you lost sight of the target market “pre-paid electricity” and the nature of the customers that normally select this option.

Prepaid is most popular in rental accommodation, short term leases and with those who’s credit rating is too low for the electricity retailer to offer credit.

Your scheme appears to offer a fixed 1 month credit and requires that the user take the card to an appropriate store, to have the meter results read every month regardless of their actual usage rates.

So a big reason for prepaid is that no one was offering them 1 month Credit to begin with. The electricity provider also cares more about the amount of electricity used than the date by which it is used. If you are suggesting that the date “time-out” add an extra level of protection then this is a reasonable idea that is already implemented in most meters that I have seen. (basically pre-paid coupon is good for 3 months maximum)

It seems to me that all your added security comes from the requirement than the card be signed by the meter, before value is added to the card. I think this is the same as I said above, unfortunately for the consumer it becomes a 2 step procedure, which makes it unpopular. Secure YES popular NO.

As far as the electricity retailer is concerned there is no real difference between fake cards and meter bypassing (as Clive pointed out). The meter accounting methods that they use to detect both types of theft are basically the same, so if the scheme is used for any significant length of time than meter inspectors will be sent to the appropriate sectors and will check for problems. I have no idea if the law is different for meter bypassing vs use of fake cards, but i suspect both are treated the same way.

I’ll reread your proposal tonight when I have a little more time to focus.

Nick P • September 23, 2010 8:46 PM

@ Wemer

Interesting ideas. Total consumption, in particular, has a lot of potential. It could actually be implemented just like my system, reusing much of its design effort. The device would keep a consumption counter and a consumption limit. The card could have a signed message with the new consumption limit, rather than “add this many hours” to prevent reuse attacks. I figure that’s how you intended implementation.

The utility company could represent consumption values by a 64-bit number, with 128-bit in an extreme case. The meter could do it one of two ways: a 64/128 bit number for both total and max consumption that always increase; 32 bit values along with a 32-bit counter. The lower bits are mentioned to take advantage of cheap 32-bit chips and possibly 16-bit chips that can do simple 32-bit math. I’d rather use 32-bit w/ MMU to take advantage of recent safety-critical RTOS’s, esp. separation kernels.

In the 32bitscheme, each reload would subtract last months total consumption from the running total and optionally set a new max consumption. The inputs would be provided on the card by the utility company and signed. I am using subtraction here to account for the delay between meter reading and loading continued activation data from the utility company. I think even if it goes through months worth of use before a reload, the consumption value shouldn’t overflow: residences that use over 4,294,967,296 kwHr’s in three months will probably be using the industrial version with 64-128 bit counters. A 32-bit counter should suffice as I doubt any home will ever experience more than 4,294,967,296 bill payments either. So, that’s three simple variables and just a few primitive operators. Seems easy enough.

Everything else in my design would stay the same. The timestamps might be removed if the utility company audits unusually low utility usage or sharp declines in usage. The audits should include comparing reported usage with substation readings and inspecting the meters of homes with sudden decreases. They could keep a record of the previous month (or all months) to perform this check to ensure a sane data value and use the signature to verify authenticity.

All in all, your proposal is pretty cool. If we use my old scheme with your total consumption modification instead of cutoff dates, we still can have untrustworthy cards and only need to activate the meter, which can be done through the card with signed command. In the process, we may be able to remove the time stamps and maybe the ultra-reliable clock requirement for the control system. Nice progress on this for four guys and a few hours effort. 😉

Nick P • September 23, 2010 9:06 PM

@ RobertT

It does seem to be an issue of markets. In that market, my system wouldn’t meet requirements. Like I said, out here people do actually get a month or two credit. I don’t know if it’s most of the US or just most of the Southern states where I’ve owned property. There may be some usage limits, but I’ve never noticed them in many cities. Their MO is to let you turn on electricity with a deposit (covering their butt), let you use it until billed, cut you off if you don’t pay, and sue you for the money if you don’t pay the now higher bill (penalties and such). So, our utilities essentially do work on a month or two credit and the Mid-South companies treat the second month as a grace period where they add late penalties and you don’t get cut off. The time between first bill and cutoff usually doesn’t change so that could automatically determine the digital cutoff date put onto a card.

Your usability complaint is valid. It does add an extra step. However, the same complaint can be lodged against the credit based offline systems. As far as I was aware, the user had to load the card somehow and then use it on the meter somehow. In my system, the user loads data on the card and uses it on the meter. Same no. of steps. In our existing Mid-South companies, I just use as much electricity as I want and then pay when the bill comes. Payment can be done in person, by mail or over the phone with cash, check or credit cards. All offline smart meter systems that have been proposed add at least one extra step for us. It might not be a problem: utilities are a monopoly out here and they can easily force a system adoption. They have in the past and they certainly could again, so an extra step or two might only hurt public relations rather than adoption.

I could build a usage monitor into my design similar to the total consumption that Wemer and I are discussing, but I really haven’t seen it. Business customers might have to deal with that but I’ve never had to handle the administration details for business class electricity and hence don’t know if it’s different for them. The only limits I’ve run into on utilities have been an Internet bandwidth cap. If the utility wants to impose limits, the system and signed data could be modified to do that. I think I need to study the markets you are discussing as they seem to be very, very different from ours. Maybe crank out a credit-based design for them after I learn how they work. In mean time, with my market characteristics I’ve given you, what do you think of the cutoff or consumption systems?

Ralph • September 23, 2010 9:22 PM

These meters charge about 1/3 more for the electricity than someone getting credit and paying by direct debit.

It really is expensive power. They make the poor pay more. In Scotland as well – chilly.

Not only that but they can increase the rate to include paying back any previous debts or indeed debts of previous tenants.

RobertT • September 23, 2010 11:06 PM

@NickP
Just a quick reply
1) People selecting Perpaid electricity often may not want Credit because of the associated on-going liability associated with Credit.

2) for prepaid client: think of someone that moves to a new city rents an apartment month to month and needs electricity. He gladly buys a $100 prepaid coupon. and will try to stretch that amount to last for his intended stay. If needed, or for longer stays, he repeats procedure.

With this customer there is no liability for electricity consumed after he left the premises, but forgot to inform the electricity retailer. There are no hidden account cancellation charges…..He pays $100 and buys some number of KWH or power and leaves (maybe selling any residual value to the next tenant).

He is happy, the retailer has no account setup costs, and no reason for further billing him, power automatically turns off when the credit is exhausted. Simple.

I actually know some people who select prepaid and prefer it because it acts as an in-built consumption limiter. Typically the meter will display residual power, so I know if I have 100KWHr of electricity left on the meter and 10 days to go before, I move or have enough money to again pay, than I know that 10KWHr per day is my maximum consumption rate. When I check the next day and see that I’ve used 20KWhrs than I get an idea about how to adjust my usage to make the available electricity last for the required period. Pensioners and those on fixed incomes fit into this class.

Werner • September 24, 2010 2:56 AM

@Nick P: don’t subtract anything. Just keep counting. Design the counter such that it cannot possibly have a valid reason to overrun.

The procedure would be as follows: old limit on card is X. We assume the limit has been transferred to the meter. (But it’s okay if it hasn’t.)

You go to the shop and pay for Y more units of whatever. Card gets set to X+Y.

You go back home and put the card in the meter. Its current limit is L, the running total T.

If X+Y is less than L, ignore the card. This can be an honest mistake, e.g., someone owning more than one card and inserting the wrong one.

If X+Y is greater than T+some safety threshold S, reject the card or accept only T+S and increment the “unusual transactions” counter. This protects against assigning some insanely large limit for whatever reason (manipulation, malfunction, whatever).

If we’ve made it this far, set L to X+Y.

If you lose the card, just buy a new one with the limit set to X+Y from the company’s records. This depends on the shop having online access to a database containing the customer’s record.

Regarding the hardware, I don’t know what exactly they put into these meters, but it’s probably simple. This also helps with hardening the system against tampering.

  • Werner

Clive Robinson • September 24, 2010 12:36 PM

@ Nick P,

“”

I’ve not yet sat down with pencil and paper to work through it.

However my first question prior to that is have you done a Cost / Benift Analysis?

If you assume that 99.9% of housholds are honest (ie 1 in a thousand are criminals, which is about the population density of criminals in the UK) then the loss you are looking to protect needs to be atleast balanced by the difference in price between a traditional meter and a smart meter in every home. The average home usage is around 130 GBP / quater or call it 500GBP a year.

This means if the utility companies are paying for the meter (as they currently do) then they are going to be looking at less than 50pence a meter price difference after manufacture to make it worth while doing (to every home).

The last time I looked “key meters” where tens of pounds more expensive thus they where only put in where theft had already happened or was deamed very likley to happen.

They then offset the price of this meter and the higher running costs on the tariff.

However there is ample evidence according to a number of consumer groups in the UK that the utility companies are “over egging the pudding” and have a payback period of six months or less. Thus the accusation levied against the utility companies of “blatant profitering”.

Having pulled quite a few of the first second and third generation electronic pay meters apart I can assure you that just on safety grounds alone I would not have one in any house.

That is in the UK we have the principle of “double insulation” that is there are atleast two insulating layers sufficient to withstand atleast twice (if not significantly more) times the voltage under the majority of use cases (like a cable dropping in a bath etc). None of the meters I looked at had double insulation the cases where made of brittle materials and they where most certainly not by any stretch of the imagination water or gas proof.

The electrical regulations have a very very (and compleatly inacurate) assumption that they will be mounted in a seperate lockable enclosure in ordinary usage. In mot cases they are put on a board (to stop you “flipping the meter”) under the stairs or in the “mop cupboard” where people natural stick things like step ladders, tool boxes, vacuum cleaners, buckets, mops, brooms and just about any other clutter you can imagine (and I’ve seen a few you such as “exploding bottles of home brew” and “hydraponic hemp gardens”).

So most of what you would consider likey to go through the meter case in one way or another is in reality right there just waiting to happen (and believe me it does with regular monotony and many people get hurt in a year).

So… there is evidence the utility companies will not even pay to make the meters “safe/fit for purpose”…

Hence my earlier comments about the utility company joy at legislation forcing the ever ripped off consumer having to pay for the new “smart meters” our political lords and masters are getting off on (as it does not cost them either).

Nick P • September 24, 2010 4:18 PM

@ Werner

@ Werner

Well, I do prefer the addition only version as well. It was the first of my two methods. I mentioned subtration in scheme two so we could use 32-bit values only. That might allow us to use extremely cheap hardware and verify the design easier. I considered this because I figured the utilities would probably only go for the cheapest hardware when selecting a smart meter design. I don’t know if doing 64-128bit additive design will require an expensive processor. Maybe a hardware guy can chime in on this? I guess we should proceed on the additive design since this is a thought experiment. 😉

I see you are also building in little safety checks. I have no issues with any, so I’ll integrate from there. My system design uses the card to carry commands rather than just values. We can probably do it a lot like IP and other protocols with a fixed number of bits at the beginning to represent the command, then a set to represent the length of the data/arguments, the data/arguments, and then the signature. No need for a checksum for the data tks to the signature. But the signature could be corrupted. Optional prevention might be having the signature’s integrity verified during the load process. This is probably unnecessary though, as a flaw would be good motivation to buy a new card.

So, we have Command = CommandName+Length+Data+Signature. A few commands that come to mind for your system are SetLimit, SetSafetyThreshold, and ActivateMaintenanceMode. The last command is optional and would allow field personnel to disable tamper sensors and activate necessary software with merely the swipe of a card. That’s just three commands and the commandname field could be as little as 2 bits long (four possible values). Very economical. If we are doing additive, then limit and threshhold are 64 bit values. Hence, the data for one command never exceeds 64 bits. Might get rid of the size field and just have 64 bits between CommandName and Signature on all commands.

The system should also probably have a way to include multiple commands, at least SetLimit and SetSafetyThreshold done together. To make parsing easier, we could put the number of commands present as the first thing on the card. Due to the small number, it too would be a tiny data type. So, we extend our card contents to NumberOfCommands + One or More of Command where number of Commands equals NumberOfCommands. (I know it sounds redundant but specification tools often require things like that to aid automated checks.)

Since I’m toying with a high assurance design, I will intentionally overdesign this and decompose the system into functions. Only one sideeffect is allowed per function. Pre- and post-conditions are used to catch errors. SPARK Ada would probably be used, but I’m doing pseudocode here. Some functions aren’t thoroughly defined here.

global variables (info flow analysis keeps this from being a problem)

define totalusage as 64-bit number and set to zero
define usagelimit as 64-bit number and set to zero
define safetythreashold as 64-bit number and set to zero
define carddata as binary array and set to empty
define cardreaderror as integer and set to zero
define powerstatus as boolean and set to false (off by default)
define varproperpowerstatus as boolean and set to false (off by default)
define maintenancemode as boolean and set to false

define function setpowerstatus(boolean newStatus) Turns power on or off depending on argument. Updates powerstatus variable.
define function properpowerstatus(totalUsage, Limit) Decides if power should be on or off. Returns boolean. That is sent to setpowerstatus.
define function readdatafromcard() Returns an error code or a binary array (or byte array or whatever) of the data on the card.
define function maintenancemode() Enters maintenance mode. May necessitate other variables and functions and have total write access to system.

pre(powerstatus== (true or false))
setpowerstatus(newStatus)
post(powerstatus == newStatus)

pre(varproperpowerstatus == false; usagelimit and totalconsumption are positive)
properpowerstatus(totalUsage, usagelimit)
post(varproperpowerstatus == true or false; usagelimit and total consumption are positive)

pre(carddata is empty; cardreaderror equals zero)
ReadDataFromCard
post( (carddata is not empty and cardreaderror equals zero) OR (cardreaderror > 0) )

pre(carddata is not empty; cardreaderror equals 0; usageLimit, totalUsage, and safetyThreshold are positive)
ProcessCardData()
post(carddata is empty; cardreaderror equals 0; increased(usageLimit) OR changed(safetyThreshold) OR maintenanceMode==true)

LOOP FOREVER

If maintenancemode==true, then maintenancemode();

set varproperpowerstatus to false;
properpowerstatus(totalUsage; usageLimit);
setpowerstatus(varproperpowerstatus);

set carddata to empty;
set cardreaderror to zero;

ReadDataFromCard();

If cardreaderror equals 0, then ProcessCardData() else ProcessCardErrors()

END LOOP

Easy as pie, oh my! I wonder if I should code it up or do the parser. I’m not sure how I would design a safety critical parser. I’m trying not to do any dynamic memory allocation in this system so it will be totally predictable and possible to use a separation kernel with time partitioning. I think this is the perfect system to use with something like Integrity-178B, DEOS or Xtraatum. It’s just so simple. So, where’s my mistake if any? (Other than left out documentation, which is intentional cuz I ain’t putting that much time in right now. 8)

Nick P • September 24, 2010 4:29 PM

@ Clive Robinson

Your cost arguments are good but you already had the counter in your own post: the companies are pushing smart meters for more control and profiteering. They also have special status that allows them to force consumers to do it their way and have no other options. So, the cost would be passed to the consumer for at least the first meter. Might be an activation charge or equipment renewal fee annually to cover for future maintenance. Cost won’t be an issue at the user side and cost at the utility’s end can (and will) be minimized.

When looking at the costs, I think there might be a small payoff to the system. Other than making meter fraud a bit harder, the system will automate the process of disconnecting and reconnecting homes. If a meter bypass prevents this, their traditional auditing methods will catch it. In other cases, the system will save the utility company a trip. This could provide cost benefits. The knowledge that the cutoff will be automatic and merciless might prevent some customers from being too behind on their payments. So, I see a few potential payoffs for the utility company, but imho smart meters are almost always bad for the consumer in some way.

Werner • September 24, 2010 4:47 PM

@Nick P: err, even the tiniest of CPUs can handle very very large integers. It just takes them slightly more time. Do you think computers had great difficulties counting above 255 in the days of, say, the Apple ][ ? 🙂

  • Werner

RobertT • September 24, 2010 11:07 PM

@NickP
Lot of interesting work, BUT you are fixing a problem that does not exist, at least not for future Meter systems.

All new meter systems being installed, (basically anywhere in the world today) have two way communications built in. So called Smart Grid Meters.

Once you can remotely control the meter, and remotely read the electricity usage there is very little reason for the Pre-paid Card activated meters.

You can keep this “downcounter” meter functionality if the user wants prepaid “look-alike” meter but the infrastructure is all smart grid.

As Clive has pointed out, users have the privilege of paying for these new meters (sometimes up to $400USD) to have a perfectly good meter replaced by a smart meter. In most cases the only possible beneficiary of the Smart Meter is the electricity retailer, so it is remarkable that the user pays model has been so universally adopted. (but that’s politics not engineering so I’m not at all qualified to comment)

Nick P • September 25, 2010 12:40 AM

@ Werner

It’s not as much my concern that the smaller processors couldn’t handle big numbers as much as how it would work when time partitioning on the RTOS only allows so much time to do the work. I guess it’s not really a big deal, esp. as I was preferring a 32-bit processor w/ MMU. Don’t know why I got hung up on it. (Sleep deprivation possibly…)

@ RobertT

If they do, then we can make an online protocol. You say “anywhere in the world” but our meters require physical termination and activation. It would seem the two way link doesn’t support this critical functionality. There might be smart meters available out here that have that function, but I admittedly don’t know much about their availability or features. I’ll have to look into it. I agree that a User Pays model for a product that only benefits the utility is very bad for us and shouldn’t have any user support.

Ok, if we can get two way meters, then the design will change. I still prefer Werner and I’s system components that use total vs max consumption. If this could pose a problem for any reason, the cutoff date approach and a strong time protocol could be used. Two-way communication actually simplifies the situation if we’re using digital signatures. Well, at the protocol design level. The implementation of course becomes more complex. Our offline system was a fun thought experiment regardless of its practicality. At least it had some value… 😉

Clive Robinson • September 25, 2010 4:02 PM

@ Werner,

“… err, even the tiniest of CPUs can handle very very large integers. It just takes them slightly more time. Do you think computers had great difficulties counting above 255 in the days of, say the Apple ][ ?”

The addition (which subtraction is anyway) should be atomic, due to openings caused by interupts and the like.

I actually was involved with an energy system on the Apple ][ back in the early 1980’s using the UCSD P system (I still have an Apple ][ and the disks etc in a cupboard).

And yes interupts where a problem as meter readings could get updated during an addition in the main program and you could get a hidden “roll under” effect where the interupt caused a middle byte in a reading above say 0xF0 to rollover to less than 0x0F during the addition.

As it is an effect that is normally never seen (ie in a 3byte addition on ~10min interupt interval) during testing and often does not occure reproducably in the field it’s put down to being just a “glitch” at best. So the protection code never gets even considered let alone added by the code cutters.

Fast forward 6years or so and I was investigating (in my own time) what are now called (in some places) “EM Active Envelop Fault Injection Attacks” on an “electronic purse” and I found I could change values in the purse by large amounts due to simmilar probs with 4byte wide adds on 8bit micros.

Now I would have been one of the first to put my hands up to saying I don’t rate it highly as an attack vector on electronic electricity meters due to the implementation cost vastly outweighing the potential loss (ie a smart student filching a bit of “lecie” in their digs) due to the limiting effect of the “total metering” at the substation.

But… I likewise would not have rated this attack in Scotland simply because I would not have seen the cost benifit for a “single person” and not think about how “criminal gangs” could profit by it (in the same way drug dealers do of giving a freebie to get you hooked).

This attack has changed the “game” thus the “defenders” need to consider attack vectors which might only be profitable if done on 100+ meters.

And yes “this old dog has learned a new trick”, by the way the gangs have employed “drug dealer” tactics in a new way.

Mark • September 25, 2010 9:57 PM

Who needs doorstep crooks to get free electricity?

At the height of the Y2K hysteria, our prepaid meter gave up charging us for the actual electricity (or even noting what we’d used) but continued charging us the day charge, reducing the charge to about a fifth of what it should have been. The lazy oiks at the electricity company didn’t actually notice for two years, at which point they replaced the meter but didn’t try to stiff us for the money, partly, I assume, as there was no record of what we’d actually used. As there were several people in the house topping up every now and again, we hadn’t even noticed for the first year.

Roll forward 4 years and in another property we switched suppliers, because the current supplier was really taking the Michael with the price. We knoew the new supplier was way cheaper, but were pleasantly surprised when they turned out to be less than half the price. Only they weren’t, as we found out a year later when the contacts on our key broke and it had to be replaced. They didn’t bother chasing it, or in fact mentioning it.

In May last year, our recently fitted meter again gave up recording what we used. We didn’t notice till July because we’d put a huge chunk of money on it as we were away a lot. When I did look, it had only gone down by about a days worth in 3 months. Gave it a couple of weeks, then called in mid August to get it fixed, expecting the suppliers to be only too keen to get it fixed so they could start charging again. Hardly; the first appointment they could drum up was mid November.

Makes you wonder if the ridiulous prices are to make the customers they do manage to charge cover for their endless failure to run their businesses even passably well.

RobertT • September 25, 2010 11:17 PM

@Clive
“Fast forward 6years or so and I was investigating (in my own time) what are now called (in some places) “EM Active Envelop Fault Injection Attacks” on an “electronic purse” and I found I could change values in the purse by large amounts due to simmilar probs with 4byte wide adds on 8bit micros”

Interrupts are an interesting problem with any high security micro. Typically with a realtime system you assign the highest priority interrupts to the time critical tasks (like measurement) and figure the Crypto can be done at the lowest priority. Unfortunately this concept opens the micro to a whole class of attacks where the timer interrupt is flooded. I’ve also seen several EM attacks that injected into the Xtal cct. Surprisingly I don’t think I’ve ever seen this class of attacks talked about before. (I don’t think Ross has ever mentioned these attacks).

In some Micros you can cause a stack overflow which results in the return address overwriting the stored data.

Another class of interrupt attack is to detect the jitter in the start of a certain lower priority interrupts, this attack assumes that during critical adds / multiplies the lower priority interrupts (or os tasks) are masked. as a result the micro reveals the length of each multiply…opps (I love these side channel attacks, because most people are clueless as to how you hacked it. worse than this they still don’t get it when you explain the attack)

.

Clive Robinson • September 26, 2010 1:26 AM

@ RobertT,

“I don’t think Ross has ever mentioned these attacks”

If by “Ross” you mean Prof Ross J Anderson over at Camb Labs I had mentioned in an email to him about using EM attacks against systems when he was looking at “self clocking” systems as a way to get around Differential Power Analysis.

I’m assuming that as he did not appear to persue self clocking systems after that, that he realised what the potential for EM attacks was. He also made oblique refrence to it in his book when talking about computer keyboard leads and their susceptibility.

To be honest the only academic paper I have seen relating to EM attacks was the recent one on what a plain CW signal did to a random number generator (went from 32bit equivalent to sub 8bit equivalent) by a couple of researchers at Camb Labs and pressented at an IEE conferance (it’s up on the lightthebluetouchpaper.org site)

It’s actually quite odd because I’ve not exactly been quiet on the subject these past thirty years, I guess people just assumed passive EMC would make it a non issue. However active EMC where you use spread spectrum techniques “to beat the mask” has actually made active EM attacks a whole lot easier as the SS clock is usually directly derived fron the same master clock that drives the CPU thus providing a loverly synchronisation system for free…

I’m waiting to see if the bods in Camb Labs will actually combine a couple of the attack vectors such as monitoring the SS signal from the master clock to determin clock drift and pump high load network traffic (say SSL etc) to change it.

It would be a practical way to identify which SS signal you want coming from a room full of computers such as a server farm, and thus corelate an EM attack with a network attack etc…

I realy feel we will see real EM attacks in the wild in the not to distant future and I know @ Nick P has had some thoughts on the issue to chat to his clients about.

Nick P • September 26, 2010 11:11 PM

@ RobertT

“I love these side channel attacks, because most people are clueless as to how you hacked it. worse than this they still don’t get it when you explain the attack.”

I wish I could say I wasn’t “most people” in this case but…. grr… You said you’ve seen an attack like this in the real world. Could you give even a filtered explanation of what occurred and how you determined the method they were using? (Doesn’t seem like something anyone would monitor or easily monitor.) I would also be very grateful if you explained in semi-lay terms exactly how this attack is accomplished, detected and prevented. As I’ve said before, I’m mainly a systems guy with very little direct hardware experience. I’m slowly picking these things up and I figure if enough people explain it my understanding of it will be pretty good. Thanks for any help on this ahead of time.

@ Clive Robinson

I wonder how much of the TEMPEST Level 1 standard and Type 1 cryptographic devices protect from active attacks. I know the old STU-3 was vulnerable to active EM attacks because you couldn’t use cell phones near them. I wonder if the new ones have those capabilities or if you have to have everything in a Faraday cage.

“I realy feel we will see real EM attacks in the wild in the not to distant future and I know @ Nick P has had some thoughts on the issue to chat to his clients about.”

Yeah, I told them to switch back to paper, vaults, guards and monitoring galore if they are concerned about that on general purpose or COTS systems. Let’s face it, Clive: there’s no cost-effective solution and the risk is currently too low to justify to even the most paranoid management types. Maybe RobertT’s description of the real-world incident will be helpful for those articulating the real-world dangers. As it stands, we can barely get passive EM resistance in businesses and government is doing less than ever. Have you noticed how they relaxed their EMSEC requirements over the years? Did you notice how that paid off? (lulz)

Btw, why do you often say “@ Nick P” rather than “Nick P”?

RobertT • September 27, 2010 1:07 AM

@Clive
I agree, at first glance SS clocking looks like a great fix for Differential Power Analysis (DPA) but when implemented it actually makes DPA easier, because it gives you a clock edge plus long term SS sequence to lock too. Most of the first generation anti DPA systems used a short LSFR to generate a jittered clock that varied the instruction start execution time (relative to the system clk). So externally the instruction timing looks just like SS clocking.

Self timed logic is also VERY sensitive to thermal and voltage conditions. So intentionally modulating the temp and voltage and creating, what test experts call a “schmoo plot”. and comparing the power spectrum at different Schmoo corners reveals a lot about the nature of the calculations. Using thermal gradients across the chip is also very useful when combined with DPA on self timed logic.

From my experience “self timed” logic is the worst choice for anti DPA, however it does help prevent “glitch” attacks.

Some are new products are generating the instruction clock using multi input LSFR’s and dithering the LSFR with the output of a hardware RNG. I’ve looked at one of these secure micros on the bench and found it very difficult to get any information from the power spectrum. (I believe they also have a shunt regulator internally, so this really helps smooth out the IDDQ variations.)

Clive Robinson • September 27, 2010 10:12 AM

@ Nick P,

‘Btw, why do you often say “@ Nick P” rather than”Nick P”‘

Well, put simply the at (@) symbol catches the eye of those doing a mark 1 eyeball search down the hundred recent posts list.

It also helps for those with names that also get caught in common automated word searches (of which nick is one).

It’s also become a habit and we know how hard those are to break 😉

Clive Robinson • September 27, 2010 10:34 AM

@ RobertT,

“Some are new products are generating the instruction clock using multi input LSFR’s and dithering the LSFR with the output of a hardware RNG. I’ve looked at one of these secure micros on the bench and found it very difficult to get any information from the power spectrum.”

Yes I expect for most “bench instrumentation” that would be the case as the “chip rate” is constantly changing (the same trick has been tried with very high chip rate DSSS systems). However the catch then becomes any regular time frame. This is the weakness of any digital modulation SS system as you can use the data frame as the null point to center your tracking demodulator.

However with a micro controler with a little care you can make any such “required” clock edge asynchronous to the main CPU functioning (a simple random length pad or fill at the end of an interupt that generates the edge will do that).

As for,

“I believe they also have a shunt regulator internally, …”

Provided it’s in the chip and they don’t make the usuall “current path” mistakes you see in digital only chips then yes it will go a long way. However designing a micro along similar lines to a 24bit A-D chip is going to have quite a few implications.

I was once shown the design of a “serial CPU” that actually had multiple small chips optocoupled together in the package and to say I was “gob-smacked” would be an understatment. And before you ask no I do not know if it ever went into production, the fact it was contemplated to get over a percieved potential side channel problem spoke volumes about what some people then knew about side channels.

Nick P • September 27, 2010 2:25 PM

@ Clive Robinson

I’m wondering if there is even a way to make a processor useful for running modern apps that is immune to passive and active EM attacks. I think this is going to require so many usability, performance and cost tradeoffs that it might be better to focus our actions on TEMPEST enclosures and ways to prevent EM links that external interfaces (ethernet, power linet, etc.). This is what most TEMPEST systems do and seems to be the easiest method.

Actually, the easiest method is throwing a bunch of critical systems in an EMSEC cabinet or room w/ filters on cords leaving it. I’ve only seen two books or guides on EMSEC. Most of the good info is classified. The best help hardware security experts could give us system guys is good info on building TEMPEST enclosures and filters. We need some open hardware designs and books on the subject. Maybe we can get the cost down on a bunch of components and get more of them in COTS systems. That’s the only solution I see working interim. (Then there’s the issue of processor bugs and hardware not behaving according to spec. Got to fix that too.)

Clive Robinson • September 27, 2010 6:43 PM

Nick P,

“Actually, the easiest method is throwing a bunch of critical systems in an EMSEC cabinet or room w/ filters on cords leaving it.”

For some applications you could put the chip in it’s own EmSec case only fractionaly larger than a 14pin DIL package.

Think about a smart card chip slapped between two (appropriate) metal plates with surface mount filters between the external pins and chip bond out pads.

Provided the function is such that the data rate on any pin is low then likewise radiation will be low. For high speed data you could encrypt the data and use an appropriate crypto mode to ensure “traffic flow” cannot be performed.

With regards,

“I’ve only seen two book or guides on EMSEC.”

Yes they are a bit thin on the ground. However a lot of the basic stuff is realy common sense and most RF or analogue design engineers can work it out with just a simple pointer or two. And if you know where to look the hints and the theory they relate to are easily found.

A place to start for most is a good book on EMC, Hewlet Packard used to have some very good ApNotes and they are still up on the web in several places.

It’s when you get past the basics the fun starts but again it’s not (quite) rocket science and can be worked out.

The big thing to recognise is “encapsulation and segregation” of function as a design philosophy and to recognise and control the “channels” by which susceptability or emission occur.

Also recognising the sometimes arcane and complex methods by which information leaks as energy escapes any which way it can.

Sadly the area of theory that is a bit sparse is “near field” and that is where the bulk of the EmSec physics happens.

I do however suspect that the academic work in this area will improve greatly over the next couple of years, simply because the other low hanging fruit are starting to be “mined out”.

RobertT • September 28, 2010 12:21 AM

@Nick P
“I wish I could say I wasn’t “most people” in this case but…. grr… You said you’ve seen an attack like this in the real world. Could you give even a filtered explanation of what occurred and how you determined the method they were using? ….”

It wasn’t THEY but rather it was me implementing the attack on a design that a team had been working on, I always like to try out new hardware hacks on my own projects, usually without telling the design team in advance about the intended attack vector. The point is that they need to be independently thinking about information leakage vectors, because if I can dream up an attack than so can lots of other people….

Detecting and prevent attacks:
Detecting is remote EMsec attacks is relatively simple, you need several antenna {hertzian-dipoles} tuned to different frequency ranges. Since all remote Emsec attacks require high intensity RF fields you can detect them with a simple peak detect circuit connected directly to the antenna. Basically you are crudely measure EM field strength over a broad frequency band.

Another common input vector is through the power supply, protecting against this vector is a little more difficult but it requires a LOT of EM power or direct effect to the power supply regulation. So this is a Near field only attack.

My favorite attack is to locally inject power supply interference is by overdriving CMOS output signals. This attack is nice because it can utilize existing fault protection hardware against as a fault injection vector. (for example an enclosure lid switch would typically be directly connected to a CMOS I/O, if I can access this wire than I can reverse drive it to inject substrate current) This method means that the PCB level power supply decoupling caps are now isolated by the bond wire / pads of the chip. This overdrive current forward biases the output ESD protection structures and causes them to locally inject minority carriers into the chip substrate. (sorry no easy way to explain this, but it is related to the physics of a CMOS fault called Latch-up) minority carrier recombination can be used to de-bias internal analog circuits, particularly internal LDO’s (low drop-out regulators) and bandgap references. If the bandgap circuit is susceptible to minority carrier injection, than you can directly modulate the chip internal supply voltage, which is extremely useful for timing and so called “glitch” attacks.

Checking for active EMsec susepibility:

In general, Active EMsec attacks, affect high impedance input nodes of a product. So to check if a particular product is likely to be sensitive to Active Emsec I’ll intentionally add, to suspect nodes, a burst of sine waves, from a highish impedance oscillator source (say 1k to10k ohms). If this results in an observable change in power or functionality than I conclude that an EMsec attack, on this node, COULD compromise the product. So I need to take extra shielding / filtering care with this node. Implementing a real active EMsec attack is not always possible because of the physical constraints of a real product, basically for active Emsec attacks to work the injection node must behave like an efficient antenna at the carrier frequency being used. So where I mentioned Active Emsec sensitivity, I usually take the shortcut of deliberately injecting a burst sine wave on a bench setup. I do this with my own products, and the products of competitors.

Sensitivity of 32 khz crystals:
Usually the xtal oscillator is one of the easiest ccts to inject into. Most crystal oscillators are VERY high impedance common mode circuits, so injecting a disturbance signal into this node is very easy. In many microcontrollers the 32Khz osc is divided down to create a 1msec timer interrupt. If you inject a burst signal at 320khz into this node, the interrupt will occur at 0.1msec intervals. Now since the rest of the tasks are typically scheduled from the timer interrupt, everything will try to run 10 times faster. Unfortunately the actual CPU clock has not been increased, so the round robin tasker will get into a real mess. In some designs, the tasks will rescheduled before they even complete, this results in a return stack overflow. By controlling the timing and length of the injected burst, relative to the program execution, I can intentionally interfere with the execution and the results of crypto tasks, such as mutual authentication. Usually the fault vector is through overwrite of the data stack, however when the return stack is messed up, calls to one task can result in returns to another.

It is also possible to combine burst interference with DPA. Usually this method will try to incrementally speed-up the microcontroller task execution until asynchronous tasks interfere. To do this I would normally do an FFT on a suitable length of power analysis. What you see is the timing sequence for all the software tasks, such as read keyboard every 20 msec, measure temp every 50msec …. these tasks will all speed up, by the incremental change in the effective Xtal frequency( actual freq + injected error). You will also see some tasks that stay at the same repetition frequency. The tasks that change frequency are scheduled as a result of the timer interrupt, and those that stay the same have other real time sources. Since these other tasks are probably interrupt driven themselves, you can use these tasks to interfere with the desired crypto task. (in effect you increase the timer task execution rate until the independent task is exactly harmonically related to the timer task. You can than slowly walk the two sequences across one another and lock when the crypto task occurs. This technique is very powerful, especially if the crypto task disables interrupts during critical adds / multiplies. By doing this you can identify the exact interval over which interrupts are disabled. (on the DPA FFT it shows up as side bands on the independent task spur), the frequency shift of the side band directly gives you the interrupt disable length. If the code is done correctly, BIG IF, than there is NO information in this task jitter, however it is very difficult to make all code execution paths have identical path lengths and execution time, so observing the disable interrupts interval, directly leaks information about the nature of the crypto task multiplies. From here on the attack becomes a standard timing analysis attack…

Unfortunately there is no simple way to combine “real world” real time functionality with the secure computer desire for no information leakage.

Simon C • September 28, 2010 10:41 AM

On my meter the topup is a plastic stick with the contacts protected by a little scabbard.
In order to top up you have to take it to a local shop with the apropriate top up machine and after paying the fee you are given a receipt.
My last one now details this scam and says that the power company knows when you steal electricity.
Also replacement keys are charged at varying prices from £30-£150 based on the cost of couriering the new key to you. Presumeably to discourage you from having serveral.

Nick P • September 29, 2010 8:00 PM

@ RobertT

I appreciate your reply. I’m adding it to my archives on the topic, to be fully comprehended at a later date. There’s quite a few of Clive’s posts in there, as you may have guessed.

RobertT • October 2, 2010 3:00 AM

@NickP
Nick I just reread what I had posted and realized that it is VERY bad advice to try to implement some of these fixes without understanding the back-doors that the fixes open.
For instance: detecting high strength E fields is easy using dipole antenna’s, HOWEVER the very existence to this detector opens the system to a class of overdrive attack. So to properly do this the Dipole inputs need to be protected by external diodes which limit the maxim peak to peak swing to +-0.7V.

IMHO the only real hardware security is to truly believe that you are at least one step ahead of all likely attackers. This knowledge (or lack thereof) lets you sleep well each night.

What’s sad is that your security chip business can prosper, if you can honestly tell the customer how bullet proof the system is. It really does not matter if this is a statement of your own ignorance, or truly reflects the advanced level of your hardware security.
Note this is especially true when you start discussing attacks at a semiconductor / substrate level.

Clive Robinson • October 2, 2010 11:19 PM

@ Nick P,

To chase up on papers to do with some of what RobertT has mentioned have a look at this publications page for a “Reader” at Queens Uni Belfast,

http://www.ecit.qub.ac.uk/Aboutus/BusinessCard/index.html?name=m.oneill&AllPapers=true

The lady has some chip level knowledge of side channels and has researched into various aspects of them.

@ RobertT,

What brought her to mind was an odd item on Dark Reading about a TRNG which is an almost direct copy from the Uni reasearch center news page about a new Ubiquitous TRNG,

http://www.ecit.qub.ac.uk/News/

The blurb says,

“Optimised for circuits, FPGA and ASIC, they push efficiency to the limit by using just one logic gate, one look-up table and four transistors respectively.”

Which as a description just sounds odd… Almost like a student describing their first project.

However the more interesting bit was,

“The next step is to find ways of making the generators sufficiently robust to be embedded in devices such as mobile phones, smartcards and RFID tags, and – where they are used for security applications – to secure them from attack and develop appropriate countermeasures.”

The trouble as always with these things is there appears no further info up on the web.

en4rab • October 3, 2010 6:21 PM

Whilst i understand that security is important, in this instance is it the end of the world? Even if a customer fiddles the electric there should still eventually be a day of reckoning where the reading on the electronic meter will be reconciled against the suppliers records of payment made through the meter key topup system, from there on its a matter of threats of court action and adding the discrepancy as a debt to the meter so the user has to pay the outstanding money back over the next X months etc

This is a similar situation i guess to a “canteen cashcard” system I have seen where a “value loader” is used to put money on a card for use in payment from the canteen/vending machines, the one I am familiar with uses a mifare classic RFID card and it took all of 5 mins to dump it using a £35 reader from touchatag, Im fairly sure you could then edit the card to contain an arbitrary value up to £655.35 (it stores the value as 16bit integer number of pennys) there is a record of the last 3 transactions on the card, and i would hope there is a record of money added on a back-end server to allow a tally up of money added vs money spent to catch fraud, but im not sure if this is the case and im not going to try to find out.
Interestingly the supplier of this kit has options for Mifare classic/Legic/iClass i haven’t looked but i assume the legic and iClass cards are the least secure most rubbish of their respective family’s since the seem to think mifare classic is secure.

RobertT • October 3, 2010 11:09 PM

@Clive,
Interesting find, I was not aware of this work.

On reading the TRNG details (as limited as they are) I’m very skeptical about the ability of the circuit to generate real random results in the presence of modulated Substrate currents and extreme power supply noise.

The problem is always with the Random Noise sampling point. Even very experienced Analog and RF CMOS designers have lots of problems achieving good PSRR (over 70dB) with purpose built custom circuits and lots of balanced symmetric layout tricks. It is somewhat difficult to believe that one FPGA gate + 4 Fets and a small look-up table will somehow out preform full custom mixer circuits (which is essentially what the RGN sampler does)

At the moment they are apparently keeping their circuit secret. If they send me a schematic and or layout I’ll gladly review it. However, my guess is they would rather continue to exist (and publish) in blissful ignorance, it is easier to make incredible claims when you know no better.

I’ll see if I can find out any details of the PUF cells, they also claim to be working on. I have a feeling that their TRNG might be based on an auto-offset correcting PUF cell plus a non-linear dither table. This creates a self oscillating continuous time 1st order sigma delta modulator, which in effect folds thermal noise into frequency domain jitter.

Steve Simon • October 20, 2010 6:43 PM

The traditional method of doing this in the UK was to make a play-do mould of the coin the meter takes (used to be 50p). Fill the mould with water and freeze it. Then use the ice 50p pieces in the meter.

All works well until the meter is read and the reading does not match the cash in the coinbox.

Ahh – them where the days.

karenwhe • November 16, 2010 2:00 PM

Unfortunately this (scams) are also happening in South Africa which is the home of STS technology and prepayment is very widely employed.

Furthermore, municipal meters are stolen then sold as sub-meters at exorbitant prices by people who claim to be municipal employees (some actually are).

By the time the consumer finds out that the meter is useless and it has to be returned to the municipality, it is too late.

Unfortunately consumer knowledge is also very low in regards with utilities and hence scams are wide spread.

Very sad.

Alex • December 16, 2010 12:53 PM

can somebody help me whit mifare algorithm? krack hack i dont know the word, or build or idont know sell it to me somehow? thak you werry much alex contact me at sebbank@mail.ru

wze3369 • December 23, 2010 11:47 AM

actually its not a hacked or cracked card. its a stolen engineers key. they issue them to engineers so when they install a new pre pay meter they can check it works an give ya £20 or whatever credit plus £5 emergency. costs tenner a click in suffolk as far as i know. and if you intersperse it with 5 legit top upsan 1 cheapie it doesn’t come on top. or hasn’t yet(as far as i know). @18 months plus of usage. good job anyway,rip off merchant energy companys. i’d clone an give every pre payer a free £20 key if i could cause its only poor people in general need pre pay an pay extra for it!

Lafayett • January 11, 2011 11:24 AM

I was wondering how long it would take for these prepay meters to be hacked. I do know the electric people recently replaced the key as they claimed the old one was broken. Maybe they’ve gone public now as they have a defense. Either way, wouldn’t it be simpler to attach a switch to bypass the meter, it’s virtually impossible to detect ‘stolen’ electricity as there are so much losses in the system. I also recall the old method where you plugged in a capacitor that caused the meter to go backwards ..

dotty • December 13, 2011 5:47 PM

what if you are accused of fraud and didnt do it? i am getting letters that i bought electricity from a door step seller.

i had requested teh meter be changed over three times and each tiem there was a reason it was not changed.

what would make them think i didi this
i have a debt collector calling me and im not sure what to do- i already told them i suspected the memter was broken as i often would top up te key and no electricity would appear?
how do they keep track bc no on has come to read the meter since i switchde to edf and now ive moved from that property
they are sending me electricity billsnd

mutznutz • May 1, 2012 10:24 AM

i had 27 gray master keys for putting lecky on 15pound ones that clears debt as well 25pound ones 20pound and 1pound red keys and green keys and some little box Called a FLAG KEY it says push button to activate key property of northern electric

mutznutz • May 1, 2012 10:28 AM

you can not get caught if you top up as normal they will get its just when you get credit on you doent top up as normal

Mark • January 31, 2024 9:56 AM

Buy how do we hack the electric pre pay plastic keys please…I’m sat here with no electric 😭

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.