Schneier on Security

RobertT • December 26, 2010 9:06 PM

I’ve noticed that nobody has mentioned “powerline” modems as a data back haul option.

In the last few years this technology has really taken off and there are a lot of possibilities. Basically your options are Narrowband (40khz to 480khz) or broadband(2Mhz – 30Mhz)

The broadband can support very high data rates (over 100Mbps) but it is easy to detect due to RFI and has limited range.

The Narrowband systems can have a range of up to 1000m at data rates of up to 2Mbps. Narrowband systems are VERY difficult to detect from RFI you actually need to do a spectrum analysis of the AC line. Since the modern Narrowband systems use OFDM (about 100 carriers) with data typically 8DPSK (sometimes 16 QAM) it is VERY VERY difficult to detect the existence of a narrowband Powerline modem. It all just looks like a noisy AC signal (which is not unusual), most techs seeing this AC-line noise would suspect a failed Filter cap in a switched mode power supply, rather than intentional communications. Some narrowband systems have a feature to automatically configure as a Multi hop modem. This lets you make the TX power at the origin very low. With narrowband systems it is also possible to retrofit the MV=>LV AC transformer with a coupler so that you can monitor the MV from a respectable distance (important in US due to 110VAC)

RobertT • December 27, 2010 8:25 PM

@Clive,
for frequencies below 500Khz power factor correction caps are a big problem, but not an impossible problem. You need to change the modulation and use OFDM. the presence of a PFC cap will make DSSS impossible to equalize, so you get killed by ISI.

Regarding Modulation:
BSK modulation is completely ruined by PFC caps, but Differential PSK modulations work OK (try Bluetooth 2 phy/4 DPSK). OFDM will also keep some of the channel’s unmodulated so that noise and Eq can be measured (approximated) for that region.

Detecting this signal is VERY difficult, especially at the lower frequencies because the AC mains make a very inefficient Antenna at 100Khz (especially in US) The systems that I have seen all use carriers at about 10dB below the system noise floor, so the modulation only shows up as an increase in the noise floor over a certain frequency range. Because it is AC-Mains you cannot turn it off and get a measure of the line noise with and without modulation. so all you see is slightly higher than expected noise bump. these days if you are trying to hide, than hiding behind the noise of typical computer switched mode power supplies is much better than using the AM stations. Even when a tech finds a signal, in a typical office there are 100 other local signal sources that all look similar.

RobertT • January 2, 2011 9:25 PM

NickP
I like what you are trying to do, because I’m a big believer in “formal verification” especially at the product definition and development level. I’m also a big fan of “compliance matrix testing” at the product level. Unfortunately focusing on the technical side of the security process ignores the weakest link, which is the people involved in the process.

Within chip development teams there is an unending supply of cerebral narcissists, the higher you climb, the more prevalent they become, it is almost a predilection for the job. Now what balances the team is the Inverted Narcissist, especially when the co-dependent is really the smarter of the two. The real trick is to construct a project where the Inverted Narcissist actually controls sign-off but the Classic Narcissist gets the glory. The reason this is important, is it puts the Classic into the role of the co-dependent so that the classic Narcissist supports the Inverted. Unlike the Classic the Inverted achieves glory in perfection, only that which can stand the review of the Classic is in any way “good enough”

That’s enough Psych101, but I would respectively suggest that as you strive for real EAL7 performance you will need to delve deeper into the Psyche of your developers.

RobertT • January 2, 2011 11:36 PM

@NickP
At the moment my interest is on Mobile computing viruses and ways to inject these viruses into chip definition databases.

For mobile devices, the holy grail, would be to compromise the ARM9 and ARM7 databases. Imagine a worm say like Stuxnet that could identify the ARM source database and modify this at a ‘C-code’ or Verilog level to insert an operation that intentionally leaks information relevant to typical crypto operations. You get side channels built in to ALL derivative products (basically EVERY smart phone) and supported at a level that most apps developers and code-cutters would consider impossible.

All manner of “zero day” attacks would be created, and new ones could be developed whenever an old hardware leak was fixed.

In theory this could all be done without the original developer even realizing that their processor definition database was corrupted!

From my experience most chip databases are only protected by typical Unix group permissions, I’ve never seen private key signing, implemented to control the incorporation of new features. Even tracking for source database modifications is rudimentary.

It’s a work in progress….

RobertT • January 4, 2011 10:35 PM

@Nick P

Too many points to address immediately let me try to get us moving in the right direction.

