Study Group: Physical security and FPGAs - Part II

In this week's study group we resumed the topic of FPGA Security and discussed issues covered by 4 papers:

Amir Moradi and Alessandro Barenghi and Timo Kasper and Christof Paar
“On the Vulnerability of FPGA Bitstream Encryption against Power Analysis Attacks – Extracting Keys from Xilinx Virtex-II FPGAs” [pdf]

Amir Moradi and Markus Kasper and Christof Paar “On the Portability of Side-Channel Attacks – An Analysis of the Xilinx Virtex 4, Virtex 5, and Spartan 6 Bitstream Encryption Mechanism” [pdf]

Tim Güneysu and Amir Moradi “Generic Side-Channel Countermeasures for Reconfigurable Devices” [pdf]

G. Canivet, P. Maistri, R. Leveugle, J. Clédière, F. Valette and M. Renaudin
“Glitch and Laser Fault Attacks onto a Secure AES Implementation on a SRAM-Based FPGA” [pdf]

The study was moderated by Dan and Simon. Dan started his talk with a short introduction to FPGAs and described the main building blocks in SRAM-based FPGAs such as LUTs, embedded memory blocks, dedicated blocks for multiplication or additions. He also briefly described the potential weaknesses in terms of security.

In short, FPGA could be used to implement third party design and those designs sometimes have to be protected against counterfeiting. One mechanism that tries to solve this problem is bitstream encryption, where the vendor tool encrypts a bitstream using a symmetric key K_BIT: once loaded to the FPGA another internal mechanism decrypts it using the (previously loaded) same symmetric key K_BIT. The bitstream itself can consist of a variety of designs but one of them might be, e.g., Advanced Encryption Standard (AES) used as a cryptographic primitive. To perform an operation on AES this cryptographic primitive should be supplied by a symmetric key K_AES.

There were three main questions set at the beginning of the Study Group that both Dan and Simon tried to answer based on the above-mentioned papers.

• Can we recover the symmetric key used in the cryptographic primitive K_AES?
  
• Can we recover the symmetric K_BIT used in bitstream protection via Differential Power Analysis?
  
• What kind of countermeasures can we use to prevent DPA attacks that reveal K_AES?
  

The first presented paper is addressed at question 1. Authors describe a fault injector platform for SRAM-based FPGA devices. Faults can be induced in the experiment by voltage glitches or laser attacks. Apart from practical issues, another interesting feature of the paper is the fault model for SRAM-based FPGA devices. In the presented model, authors described the following types of errors: no effect: the internal state of the circuit was not modified at all, silent errors: the state of the circuit is modified, but the result is correct and no error is detected, false positives: there actually is an alteration, and an alarm is raised, but the result is nonetheless correct, detected errors: the fault led to an unexpected result and it was successfully detected, undetected errors: no error is detected, but the cipher is not the expected value.

There are few techniques available in the literature to implement error detection. One of them is based on a temporal redundancy, where computation is performed twice (or more) and then the results are compared. Authors implemented AES as a target algorithm and used Dual Data Rate (DDR) as a fault detection scheme. The DDR implementation uses rising and falling edge to update a different set of registers and thus allows data to be parsed twice for each clock cycle. Then “saved” time can be used to compute results again and check them against faults. This architecture has been attacked by laser-based fault injections during runtime. Results showed that although DDR AES implementation is very resistant to transient faults, FPGA could be vulnerable to faults that modify configuration bitstream.

Another interesting paper presented (by Simon) during the Study Group dealt with countermeasures against K_AES leakage from an FPGA device; i.e., what can we do with off-the-shelf SRAM-based FPGA fabric to prevent DPA? Authors focus in this case on a Viretx-5 device from Xilinx and combine a few techniques to make a DPA (especially first-order) more difficult, e.g. generating Gaussian Noise (using Shift Register LUTs, BRAM Write Collisions, Short Circuits in Switch Boxes), clock randomization (using Digital Clock Managers – DCMs), preventing clock frequency manipulation and block memory content scrabbling. As a result, authors present an FPGA armed with countermeasures ready to be used by non-side-channel-aware engineers. During a case study evaluation, authors showed once again that, in general, increasing a noise level is not a good idea to make your design secure against power attacks. More useful was an idea to use a Digital Clock Manager (DCM) available on FPGA chip and modified their output to achieve a pseudorandom clock behavior. In other words, the rising edge of a clock used in a design is “floating” in some range, which makes the power consumption more unpredictable. The strength of this approach was increased by preventing clock frequency manipulation method to mitigate known workarounds for clock frequency randomization techniques. The combination of all applied countermeasures increased the total number of traces measurements required to at least 100 million and even that did not guarantee the success of first-order DPA.

