Daniel’s blog

This presentation shows three main points: (1) a methodology for including security into a design flow, (2) the importance of Elliptic Curve Criptography (ECC) and (3) the vulnerabilities existing on current implementations and how they are exploted.

The slides of the presentation can be retrieve from FPGA Security and Elliptic Curve Criptograph  as a pdf file. As a highlight, the conclusions for including security into the design flow are:

- independent of the encryption algorithm
- uses existing technology and ready to automate
- proved effective
- increases design area and power dissipation
- reduces throughput and frequency

This paper addresses the cons of normal P2P (peer to peer) applications, by means of rewarding the individual that contribute to the network with e-cash. This virtual coin “e-cash” gives a user the monetary means to buy from another user an amount of data, and provides to the other user with a mean to acquire more money that can later be used to download data.

Approaching the P2P community as an economy market, where an individual makes money by the excess of content uploaded vs content downloaded is an effective approach to get rid of selfish individuals that populate existing P2P networks nowadays. As those individuals will have no e-cash money to pay for a transaction to download content. Thus this approach proves effective to reward those individuals that contribute to the network, and a way to punish or get rid of those who don’t.

The proposed e-cash implementation goes in hand with two centralized entities, a bank and a Trusted Third Party (TTP). The role of the bank is to verify the amount of currency own by each individual has been properly acquire, by validating each coin spend or earned by individuals – thus solving a potential problem of a user trying to do multiple transactions with a single coin. The role of the TTP is to resolve the problems generated by a failed transaction. If a fraudulent seller doesn’t provide the buyer with the promised contract, the buyer can retrieve its money and the seller can’t make a profit.

The implementation of this e-cash P2P is enable by the used of encryption. A buyer who which to download a content ask the tracker of P2P content the source from where it can download, the tracker connects the buyer with a seller, then the seller transmits the encrypted content with a key K to the buyer through a secure connection. After receiving the encrypted content the buyer endorses a coin to the seller and generates an exchange ID, with that a contract for what she is paying is form (hash of block transfered, a timeout, endorsed coin, ID), after the seller receives the endorsed coin it transmit the key K to the buyer to decrypt the content. If anything goes wrong, and the buyer can not successfully decrypt the content, the buyer can refer the problem to the TTP to get its money back.

One of the main drawbacks of the proposed e-cash approach is the overhead paid for transaction and the need of at least one centralized entity – the bank. Becoming a single point of attack and a possible bottle neck as all users must register their acquires coins with them – under this methodology a simple denial of service attack to the bank is all is needed to bring the P2P connection to its knee.

Another concern is the multiple coin denomination, a scheme used to perform fewer amount of buy-sell contracts for longer contents, thus alleviating the overhead pay by the e-cash P2P. Under this approach users of the network might cluster eve more by bandwidths and potentially users can start denying transactions with low contents as the ratio of (overhead paid)/(money earn) is lower.

This paper describes how to get out of a Static RAM both a unique identification number and a true random number generator (TRNG). The unique ID can be used to identified a chip with an embedded SRAM and the random number can be used as a key generator for encryption applications.

The main idea exploited by the paper is that the physical construction of the SRAM cells have random variations inherited by process fabrication (lithography), noise substrate temperature variations and supply fluctuations that are unique to a SRAM memory, and don’t correlate across SRAM on the same wafer or within a field position. This uniqueness provided by each single SRAM cell translate at boot up time of the memory on two types of memory cells, Type A which values are skewed to 0 or 1 across multiple trials, Type B which are not deterministics and provide true random number generation.

Type A cells are determined over multiple boot up trials and they are used to form a unique ID for the SRAM memory. Although their values are strongly skewed to a know value of 0 or 1, as these values are probabilistic and a certain degree of randomness still exist a hamming distance is used to compare the ID. I.E at each boot up time a latent fingerprint is found (a possible ID) taking the hamming distance of all the latent fingerprints provide a unique ID.

Type B cells are found to have the same skew toward 0 or 1 across multiple boot up trials. These cells are used to form random numbers, in which each bit of the random number can be the multiple aggregation of type B cells.

The strength of this paper is to show that is possible to generate unique IDs from embedded SRAM cells and true random numbers. Its main weakness is that it fails to clarify how those type A and B cells are found in an automated way by the embedded application. Although it is true that a microprocessor can have instructions to read its memory and do OR, XOR, AND and shift operations to generate a key, it must know a priory from which memory cells to read.

My questions are:

1. “how does a microcontroler with embedded SRAM determines which cells are to be considered of type A, which of type B at boot up time?”
2. “does the paper imply that we need to determine manually for each microcontroller the SRAM cells that contribute to its ID and to its TRNG?”
3. “is there any way to do a sort of BIST that determine those bits and feeds the microcontroller with that information?”

I find it quite amusing to write about information security on a blog; but there is a reason to it. It is required for my 691i class – so under the topic “Information Security” i will be posting anything related to that class.