Fabs for Mobile chip sets:
Most new devices today are being targeted at 40nm processes
There are only 6 fabs in the world capable of producing volume designs at 40nm, these are
1) TSMC (Taiwan)
2) Global Foundries (Abu dhabi) (old Chartered semi and AMD fabs)
3) maybe UMC (not sure when 40nm available) (Taiwan)
4) Samsung (not really a foundry) (S. Korea)
5) Intel (zero presence in mobile device market)
6) IBM (no mobile presence)

The physical security of the mobile device fab production needs to happen in Taiwan (TSMC/UMC), Singapore (old Chartered Semi) and South Korea (Samsung).

As far as I know, neither Intel nor IBM is fabing any mobile devices, neither are the old AMD fabs in Dresden Germany (now Global) nor the old IBM / Freescale fabs in US.

Interfering with a database after delivery to the fab:
This is possible but highly unlikely because the fab deliverable is typically at a physical layout level (called GDS2 or Mebes data). With an automatically placed “sea of gates” layout/ routing , it is difficult (not impossible) to translate this back into a simulation / human understandable form. However, identifying features like “hard macros” such as a hand layed-out Wallace tree multiplier is fairly easy. Adding several traces to say, copy the Carry out flag or certain bits of the multiplier is possible. (Big problem is that the extra signals could reduce the execution speed of the block, which would cause someone to look at the chip layout (40nm is way below what we can see with visible light so an optical microscope is useless, to actually know exactly what is on the chip requires inspection layer-by layer with a SEM / FIB microscope) = EXPENSIVE!

Often these days the Fab will supply certain hard macros, such as a PLL which the chip vendor uses sight unseen. Having an undocumented register within the fab supplied PLL block and then routing multiply signals to the undocumented registers, is in theory possible.

What I’m trying to demonstrate is that it is probably beyond the capabilities of anyone but a state actor to modify a design at the fab level. The other factor limiting this is that the client expects the chips back in under 2 months. not much time to make modifications.

Modifying the Chip database:

For cost reasons Mobile chips are Systems on a Chip (SOC) designs, they contain over 10M transistors and can often have 4 or more main processor cores and as many as 8 state machines (these are often actually small 8 bit microcontrollers). I can guarantee you that the person working on the AES hardware function does not know what happens at the mobile protocol stack level, although both functions are on the one chip. Similarly the Protocol Stack person would never have reason to look into the inner workings of the power management microcontroller. So at the chip top “block assembly” level it would be easy to add undocumented registers that allow these blocks to communicate, thereby creating backdoors. The best location for the backdoors is probably within the least technically difficult blocks, such as within the power management microcontroller or HID interface micro. Both of these are also ideal locations for introducing unexpected side channel communications paths.

As an external person modifying a top level chip data base it would be possible to add undocumented registers by connecting up unused gates. Normally a new chip design adds extra gates into unused spaces between blocks so that minor errors can be easily patched. Nobody is “in charge” of the extra gates and having some used, even at the beginning, is not unusual (typically extra resister gets added to help with timing errors or control signals get inverted / delayed to synch blocks that kind of thing) so it would not be unusual to see these gates used and nobody would wonder what that function does….(basically it s just some added “glue logic”).

More tomorrow:

RobertT • January 5, 2011 4:21 AM

@Clive,
“With all the security features disabled what would it take to ‘make them suspect’?”

The checks only exist to catch some young engineer accessing things that they are not authorized to access. To be honest that’s it! This step is only done to limit the scope of a data breach from an inside job.

“With regards the foundry / fab facility what is the actual procedure to ensure that the customer sent package is actually the package they sent?”

Usually transfer is simply through an ftp drop. So the Fab sets up an ftp location which is password protected and the design company transfers the design to the specified location. As a result there is probably nothing stopping a MITM attack on the transfer of the database. In reality this MITM or database substitution would need to happen quickly because there are always plenty of telephone calls coordinating an important database transfer.

If you managed to make this substitution AND your modifications did not cause any execution errors, than they would most likely never be found, or even suspected!

There is one final check where the fab sends the design company the actual Mask making data, but this is almost never looked at, (and few people actually understand the extra data in this file). About the only time anyone ever accesses this mask data is if some functional error is suspected to be caused by whats called Optical Proximity Correction structures, or “Fill” metal. These are added by the Fab / Mask house and so are not in the design/layout database.

“And how much does it cost to go from the data held in the design database to the “physical layout”?”

In reality you would need to modify the already completed layout database because otherwise you would never get an exact match to the original automated layout. The most likely way to do this would be with a manual layout at the chip top level. So someone would add the extra routes to hook up the spare gates after everything else was done. The cost to make these changes is minimal say 2hrs work for a skilled layout person, but you better not make a mistake. The mask set themselves costs several $M for 40nm, but if you substituted the database than you wouldn’t need to pay this.