The last two papers presented by Simon describe practical attacks on the bitstream configuration mechanism. These are the first attacks described in the open literature that aim to reveal the bitstream protection key using side-channel methods, and according to authors it was successful for Virtex II, Virex-4 and Virex-5 devices. Because of the black-box approach (which means that the attacker has very limited knowledge about an internal design) authors had to answer a few additional questions to become familiar with the overall architecture, e.g., what type algorithm has been used, what is the mode of operation, is it a pipeline, loop or software implementation. A number of additional steps (for example, improving the S/N (signal to noise ratio) via filters and alignment techniques) had to be performed as well. Interestingly, in the case of Virtex-4 and Virex-5, GPUs have been used to speed up computation; with increasing complexity of DPA attacks this approach might be very useful for future studies.

Study group: Models of Malware

The study group topic for discussion this week was on formal methods of modeling malware and viruses. In the late 80's Fred Cohen, at the time a student of Leonard Adleman, described an abstract definition of viruses and used it to prove that there is no algorithm that can perfectly detect all possible viruses (text). Adleman himself published a paper a year later, using an abstract definition of a computer virus to answer questions on the detection of, and protection against viruses (text). Since the late 80's the capability of malware designers has increased and the complexity of malware itself has evolved, resulting in a renewed interest in abstract definitions and modeling of malware and viruses. In the study group Theo introduced some more recent research that follows on from Cohen and Adleman's earlier work; "Toward an Abstract Computer Virology" by G. Bonfante, M. Kaczmarek, and J.-Y. Marion ((pdf) and "Math on Malware" by Henk-Jan van der Molen (pdf).

Bonfante et al. suggest a newer definition for viruses that encapsulates Adleman's previous definitions, amongst others, and use the new definition to make an interesting observation on virus detection and to propose a countermeasure against a particular type of virus propagation. A virus is a program with a propagation mechanism that can be described in terms of some computable function B, that selects from a list of available programs and then replicates the virus inside the target. In other words, B is the delivery mechanism; some functional property or flaw in the programming language used by the virus to infect the system. A common approach from previous attempts at formalising viruses has been to define a virus as a self-replicating device; a virus has the capability to act on a description of itself. This leads to a definition that uses Kleene's recursion theorem to construct the viral mechanism. The self-reproduction is provided by a duplication function that copies a virus into a program in different ways.

There are three particular types of duplication function to mimic three types of virus behaviour. A crushing is simply a virus that has some behaviour involving copying itself, e.g. to a directory. A cloning is a virus that copies itself into some parts of a program environment, without increasing the overall program size (typically by overwriting honest code). Finally an ecto-symbiotic virus essentially attaches itself to a host program, without overwriting. Further definitions that cover polymorphic viruses (viruses that in some sense mutate when they reproduce) are discussed in the paper. The authors also show how these definitions can encapsulate Adleman's original definitions by translating it into the new formalism. An interesting result is that it can be proven, under the definitions that are approximately described above, that there are at least some propagation mechanisms B for which it is decidable whether a particular program is a virus.

A slightly different question is to ask how malware or viruses propagate throughout a network once they are introduced into the environment. Henk-Han van der Molen focuses on using ideas from epidemiology and network theory to study how infection rates change over time once a network is compromised. In particular, a highly useful metric would be to quantify how impactful particular countermeasures and security methods are at reducing infection rates (and increasing clean-up rates). For instance, potential tools for alleviation such as deployment of anti-virus software, periodic re-imaging, increased user education, and incident management/disaster recovery procedures have varying economic costs, so knowing their real effectiveness as countermeasures can increase efficiency.

