A Security Scheme for Dependable Key Insertion in Mobile Embedded Devices

. Public Key Cryptography enables entity authentication protocols based on a platform’s knowledge of other platforms’ public key. This is particularly advantageous for embedded systems, such as FPGA platforms, with limited or none read-protected memory resources. For access control systems, an access token is authenticated by the mobile system. Only the public key of authorized tokens needs to be stored inside the mobile platform. At some point during the platform’s lifetime, these might need to be updated in the ﬁeld due to loss or damage of tokens. This paper proposes a holistic approach for an automotive access control system based on Public Key Cryptography. Next to a FPGA-based hardware architecture, we focus on a secure scheme for key ﬂashing of public keys to highly mobile systems. The main goal of the proposed scheme is the minimization of online dependencies to Trusted Third Parties, Certiﬁcation Authorities, or the like, to enable key ﬂashing in remote locations with only minor technical infrastructure. Introducing trusted mediator devices, new tokens can be authorized and later their public key can be ﬂashed into a mobile system on demand.


Introduction
Embedded systems in various safety critical application domains such as automotive, avionic, and medical care perform more and more complex tasks using distributed systems like networks of electronic control units (ECUs).Introducing Public Key Cryptography (PKC) to embedded systems provides essential benefits for the fabrication of electronic units needing to meet security requirements as well as for the logistics involved.Due to the nature of PKC, the number of keys that need to be stored in the individual platform is minimized.Only the private key of the platform itself needs to be stored secretly inside each entityin contrast to symmetric crypto systems where a single secret key needs to be stored inside several different entities.In context of PKC, if one entity is compromised, the others remain unaffected.
Besides encrypting or signing of messages, PKC can be employed to control user access to a device via electronic tokens.Examples for this are Remote Keyless Entry (RKE) systems [1] in the automotive domain or Hilti's TPS technology [2].These systems incorporate contactless electronic tokens that substitute classical mechanical keys.The owner or authorized user identifies himself to the user device (Í ) by possession of the token.Í and token are linked.Only if a linked token is presented to Í , it is enabled or access to Í is granted.In order to present a token to Í , information has to be exchanged between the two.The communication channel is usually assumed to be insecure.To prevent the usage of a device or its accessibility by an unauthorized person, the authentication has to be performed in a secure manner.
Authentication schemes based on Public Key Cryptography such as the Needham-Schroeder protocol [3], Okamoto-Protocol [4], and Schnorr-Protocol [5] provide authentication procedures where no confidential data is transmitted.
Secret keys are stored in the tokens only and not in Í , thus omitting the need for costly security measures in the Í .Only public keys have to be introduced into Í (see Section 2), which can usually only be done by the manufacturer (Ç Å) of Í .In real-world operation, the introduction of public keys is International Journal of Reconfigurable Computing done in the field where Í is not necessarily under the control of Ç Å and a live online connection to Ç Å may not be possible.PKC is computationally very expensive, especially when aiming for high security levels.Dedicated hardware can provide the necessary speed up of cryptographic operations.With the decreasing cost of FPGAs, these devices are introduced more and more into embedded systems and mass market products.Therefore, hardware accelerators can be made available in these cost sensitive systems by adding cryptographic computation blocks on FPGA.
We propose a system to introduce public keys into FPGA based user devices to pair them with a new token.The proposed key flashing method allows authorization of the flashing process by Ç Å. Additionally it can be carried out with Í in the field and with no active online connection to Ç Å while flashing a key into Í .Introduction or flashing of new keys to an embedded device can be seen as a special case of a software update.Latter focuses on protection of the intellectual property, interoperability, correctness, robustness, and security.Recent approaches for the automotive area have been developed, for example, in the german HIS [6,7] or the EAST-EEA [8] project.A general approach considering security and multiple software providers is given in [9].Nevertheless, general update approaches are focused on the protection of IP and the provider against unauthorized copying and less on the case that the system has to be especially protected against unwanted updates as in our key flashing scenario.
The remainder of this paper is structured as follows.In Section 2, we present the basic application scenario followed by a short introduction to public key cryptography in Section 3. Section 4 describes a high-speed architecture for cryptographic computations.The requirements for the keyflashing scenario are described in Section 5. Based on this, we propose our flashing concept in Section 6, followed by the according requirements (Section 6.3).Section 7 details the flashing protocol with a live online connection available and Section 8 the protocol with no online dependability.Implementation details of the prototypical flashing framework are given in Section 9. We conclude with a security analysis and an outlook to future work in Sections 10 and 11.

Application Scenario: Automotive Access Control Systems
The target application focused on in this work is foremost automotive access control system.They comprise an entity that acts as the verifier (an ECU within the car) and an entity that acts as a prover (the traditional car key).Traditionally, a standard car key serves the sole purpose of identifying the current owner of the key as the authenticated user of the car (authentication by ownership).This also holds true for electronic car keys.As depicted in Figure 1, access to the car is granted by unlocking the doors only if the correct car key (prover) is presented to the car.The same procedure can be employed to disable or enable the immobilizer of the car, allowing the car's engine to start or not.
Prover Verifier 1 0 0 0 1 1 1 0 0 01 1 100 011 00 11 1 1 0 0 0 1 1 1 1 0 The automotive domain implies a very specific set of requirements.The industry is extremely cost driven, thus creating the need for very small hardware footprints.To comply with limited cost, OEMs tend to resort to cheap off-the-shelf components instead of specialized ASICs or complete systems-on-chip (SoC).Additionally a car's life cycle is about 10-15 years.Within this time span, all systems should work flawlessly.
Access control systems are a natural point of attack.Therefore, they need to offer very good security.To provide this, electronic car keys incorporate some kind of cryptographic algorithm.Raising security levels in this context can be achieved by adaption of the authentication protocol being used, enlarging key lengths, or substituting cryptographic primitives.All these measures tend to increase computation times.But all underlying computations and algorithms incorporated in access systems shall not be noticeable to the user of a car for best usability.Keeping the underlying hardware platform adaptable to varying interfaces and functionalities, it enables for integration of the same hardware components into a wide range of car keys for a multitude of different car models.With FPGAs dropping in cost over the last years, they also have been introduced more and more in cost driven industries such as the automotive domain.These devices are already being used in infotainment and multimedia devices.In addition to that, they can be used to provide dedicated hardware modules to accelerate cryptographic computations within user authentication in these systems.By using FPGA platforms for access control systems, they are adaptable over the lifetime of a car and offer some flexibility regarding changes in protocol and processing units.
In summary, we will regard the following application scenario: an access control system is applied to a mobile user device (Í ); in our case, a vehicle is depicted in Figure 2.
Through the access control system, the use of the Í can be restricted by allowing only the owner or authorized user access to the device.A transponder (ÌÊÃ) serves as an electronic version of a mechanical key.ÌÊÃ communicates to Í over a wireless communication channel.The user device accepts a limited number of transponders.If one of these is presented to the user device, it authenticates the transponder and the device is unlocked, thus granting access.
Anyone possessing a valid ÌÊÃ is considered an authorized user (ÇÏAE).This setup forms an authentication chain for usage of Í .An authorized user is authenticated through the possession of a valid ÌÊÃ paired to the the Í .ÌÊÃ in turn is authenticated by Í .In automotive systems, authentication of a ÌÊÃ can be achieved through a number of methods: rolling codes, symmetric codes, one-way-functions, or asymmetric codes.As analyzed in [10], there is a major disadvantage in using rolling codes and symmetric codes since secrets have to be stored within ÌÊÃ as well as in Í , demanding for highly secure key management.One-way-functions such as cryptographic hash functions can circumvent this to some extent but demand for a substantial amount of secure storage.The most wide spread method for authentication in mobile devices is probably the usage of rolling codes (such as the KeeLoq [11] algorithm) due to easy implementation, followed by one-way-functions.
Asymmetric codes are very computationally expensive, although they provide extremely high security.With the advent of more and more computational power in embedded systems [12,13], introducing such codes for user authentication is now feasible.
Ç Å is the manufacturer of Í .Due to the mobility of Í , it may be nowhere near Ç Å.Therefore, a service infrastructure has been established by Ç Å to repair, service, or replace a Í in the field.This infrastructure consists of a number of service points ËÈ that are Ç Å certified.In the depicted example from the automotive domain, this would be a dealer or a car repair shop.ËÈ is enabled by the Ç Å to carry out certain work on Í and acts in a way as a substitute for the Ç Å in the field.
In case of loss of a transponder, it is desirable to replace it, particularly if the user device itself is very costly or actually irreplaceable.Since the user device is mobile, linking a new transponder to a Í usually needs to be done in the field.This might include very secluded areas with minor to none communication infrastructure.

