Similar to the first day, the second day of ECRYPT II VAM2 Workshop on Practical Implementation Attacks was mostly dedicated to industry talks. The morning session started with a very interesting talk given by Steven Murdoch from Cambridge University who presented man-in-the middle attacks for chip and PIN payments. It was his second talk on this workshop and the second one being as interesting as the first one on the day before. He described possibilities how to use a fake terminal to perform an on-line attack and charge the user more for a transaction then he would expect.
Next, Benoit Feix from Inside Secure gave a talk about the Daily Life for a Secure Product in the Industry, where he introduced threats and countermeasures against physical attacks and a more general overview of how companies have to deal with it in their product and design life cycle. Afterwards, Lex Schoonen gave a talk about the Practical Aspects of Security Evaluation where he described the use and pitfalls of Common Criteria standards. He also presented a couple of practical evaluation examples which shown out-of-the-box thinking, e.g. use an UZI gun to shoot away a chip from the PCB board which was responsible for raising an alarm and erasing the key storage. The trick was to be quicker than the signal propagation time, chip setup time etc. So it seems that that the UZI has a new application.
The workshop ended with two talks given by Sergei Skorobogatov from Cambridge University in which he presented Fault Attacks on Secure Chips and Side-channel Attacks: New Directions and Horizons. Both talks were very interested, specially the second one where we could hear about new measurement setups with lower noise. This allows to perform power attacks quicker and with less traces. Unfortunately, to achieve lower noise, lots of design details have to be know in advance. The whole idea also suffers from randomization issues but nevertheless the overall performance improvement was significant.
A blog for the cryptography group of the University of Bristol. To enable discussion on cryptography and other matters related to our research.
Monday, June 6, 2011
Thursday, June 2, 2011
Day 2 of WISTP'11
Today I'm going to write about two interesting talks from the WISTP 2011 conference which deserve some attention. The first was Pim Tuyls talk on intrinsic PUFs. It was an invited talk like yesterday's talk by David Naccache but unlike yesterdays talk it didn't focus on research to come but on a topic that has mostly moved from the world of research to the world of product development: Intrinsic PUFs. Pim Tuyls described the security advantages of PUFs very convincingly but even more outstanding in his talk was another advantage of intrinsic PUFs: They can be implemented as soon as a new semiconductor technology step (for example 28nm technology) is available and doesn't have to wait for non-volatile memory such as flash to be available in that technology. Considering that it usually takes considerable amount of time between the availability of a technology step and the availability of non-volatile memory in the same technology, this is quite an important advantage.
The second talk I have to mention is Matt Henricksen's talk on AES variants secure against related-key attacks. I am not going to describe their paper in great detail as I am not convinced that the AES standard will be modified to support another key schedule anytime soon (not least of all because the practical relevance of related-key attacks is contestable) but I have another reason for selecting this talk: It was a good demonstration that something as "trivial" as a key schedule should not be neglected in research. Indeed, as far as AES is considered, the problem of designing a symmetric cipher seems to be better understood than the problem of designing a key schedule for this cipher. Matt's talk made it clear that they have made an important contribution to solving this problem and I look forward to read their paper (even though I'm not an expert for the design of symmetric ciphers).
The second talk I have to mention is Matt Henricksen's talk on AES variants secure against related-key attacks. I am not going to describe their paper in great detail as I am not convinced that the AES standard will be modified to support another key schedule anytime soon (not least of all because the practical relevance of related-key attacks is contestable) but I have another reason for selecting this talk: It was a good demonstration that something as "trivial" as a key schedule should not be neglected in research. Indeed, as far as AES is considered, the problem of designing a symmetric cipher seems to be better understood than the problem of designing a key schedule for this cipher. Matt's talk made it clear that they have made an important contribution to solving this problem and I look forward to read their paper (even though I'm not an expert for the design of symmetric ciphers).
VAM2 workshop - day 1
Today was the first day of the ECRYPT II VAM2 Workshop on Practical Implementation Attacks. We had four interesting lectures, mostly from people from industry. Guillaume Dabosville from Oberthur talked about the security challenges in the smart card industry. The biggest challenge today is still the issue of how to secure systems which center around an insecure user devcie (be it a conventional desktop PC or a modern smart phone). Even if secure components like a SIM card are present, this is still an unsolved problem. Then, Steven Murdoch from Cambridge University presented their attacks on payment terminals which allowed to spy out user PINs, clone cards, and make unauthorized payments. These attacks are especially interesting as they pertain to a large group of EMV users (which encompasses the holders of about a billion EMV cards). Lex Schoonen from Brightsight evaluation labs discussed certification and compliance for the security industry, which mainly relates to Common Criteria certification. Finally, Marc Joye from Telecolor (formerly Thomson) showed details on his work on efficient and secure generation of primes for cryptographic use on smart cards. His talk gave a good insight on the interplay between design for efficiency and design for security.
Wednesday, June 1, 2011
On subleq machines
One of the most interesting talks at WISTP so far was David Naccache's talk who, as an invited speaker, used the time to talk about some projects he's currently working on with students and fellow researchers and one of those topics was subleq machines. I've heard about RISC and CISC machines, Turing machines, single- and multicore processors, reconfigureable processors, general-purpose and dedicated co-processors and a lot of other architectures before but a subleq machine was completely new to me. It's not about Complex Instruction Set Computing nor Reduced ISC but about Single Instruction Computing. Now this might initially sound stupid if not impossible but quite to the contrary: Not only is it possible to compute any instruction using sequences of the subleq instruction (a bit like NAND-logic where you build arbitrary gates from NAND gates) but there's also some sense to limiting yourself to just one instruction. But let me explain the subleq machine a bit more, first.
A
subleq a b c
instruction computes the same as the following C pseudo code:
*b = *b - *a;
if (*b <= 0) { goto c; }
With this,
subleq a, a, $+1
is the same as
clear a
just to give an example of the construction of other instructions and David Naccache showed some more. Also, subleq isn't the only instruction which could be used for a SI(S)C machine but among all the instructions investigated so far, subleq was their favourite.
So why would you want to build such a subleq machine? One thing is, that it is a very simple machine and thus easy to analyze on the hardware level if you need to prove resilience to power analysis attacks and fault injection. It also fills the gap between theoretical fault injection ("I have this equation and if there's a fault in this value then...") and practical fault injection ("I have this device and point my laser at that position and something happens...") as a subleq machine is simple enough to be used within formal frameworks of theoretic computer science. Using the tools of theoretic computer science one may thus hope to prove for a specific subleq program that it is resilient for up to n faulty instructions.
A
subleq a b c
instruction computes the same as the following C pseudo code:
*b = *b - *a;
if (*b <= 0) { goto c; }
With this,
subleq a, a, $+1
is the same as
clear a
just to give an example of the construction of other instructions and David Naccache showed some more. Also, subleq isn't the only instruction which could be used for a SI(S)C machine but among all the instructions investigated so far, subleq was their favourite.
So why would you want to build such a subleq machine? One thing is, that it is a very simple machine and thus easy to analyze on the hardware level if you need to prove resilience to power analysis attacks and fault injection. It also fills the gap between theoretical fault injection ("I have this equation and if there's a fault in this value then...") and practical fault injection ("I have this device and point my laser at that position and something happens...") as a subleq machine is simple enough to be used within formal frameworks of theoretic computer science. Using the tools of theoretic computer science one may thus hope to prove for a specific subleq program that it is resilient for up to n faulty instructions.