The particular network model chosen for analysis is described as the "Susceptible-Infected-Susceptible" (SIS) model. From a biological standpoint, it captures a scenario whereby after contracting a disease, and recovery, humans are still susceptible to re-acquiring the condition later on. This is perhaps the best-fit for modeling a computer network, as it may be that machines that are cleaned/re-imaged/patched still have potential vulnerabilities. Without going into the mathematical description too heavily, the SIS model starts by assuming that in the early phase, infection rates grow slowly because there are few infected computers to spread the malware. The number of infected computers that are returned to the susceptible state is proportional to the number of infected computers. Two other additional factors are the probability of resuscitation, which models the effectiveness of the countermeasures in cleaning an infected node back to its susceptible state, and the contamination factor, which models the probability an infected node can infect a susceptible neighbour.

The SIS model is analysed in three particular scenarios. The first is the 'corporate' scenario, with statistics from malware infections in organisations used to estimate the resuscitation and contamination factors. In the 'practice' scenario, the goal of the malware is assumed to be to infect as many computers as quickly as possible. In this instance, the parameter estimation is difficult because there are few sources of reliable statistics available. In the final 'cyberwarfare' scenario, the malware needs to remain undetected for as long as possible to keep target nodes in the infected state. One interesting result drawn from the model is that with a periodic reset of software, in the corporate scenario the steady state of malware infections drops almost to zero. With the increasing proliferation of virtualisation techniques in business, executing this strategy frequently may become more and more viable.

Another mitigating factor in the spread of malware is the diversity of the software installed on a network. A fully Windows-based network could potentially be entirely compromised by a single Windows-based virus, but a network comprised of a mix of Mac OS, Linux and Windows could not be infected to the same extent by just one such virus. An analysis of the SIS model seems to support this hypothesis, with increasing diversity resulting in slower infection rates. However the practical and economic implications of this strategy are much harder to capture: the support costs for supporting diverse software are higher, typically vendors try to encourage lock-in, a reliance on software supporting shared data standards is introduced, and so on.

The research poses a challenging yet important problem. Through modeling it will be possible to improve our understanding of virus and malware propagation and the effectiveness of tools and procedures as countermeasures, but a further understanding of the implications and costs of the mitigating factors is also required to have a complete solution.

InfoSecHiComNet 2011

Last week I was attending a conference we helped organise in India entitled InfoSecHiComNet 2011. The conference received 122 submission, of which 14 went in to the conference program. These were complemented by invited talks by Jorn-Marc Schmidt, Ingrid Verbauwhede, Benedikt Gierlich, Saibal Pal, Palash Sarkar, and Sanjay Burman.

We expect that this conference will be repeated under the less general theme of "Cryptography and Cryptographic Engineering", which we hope will help encourage cryptography research in India. This conference is expected to complement CHES, since the number of submissions generally received by CHES demonstrates the popularity of research into topics related to cryptographic engineering. The intention is also to hold conferences that will not be in direct conflict with Indocrypt.

Study Group: Physical security and FPGAs - Part I

In this study group Marcin and Philip started the discussion on Physical security of FPGAs which will be followed by a second part in two weeks. They based the study group mostly on two papers by Saar Drimer, "Volatile FPGA design security - a survey" [pdf], "Security for volatile FPGAs (Technical Report)" [pdf] and on the paper "Protecting multiple cores in a single FPGA design" [pdf] by Drimer, Güneysu, Kuhn and Paar.

As we have both theoretic and practical cryptographers in our group, Marcin and Phil started by describing the basic technology of a Field-Programmable Gate Array: Unlike ASICs (Application-Specific Integrated Circuit), the function of a FPGA is not determined when it is manufactured. Instead, FPGAs have to be configured; based on their configuration mechanism, they are either

• volatile, i.e. the configuration can be changed, or
  
• non-volatile where the configuration is "burnt" into the device, e.g. using anti-fuses.

The key manufacturers of FPGAs are Xilinx, Altera and Actel which was bought by Microsemi.