Basic PKC Functionalities
In 1976, Diffie and Hellman introduced the first PKC crypto system [14] for data encryption and confidential data transfer.Two different keys are used, one public (PK) and the other secret (SK).SK and corresponding PK are a fixed and unique keypair.It must be computational infeasible to deduce the secret key (SK) from the public key.With PK, a message M p can be encrypted into M c but not decrypted with the same key.This can only be done with knowledge of SK.If an entity Alice wants to transmit a message M Alice to an entity Bob, it encrypts it with Bobs public key PK Bob .Only Bob can retrieve the plain text from the encrypted message, by applying the appropriate decryption algorithm using his own secret key SK Bob .
PKC can also be used to digitally sign a message.For this, a signature scheme is used that is usually different from the encryption scheme.When signing a message, the secret key is used and the signature can be verified using the according public key.In other words, if Bob wants to sign a message, he uses his own private key that is unique to him and solely known to himself.This key is used to sign a cryptographic hash value of the message M Bob .The resulting value {HASH(M Bob )} sig is transmitted together with M Bob .A receiver can validate the signature by using Bob's public key to retrieve HASH(M Bob ).From M Bob , the receiver can compute the according hash value and compare it with the retrieved value.If both match, the signature has been validated.Since in the case of signature schemes the public key is often called verification key and the secret key is called signing key, we denote them accordingly VK and SK in the following.

Cryptographic Processing Entity
Computational efforts of cryptographic functionalities for PKC are very high and time consuming if carried out on today's standard platforms (i.e., microcontrollers) for embedded applications.Integrating security algorithms into FPGA platforms can provide high speed up of demanding PKC crypto systems such as hyper elliptic curve cryptography (HECC).By adding dedicated hardware modules for certain parts of a crypto algorithm, a substantial reduction of computation time can be achieved [15,16].
In [16], an FPGA platform has been introduced which allows extremely fast authentication as proven by an experimental setup with two of these platforms.For this demonstrator, both platforms have been implemented on a Xilinx Spartan-3 XC3S2000 FPGA at 33 MHz.The communication channel in the setup is a wireless automotive transmitter [17] as is currently used in keyless go systems and is clocked with 412,5 kHz.The transceiver is connected to the FPGA system over ËÈI.Authentication of ÌÊÃ via the Schnorr-protocol [5] in this setup lasts 120 ms including communication times over the wireless channel.To enable for even faster computation, we have developed a new, lean cryptographic core for Xilinx FPGA.It enables to carry out aforementioned mutual authentication within 82 ms.
Both platforms carry out calculations for public key cryptography based on hyper elliptic curves (HECC).They offer a higher security level than RSA while relying on relatively small key sizes of around 160 bit [18].A detailed view on HECC and its underlying mathematics can be found in [19].
As shown in Figure 3, the automotive electronic control unit (ECU) comprises a MicroBlaze processor that handles arbitrary tasks necessary for running the car and is equipped with an appropriate interface such as CAN International Journal of Reconfigurable Computing to communicate with other ECUs residing in the vehicle.Additionally, a coprocessing unit composes of a PicoBlaze processor [20] and a Cryptographic Processing Module (CPM) is included.All cryptographic computations are done within this coprocessor.When no extensive tasks need to be run and only cryptographic functionality is needed, the coprocessor can also be run without the MicroBlaze.In this case, the PicoBlaze Controller is interfaced directly to the communication interface.This setup is very suitable for implementing a car key (ÌÊÃ).
For HECC, three types of operations are essential (P i denoting a point on a hyperelliptic curve and k, y, a, e, r are denoting integer values): (i) calculation on a hyperelliptic curve (k•P and P 1 +P 2 ), (ii) integer calculation with large operands (y = a • e +r), (iii) data exchange to/from the cryptographic unit.
Each arithmetic operation is assigned to a specialized hardware module to enable fast computation.At the same time, all cryptographic functionality is bound strictly to CPM, thus keeping all sensitive data on chip.

Cryptographic Processing Module.
The Cryptographic Processing Module (CPM) is designed to efficiently compute k • P on a hyperelliptic curve, as well as integer multiplication with large operands.As depicted in Figure 4, the proposed architecture encompasses dedicated modules (HPU, bigINTmul) for these two operations and an additional module for generating random numbers (RNG).
A small finite state machine (FSM) is implemented for control flow of the calculations and to provide data exchange over the PicoBlaze processor.It controls all modules within the CPM directly.All arithmetic modules can work fully in parallel, allowing for concurrent operations within the protocol if necessary.A set of registers is provided for data exchange that can be accessed directly by PicoBlaze.Register e acts as input whereas y i and the address space X of the CPM's internal memory DataMem are doubling as output registers.Some additional internal registers store cryptographic key material (Reg a i ) or random numbers (Reg r i ) and cannot be accessed from outside the CPM.

bigINTmul.
A dedicated integer unit performing y = a•b+c on large operands is included in the CPM.Input to the multiplier are two operands a and b.The result p = a • b and operand c are then input to an adder stage calculating y = p+ c.A sequential multiplier as depicted in Figure 5 is provided to execute a naive shift&add algorithm.p is accumulated by bitwise shifting of the bigger operand b, evaluating the least significant bit and adding a to the intermediate result if b 0 = 1, and then shifting p.If b 0 = 0, p is shifted without adding a.
In our use case, the two operands do not have the same bitlength since one input is the platforms secret key a i and the other input is the challenge e.

