1

When we are using a FPGA for file, container or full-disk encryption, we need to input a password for encryption/decryption process. How can we prevent side channel attacks to steal password for a stolen FPGA?

  • Considering without such 'initiation password' an attacker with physical access would just need to take the FPGA power it on and listens to the crypto hardware operations in order to crack the key?
  • Regarding side-channel-attacks is there a preference between symmetric vs asymmetric algorithms used in FPGA to protect data?
  • Are there open source code reference implementations available for FPGA with reviewed source code? Can you recommend a website or community regarding FPGA crypto implementations, either symmetric and asymmetric algorithms.
  • I think you are a little confused about side channel attacks. I wouldn't call it a physically safe place if it leaked power/radio information. But that aside, the answer is "no" to all four. – Ben Feb 11 '14 at 15:14
  • @Ben: You got me wrong. I'm asking if a password promt before (!) encryption/decryption wouldnt allow an attacker who finds the (powered off) FPGA to analyze crypto operations? For side-channel-attacks the attacker needs to 'listen' to the cryptographic operations. BUT without password to legitimate encryption/decryption he cant start a side channel attack on this device, I mean. Is that correct? – user3200534 Feb 11 '14 at 15:46
  • What is the scenario? Lost/stolen item?.... If you prevent it from doing any crypto operations then it will be immune from all side-channel attacks on said operations for the period when it doesn't do them.... Of course it will be subject to side-channel attacks on the password verification.... Generally side-channel attacks are only of interest when you expect the device to be out of your control, so apart from lost/stolen scenario, presumably the attacker has the password since the attacker may be e.g. the authorised user. – Ben Feb 11 '14 at 17:18
  • Scenario: Attacker steals the FPGA. He connect the power wire to start the device. The FPGA starts and immediately asks for user-verification! Only if the person knows the password he can initiate the encryption or decryption process of the FPGA. --> Can the attacker run a successful side-channel-attack (or else) on this password prompt? – user3200534 Feb 11 '14 at 17:52
3

"FPGA" is mostly a red herring here.

Side-channel attacks try to exploit leaks of secret data element when a system uses the said elements. Leakage can occur in a variety of physical ways, such as energy consumption, processing time, emitted radio waves...

IF:

  • you have a system which contains a secret element;
  • AND that system may leak information when using the secret element;
  • BUT the system will refuse to work until an authorized owner has been duly authenticated;

THEN side-channel attacks won't apply even if the device has come under physical control of the attacker: the attacker won't be able to make the device leak the secret because the device will simply refuse to run the operations which could leak.

HOWEVER this is all relative to some core assumptions which are not necessarily true:

  • This assumes that the authentication mechanism cannot be broken, though that one can be exercised at will by the attacker.
  • This also assumes that the device is tamper-resistant: even if the device refuses to use the secret, it still contains it. The attacker has physical access to the device and may try to break it apart and plunder its contents directly. A FPGA is not necessarily tamper-resistant. Since it is a physical chip, it may have been shielded and enhanced with tamper resistance features, but that's not a given. Some FPGA claim tamper-resistance, to some extent (the Devil is in the details, as usual).

As for open-source FPGA implementations, they are not as widespread as their software counterparts, but there is a growing trend for that as well. See for instance OpenCores, which tries to aggregate information about available open-source designs for FPGA and ASIC.

0

I am wondering how exactly the password comes into play with the encryption itself. You have (at least) two options here.

  • The decryption key is derived from the password

This would not give an attacker any advantage. If he steals the device the decryption key is as unknown as the password. So there is no way the decryption key can be leaked because it is simply not in the device.

  • The password is used to unlock the device which already contains the encryption key

Here the decryption key is stored inside the device. So there are way to extract it. First of all you can open the device with acid or whatever does the job and read out the key. This is obviously not too simple.

There may also be possibilities to recover the password, depending on the implementation of the password check. If you compare Byte by Byte timing attacks may be possible.

Considering without such 'initiation password' an attacker with physical access would just need to take the FPGA power it on and listens to the crypto hardware operations in order to crack the key?

This might not be necessary at all. Depending on the implementation it may be sufficient to let the device encrypt zeroes to recover the pad that is used for encryption.

When the device is 'unlocked', it may be possible to recover the key with a side-channel attack. If the implementation is done without protection a simple or differential power analysis can recover the key bit by bit or byte by byte.

Regarding side-channel-attacks is there a preference between symmetric vs asymmetric algorithms used in FPGA to protect data?

There is no preference. Side-channel attacks can recover keys of both types.

Are there open source code reference implementations available for FPGA with reviewed source code?

Not to my knowledge.

Can you recommend a website or community regarding FPGA crypto implementations, either symmetric and asymmetric algorithms.

Actually no. Side-channel resistant implementations are a good starting point for your own business. They are of great value.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.