The study group focused on volatile FPGAs, which essentially consist of an array of SRAM lookup tables (LUTs) which map a fixed number of input bits (e.g. 4) to a smaller number of ouput bits (e.g. 1) and configurable interconnect. The LUTs basically emulate the truth tables of the logic gates used in ASICs while the configurable interconnect assures that basically all LUTs can be "wired together" as required. Being SRAM, the LUTs have to be reconfigured at boot time which provides the volatility of the FPGA. A comparison of FPGAs to CPUs and ASICs results (roughly) in the following table:

	CPU	FPGA	ASIC
Speed	low	medium	high
Power consumption	high	medium	low
Implementation cost	low	low	high (tapeout, masks)
Cost per unit	medium	high	low
Updateability	good	doable	none
Implementation	C, Java,...	HDL	HDL

Of course FPGAs come with a couple of security related issues including such as

• leakage (side channel attacks)
• semi-invasive attacks (fault injection)
• invasive attacks
  
• trustworthy (remote) configurations (hw trojans, reliability)
  
• protection of Intellectual Property in configuration bitstreams (IP cores).

A FPGA is configured using a "bitstream" which consists of the data to be written to the LUTs and of the configuration bits for the interconnect. Since updateability is one of the key features of a FPGA, one would of course want to do it remotely and allow only trustworthy, i.e. authenticated bitstreams to be loaded into a FPGA. At the same time, the bitstreams contain valuable IP and whoever can read the bitstream can either clone the device (by loading the bitstream into another FPGA) or reverse engineer the IP from the bitstream. Furthermore, it is common that a System Designer doesn't implement all the IP in a bitstream himself - instead he licenses IP cores from several IP Core vendors. (Commonly, an embedded system on a FPGA consists of a microprocessor core, some interface cores such as UART, USB or Ethernet, some accelerator cores e.g. for graphics, crypto, signal processing and a bus core to connect all of the other cores. These may all be supplied by different IP core vendors.) So the IP core vendors have to ensure that their cores are only used in devices for which someone bought a license from them.

The first protocol presented by Marcin and Phil is a simple remote update protocol for which the FPGA needs to have

• a fixed update logic UL besides the configurable logic which can compute a keyed MAC,
  
• a unique and public fingerprint F,
  
• a version number V of its current bitstream (to guarantee freshness)
  
• and of course a key which will be used as input for the keyed MAC.
  

Then, the FPGA has to identify itself and its current bitstream version to the update server so that both sides know F and V. Additionally, both sides need to generate nonces in order to avoid replay attacks; for the FPGA it is sufficient to use a counter while the update server should create a truly random nonce. The bitstream is then sent to the FPGA together with its MAC value which serves both as authentication and error protection mechanism. It is important for the remote update protocol to provide a backup solution for the case that something goes wrong during the backup - otherwise the FPGA would be unusable. One option is to have a default bitstream stored in some non-volatile ROM without using too much (expensive) memory. Note also that the remote update protocol does not need to decrypt the bitstream - commonly the encrypted bitstream is stored in the non-volatile memory as is and gets only decrypted when it is loaded into the configurable logic at boot time using a key and the decryption routine embedded into the boot logic.

The second protocol presented by Marcin and Phil addresses the bit stream decryption and IP core protection problem. Basically, if the bitstream is completely owned by the System Designer (SD), the SD could just encrypt it using a symmetric key he has loaded into the FPGA. But IP core vendors want to protect their IP even though it will always be used by SDs as part of a larger system. So a more complex system is needed and Diffie-Hellman style key-exchange can provide it as the presented 4 stage protocol with three parties (FV - FPGA Vendor, CV - Core Vendor, SD) shows. The needed prerequisits of the FPGA are

• a unique key K_FPGA,
  
• unique identifier FID (both stored in non-volatile memory inside the FPGA),
  
• some hardwired additional registers to store a bit stream encryption key for each CV and
  
• a hardwired decryption module which has access to all of the above keys.

Obviously, none of the keys should be accessible to the outside world. The 4 stages are:

