In a developerWorks DataPower Forum thread the question was raised on how to do ECB mode DES encryption with DataPower.
The answers were two-fold:
- based on DataPower crypto extension function primitives DES is available in CBC mode only (cipher block chaining)
- but that does not mean that you cannot do DES encryption in ECB mode:
just implement the cryptographic primitive (64bit block en-/de-crypt) in XSLT(!)
Find the implementation with a sample from "The DES Algorithm Illustrated" in action, portable for DataPower and xalan use:
The implementation works of 01-strings, hexTObin and other conversion functions included.
This reminds me 5.5 years back when I worked in Smartcard development department in Boeblingen Lab.
The person responsible for side channel attacks left IBM and I was the first who raised the hand for the equipment:
- two oscilloscope cards for the server (100MHz, 2GHz)
- a special card reader with high precision probe
- many smartcards, some secure, others less secure, for adjustment
- software for doing side channel attacks.
What was easy to do was to break triple DES on cards without randomization counter-measure based on statistical analysis of several thousand measurements.
What I heard about is the single request break of RSA private keys in early smardcards.
The code for doing exponentiation in that cards was "efficient", it did compute
- x^(2*n) by (x^n)^2 and
- x^(2*n+1) by ((x^n)^2)*x
So the single bits of the private key could be directly seen on the oscilloscope by long (odd exponent) or short (even exponent) areas of high power consumtion.
We did not have the equipment to cut reader power based on some runtime condition or at a specific clock cycle of computation.
But the certification agencies (and real attackers) had.
Once we got a complaint from a cert agency that a specific pattern on the oscilloscope would leak information.
They claimed that the pattern corresponds to a specific part of the OS code.
Using the oscilloscope I was able to disprove that statement.
I just added code that created spikes at specific locations in the OS code.
Then running the request the oscilloscope proved that the pattern of the complaint belonged to a totally different part of the OS code.
Now how to generate a "spike"?
That was easy -- just power on the (hardware) random generator and immediately power it off with the next command.
But that was long ago, before IBM sold its smartcard business and I joined DataPower development 4.5 years ago.