-
my gut tells me that there has to be a simple low-cost mouse trap that we can build here that can stand up to even a very smart and very determined mouse, but maybe there isn't?
This is my field of expertise. There isn't [a low cost solution]. You need an HSM. You can build it yourself but it's almost certainly cheaper [TCO] to buy. No product is perfect but the commercial solutions readily available today can protect pretty much any secret short of nuclear launch codes (or DNC emails lol). Your app also has to be designed to actually require use of the HSM in a way that other parts of the system aren't the weak links. That's quite hard.
I don't mean to be insulting, but you have no idea what you're doing and in the security field that's an absolute recipe for disaster. Correction: you have "a little knowledge". IOW a dangerous thing. You should hire and/or consult some top level experts if you expect to protect against state actors. -
There are ways of preventing physical access, but you need to be a lot more clever than the ideas in this thread. Knowing your threat model and cost target will point towards the type of solution you must use: there is no such thing as a cost-no-object in the security field.
One hint is that potting is too late; by the time your adversary has the circuit board on their bench you have already lost. Surprise is invaluable.
yes there are ways of preventing physical acces if your opponent is a normal copetitor, being against NSA and friends is a whole lot more complicated, take a look at STUXNET, they were able to infect a security critical air gapped pc that in turn used one of the world's first PLC 0day to destroy uranium centrifuges, apple started encrypring test messages first and the whole memory of a phone later to specifically prevent the US governament to ask them to hand over data from the user's phone (icloud is different), but even apple with a pratically unlimited R&D budget, and lots of clever engineers they could not prevent the san bernardino phone from being unlocked
the problem is that (provided the device in question is valuable enough) they have a truly limitless amount of money and time, to find a weak spot, anything can be circumvented given enough time and skill, active meshes can be bypassed, you basically attach jumper wires before breaking the existing one, light sensors can be easily identified and neutralized with black paint, case switches can be glued closed before opening the case, battery backed sram looses data only if power is cut so they could easily solder an external battery before they get full acess to the device, dram can be freezed and the data extracted and so on; are all those things easy to do? of course not, will they be able to enter if they don't have multiple devices so that they can reverse engineer the anti tamper system before tampering maybe yes, maybe not who knows; but more importantly assuming they have access to multiple devices (and if you sell the thing you'd be a fool to think otherwise) they will get in, it's just a matter of time
whis is the same thing as asking how to make a system un-reverse engineerable, it simply can't be done, you can make the life of the attackers hard so it's cheaper to design the product than to copy it and that's all -
Mr CM300's Pandora's box:
Mercury delay lines weigh hundreds of pounds, and HF is a weak acid.
How do you effect cooling inside your vacuum sealed box?
You got a point there with the mercury delay lines, though HF Acid would be perfect if you wanted to damage the glass optics & silicon.
Oi! no need to palm at me, you simply use jets of cooled gas. I didn't specify perfect vacuum.
I have a more commercially viable State-proof idea, however I don't think I'll be publishing that
-
Mr CM300's Pandora's box:
Upon a vibration proof optics table, set up a vacuum chamber. Within the vacuum chamber should be a magnetically levitated cube with a solar panel for powering it from high intensity LED lights mounted within the chamber.
The cube has a mechanical assembly affixed to it with a high speed, highly sensitive gyroscope / accelerometer that detects the slightest movements of it, triggering data corruption.
The cube holds the cryptographic processor which is a custom ASIC containing, amongst other methods of protection, optical logic gates, MEMS logic gates and possibly some chemical / electrochemical methods of data handling.
Several key parts of the data should rely on external optical delay lines and internal mercury delay lines.
Naturally have the security cube reconfigure the positions of some of the protections using randomized numbers generated from a radio-isotope or heat noise random number generator.
Data to be encrypted / decrypted is transferred to and from the cube with differential light beams using interferometry to ensure the beams are not being extended for listening.
You could also have security lasers exiting the box to go around secure areas of the building, if the beams are broken then it wipes the keys and destructs itself through the release of HF acid onto it's circuit (or just a high voltage spike / overheating)
A thermal sensor would watch it's own temperature to ensure that it isn't being supercooled.
Possibly add computer vision to the security cube (IR, Visual light, X-Ray & Gamma to prevent X-Ray / Gamma visualization of internals)
...... I'll eat my sock if anyone can see a way to get past that. (And record myself doing so.)
You have violated one of the stated requirements - that physical access is not prevented. But in general you have put your finger on the problem. You have made the system extremely expensive, and extremely difficult to use, and have not eliminated all possible attacks. I will leave it to your cleverness to uncover the weaknesses that I (not an expert in the field) would use to start an exploit. I will grant that you have made it very difficult. -
Mr CM300's Pandora's box:
Upon a vibration proof optics table, set up a vacuum chamber. Within the vacuum chamber should be a magnetically levitated cube with a solar panel for powering it from high intensity LED lights mounted within the chamber.
The cube has a mechanical assembly affixed to it with a high speed, highly sensitive gyroscope / accelerometer that detects the slightest movements of it, triggering data corruption.
The cube holds the cryptographic processor which is a custom ASIC containing, amongst other methods of protection, optical logic gates, MEMS logic gates and possibly some chemical / electrochemical methods of data handling.
Several key parts of the data should rely on external optical delay lines and internal mercury delay lines.
Naturally have the security cube reconfigure the positions of some of the protections using randomized numbers generated from a radio-isotope or heat noise random number generator.
Data to be encrypted / decrypted is transferred to and from the cube with differential light beams using interferometry to ensure the beams are not being extended for listening.
You could also have security lasers exiting the box to go around secure areas of the building, if the beams are broken then it wipes the keys and destructs itself through the release of HF acid onto it's circuit (or just a high voltage spike / overheating)
A thermal sensor would watch it's own temperature to ensure that it isn't being supercooled.
Possibly add computer vision to the security cube (IR, Visual light, X-Ray & Gamma to prevent X-Ray / Gamma visualization of internals)
...... I'll eat my sock if anyone can see a way to get past that. (And record myself doing so.)
You have violated one of the stated requirements - that physical access is not prevented. But in general you have put your finger on the problem. You have made the system extremely expensive, and extremely difficult to use, and have not eliminated all possible attacks. I will leave it to your cleverness to uncover the weaknesses that I (not an expert in the field) would use to start an exploit. I will grant that you have made it very difficult.
Not sure where it was said that physical access needed to be available to the actual board.
I also still can't see any way for you to get access to the keys....
The other idea was to put the board, with optical lines and a power line, into a holding frame, then mount a laser galvometer on the board.
An FPGA on the board with various ADCs and DACs has several 100 outputs that connect via thin wires to 2 copper-plated plastic hemispheres that are placed surrounding the ball.
The board is then supplied with a YAG laser beam to ablate the copper foil with a heat-noise generated random pattern, the ADCs then pass various signals through the wires and foil at constantly varying frequencies and waveforms, the moment a change in characteristics is detected it will erase the keys.
An X-Ray and radiation detector will be put on the board too to detect if it's being observed via X-ray style techniques to reverse engineer it to open it. A temperature sensor detects and erases the keys should it be attempted to cool it beyond 0*C
Keys are wiped should power be lost. (naturally)
Uses a tritium / radioactive battery to supply power to erase / re-write / jumble any data to ensure no memory is kept.
Data is passed in and out to be encrypted or decrypted via fibre connections to an outside holding frame. -
my gut tells me that there has to be a simple low-cost mouse trap that we can build here that can stand up to even a very smart and very determined mouse, but maybe there isn't?
This is my field of expertise. There isn't [a low cost solution]. You need an HSM. You can build it yourself but it's almost certainly cheaper [TCO] to buy. No product is perfect but the commercial solutions readily available today can protect pretty much any secret short of nuclear launch codes (or DNC emails lol). Your app also has to be designed to actually require use of the HSM in a way that other parts of the system aren't the weak links. That's quite hard.
I don't mean to be insulting, but you have no idea what you're doing and in the security field that's an absolute recipe for disaster. Correction: you have "a little knowledge". IOW a dangerous thing. You should hire and/or consult some top level experts if you expect to protect against state actors.
exactly, that is why you read FIPS140 level 3 and realise that it needs to be bought not made from the contents of your spare parts bins. -
HYSOL 1C white ceramic loaded epoxy mixed with industrial Diamond dust will slow the casual Dremel tool down to a crawl.. That stops the casual hacker, especially if you heat it pre-cure so it flows. Nothing will stop a state level hacker short of SCIFs, one way fiber optic firewall portals etc best to hire an expert as has been said.
Steve
-
Wouldn't it be easier to leave a "trap" amongst the keys, which when it is used (which you never do because you know it's a trap) doesn't release the key, but wipes the data?
Therefore, someone steals the device, extracts the keys (and the trap), uses them to access the data, but, blammo, the data is gone! -
Okay, so here's my idea:
Start with a 5" layer of epoxy (mixed with powdered magnesium) on the bottom of the case, then place 1x1x1" airtight containers containing iron sulfide every 3" in a grid pattern and cover with 1" of epoxy/magnesium mix; place the PCB on top of that, add more epoxy to cover and then repeat the iron sulfide and epoxy/magnesium covering on top.
Guaranteed to self destruct! (Well, at least the first time. The second time they might get wise and try to cut into it in a vacuum or argon/nitrogen/whatever environment...) -
In reality, thermite is old school. A photoflash cap and the right kind of resonant transformer can insure suitable destruction of an SMD device.
Steve -
The need is to protect crypto keys contained in rackmount servers. We are not trying to prevent reverse-engineering of hardware and software, only trying to guard against recovery of keys.
Read FIPS 140-2. It will not tell you how to do what you want to do, but it will tell you about the fifty things you haven't thought about yet.
Be aware that getting level 3 and higher is extremely difficult once you go to a multi module (i.e. the crypto boundary encloses a PCB as opposed to a chip).
Finally a good read of 140-2 will tell you how useless FIPS certification can be. -
FIPS-140-2 is a good start. But one need not wear a tin foil hat to believe that an openly published document in no way defines the limits of state sponsored attacks.
-
And finally, never forget that you could be laboring very efficiently to solve the wrong problem. Suppose you have succeeded, and the keys are effectively forever sealed inside your protected module/box. But since a key that can't be used at all is useless, this implies that encryption/decryption hardware must be inside the box too. Now the adversary takes the fully intact, working box, and commands it to decrypt data X using its key...
In reality, security is a chain, and an intelligent adversary will attack whatever is its weakest link. Maybe that's the key storage, but maybe it isn't. Maybe it's the developer who wrote the random number function. -
That's the thing about security....
You can go into hyper analysis, over engineering and crypto insanity which will safeguard against 10,000 different attack vectors, but your adversary only needs to find 1. -
... then, one day, you find yourself having to service the thing.
-
That's the thing about security....
You can go into hyper analysis, over engineering and crypto insanity which will safeguard against 10,000 different attack vectors, but your adversary only needs to find 1.
Yep.
PS: Watch this:
-
FIPS-140-2 is a good start. But one need not wear a tin foil hat to believe that an openly published document in no way defines the limits of state sponsored attacks.
Oh I agree. It's a perfect example of a committee produced standard. FIPS compliance does not equal security.
My favourite example is the definition of a physical enclosure - required to prevent access. There are all kinds of rules and definitions about 90 degree bends to prevent probing through vent holes. Well, believe it or not a fan is considered a contiguous part of enclosure, meaning a FIPS compliant product using this part of the rules can be defeated with a biro.
That said, the approach of defining a crypto boundary and securing that boundary is good.IMHO, the standard is a good starting point for anyone wanting to learn how to design a secure product.