1. Setup: FV generates a secret x and computes a public g^x and embeds the secret into the personalisation bitstream PB and encrypts PB using K_FPGA and sends [FID, g^x, ENC_KFPGA(PB)] to SD.
2. Licensing: For each CV and each FPGA device, SD sends (FID, g^x) to the CV who choses a secret y, computes a public g^y and uses a key derivation function KDF (specified by the FV) to compute a key K_CV=KDF(y,g^x,FID) which he uses to encrypt his IP core and sends [ENC_KCV(core), g^y] to the SD.
3. Personalisation: Having assembled his own bitstream containing all the encrypted cores of the CVs, the SD loads first the encrypted PB onto the FPGA which the FPGA is able to decrypt using K_FPGA. The PB contains an implementation of KDF and of the vendor secret x. Furthermore, the SD provides all the g^y to the FPGA which in turn uses the KDF to compute all K_CV=KDF(x,g^y,FID) which it stores in the registers of the decryption logic. (The computation works thanks to Diffie-Hellman.) Now the Personalisation logic (within the configurable part of the FPGA) isn't needed anymore as the (static) decryption logic is fully prepared to decrypt the bitstreams.
   
4. Configuration: The SD sends all encrypted bitstreams to the FPGA which decrypts them using the respective K_CV's which were stored during personalisation in the decryption registers.

Note that the SD learns neither the secret x nor any of the secret y's and therefore can not compute any K_CV to decrypt any of the IP cores he licensed. Additionally, the K_CV are tied to the individual FPGA chip thanks to FID so cloning of a device is not possible.

Study group: RSA-based standard model signatures

Nigel and Ming-Feng presented the results of 4 papers on provably secure digital signatures in the standard model. Ming-Feng started with Cramer and Shoup's seminal paper from 2000 [ps], and then discussed reductions of the signature length by Fischlin (PKC 2003) [pdf]. Nigel then mentioned the first (stateful) scheme based on the RSA assumption by Hohenberger and Waters [pdf], and dedicated a more thorough presentation to their follow-up work at CRYPTO 2009 [pdf], which is a stateless scheme.

Cramer-Shoup signature scheme was the first to have a standard-model proof of security against adaptive chosen-message attack. It is stateless (which is now the standard for digital signatures, meaning the signer need not keep any state information) and based on the strong RSA assumption. The RSA assumption is, given an RSA modulus n (which is the product of two large primes) and r, z ∈ Z_n^*, it is hard to find y ∈ Z_n^* s.t. y^r≡z (mod n). For the strong RSA assumption, the adversary has more flexibility: given n and z, she has to find both r>1 and y ∈ Z_n^* s.t. y^r≡z (mod n).

Note that while the latter assumption is stronger than the former, the best known attack against both of them is to factor the modulus n.

A signature scheme SIG=(KG,Sign,Ver) consists of algorithms for key generation, signing and verification, which can be sketched as follows (pk is the public key and sk is the signing key):

• 1^k → KG → (sk,pk)

• (sk,m) → Sign → σ

• (pk,m,σ) → Ver → 1/0

A scheme is secure against chosen-message attacks if an adversary getting the public key and a signing oracle that returns signatures on messages of its choice cannot output a message it has never queried and a valid signature on it.

Note that the "text-book" RSA signature (where a signature is simply m^d mod n) scheme is not secure under chosen-message attack, since signing is homomorphic. "Hashed RSA" is secure in the random-oracle model.

Cramer and Shoup proposed the first scheme that is provably secure against chosen-message attacks in the standard model. The scheme has 2 parameters l and l' with l+1<l'. Typical assignments are l=160, l'=512.

Key generation

