I have read many cryptographic papers or articles where I have came across about the software and hardware implementation for the cryptographic algorithms. I want to know how its been done. Is there any need to create a separate software to do this. Why there is a need of using FPGA board for the hardware implementation.
$\begingroup$
$\endgroup$
2
-
5$\begingroup$ It's unclear what "separate" means in the question's "separate software". The usual justification for "using FPGA board for the hardware implementation" is execution speed, sometime reduced power. Another fair justification is that it's less difficult to avoid secret-dependent timing variation, which can open to attack. Another usual motivation is learning how to use FPGA/VHDL, or related to that like getting a diploma. $\endgroup$– fgrieu ♦Sep 28 at 12:20
-
2$\begingroup$ Yet another common motivation is integrating the cipher into a self-contained hardware crypto co-processor to provide a security enclave, e.g. smartcard payment, TPMs. One can certainly use a CPU core and program the cipher as software (firmware), but since you're already making chips you usually don't waste the opportunity (even if it's only an power efficiency or speed optimization, if not for better immunity to timing attacks) $\endgroup$– 比尔盖子Sep 28 at 20:35
Add a comment
|
2 Answers
$\begingroup$
$\endgroup$
what is mean by software and hardware implementation? I want to know how its been done.
Cryptographic Software implementation is coding the cryptographic schemes/algorithms with a programming language so that it can run under the target operation system. The programming language can be really wide;
C is preferred most for low level systems
C++ is usually preferred system levels
Java mostly used for smart card systems.
We can talk some other languages like go, Rust, Swift,...
In some cases Assembly language is used. For example writing CUDA assembly really increase the performance. Some FHE schemes have such implementations.
- Well, in most of the cases, where side-channel resistance (this is a 101) is required thanks to seminal paper of Kocher, assembly is used since the compiler tends to optimize the codes that written for side-channel resistance. Well, we have built-in side-channel resistance algorithms like ChaCha (ARX design other like Speck, XXTEA, and BLAKE) or Montgomery Ladder ( and Joyce ladder for non Montgomery Curves i.e. $cofactor < 4$).
We should not finish the list without mentioning the T1 programing language of our bear ( Thomas Pornin). That was created to eliminate side-channel artifacts of the compilers to convert the side-channel designed codes into insecure codes.
Cryptographic Hardware Implementation is writing some code for hardware so that finally it can be turn into a chip ( ASIC) or part of chip like the Intel's AES-NI and Galois Field New Instructions (GFNI) in the CPU or the be used in FPGAs.
This implementation has a long path, been there done that.
Use VHDL/Verilog like hardware description language to describe the logic from low level and,or,x-or, to using some ready libraries like module in programming languages. Alternatively, use schematic design.
Use FPGA as an intermediate so that one can test the implementation, simulate the logic to see that it's behaves exactly as described.
Deploy into real FPGA require place-and-routing, to use it or test more detailed.
Now, turn into Cadence's like software place-and-route (this time there is no FPGA). The path is not done yet. Here one can get timing and space requirements.
This is the cycle; does we fit into requirements? If so, continue to physical deployments ( this is really I've been apart)
If not, then this is where the big firms differs
I used to compile 6M gates alone myself, though the part are mostly copy of themself - except the finite state machince part. I talked a professor that previously worked Motorola, they said;
What the hell of size are you working to optimize? In Motorola, we had a team of 20 people to optimize 200K gates and for the same size Intel had 200 people. The talk was planned for 15 minutes, we talked more than one hour ( the busy professors, they prepare time when they find it is worth for them :) )
IF you think that FPGA/ASIC can be easily written to have side-channel resistant, obviously wrong
- The Unpatchable Silicon: A Full Break of the Bitstream Encryption of Xilinx 7-Series FPGAs, little explanation was here.
- (This was belong to Nigel Smart, they showed me couldn't find the paper. They used to extract some information from Intel CPU that was not accessble, well that made the manager's very angry, as Smart said)
- Meltdown and Spectre
- Search for "intel cpu side-channel attack"
How to do it?
Just choose your target system and select the appropriate software tools.
Is there any need to create a separate software to do this.
Each specific system requires specific tools to compile. Even there are distinction in the software. There are no binary compatibility in the operating systems yet there may be no in the same operating system with different version. So, to be on the safe side one selects the programming language and tool after the target OS determined.
There are work in Hardware companies to eliminate/reduce the amount of hardware description, however, there is no 1-1 tool that let you write a code that can be easily (not talking pragma hacks) run on the software and builds logic for the hardware. Mostly they want to let the user to use programming language very close to software programming languages, more than what Verilog does to C.
Why there is a need of using FPGA board for the hardware implementation.
Talked before, still add some;
- Going ASIC is expensive and takes time. Before ASIC, it is much better to see the logic in FPGA and eliminate the errors.
- There are systems that need to be deployed very fast, so FPGA can be best solution.
- FPGA doesn't leak the internal design as ASIC does ( remove the layer to see the design and use X-ray). FPGA's programming information can be placed into very different format, let assume we use EEPROM and deployed our top secret secure block-ciper (that is more secure than AES with obscurity!) into our field crypto machines. When there is a danger, we not only want to delete the installed keys but also the algorithm, so a signal all lost, the keys on the memory and FPGA code (Ole, we are still secure with our obscurity!).
$\begingroup$
$\endgroup$
Sometimes there is a need for hardware acceleration of some cryptographic functions. This depends on the system and the particular algorithms (both as needed and as implemented).
A general-purpose processor (most would call this a CPU core) can evaluate anything given enough time if programmed correctly. However some functions like the AES instruction set can be accomplished faster with optimized silicon.
In order to do some common functions faster, some processors have AES-NI extensions or GPU cores. GPU cores can be installed externally to the general purpose die. In some cases, for some algorithms, FPGAs may be faster, although FPGAs are often just a stop-gap until someone does it faster and better in either an ASIC or a block of a custom IC.
Which algorithms? That's complicated and there's a great deal of variety, but maybe start here or here for some examples.