HECC Processing Unit.
The HECC Processing Unit (HPU) acts as a stand alone module for scalar multiplication X i = r i • P i on a hyper elliptic curve.It comprises a dedicated arithmetic logical unit dALU for finite field arithmetic (GF-operations), internal memory DataMem for storage of intermediate values such as curve parameters and points P i , and a control entity HECC CTRL connected to a program memory pMEM.
HECC CTRL in conjunction with pMEM implements the control flow of a dedicated algorithm for a scalar multiplication as a fixed sequence of GF-operations.The control flow is strongly optimized to execute a scalar multiplication in wMOF [21,22].To execute it, a highly specialized instruction set is implemented.An example of such an instruction is shiftl 2 which shifts the content of the accumulator 2 bits to the left, an operation essential in wMOF [22].The full instruction sequence of wMOF is stored in pMEM.
HPU is laid out as accumulator machine with harvard architecture.This enables to implement different data widths for DataMem and pMEM individually.This is particularly advantageous as we operate on galois fields GF(2 n ), n being a big prime number, resulting in data words of n-bit length being stored in DataMem, while pMEM only stores minimal instruction codes.
Input to the HECC processing unit is a scalar r i (bitlength of r i ≤ l) that is written into a dedicated register rREG of length l.Point P i is a predetermined common point on a hyperelliptic curve and acts as a constant input decided upon during design time.Therefore, it is permanently stored in DataMem together with other curve parameters.On galois fields of genus 2, addition and subtraction can be implemented very efficiently by a bitwise XOR of the two operands u and v. Modular multiplication can be implemented as shown in Algorithm 1.It is performed as a Shift&Add algorithm with modular reduction in every step by adding the irreducible polynomial P(x) if the intermediate result T(x) exceeds the field size of GF(2 n ).A single GFmultiplication U • V mod P will take n clock cycles since the size of the input word U is n-bit and U is examined bitwise (line 2-7 in Algorithm 1).
To speed up the multiplication a scalable GF-Multiplier (MALU) is integrated into the HPU.Instead of examining U a single bit at a time, a number d of neighboring bits in U are evaluated blockwise and in parallel.Algorithm 2 shows how d adder stages with modular reduction are fed with the operands U and V (line [3][4][5][6].This gives d individual intermediate results T d (x) which are then added and reduced to form the result T(x) (line 6).This addition step is done over d cascading adders, so no additional clock cycle is necessary.The final result of a GF-multiplication is available after (n + d − 1)/d clock cycles.
Speed up of the multiplication is achieved through the parallelization of additions, but hardware area increases as well.No additional instructions in pMEM are necessary, thus keeping this change in algorithm transparent to HECC CTRL.
Although u 2 can be calculated by feeding u into both inputs of MALU, a dedicated HW squarer requires 25% less computation time [23].Because HECADD and HECDBL operations depend heavily on squaring [24], we included a GF-Square module in dALU.

Resource Usage and Timing Results
. Table 1 gives a detailed view of the size of our system, and Table 2 shows the processing speed.To the best of our knowledge, no measurements of the execution time of Schnorr-and Okamoto-Authentication protocols based on HECC in the domain of Algorithm 1: GF multiplication of U • V mod P by adding n times.
embedded systems has been published.Because of this, we use the execution time of one scalar multiplication k • P as a benchmark in Table 3 to give a fair comparison of our architecture to other implementations.
As shown in Table 1, the deviation in size of the platform synthesized for executing a single scalar multiplication and the platform synthesized for execution two of this operation is less than 10%.The increase lies in the Cryptographic Processing Module (CPM) due to the increase in memory needed.An additional secret key a 2 , as well as an additional random number r 2 , needs to be stored, thus adding two registers.Also a 2nd memory page is needed, reflecting directly in the doubled number of BRAMs.These in turn require some additional slices for glue logic and enlarged multiplexers.
In a prototypical setup both the Schnorr-and Okamoto authentication protocols have been implemented.Table 2 shows that for both variants our architecture easily beats the real-time constraint of 180 ms, which is the average human reaction time [25].
When comparing our architecture with others (see Table 3), we compute a single k • P in roughly 8 ms.This is more than twice as fast as the platform no. 3 and no. 4. It also outperforms platform no. 1 which is one of the first full hardware implementations of a HECC scalar multiplication.

Pairing of Verifier/Prover Devices
With introduction of public-key-cryptography to automotive access control systems is advantageous for logistics.Less secret key material has to be handled.When integrating an authentication protocol such as Schnorr [5], no secret key resides in a vehicle (Í )-it only needs to be stored in the vehicle's transponder key token (ÌÊÃ).Pairing of the two is done by storing a transponders public key in Í .In this paper, we mainly focus on this key flashing procedure for automotive entities and especially introduction of key material into Í during it's lifetime in the field.
Every Í has a number of public keys of transponders securely stored, thus establishing a "guest list" of legal ÌÊÃs.
During production, at least two initial public keys of ÌÊÃs are written to the user device.This ensures that upon loss of one of the transponders, the remaining can be used to authenticate the owner.This initial operation certainly has to be secured against attacks to ensure that the "guest list" is not altered maliciously, otherwise illegal access to a Í might be granted.
As mentioned above, it is necessary to pair ÌÊÃs with a Í .This is achieved by flashing the public key of ÌÊÃ into the user device, where the key is stored securely and is protected against unauthorized alteration.A number of initial ÌÊÃs are paired during production in a secured environment by the Ç Å.Today pairing ÌÊÃ to Í is done by introducing some kind of key material into Í , thus authorizing this token to use Í .Today's procedures either demand a live online connection to Ç Å or accept new ÌÊÃs if a "master" token (ÅÌÊÃ) is presented to the device [28,29].This means that such Í specific ÅÌÊÃ have to be stored very securely by ËÈ and Ç Å has to fully entrust ËÈ to do so.At the same time, there is no way to prevent ÌÊÃs to be flashed into a Í .Therefore, they have to be kept in secure, physical storage as well.
When employing asymmetric codes, these drawbacks are inexistent.Pairing procedures in this case depend mostly on a trusted third party (TTP) that generates key pairs and distributes them to the different entities.Because not only public key material is transferred but also secret key material this demands for fully encrypted end-to-end communication channels.Traditionally, this is done by establishing a mutual secret key between the two communication partners (i.e., via Diffie-Hellman key exchange [14]) and using symmetric ciphers to encrypt all data over the communication channel.
In our application scenario, we have the following main participants: (i) a user device Í that may only be accessed or used by an authenticated user, (ii) a human user ÇÏAE and he is authorized to access or use Í if he possesses a legitimate token, (iii) a transponder key token ÌÊÃ orig originally linked to Í and a second token ÌÊÃ new that shall be flashed to Í additionally, (iv) the manufacturer Ç Å that produces Í .Í accepts a number of ÌÊÃ to identify an authenticated user ÇÏAE of the Í .At least, two tokens are linked to a Í by storing the respective public keys ÎÃ TRK inside the Í .The Ç Å is initially the only entity allowed to write public keys into any Í .
Solely, the public keys stored inside the Í shall be used for any authorization check of ÌÊÃs.The Ç Å's public key ÎÃ OEM is stored in the Í as well.
Ç Å, ÌÊÃ, and Í can communicate over any insecure medium, through defined communication interfaces.

Goals and Security Requirements. A new transponder
ÌÊÃ new should be linked to Í to substitute an original token ÌÊÃ orig that has been lost or is defective.In the following, we will call the process of linking ÌÊÃ new to an Í flashing.
Introduction of a ÌÊÃ should be possible anytime in the complete life cycle of the Í .When flashing the Í it is probably nowhere near the Ç Å's location while introducing a ÌÊÃ needs to be explicitly authorized by the Ç Å.Also should any ÌÊÃ only be flashable into a single Í .Theft or unauthorized use of the Í resulting from improper pairing of a ÌÊÃ needs to be prohibited.In addition, we demand that online connection of Í and Ç Å during the pairing procedure must not be imperative.In summary, the protocol shall allow dependable authorized flashing under minimal assumptions while preventing unauthorized flashing reliably.Therefore, it has to guarantee the following properties, while assuming communication over an unsecured open channel.
(i) Correctness.In absence of an adversary, the protocol has to deliver the desired result, that is, after complete execution of the protocol, the flashing should be accomplished.
(ii) Authentication.The flashing should only be feasible if both Ç Å and ÇÏAE have been authenticated and have authorized the operation.
(iii) No online dependency.The protocol shall not rely on any live online connection to the Ç Å.
(iv) Secrecy.No confidential data like secret keys should be retrievable by an adversary.A has access to all inter device communications, meaning he can eavesdrop, delete, delay, alter, replay, or insert any messages.We assume further that the adversary is attacking on software level without tampering with the participating devices.Without choosing particular instances of the cryptographic primitives, we assume that the signature scheme used is secure against existential forgery of signatures and regard the cryptographic hash function used as a random oracle.

Key Flashing Definitions and Requirements
The objective of the proposed key flashing protocol is the introduction of a public key ÎÃ ÌÊÃ into Í .Main focus of it is the security aspect of the protocol itself, while it shall be usable under real world constraints as well.The protocol shall ensure the legitimacy of all entities involved as well as the security of the protocol itself to prevent misuse by a malicious attacker.Only after a correct, complete and successful flashing procedure, a new public key may be accepted and stored inside Í .If any error occurs during the flashing procedure, all previous steps in the protocol have to be revoked.All data resulting from these steps shall carry no information that can be exploited by an attacker.
Since ÌÊÃs gain their relevance only after successfully linking them to Í , they shall have no utility value before a successful key flashing procedure.This enables holding numerous ÌÊÃs in stock without an inherent need to restrict access to unflashed ÌÊÃs.
Two basic flashing scenarios are conceivable.One is that ÌÊÃs are flashed directly by the Ç Å, either during production or via an online connection as is addressed in Section 7. The second scenario is the flashing of ÌÊÃs through an authorized service point (ËÈ) with no immediate online connection to the Ç Å (see Section 8).
6.1.Notations.For presentation of the protocols, we abstract from the specific algorithms and use abstract cryptographic primitives instead.Therefore, we introduce some assumptions, definitions, and notations.
Let H be a collision resistant cryptographic hash function of length k that maps any input of arbitrary bit length to an output of fixed bit length k.Application of H can be seen as taking a fingerprint of the input and is often used by signature systems.Nevertheless, our notion of a signature system given in Definition 1, abstracts from any implicitly used hash function.
Definition 1 (signature system).Let Σ 1 , Σ 2 be finite alphabets.A signature system SigSys is a 7-tuple  ( To ease readability and presentation, we introduce a shortened notation.We define the signed message as the message M together with the respective signature.Let SM be the set of all signed messages.In the following, we use an extended signature function and the respective extended verification function For a tuple (M, S ), where either the signature or the message is altered, we define Furthermore, the tuple (SK X , VK X ) ∈ K denotes the key pair of entity X.

Entities. In addition to the entities introduced in
Section 5 (Í , ÇÏAE, ÌÊÃ, and Ç Å), we use three additional participants, namely the transponder manufacturer ÌÊÃÅ, a service point ËÈ and an employee ËÈ of this service point conducting the flashing procedure.In the following, an overview of the entities involved as well as their required properties and abilities is given.Í , ÌÊÃ new , and ËÈ are under control of ËÈ , and the communication links to Í , ÌÊÃ orig , ÌÊÃ new , ËÈ, and Ç Å can be eavesdropped, but the trusted module cannot be penetrated.

Flashing Policies.
In order to meet the goals defined in Section 5, some additional requirements must be met as follows: (1) legitimation of the flashing procedure by ÇÏAE, (2) legitimation of ÌÊÃ new by a certified ÌÊÃÅ, (3) only an Ç Å-authorized ÌÊÃ may be flashed, (4) any single ÌÊÃ may only be flashed into a single Í .Legitimation of a flashing procedure is achieved if the legal owner of ÇÏAE has commissioned and approved a flashing procedure.Legal ownership of a Í is proven by ÇÏAE through possession of a valid ÌÊÃ that is already activated in Í .If no such ÌÊÃ is available, legal documents proving the ownership have to be presented to Ç Å.Such a document could be a deed of ownership, for example.If ÇÏAE cannot prove his legal ownership, it is mandatory to prohibit flashing in order to prevent usage of an illegally acquired Í with an unauthorized ÌÊÃ.
Legitimation of ÌÊÃ is first achieved by adhering to all manufacturing policies posed by Ç Å.This is guaranteed by ÌÊÃÅ which in turn certifies the manufactured ÌÊÃs by signing their respective public keys ÎÃ ÌÊÃ .A main requirement for a legitimate ÌÊÃ is its uniqueness and International Journal of Reconfigurable Computing accordingly the uniqueness of its cryptographic key material.
Otherwise two identical ÌÊÃs, linked to two separate Í s would automatically be able to access both Í s.Additionally it has to be ensured and guaranteed that no secret key material of ÌÊÃ is available to any entity other than to ÌÊÃ itself.
Authorization of a legitimate ÌÊÃ to be flashed is handled through Ç Å. Ç Å verifies the identity of each individual ÌÊÃ to be flashed.Identification of a ÌÊÃ can be achieved directly via checking ÎÃ ÌÊÃ .The identities are then stored by Ç Å.Only ÌÊÃs that have their identities checked and stored this way are considered to be authorized by Ç Å. Prove of authorization can be given by Ç Å through a signature Ë Ç Å (VK ÌÊÃ ).

Key Flashing Protocol without Mediator
The most direct flashing scenario is depicted in Figure 7, where the key flashing into a Í is done directly through the Ç Å.This scenario is valid during production of the Í or if the ÇÏAE is not able to legitimize the procedure through the possession of a second ÌÊÃ as is needed in the standard flashing scenario as described later in Section 8. Therefore the legitimation of the flashing procedure is done implicitly through the Ç Å by checking the legal credentials of ÇÏAE (i.e., billing receipts, legal records, etc.).Only if sufficient proof of ownership is presented to the Ç Å, the flashing procedure is carried out.
The following entities are involved in the key flashing protocol: (i) manufacturer Ç Å, (ii) user device Í , (iii) transponder ÌÊÃ new .
As shown in Algorithm 3, the direct flashing has two requirements.It is mandatory that Í has stored an immutable ÎÃ Ç Å .This enables Í to verify the correctness of the Ç Å's signature later in the flashing protocol.A mandatory requirement for carrying out the flashing procedure is that the Ç Å has verified that the commissioning of the flashing procedure has been done by the legal owner of Í .
In a first step, Ç Å reads out the public key of the ÌÊÃ to be flashed (ÌÊÃ Bob ).The manufacturer ÌÊÃÅ of ÌÊÃ Bob has certified the key by signing it (Ë SKÌÊÃÅ (VK ÌÊÃnew )).The Ç Å then checks if ÌÊÃÅ has fulfilled all legal obligations to be considered as a trusted manufacturer.If this is the case, the Ç Å checks if VK ÌÊÃnew is already stored in its internal database and if it has been already flashed to a Í or not.Only if VK ÌÊÃnew is a fresh key, it is stored in the Ç Å's database and the protocol is continued.
The second step consists of the Ç Å triggering the start of the flashing procedure.Í authenticates the Ç Å by means of an appropriate public key authentication protocol, referring to the internally stored VK Ç Å .The protocol can only be passed successfully by the Ç Å since knowledge of the signing key SK Ç Å is mandatory for the entity being authenticated.Subsequently, Í sends its self-signed verification key Ë SKÍ (VK Í ) to the Ç Å.
The signature is then verified by the Ç Å in order to ensure that the transmitted verification key VK Í has not been tampered with.Subsequently, the Ç Å binds VK ÌÊÃnew to VK Í by composing an adequate data packet and signing it as a whole.This is then transmitted back to Í (Step 4 in Algorithm 3 ).
Í verifies the correctness of the packet by checking the Ç Å's signature in Step 5.After that, Í verifies the correct binding of data packet to its own identity by inspecting the VK Í including the data packet received.Only if the received VK Í is identical to his own verification key VK Í , Í will accept VK ÌÊÃnew included in the received data packet as a valid, legitimate, and authorized transponder key to be flashed.Í stores VK ÌÊÃnew into internal protected memory and sends an acknowledge message back to the Ç Å. Storing VK ÌÊÃnew in Í turns ÌÊÃ new into an activated transponder VK ÌÊÃorig linked to Í .Ç Å logs the successful conclusion of the protocol and annotates the VK ÌÊÃnew (now VK ÌÊÃorig ) accordingly to exempt it from future flashing attempts.

Key Flashing Protocol with Mediator
The procedure as outlined in Section 7 demands a live online connection of Í to Ç Å.To fully comply with the flashing requirements introduced in Section 6, this online connection shall not be mandatory for the complete protocol.Therefore, an additional entity is introduced, a trusted Service Point ËÈ that substitutes for the Ç Å in the field for introducing a new ÎÃ ÌÊÃ into a Í when no direct online connection to Ç Å is possible.The mediator and its properties are detailed in Section 8.1.The flashing procedure including a mediator comprises the following steps (see also Figure 8 ): (i) delegation of trust to ËÈ, (ii) authorization of ÌÊÃ new by Ç Å, (iii) introducing an authorized ÌÊÃ new into an Í .The first two steps form an initialization phase to enable an ËÈ to substitute for the Ç Å while flashing a new ÌÊÃ into a Í .This two-step initialization will be detailed in Section 8.3.
These steps form the first phase of the flashing process and can be done in advance without Í and ÇÏAE but need a communication link to Ç Å.
The last of the three steps, the actual flashing process of a new ÎÃ ÌÊÃ into an Í , do no longer depend on any direct interaction with Ç Å.Details will be given in Section 8.4.

Mediator.
Because a mediator has to partly replace the Ç Å during the flashing protocol and Í only allows ÌÊÃs to be flashed through a trustworthy source-namely the Ç Åthe mediator has to be enabled to act as a trustworthy entity [30].For this, the Ç Å has to delegate trust to a ËÈ, in order to enable Í to entrust ËÈ enough to accept a flashing request from it.It has to be ensured that the security of the overall flashing protocol is not weakened.Every mediator (ËÈ) is evaluated by the Ç Å for its trustworthiness.Assessment factors can also include nontechnical aspects such as political and cultural environment, legal issues, or business models.Í sends Ë SKÍ (VK Í ) to Ç Å.
Step 6: Í verifies that VK Í != VK Í .Then the new transponder ÌÊÃ new can be activated.The protocol is completed by sending a DONE-message to Ç Å.Based on this evaluation, trust credentials (see Section 8.2) are issued to each individual ËÈ.
To restrict access to the flashing capability of ËÈ, as might be necessary in order to comply with the flashing policies of Ç Å a separate authentication of employees (ËÈ ) working at ËÈ is suggested.Such authorization of ËÈ can be done, for example, via a password (knowledge) or by biometrical identification (physical property).

Service Point as Trusted
Platform.An ËÈ constitutes a trusted platform as defined in [30] meaning that ËÈ always acts as specified at any point in the protocol.At the same time, it needs to act reliably in order to enforce trust policies.
Typically, an ËÈ might reside in a hostile environment and can be accessible to malicious attackers.Therefore, some minimal functionalities of ËÈ must be inherently secure and are encapsulated in a Trusted Zone (see Figure 9 ) as follows: (i) generation of trust key pairs, (ii) storage of private keys (SK TD ËÈ and SK ËÈ ), (iii) signature generation, (iv) enforcement of Trust Policy.
For all key pairs that are generated to be used as temporary trust keys, it has to be ensured that a SK TD  ËÈ is never communicated to another entity.Also, it has to be ensured that SK TD  ËÈ cannot be deducted from VK TD ËÈ .This can be ensured with a proper key generation algorithm.Signing of messages has to be secure in order to prevent manipulation of signed data packets.This means that any signing operation is always done with the proper signing key residing in ËÈ.
The main point of the trusted platform is the enforcement of trust policies.ËÈ is issued a temporal trust key pair (SK TD  ËÈ , VK TD ËÈ ) as will be described in Section 8.3.This key pair expires after a timepoint T or after a certain amount of flashing procedures N .Expiration is enforced from within the Trusted Zone with a secure unforgeable counter that is keeping track of the number of flashing cycles.As soon as the counter value reaches N , the trust key pair is fully deleted and the counter is reset.ËÈ also compares its system  time T ËÈ to T. If T ËÈ ≥ T the trust key pair is also fully deleted.

Trust Delegation and TRK new Authorization.
To be able to perform a key flashing procedure without an active link to Ç Å, a local representative has to be empowered by the Ç Å to perform the flashing, assuming that Í trusts only the Ç Å to flash legit keys.This is done by presenting a credential to Í accounting that flashing is authorized by Ç Å. ËÈ , VK TD ËÈ ) and sends its ID together with the created verification key VK TD  ËÈ as a signed request [Ë SKËÈ (VK TD ËÈ ), VK ËÈ ] for a trust credential to Ç Å.
Step I.3: Ç Å verifies that ËÈ and the respective verification key VK ËÈ is listed in the internal database of trusted mediators and that V(Ë SKËÈ (VK TD ËÈ ), VK ËÈ ) ! = 1.In this case Ç Å creates a trust delegation credential Ë SKÇ Å (VK TD ËÈ , VK ËÈ , T, N) bound to ËÈ with timestamp T and number of granted transactions N and sends it to ËÈ.
Step I.4: ËÈ receives Ë SKÇ Å (VK ËÈ , VK TD ËÈ , T, N) and stores it in the trusted storage.This step completes the trust delegation for flashing.
This step completes the activation of the transponder ÌÊÃ new for flashing over ËÈ.
Algorithm 4: Initialization step for mediated key flashing.
to prevent ËÈ abusive operations.Afterwards, ËÈ can connect to Ç Å and request a trust credential (Step I.1).
A trust credential consists of a cryptographic temporal trust key pair (SK TD ËÈ , VK TD ËÈ ) with the public key VK TD ËÈ being signed by Ç Å.Therefore, ËÈ creates a fresh trust key pair.From this pair, ËÈ sends the fresh verification key VK TD

ËÈ
as well as its ID as a signed data packet to the Ç Å, while the secret key SK TD ËÈ never leaves ËÈ.The ID is the standard verification key VK ËÈ of the service point (see Algorithm 4 Step I.2).For ease of implementation, this can be replaced with a unique identifier that can then be matched by the Ç Å to the appropriate VK ËÈ stored in an internal database.
Using VK ËÈ Ç Å verifies the correctness of the data packet received.If ËÈ is considered a trustworthy entity, that is, if it adheres to all of Ç Ås policies, Ç Å issues a trust credential.As shown in Step I.3 (Algorithm 4) it comprises the verification key of the trust key pair, the standard verification key (VK ËÈ ) of ËÈ, as well as a timestamp T, and a maximum transaction number N in an Ç Å signed packet.Through inclusion of VK ËÈ , Ç Å binds the trust key VK TD ËÈ to ËÈ.Later, this binding will be verified by Í (see Section 8.4).A trust key pair is only valid for a limited time and limited number of flashing operations after which it is deleted by ËÈ.
Step I.4 concludes the trust delegation phase with ËÈ storing the Ç Å-signed packet in trusted storage for later use in the actual flashing procedure (Section 8.4).
In order to flash a ÌÊÃ new , the transponder needs to be authorized by Ç Å.The second part (Steps II.1-StepII.3) of the protocol shown in Algorithm 4 accomplishes this for a single ÌÊÃ new .If more than one ÌÊÃ shall be set up for flashing, this part of the protocol is rerun for each additional ÌÊÃ new .ËÈ reads out the verification key of ÌÊÃ that previously has been certified and signed by ÌÊÃÅ.ËÈ send this key as a self-signed message as shown in Step II.1 to Ç Å for authorization.In Step II.2, Ç Å verifies both signatures and ensures that ÌÊÃÅ as well as ËÈ are trusted peers.If this is the case, Ç Å forms a data packet comprising the public key of ÌÊÃ new as well as the standard public key of ËÈ and sends it as a signed message to ËÈ.This message effectively binds ÌÊÃ new to ËÈ, thus enabling solely ËÈ to flash ÌÊÃ new into Í later on.The second part of the protocol in Algorithm 4 is finalized in Step II.3 by ËÈ storing the received, signed message in its trusted module.
Only a limited number of authorized ÌÊÃs can be stored at any given point in time.As soon as a ÌÊÃ has been authorized by the Ç Å, physical access to the ÌÊÃ needs to be controlled.The authorization process of ÌÊÃs is the only step that demands a data connection between ËÈ and Ç Å.
This does not necessarily need to be an online connection since data could also be transported via data carriers such as CDs, memory sticks, or the like.

Flashing of ÌÊÃ.
The actual flashing of a ÌÊÃ new to a given Í is shown in Algorithm 5.It demands a valid new transponder ÌÊÃ new and authorization by Ç Å and ÇÏAE.Former either directly or delegated to ËÈ using the credential introduced above, latter done by presenting a valid and linked ÌÊÃ orig assumed to be solely accessible by ÇÏAE.If an online connection to Ç Å is available, the protocol can be performed by Í and Ç Å directly as described in Section 7, with ËÈ only relaying communication.
If ËÈ has to act as an offline mediator, the initialization protocol (Algorithm 4) has had to be successfully completed.From there on, the flashing protocol commences as shown in Algorithm 5 with ËÈ contacting Í and sending the trust credentials that ËÈ has received from Ç Å (Step 1).In Step 2, Requirements (i) The initialization protocol has been completed successfully.
(iii) ËÈ has a valid trust key pair and has not reached the maximum quota N of allowed flashing procedures.
Step 3: ÇÏAE authorizes the start of a key flashing procedure by presenting a valid ÌÊÃ orig .Í authenticates ÌÊÃ orig using the internally stored VK ÌÊÃ orig and a PKC authentication protocol.
Step 5: Then the new transponder ÌÊÃ new can be activated: TRK new → TRK orig .The protocol is completed by sending a DONE-message to ËÈ. Í verifies these credentials using the Ç Å's verification key that is already embedded in Í (Section 6.2.4).The verification key of the trusted key pair VK TD  ËÈ is stored temporarily for use in Step 6.As an acknowledge message, Í sends a self-signed packet to ËÈ that includes its own public key as well as the standard public key of ËÈ.
Since ÇÏAE has to authorize the flashing procedure he presents his credential in form of an original ÌÊÃ orig already linked to Í .Í authenticates ÌÊÃ orig by means of a public key authentication protocol (Step 3).Only if ÌÊÃ orig has been successfully authenticated Í will accept a ÌÊÃ new being flashed into Í .In Step 4, ËÈ sends the authorized data packet for the ÌÊÃ to be flashed that it has received from the Ç Å during the second phase of the initialization procedure (Section 8.3).It is annotated with Í 's public key VK UD and additionally signed by ËÈ using the trust key pair.That way, the ÌÊÃ new is bound to Í .To finalize the protocol, Í enforces the flashing policies in Step 5. First it verifies if the signature of ËÈ is correct and has used the trust key pair.If that is the case, it verifies the correctness of the Ç Å's signature on the data packet for ÌÊÃ new .Since this data packet has been bound to Í , Í verifies if its own public key has been used to annotate VK ÌÊÃ new .Only a correctly annotated VK ÌÊÃnew will be accepted, all others are dismissed and will not be stored into Í .
In the case of successful verification, Í accepts the new token ÌÊÃ new and adds VK ÌÊÃnew to its internal list of linked tokens thus transforming ÌÊÃ new into a ÌÊÃ orig .The correct and full flashing is then reported back to ËÈ.Subsequently, ËÈ will log this as a successful flashing procedure and decrement its internal counter for allowed flashing processes.

Entity Requirements.
Regarding the proposed flashing protocols certain requirements for the entities' functionalities have to be satisfied.An overview is given in Table 4. Data management is one of the key requirements in the protocol in the sense that public key data needs to be stored.Secure  storage for delegated trust has some additional requirements such as intrusion detection to protect data from being altered in any way.At the same time, it is mandatory that this data is always changed correctly as demanded by the protocol.
Also, the Ç Å's public key needs to be firmly embedded into the entities and must not be altered in any way.Otherwise, the Ç Å cannot be identified correctly within the proposed protocols.

Implementation
The protocol has been implemented as a proof of concept in a prototypical setup based on a network of standard PCs representing Ç Å and ËÈ (see Figure 10).Furthermore, Digilent Spartan3E Starter Boards with a Xilinx XC3S500 FPGA represent ÌÊÃs and Í s.ÌÊÃ, ËÈ, and Í have to be connected when flashing the key.The Ç Å connection needs to be established anytime prior to the flashing according to the proposed protocol and is connected via TCP/IP to the ËÈ.All other communication is done over RS232 interfaces that are available both on PC and the FPGA boards.These can be substituted for other communication structures if needed, that is, wireless transmitters.9.1.Choice of Cryptographic Primitives.The proposed key flashing concept demands asymmetric encryption and a cryptographic hash function.RSA [31] is chosen for encryption and signing, SHA1 [32] for hash functionality.Both schemes are today's standard and have not been broken yet, but can be substituted in our implementation for more secure schemes such as HECC if needed.RSA as well as SHA1 implementations are freely available as software and hardware modules for numerous platforms.RSA parameters used in the prototype are given in Table 5.
All signatures in our context are SHA1-hash values of data that has been encrypted according to the signing scheme PKCS#1 v1.5 [33].Such a signature has a length of 128 Byte when using a key length of 1024 bit and hash values of 160 bit length.It also includes the ÖÝÔØÓ Ö Ô Ý-namespace providing all needed cryptographic primitives including hash functions and a random number generator that are based on the FIPS-140-1 [35] certified Windows CryptoAPI.The software is modularized to enable easy exchange of functional blocks and seamless replacement of algorithms.Software modules communicate only over defined interfaces to enable full functional encapsulation.For ease of usage, a graphical user interface (GUI) is included as well in both entities.9.3.Transponder/UserDevice-FPGA platform.The targeted user device is an FPGA.To ease reuse of functionalities the exemplary ÌÊÃ has been implemented on FPGA as well, but can also be integrated into a smart card or RFID chip as long as the appropriate cryptographic primitives are provided.
In the prototypical setup, we used a MicroBlaze-based ECU (see Figure 3) for both Í and ÌÊÃ.We omitted the coprocessor and implemented all functionality on the MicroBlaze including cryptographic functions.Hardware peripherals such as an LCD controller have been integrated for debugging purposes.To enable handling of big numbers, as are used in the cryptographic functions of the protocol, the libraries Ð ØÓÑÑ Ø [36] and Ð ØÓÑ ÖÝÔØ [37] are used.
Only necessary components have been extracted from those libraries and are integrated into ÌÊÃ and Í .Resource usage of the FPGA-based components Í and ÌÊÃ are given in Table 7.By implementing all functionality on a MicroBlaze softcore, the hardware usage is quite moderate.On the other hand, the software footprint is 295 KB for the Í implementation, due to the nonoptimized memory usage of the crypto library.
Shown in Table 8 are the execution times of the diverse protocol instances.The duration of parts of the protocol that are based solely on Ç Å and ËÈ is in the area of few milliseconds.As soon as mobile devices (Í , ÌÊÃ) process parts of the protocol, speed is declining since all crypto operations are currently carried out on an embedded microcontroller.Main factor here is the RSA decryption operation.With appropriate hardware support, choice of parameters, cryptosystem, and substantial speedups can be achieved as shown in [16].

Security Analysis
Looking at the security of the proposed concept some points can be identified where security relies on policies and implementing rules while other issues are covered by design.
Using PKC primitives and trusted computing approaches, the protocol ensures confidentiality of secret keys and mutual authentication of ËÈ and Ç Å, ÇÏAE and Í , ËÈ and Í , ËÈ, and ËÈ .Due to the necessity of online independence, there are some assumptions that have to be made to guarantee security.This is mainly the trustworthiness of the ËÈ in combination with the physical protection of any authorized ÌÊÃ new and all ÌÊÃ orig .If these assumptions are broken, for example, by theft of authorized ÌÊÃ, the corresponding ËÈ and the ËÈ password, unauthorized flashing may be possible.As countermeasures, the usage of the protocol can be adapted to dilute effects of such events.So, the number of allowed authorized ÌÊÃ should be as low as possible and the ËÈ should be implemented using trusted components and based on a trusted platform.Secrets should be especially protected against misuse by a physical attacker.
There certainly is a tradeoff between security and usability of the flashing scheme, since the protocol has been designed for real-world implementation.
10.1.Security of Direct Flashing Scenario.In the flashing scenario with no mediator (Section 7), an illegal flashing of ÌÊÃ is not possible.The flashing procedure is authorized through the Ç Å directly.Only the Ç Å is considered trustworthy enough to accept flashing commands from.By verifying the signature on a ÌÊÃ's key, it can be checked if a certain ÌÊÃ has been manufactured by a certified supplier ÌÊÃÅ or not.Certification policy ensures that such a ÌÊÃ has a unique ID, unique cryptographic keys, and secret key material is solely known to the ÌÊÃ itself and is nowhere else available or reproducible.
Verifying the signature of Í and the mutual authentication phase of Ç Å and Í , Ç Å can be sure that a Í is targeted in the flashing procedure that has been manufactured by Ç Å.In turn, Í can be sure that its communication partner is the Ç Å.
Binding the key material to be flashed to a dedicated Í by incorporating a mutual signature of the key material enforces that a certain transponder is flashed only into a single Í .Also, it can be enforced that the packet containing the VK TRK is only used for a single flashing procedure, thus countermeasuring replay attacks.Neither unrecognized mutation of dedicated parts of this communication packet is possible, nor forging the signatures on data, due to the security assumptions of the cryptographic primitives.No confidential information is included in any communication packet.By activating the VK TRK inside the Í only after a successful transmission without errors, it is ensured that the ÌÊÃ has no previous utility value.Readingout the ÌÊÃ's VK ÌÊÃ has no benefit to an attacker.Therefore, a ÌÊÃ has not to be stored away safely before linking it to a Í .Loss of an unlinked ÌÊÃ does also not lead to any security issues.
If all entities involved in the flashing procedure adhere to the protocol, abolish all data resulting from a disrupted flashing procedure, and implement all cryptographic primitives securely, an attacker is not able to carry out an illegal flashing procedure.

Security of Mediator Flashing Scenario.
In the flashing scenario involving a mediator as described in Section 8, the flashing procedure is legitimated through ÇÏAE directly by presenting a second ÌÊÃ that is already linked to Í during the last phase of the flashing process.A Í receiving the final communication packet carrying the VK TRK to be flashed can verify if the sender of the packet is legit and trustworthy by checking the signatures of the Ç Å as well as checking the trust credentials of the ËÈ.Therefore, the Í directly enforces the policy that only certified parties may flash a VK TRK by dismissing any received VK TRK as soon as a invalid signature is detected.
Usage of ËÈ through a ËÈ is restricted and protected by appropriate access control, so no malicious outsider can flash a VK TRK .Since trust has to be redelegated after a certain time or amount of flashing procedures, it is not possible to haphazardly flash ÌÊÃs.
No sensitive data is transmitted during the flashing protocol that might compromise the system's security.It seems that the data packet sent by Ç Å to ËÈ might be highly sensitive, but even if an attacker were able to access the keypair forming the delegation of trust, it would not be possible to authenticate new ÌÊÃ's with the Ç Å since this demands knowledge of SK SP known only to ËÈ itself.ÌÊÃ's already authenticated by the Ç Å can also not be flashed into a Í , since it will be impossible for an attacker to correctly sign the data packet containing the ÌÊÃ's public key, because the signing key SK TD ËÈ is also known solely by ËÈ.
In this second flashing scenario, it is again ensured that the ÌÊÃ has no previous utility value before finally linking it to a Í in the final step of the protocol.The loss of of an unlinked ÌÊÃ does not lead to any security issues as long as it has not been authorized by the Ç Å. Therefore all unauthorized ÌÊÃ do not pose a security risk.Authorized ÌÊÃs do need to be stored away securely since they can be flashed into a Í , but only with the ËÈ that is linked to the ÌÊÃ.As before, no attacker may be able to carry out an illegal flashing procedure as long as all entities involved in the flashing procedure adhere to the protocol, abolish all data resulting from a disrupted flashing procedure, and implement all cryptographic primitives securely.

Potential Risks.
Although the technical aspects of the flashing protocols can be secured against manipulation and tampering, there are still some risks involved resulting from nontechnical aspects.A malicious insider such as a ËÈ might be able to gain access to the ËÈ, an authenticated ÌÊÃ new as well as a Í and the corresponding ÌÊÃ orig .Only if ËÈ has access to all aforementioned entities, then it is possible for him to flash ÌÊÃ new into Í , unknown to the legal owner ÇÏAE.Although such malicious misbehavior of ËÈ cannot be prohibited, it can at least be traced by logging all activity inside the ËÈ.
A similar risk is faulty implementations of security primitives that are used in the protocol leading to a leak of secret cryptographic keys, thus enabling an attacker to impersonate an entity.The two main concerns regarding security leaks lie in the nontechnical aspects of the flashing protocol through mediators.10.3.1.Social Engineering.Since the flashing of keys involves human interaction, this can offer an entry point for an attacker using social engineering [38][39][40].A conceivable entry point is the ËÈ .If an attacker is able to extract the credentials from ËÈ , he can gain access to ËÈ and therefore flash ÌÊÃs into any user device of Ç Å.This is a widely known issue in security systems in general that can only be countermeasured by proper training of ËÈ to enhance security awareness.Any misuse of the system through an ËÈ can be tracked if a secure log of all activities is provided within the trusted part of ËÈ.As soon as misuse is detected, the trust delegation to ËÈ can be revoked by Ç Å through not reissuing a trust keypair.Therefore, damage can be limited to flashing of the ÌÊÃ new already prepared for introduction into a Í .
Since the flashing scheme demands for authentication of the procedure through ÇÏAE, it is necessary to ensure the security of the second ÌÊÃ orig to be presented at the final stage of the process.If the second ÌÊÃ orig is in possession of an attacker and additionally the attacker has access to ËÈ, he is able to flash an additional ÌÊÃ into one Í .This attack is limited to a single Í , thus representing a fairly small risk, which on the other hand can easily be countermeasured.

SP Theft Scenario.
If an ËÈ carrying a valid trust key falls into the hands of a malicious attacker, the credential of ËÈ must also be known to the attacker in order to use ËÈ to flash ÌÊÃs.Additionally, it is mandatory that the attacker also has a ÌÊÃ new in his possession that has already been certified by Ç Å.Additionally, ÌÊÃ new has to be bound to the stolen ËÈ.If no such ÌÊÃ new is available, the system is not compromised.Even in case of such an aggressive attack the risk to the overall system is minimized, since only a very limited number of ÌÊÃs is flashable and a trust revocation can be carried out.
The risk level for such a scenario can be adapted through appropriate policies based on risk assessment through Ç Å.
The most aggressive policy is not to allow flashing through a mediator.A minimal risk policy is to only have a single ÌÊÃ on location that can be flashed into a Í .Only after it has been flashed successfully, does the Ç Å authenticate another ÌÊÃ.While providing higher security, such restrictive policies will naturally inhibit usability.

Conclusions and Future Work
Access control systems are an important part in many systems such as vehicles or expensive machinery.Authentication protocols based on Public Key Cryptography offer advantages in logistics and key handling.These protocols are computationally very expensive but can be accelerated in hardware.In this paper, we presented a high-speed crypto architecture based on FPGA for fast authentication protocols based on HECC.Exploiting the properties of PKC, we introduced a scheme for pairing user devices (Í ) and transponder tokens (ÌÊÃ) by flashing public keys into Í .
Compared to current key flashing procedures, our proposed protocol eliminates some logistic issues.ÌÊÃs do not have to be physically stored securely in ËÈ any more.Also, shipment of ÌÊÃs does not have to be secured physically.Today Ç Å has to fully trust an ËÈ to flash ÌÊÃs in the field.With our protocol the amount of trust in an ËÈ can now be reduced to allow for risk management.Security of the system is guaranteed by appropriate policy enforcement and usage of secure cryptographic primitives.No online connection is mandatory for linking a new transponder (ÌÊÃ) for user authentication to a user device (Í ).This makes it very practical for scenarios if ÌÊÃ's have International Journal of Reconfigurable Computing to be replaced in the field with no intact communication infrastructure.It is applicable for a variety of embedded systems that need to implement and enforce access or usage restrictions in the field.We have shown the portability of the concept to non-FPGA platforms by implementing the protocol as a proof-of-concept using a combination of PCbased and FGPA-based protocol participants.
Flashing speed is of utmost importance in real-world implementation.To make allowance for a real world integration of the proposed flashing schemes, optimization is needed regarding usage and speed of the computational units involved.In the current prototype, the MicroBlaze processor has been used for simplicity and to show that the protocol can already be easily deployed in microprocessor driven embedded system such as the automotive domain.With the coprocessing unit in Section 7, very short computation times are achieved, and on a public key cryptosystem with a high security level than RSA.Adapting this system to the complete flashing scheme is target of future work and promises dramatic acceleration of the entire key flashing procedure.
One crucial point is the protection of the ÌÊÃ's public key stored in the Í against physical attackers.Means to countermeasure attacks that might alter stored keys on a physical level need to be investigated in the future.

Figure 3 :
Figure 3: Overview of the system design.

1 :
Requirements(i) Í has knowledge of VK Ç Å (ii) Ç Å has ensured, that the legal owner ÇÏAE of Í has commissioned the flashing procedure ProtocolStep For a new ÌÊÃ new to be flashed Ç Å reads out the respective certified verification key Ë SKÌÊÃÅ (VK ÌÊÃnew ) and verifies that VK ÌÊÃÅ is in the internal database of trusted transponder manufacturers.Step 2: Ç Å contacts Í and is authenticated using a PKC authentication protocol.

Figure 9 :
Figure 9: Service point as trusted platform.

Algorithm 5 :
Indirect flashing protocol over a trusted mediator (no online connection to Ç Å).

9. 2 .
OEM/Service Point-Software Platform.Both components Ç Å and ËÈ have been implemented on a standard PC in software under the .NET framework version 2.0 [34] using C#.The .NET framework provides the Berkeley Socketinterface for communication over the PC's serial interface.

9. 4 .
Resource Usage.The resource usage of the components Ç Å and ËÈ are very similar, since almost identical functional software blocks are used in both.
• v mod p and u 2 with u, v ∈ GF(2 n ).
SK a nonempty set of signature keys, (4) VK a nonempty set of verification keys, (5) f a bijective function f : SK → VK, mapping each signature key SK ∈ SK on the respective verification key f (SK) = VK ∈ VK, and we define a set K ⊂ SK × VK of key pairs by 2.1.OEM: Manufacturer.The Ç Å manufactures the Í and delivers it to ÇÏAE.ÇÏAE issued the corresponding ÌÊÃs linked to the Í .All Í s are obviously known to the Ç Å.Furthermore, ÌÊÃÅ and all ËÈ and the respective public verification keys are known to the Ç Å.We regard the entity Ç Å as a trusted central server with database functionality.Ç Å can store data, sign data with ËÃ Ç Å , and send data.It possesses all cryptographic abilities for PKC based authentication schemes and can thereby authenticate communication partners.6.2.2.TRK:Transponder.ÌÊÃ possesses a keypair (ÎÃ ÌÊÃ , ËÃ ÌÊÃ ) for PKC functionality.It is generated inside ÌÊÃ to ensure that the secret key ËÃ ÌÊÃ is known solely to ÌÊÃ.Read access to ÎÃ ÌÊÃ is granted to any entity over a communication interface.As ÌÊÃs can be manufactured by a supplier ÌÊÃÅ that has been certified by Ç Å, the ÎÃ ÌÊÃ is signed by ÌÊÃÅ after generation and stored in ÌÊÃ ÌÊÃÅ is a supplier for ÌÊÃs that has been certified by Ç Å and manufactures ÌÊÃs that fulfill Ç Å's requirements.Certification of ÌÊÃÅ is bound to the fulfillment of the conditions of manufacturing, defined by Ç Å and is enforced through appropriate legal contracting.ÌÊÃÅ possesses cryptographic abilities to sign the public key ÎÃ ÌÊÃ of ÌÊÃ.These signed keys act as certificates guaranteeing the origin of the respective ÌÊÃ as well as the compliance of ÌÊÃÅ to all of Ç Å's manufacturing policies.6.2.4.UD: User Device.Í is enabled only when a linkedÌÊÃ is presented by authenticating the ÌÊÃ via a PKC authentication scheme.All linked ÌÊÃs' public keys ÎÃ ÌÊÃ are stored in Í .Additionally, the public key of the Ç Å ÎÃ Ç Å is stored in Í and cannot be erased or altered in any way.Í grants read access to all stored public keys.Write access to the memory location of ÎÃ ÌÊÃ is only granted in the context of the proposed key flashing scheme.Í possesses all crypto-The terminal and access to it is secured by appropriate means as in standard PC practice.ËÈ can communicate to the Ç Å as well as to Í .In addition, it is able to read the ÎÃ ÌÊÃ of any ÌÊÃ.Employee of Service Point.ËÈ is a physical person that is operating ËÈ and has to be authenticated prior to a flashing procedure to prevent misuse of the system.At the same time, ËÈ is regarded as a potential attacker of the flashing operation so that the protocol has to have a certain robustness against a compromised ËÈ .Access control of ËÈ to ËÈ is enforced via password or similar.ËÈ as a certificate.ÌÊÃ possesses cryptographic primitives for PKC-based authentication schemes on prover's side and can thereby be authenticated by communication partners.6.2.3.TRKM: Transponder Manufacturer.6.2.5.OWN: Legal User.ÇÏAE is the legal user of Í and can prove this by possession of a linked ÌÊÃ orig .6.2.6.SP: Service Point.ËÈ is a service point in the field such as a wholesaler or workshop, certified by the Ç Å.For the protocol, ËÈ is considered to be a computer terminal at the respective institution.is responsible for the system setup for the flashing application consisting of establishing the communication links of Í , ËÈ, ÌÊÃ, and Ç Å if needed.
Ç Å has knowledge of VK ËÈ and VK ÌÊÃÅ Protocol Step I.1: ËÈ presents his credential CRED ËÈ and ËÈ authenticates ËÈ .After that ËÈ is activated and communication to Ç Å is enabled.Step I.2: ËÈ creates a new key pair (SK TD The exchange of this credential is denoted in the following as trust delegation.Algorithm 4 shows the protocol for instantiating a mediator that can flash a ÌÊÃ into a Í .Steps I.1 to I.4 detail the trust delegation to ËÈ.First of all, ËÈ is authenticated by ËÈ
Table 6gives an exemplary overview of the lines of code of the Ç Å implementation.The memory footprint of the compiled Ç Å implementation is 129 KB (139 KB for the ËÈ implementation).At start up, 15400 KB of main memory is used.The execution times for RSA-and SHA1-operations were measured on a PC (2 GHz, 1024 MB RAM) and are all in the range of milliseconds.