1. generate an RSA modulus n=pq where p=2p'+1 and q=2q'+1 for p' and q' large primes (such p and q are called strong primes)
2. generate quadratic residues h,x ∈ QR_n
3. generate an (l+1)-bit prime e' and
4. define pk=(n,h,x,e') and sk=(p,q)
   

Signing

1. for a hash function H with l-bit outputs set x=H(m)
2. choose (l+1)-bit number e
3. choose y ∈ QR_n
4. choose x' where (y')^e = x' h^H(m)
5. compute y where y^e=xh^H(x')
6. define σ = (e,y,y')
   

Verification

1. check whether e is a (l+1)-bit integer and e≠ e'
2. compute x'=(y')^e' h^-H(m)
3. check x= y^e h^-H(x')
   

The proof distinguishes different kinds of forgers, depending on whether their forgery reuses the e' of a signature it obtained from a signing query or it reuses the x' or both. While forgeries that reuse parts can be reduced to the standard RSA assumptions, for forgeries with a new e we need to resort to the strong RSA assumption.

In his PKC '03 paper, Fischlin gives a variant of Cramer-Shoup signatures (also provably secure under the strong RSA assumption) which has shorter signatures: instead of |σ| = 2|n|+l+1, we now have σ=|n|+2l+1, but the public keys are longer.


While the CS signature scheme was state of the art, it requires the strong RSA assumption. The reason being that every signature requires its own value e, therefore in the security reduction, in order to simulate the signing oracle, we allow the simulator (who does not know the factorisation of n) to somehow "cheat" by creating new e's.

It thus seems the that we cannot get around this stronger assumption for RSA-based signatures. However, at EUROCRYPT 2009, Hohenberger and Waters presented a scheme that was proven secure under the RSA assumption. The caveat being that it was a stateful scheme, meaning that the signer had to store a counter, which it had to increase every time it issues a signature; else all bets are off. Their signatures were short and looked like standard hash&sign signature à la H(M)^d mod n.

At CRYPTO the same year, they then extended their ideas to define a stateless signature scheme, based on RSA. They start with defining a scheme that only satisfies security against weak chosen-message attacks, where the adversary has to give the challenger all messages it would like to have signed before it gets to see the public key.

Then they transform their scheme into a fully secure scheme by using a known trick: Chameleon hash functions. These are functions that have input a message and some randomness: H(m,r) → y. Now, given a trapdoor τ one can for any y and m efficiently compute r s.t. H(m,r)=y.

The good news is that there exists a chameleon hash function based on the RSA assumption. Given a weekly (not daily) secure scheme and a Chameleon hash function, one can generically construct a fully secure scheme as follows.

Add to the public and private key the description of the hash function. To sign pick a random r and sign x=H(m,r): σ'=S(sk,x). The signature is then defined as σ=(σ',r). To verify it, just recompute the hash and verify σ' on it.

Now given this transformation, all that needs to be done is construct a weakly secure scheme, which is done as follows (remember, a simulator's goal is given N,e and y to compute y^1/y mod n):

Key generation

1. pick an RSA modulus N, pick h ← Z_n^*
2. pick a pseudo-random function F_k:{0,1}^* → {0,1}^l
3. pick a random c ← {0,1}^l
4. define H_k,c(z)=F_k(i||z) ⊕ c, where i is smallest number s.t. H_k,c(z) is an odd prime
5. output pk=(N,h,c,k), sk=(c,k,p,q)

(Whereas in the EUROCRYPT paper, the state i is responsible for choosing the primes, now the picked prime depends on the input, not on the index of the signature.)

Signing

1. let m⁽ⁱ⁾ be defined as the first i bits of m
2. define e_i=H_k,c(m⁽ⁱ⁾) (thus, given a message we generate n prime numbers)
3. define σ = h^{∏ e_i-1}
   

Verification

1. compute e_i=H_k,c(m⁽ⁱ⁾)
2. check σ^{∏ e_i} = h
   

The proof idea is the following. First, after the adversary outputs m₁, ..., m_n, we fix pk. Since the output m* is a forgery, it must be different from all m_i, so there has to be a j s.t. (m^*)^(j) is different from all m_i^(j).

Suppose we guess this position, then we know what the (m*)^(j) is, and can then fix c s.t. H on (m^*)^(j) returns e, the target from the RSA challenge. To simulate signatures on the queried messages m_i, we raise y to the power of all primes e_i,j = H_k,c(m_i^(j)) and set it as h. Now we can take e_i,j-th roots of h. (This is similar to how Boneh and Boyen transform a challenge for the strong Diffie-Hellman assumption into signatures in their scheme.)

WESS 2011

It is not an easy task to organize a workshop on Embedded Systems Security just a little more than a week after CHES 2011. And it didn't help, that the Workshop Chair couldn't attend his workshop due to visa issues. So I didn't expect too much from WESS 2011 but was pleasantly surprised by it. For me, the highlights were:

• Steve Checkoway and Karl Koscher demonstrated in their keynote talk how to hack a car. If you've been to CHES 2010 that might sound familiar to you. But this time, they had a second part which could've been titled "How to hack a car remotely". Scary!
• In the surprise key note Nikil Dutt from the University of California (Irvine) presented an approach towards virtualization of scratch-pad memories in a multi-core embedded system, supporting secure execution environments for sensitive applications.
• Dominik Merli gave an interesting talk on "Semi-invasive EM Attack on FPGA RO PUFs and Countermeasures". For their semi-invasive attack the authors removed the packaging to improve the measured EM signal and succeeded in executing a not so simple SPA (Simple Power Analysis) attack on the ring oscillator PUFs.
• Ralf Huuck gave an interesting talk on "Model Checking Dataflow for Malicious Input", presenting his Goanna tool (commercially available, a limited version is available for free download) to detect bugs in software projects. Prior to the talk, I did know a few things about software bugs, their origins and debugging but I did not know much about the techniques used by bug detection tools. This made the talk that explained some of the basic approaches interesting to me.

It was apparent throughout most ESWeek events, that security wasn't a concern for the majority of the ES community. (Almost all concerned people were at CHES instead.) So having WESS as part of the ESWeek to fill the gap was helpful but having a stronger showing of security topics at ESWeek in the future would be very desirable. Security is an issue for all embedded systems as the talk by Steve Checkoway and Karl Koscher demonstrated. Next year's ESWeek will be in Tampere, Finland.

P.S.: This post is a bit delayed due to my busy traveling schedule.

Embedded Systems Week day 3

CODES+ISSS (one of the three ESWeek main conferences) offered a very interesting session on emerging new techniques for non-volatile memories. The talks of this session gave a nice survey of recent advances in the quest to replace current DRAM as well as SRAM caches with new, denser (and bigger) memories based on technologies such as Phase Change Memory (PCMs) and Spin-Transfer Torque RAM (STT-RAM). For some reason unbeknownst to me, the announced fourth talk on Memristors was replaced by a talk on the future of Flash memory and 3D stacking of flash memory.

Phase Change Memory cells consist of a GST (Ge2Sb2Te5) chalcogenide block which can be either in its amorphous phase (0, high resistance) or in its crystalline phase (1, lower resistance). The GST is placed between Vdd (heater) and GND. In his talk Youtao Zhang showed that the first PCM based products have been announced and highlighted some of the advantages and challenges for PCM to replace/enhance current DRAMs. One of the issues is quite obvious: Writing a bit, i.e. changing the state of one GST block requires a lot of energy and time. Another issue is less obvious but maybe even more problematic: While DRAM basically works forever, PCM will fail after roughly 100 million writes with process variations adding a relatively large amount of uncertainty. The third issue is related to security: usage of non-volatile memory as DRAM replacement makes cold-boot attacks a lot easier. On the plus side, the non-volatility of PCM would enable instant-on functionality and PCM is competitive with RAM for reading speed, reading energy and idle power leakage and thus out-performing NAND-Flash. Youtao Zhang then explained some of the techniques used to mitigate the draw backs, which fall into one of the following categories:

• Reducing the number of writes
• Wear-levelling
• Salvaging

My impression was that PCM may be a good technology to replace NAND-Flash in solid state disks but that it will be difficult to replace DRAM entirely with PCM. Splitting the RAM into a DRAM and a PCM part, as outlined by Youtao Zhang, may be a more realistic solution.

Spin-Transfer Torque Memory consists of a Magnetic Junction Tunnel which (in its simplest version) looks like a sandwich with a thick "reference layer" on the bottom that is magnetized in one direction, a thin barrier layer inbetween and a thick "free layer" that stores the bit on the top. The free layer can be either magnetized in the same direction as the reference layer (0, low resistance) or in the opposite direction (1, high resistance) . The bit line is connected to the free layer, the source line is connected via a transistor to the reference layer and the word line is connected to the transistor gate. The advantages of STT-RAM are that it offers a higher density than SRAM, has a lower leakage power and is far more robust against errors so that no ECC is needed. Unfortunately, the time and energy needed to write a bit are still too high (by a factor of approx. 5 or 6 respectively). Yuan Xie and Yiran Chen explained in their talks possible hardware and cache architectures in which STT-RAM can replace or, if used in a combination, enhance traditional SRAM.

P.S.: This post is a bit delayed due to my busy traveling schedule.