Mohammad Hassan Habibi
email: mohamad.h.habibi@gmail.com

Mahdi R Alagheband
email: m.alaghband@srbiau.ac.ir

Mohammad Reza Aref
email: aref@sharif.edu

Attacks on a Lightweight Mutual Authentication Protocol Under EPC C-1 G-2 Standard

Keywords: RFID, authentication, EPC C-1 G-2 standard, Security analysis, Traceability attack

have recently proposed a mutual authentication protocol based on EPC Class-1 Gen.-2 standard. They claim their protocol is secure against adversarial attacks and also provides forward secrecy. In this paper we show that the proposed protocol does not have cited security features properly. A powerful and practical attack is presented on this protocol whereby the whole security of the protocol is broken. Furthermore, Yeh et al.'s protocol does not assure the untraceabilitiy and backward untraceabilitiy attributes. We also will propose our revision to safeguard the Yeh et al.'s protocol against cited attacks.

Introduction

Nowadays Radio Frequency Identification (RFID) technology has been incorporated in our daily life and employed in many applications e.g. public transportation passes [1], supply chain management [START_REF]Michelin Embeds RFID Tags in Tires[END_REF], e-passport [START_REF] Hoepman | Crossing borders: Security and privacy issues of the European e-passport. NAME (IWSEC[END_REF] etc. RFID systems include tags, readers and back-end server. The tag is a low cost device with a constraint microchip, small memory and antenna to communicate with the reader. The readers are placed between tags and back-end server as an intermediary for message transmission. Not surprisingly, the back-end server has the whole information and secret values of all tags.

EPC Class-1 Gen.-2 standard is a framework for RFID communications, defined by EPC global (Electronic Product Code) organization [4,[START_REF] Inc | EPCTM Radio-Frequency Identity Protocols Class-1 Generation-2 UHF RFID Protocols for Communications at 860 MHz -960 MHz version 1[END_REF] but RFID authentication protocols based on it have undergone noticeable difficulties to satisfy the perfect security characteristics.

In order to have secure authentication protocols, an adversary should not be able to obtain any information about the target tag. Privacy and untraceability are two important issues relevant to RFID systems. Thus, an authentication protocol should assure the privacy characteristics including untraceability and backward untraceability for tags and their holders [START_REF] Lim | Strong and robust RFID authentication enabling perfect ownership transfer[END_REF]. On the other side, RFID authentication protocols are under different threats, defined as follows.

Information leakage: the tag and reader perform an authentication protocol and exchange some messages with each other. Since the wireless communication channel is insecure, it can be eavesdropped by an adversary. Hence, each authentication protocol should be designed in a way that the adversary, with reasonable computational capabilities, does not be able to exploit the exchanged messages [START_REF] Van Deursen | Attacks on RFID protocols[END_REF].

Tag Tracing and tracking: Tag tracing and tracking are damaging problems in RFID systems. Even when the leakage of information is impossible, the untraceability of tag and its holder is not guaranteed in RFID systems. Untraceability means that if an adversary eavesdrops message transmission between a target tag and a reader at time t, he does not be able to distinguish an interaction of that tag at time t' t [START_REF] Ouafi | Traceable privacy of recent provably-secure RFID protocols[END_REF].

DoS attack: denial-of-Service (DoS) is another attack on RFID systems. An adversary tries to find ways to fail target tag from receiving services, e.g. in the desynchronization attack, as one kind of DoS attacks, the shared secret value between the tag and the back-end server is made inconsistent by an adversary. Then, the tag and back-end server cannot recognize each other in future and tag becomes disabled [START_REF] Peris-Lopez | Vulnerability analysis of RFID protocols for tag ownership transfer[END_REF].

Many RFID authentication protocols have been proposed [START_REF] Chien | Mutual Authentication Protocol for RFID Conforming to EPC Class 1 Generation 2 Standards[END_REF][START_REF] Konidala | A simple and cost-effective RFID tag-reader mutual authentication scheme[END_REF][START_REF] Kulseng | Lightweight mutual authentication and ownership transfer for RFID Systems[END_REF][START_REF] Chien | SASI: A new ultralightweight rfid authentication protocol providing strong authentication and strong integrity[END_REF][START_REF] Song | RFID authentication protocol for low-cost tags[END_REF][START_REF] Duc | Enhancing security of EPCglobal Gen-2 RFID tag against traceability and cloning[END_REF]. Although these protocols tried to provide secure and untraceable communication for RFID systems, however many weaknesses have been found in them [START_REF] Han | Vulnerability of an RFID authentication protocol conforming to EPC Class-1Generation-2 Standards[END_REF][START_REF] Peris-Lopez | Practical attacks on a mutual authentication scheme under the EPC Class-1 Generation-2 standard[END_REF][START_REF] Habibi | Attacks and improvements to a new RFID Authentication protocol[END_REF][START_REF] Phan | Cryptanalysis of a New Ultra lightweight RFID Authentication Protocol -SASI[END_REF][START_REF] Van Deursen | Untraceability of RFID Protocols[END_REF][START_REF] Habibi | Cryptanalysis of two mutual authentication protocols for low-cost RFID[END_REF]. In this context, Yeh et al. have recently proposed a RFID mutual authentication protocol compatible with EPC C-1 G-2 standard [START_REF] Yeh | Securing RFID systems conforming to EPC Class-1 Generation-2 standard[END_REF] that we name SRP (Securing RFID Protocol) in this paper. The authors have claimed that not only SRP does not reveal any information but also it has forward secrecy and robustness against DoS attack. In this paper, we prove that SRP is vulnerable to a powerful and fatal attack that needs only 2 16 off-line PRNG (pseudo random number generator) computations. Furthermore, the whole security of this protocol will be destroyed inasmuch as the RFID system is most vulnerable to tag and reader impersonation, DoS attack, untraceability and backward untraceability. Finally we propose our revision to prevent the mentioned attacks.

Review SRP

Initialization phase

The nine secret values , , , , , , EP , RID and DATA corresponding to each tag is loaded in database. Besides, random values , and are generated by manufacturer and the recorded values are set in a way that = = , = = and = = . Each tag records four values = , = , = and EP .

The (i+1)th Authentication Round

In this part, the SRP protocol is briefly described. The following steps explain the protocol in the round (i+1).

M1=PRNG(EP ⨁ )⨁ , D= ⨁ and E= ⨁PRNG( ⨁ ). Then the tag forwards ( , M1, D, E) to the reader. 3. The reader computes V=H(RID⨁ ) and sends ( ,M1,D,E, V) to the database.

Receives ( , M1, D, E, V ), the database performs the following procedure: a) For each stored RID, computes H(RID⨁ ) and compares it with V to find whether the computed value is equal to V. If it is true, the database will authenticate the reader. b) Based on value , one of the two following procedures is occurred: i.

The database computes PRNG (EP ⨁ ), =M1⨁ and =M1⨁ provided that = 0, because it means the first access. Then it checks whether or correspond to PRNG(EP ⨁ ). This process is regularly repeated until a match equality is founded. X is set to either old or new provided that either or is the match, respectively. ii.

If 0, the database uses as an index to find the corresponding recorded entry. When the database finds an entry correspondent to , then the value of X is determined either old or new provided that or respectively. Corresponding and EP are extracted to check whether PRNG(EP ⨁ )⨁ is equal to M1 or not. The database obtains with the aid of K X and D, and ensures whether ⨁PRNG( ⨁ ) is equal to the received E. and sends M2 to the tag. The tag picks up the stored and computes ⨁M2 to find whether it is equal to PRNG(EP ⨁ ). If the matching is found, the database is authenticated and the tag updates as follows:

=PRNG ( ), =PRNG ( ), =PRNG ( ⨁ ).

Vulnerabilities of SRP

In this section we show the vulnerabilities of SRP. First a practical and powerful attack on SRP is presented. Then, we show that an adversary obtains the most important secret value of a tag which called EP , and show that SRP is vulnerable to tracing attacks. Hence, we show that the SRP does not provide backward untraceability and untraceability.

Reveal EP

Since and are XORed with EP , we can conclude the and bit lengths are the same as EP bit length. Furthermore, , and bit length must be equal to the PRNG bit length inasmuch as they are updated by PRNG. Due to the fact that the EP bit length is very short and fix in all rounds of the SRP, an adversary can exploit this subject to get EP . He just needs to perform two consecutive sessions with the target tag and calculate off-line PRNG computations. The procedure of our attack is explained as follows. 1. The adversary starts a session with the target tag T i in the round (i+1) by sending random number and T i replies with ( , M , ). The adversary reserves M and terminates the session. He performs the second session with T i by transmission of and gets tag's response as ( , M , , ). 2. Since the first session is not completed, T i does not update its secret key for the second session. Hence M and M are constructed as follows: After at most execution of the algorithm, the adversary finds the correct EP . As a result of the above attack, we present three noticeable attacks on SRP including tag impersonation, reader impersonation and DoS attack.

M =PRNG(EP ⨁ ) ⨁ , M =PRNG(EP ⨁ )⨁ . 3. A omits by XORing M and M : M ⨁M =PRNG(EP ⨁ )⨁ ⨁ PRNG(EP ⨁ )⨁ =PRNG(EP ⨁ )⨁PRNG(EP ⨁ )= ,

Tag Impersonation

An adversary simply gets the secret key by a passive attack. Indeed, he listens to the communication channel between the legitimate reader R and the target tag T i in the round (i+1) to obtain and ( , M , , ). Since the adversary has EP , he computes PRNG (EP ⨁

). Thus the secret key is computed as: =M ⨁(EP ⨁

) and =PRNG( ). The random number is computed as: =D⨁ and finally the index for the next session is computed as =PRNG( ⨁ ). Now, the adversary starts a new session with the reader. R sends to him and he replies ( , M , ,

) where M =PRNG(EP ⨁ )⨁ , = ⨁ and = ⨁PRN( ⨁ ). Since these values are correctly computed, the database accepts the adversary and authenticates him.

Reader Impersonation and DoS Attack

SRP is also vulnerable by two other attacks. By revealing EP , the adversary can forge a legitimate reader and then desynchronize the target tag. The procedure of these attacks is explained as follows. 1. The adversary listens to the communication between R and T i in the round (i+1) to obtain , ( , M , ,

)

Privacy Analysis

The authors of SRP have specified that not only their protocol have forward secrecy, but also SRP is resistant to the tracing attacks. We show that SRP does not have forward secrecy and we also present a traceability attack on SRP.

Privacy Model

There are privacy models for the evaluation of RFID protocols [START_REF] Lim | Strong and robust RFID authentication enabling perfect ownership transfer[END_REF][START_REF] Avoine | Adversarial model for radio frequency identification[END_REF][START_REF] Juels | Defining strong privacy for RFID[END_REF][START_REF] Vaudenay | On Privacy Models for RFID[END_REF][START_REF] Ouafi | Privacy of recent RFID authentication protocols[END_REF]. We analyze SRP protocol based on Ouafi and Phan model [START_REF] Ouafi | Privacy of recent RFID authentication protocols[END_REF] which is based on [START_REF] Juels | Defining strong privacy for RFID[END_REF] and [START_REF] Lim | Strong and robust RFID authentication enabling perfect ownership transfer[END_REF]. The model is summarized as follows.

The protocol parties are tags (T) and readers (R) which interact in protocol sessions. In this model an adversary A controls the communication channel between all parties by interacting either passively or actively with them. The adversary A is allowed to run the following queries:  Execute (R, T, i ) query. This query models the passive attacks. The adversary A eavesdrops on the communication channel between T and R and gets read access to the exchanged messages between the parties in session i of a truthful protocol execution.  Send (U, V, m, i ) query. This query models active attacks by allowing the adversary A to impersonate some reader U R (respectively tag V T ) in some protocol session i and send a message m of its choice to an instance of some tag V T (respectively reader U R ). Furthermore the adversary A is allowed to block or alert the message m that is sent from U to V (respectively V to U) in session i of a truthful protocol execution.  Corrupt (T, ) query. This query allows the adversary A to learn the stored secret K of the tag T T, and which further sets the stored secret to . Corrupt query means that the adversary has physical access to the tag, i.e. the adversary can read and tamper with the tag's permanent memory.

 Test (i, T o , T 1 ) query. This query does not correspond to any of A's abilities, but it is necessary to define the untraceability test. When this query is invoked for session i, a random bit b {0, 1} is generated and then, A is given T b {T o , T 1 ).

Informally, A wins if he can guess the bit b.

Untraceable privacy (UPriv) is defined using the game g played between an adversary A and a collection of the reader and the tag instances. The game g is divided into three following phases:  Learning phase: A is given tags T o and T 1 randomly and he is able to send any Execute, Send and Corrupt queries of its choice to T 0 , T 1 and reader.  Challenge phase: A chooses two fresh tags T 0 , T 1 to be tested and sends a Test (i, T o , T 1 ) query. Depending on a randomly chosen bit b {0, 1}, A is given a tag T b from the set {T 0 , T 1 }.A continues making any Execute, and Send queries at will.  Guess phase: finally, A terminates the game g and outputs a bit b' {0, 1}, which is its guess of the value of b. The success of A in winning game g and thus breaking the notion of UPriv is quantified in terms A advantage in distinguishing whether A received T 0 or T 1 and denoted by (k) where k is the security parameter. Besides, the notion backward untraceability is defined as: "backward untraceability states that even if given all the internal states of a target tag at time t, the adversary shouldn't be able to identify the target tag's interactions that occur at time t' < t" [START_REF] Lim | Strong and robust RFID authentication enabling perfect ownership transfer[END_REF].

Backward traceability

In this section we show how to break the notion backward untraceability in the SRP protocol. Because EP is constant in the all rounds of SRP, an adversary A can track the target tag with doing the following steps:  Learning phase: A sends a Corrupt (T 0 , ) query in the round (i+1) and obtains ( ).  Challenge phase: A chooses two fresh tags (T 0 , T 1 ) to be tested and sends a Test Proof: By the fact that EP is a permanent value in the all rounds of the protocol, we have = . Thus we have the following procedure:

If T b =T 0 ⇒ PRNG( ⨁ ) = PRNG( ⨁ ) (1) If T b =T 0 ⇒ = =PRNG( ⨁ )⨁ (2)
( ( ⇒ PRNG( ⨁ )⨁ =PRNG( ⨁ )⨁ = PRNG( ⨁ )⨁PRNG( ⨁ )⨁ = = (3)
If T b =T 0 ⇒ ⨁ = ⨁ = ⨁ ⨁ ⨁PRNG( ⨁ )= ⨁PRNG( ⨁ )= ⨁PRNG( ⨁ )= ⨁PRNG( ⨁ ) (4)


Traceability attack

An authentication protocol for RFID systems should assure the privacy of a tag and its holder. However, many RFID protocols put it at risk by designing protocols where tags answer reader's queries with permanent values. Thus performing traceability attacks not only possible but trivial. Now, we prove the SRP does not guarantee privacy location and allows tags tracking.  Learning phase: A sends an Execute (R, T 0 , i+1) query in the (i+1)th round by sending N R1 and obtains ( ).  Challenge phase: A chooses two fresh tags (T 0 , T 1 ) to be tested and sends a Test

Note that T 0 does not update its secrets in the Learning phase and uses the same secret key in both Learning and Challenge phase. Now we have the following result:

If T b =T 0 ⇒ =PRNG( ⨁NR1)⨁ =PRNG( ⨁NR1)⨁ = (7)


Revised Protocol

In order to eliminate the mentioned vulnerabilities in 3.1 and 3.2 subsections, we can modify the message M1 as: M1=PRNG(EP ⨁ ⨁ )⨁ . Although the cited vulnerabilities are fixed by the above modification, the traceability problem still will be unsolved. Hence, we need to construct the message M1 as following: M1=PRNG(EP ⨁ ⨁ T)⨁ to provide a secure protocol against all cited attacks.

Security analysis

Now, we analyze the security of the revised protocol as following.

Untraceability: Due to the fact that N T is a random and fresh value, the tag's responses are different whenever an adversary sends query and therefore, the adversary is unable to trace a tag.

Backward untraceability: If an adversary knows EPC s and N R in worth case, he cannot recognize any previous interactions by a tag inasmuch as he does not know N T .

Reveal EPC s : Since EPC s is constant and its length is short, the mentioned attacks in 3.1 subsection happened successfully. We have added the random and fresh value N T in construction of M1 to remove these flaws. As a result, when an adversary wants to reveal EPC s , he has to perform 2 48 calculations rather than 2 16 .It is a noticeable improvement in SRP security.

Conclusion

In this paper, the significant security flaws in the Yeh et al. mutual authentication protocol were showed. We presented a powerful and practical attack on SRP which reveals the permanent secret value of the target tag. This attack leads to tag and reader impersonation and desynchronization attack on the protocol. Moreover, we proved that this protocol did not provide untraceability and backward untraceability. Our privacy analysis has been presented in a formal privacy model. Finally, to eliminate all cited vulnerabilities, we revised the SRP protocol and constructed the message M1 in a new way.

  c) Computes M2=PRNG(EP ⨁ )⨁ and Info=(DATA⨁RID), and sends them to the reader. d) If X = new, it updates the stored values as follows: ). But if X=old, it just updates as =PRNG( ⨁ ). 4. The reader does XOR operation with RID and the received Info and extracts DATA,

  (k) =| pr (b = pr (random flip coin) |= | pr (b' = b) -| where 0 (k) ≤ .



  (i, T o , T 1 ) query. Depending on a randomly chosen bit b {0, 1}, A is given a tag T b from the set {T 0 , T 1 }. A makes an Execute (R, T b , i) query in the round (i) and as a result, A is given messages { ( )}. Guess phase: finally, A terminates the game g and outputs a bit b' {0, 1} as its guess of the value of b. In particular, A performs the following procedure to obtain the value b': 1. He computes PRNG( ⨁ )⨁ = where is a 16-bit string. 2. A utilizes the following simple decision rule: =|pr (b' = b)pr (random flip coin)|=|pr(b'=b) -| = |1 -|=

  (i+1, T o , T 1 ) query. Depending on a randomly chosen bit b {0, 1}, A is given a tag T b from the set {T 0 , T 1 }. A makes an Execute (R, T b , i+1) query by sending N R1 and as a result, A is given messages ( ).  Guess phase: finally, A terminates the game g and outputs a bit b' {0, 1} as its guess of the value of b. In particular, A utilizes the following simple decision rule: b' = { Hence we have: (k) =| pr (b' = b)-pr (random flip coin) |= | pr (b' = b) -|=|1 -| = Proof: According to the protocol, we have the following equations:

  Therefore, the tag and reader have been desynchronized because the secret stored values in database are completely different from the values stored in the tag.

					and M . As the adversary has EP , he computes
	PRNG(EP ⨁	) and gets the secret key	as: =M ⨁PRNG(EP ⨁	)
	and	=PRNG( ).	The	secret	key	is	gotten	as:
	=M ⨁PRNG(EP ⨁	) and	=PRNG( where	= ⨁ .
	2. He begins a new session with T i and sends	to it. T i replies with (	, M , ,
	), created by EP ,	, ,		and	.
	3. After receiving the tag's response, the adversary extracts	(	= ⨁ ),
	computes M =PRNG(EP ⨁	)⨁	and sends it to the tag.
	4. T i checks whether M ⨁		is equal to PRNG(EP ⨁	) or not. T i
	authenticates the adversary and updates its secret values provided that the equation
	will be true:		=PRNG(	),	=PRNG(		=PRNG(	⨁	).
	Eventually, the stored secret values on T i are (	,	,	, EP ) whereas the
	database has stored ( , , ,	,	,	RID, EP , DATA).

Acknowledgment

This work was partially supported by Iran National Science Fund (INSF)cryptography chair and research institute for ITC, Tehran, Iran.


Theodoros Ntouskas
email: tdouskas@unipi.gr

George Pentafronimos

Spyros Papastergiou

STORM -Collaborative Security management environment

Keywords: Security Management, Risk Management, Vulnerability Assessment tools, Security Tools, Collaboration

Security Management is a necessary process in order to obtain an accurate security policy for Information and Communication Systems (ICS). Organizations spend a lot of money and time to implement their security policy. Existing risk assessment, business continuity and security management tools are unable to meet the growing needs of the current, distributed, complex IS and their critical data and services. Identifying these weaknesses and exploiting advanced open-source technologies and interactive software tools, we propose a secure, collaborative environment (STORM) for the security management of ICS's.

Introduction

The most critical and sensitive data of the organizations is hosted in their Information and Communication Systems (ICS). Degradation, interruption or impairment of their ICS has serious consequences on safety, loss of sensitive data, loss of reputation or loss of service making security management one of the most important organizational concerns [START_REF] Wigert | An inventory of 20 national and 6 international critical infrastructure protection policies[END_REF]. Current ICSs are distributed; complex and multidimensional resulting to the fact that security management is a cooperative obligation requiring the involvement and participation of all ICS participants.

Existing security management (e.g. ISO-15408 [START_REF]Information technology -security techniques -evaluation criteria for it security -part 1: Introduction and general model[END_REF], ISO-17799 [START_REF]Information technology -security techniques -code of practice for information security management[END_REF], ISO-27001 [START_REF]Information technology -security techniques -information security management systems -requirements[END_REF], ISO-27002 [START_REF]Information technology -security techniques -code of practice for information security management[END_REF]) and risk assessment (e.g. Cobra [START_REF]COBRA Methodology: Security risk analysis and assessment[END_REF], CRAMM [START_REF]CRAMM: Ccta risk analysis and management method, cramm version 5.2 information security toolkit[END_REF], EBIOS [START_REF] Ebios | Expression des besoins et identification des objectifs de securite[END_REF]) tools do not enable collaboration and they do not consider all aspects (technological, business, legal, economical) that influence the evaluation of the ICS threats and vulnerabilities leading to incomplete and ineffective security management, with generic security policies and incomplete security procedures.

The risk management for current complex organizations (e.g. large-scale infrastructures, critical infrastructures, large enterprises) requires many interviews with all participants in order to identify the architecture of the ICS, the assets, and their interdependency, risks and criticality (from an organizational, technological, legal, business and economical perspective).

Furthermore, it does not exist an automated collaborative tool embedding security standards, methodologies, tools and guidelines that continuously guide and train the participants in the security management in order to:

-Perform risk assessment for risk identification -Conduct vulnerability assessment -Execute penetration tests/scenarios -Implement appropriate countermeasures -Design security policy and procedures -Design security business continuity and disaster recovery plans The aim of this paper is to contribute to the above challenge by providing a collaborative security management tool (STORM) which provides:

-Innovative collection of security knowledge. Using the STORM environment the necessary information will be collected from all participants, minimizing the gathering time, reducing costs for the organizations and most importantly taking into account the security knowledge of all participants of the ICS in order to obtain an accurate security policy. -Secure dependable and collaborative environment. By the use of STORM modules, the governance of complex organizations will be able to establish and maintain a secure cooperate environment for their local and external users.

STORM is a prototype of a new generation, collaborative, innovative security management environment, which will be able to provide the necessary level of confidentiality, reliability, interactivity and interoperability of the organizations and their ICS's. The proposed STORM environment is an open and cost effective approach that is based on widely used collaborative web 2.0 technologies such as wikis, blogs, RSS and forums. The rest of the paper is organized as follows: Section 2 describes existing standards and methodologies for Security Management and analyzes the ICS complexity. Section 3, describes the STORM architecture and its basic components. Finally, Section 4 draws conclusions.

State of the art

Security Management is a continuous and systematic process of identifying, analyzing, handling, reporting and monitoring operational risks of an organization [START_REF]Basel Committee on Banking Supervision: Sound practices for the management and supervision of operational risk[END_REF] [START_REF]ENISA: Risk Management: Implementation principles and Inventories for Risk Management/Risk Assessment methods and tools (2006) 19. ENISA: Cert exercises handbook[END_REF]. Security Management is an important governance and administration procedure aiming at the protection of an organization from internal and external risks that would negatively affect the achievement of its operational objectives.

Current ICS's are characterized by growing complexity, distribution of their Information System (IS) (network, hardware, software, human resources) in various locations (rooms/buildings/cities) and by the plethora of electronic services. In addition, these complex ICS's interact, interwork and their business become dependent on other organizations (e.g. providers, partners, banks, insurance companies, Tax authorities). They have a large number of users (internal, external administrators, users, providers), and they face a growing number of different types of spatial and temporal dispersion effects of attacks.

Despite the growing need for effective security management within the organizations, the existing security-related methodologies, standards and frameworks are inadequate to meet the above needs of current ICS in a holistic and integrated way. More specifically:

-Existing security management standards/frameworks/methodologies for the establishment of corporate security governance (e.g Cobit [START_REF]COBIT4.1: It governance control framework[END_REF], ITIL [START_REF] Clinch | Itil v3 and information security[END_REF],

ValIT [START_REF] Valit | Enterprise value: Governance of it investments-the val it framework 2[END_REF], ISO-17799 [START_REF]Information technology -security techniques -code of practice for information security management[END_REF], ISO-27001 [START_REF]Information technology -security techniques -information security management systems -requirements[END_REF], ISO-27002 [START_REF]Information technology -security techniques -code of practice for information security management[END_REF]), have not been implemented in a tool since they present specific limitations. They usually define principles and provide only guidelines mostly in the form of recommendations rather than strict rules that should be followed. -Existing risk management methodologies (i.e. Cramm [START_REF]CRAMM: Ccta risk analysis and management method, cramm version 5.2 information security toolkit[END_REF], Octave [START_REF]OCTAVE: Octave method implementation guide version 2.0[END_REF], ISO-15408 [START_REF]Information technology -security techniques -evaluation criteria for it security -part 1: Introduction and general model[END_REF]) and their automated tools (e.g. Cramm [START_REF]CRAMM: Ccta risk analysis and management method, cramm version 5.2 information security toolkit[END_REF], Cobra [START_REF]COBRA Methodology: Security risk analysis and assessment[END_REF]) are costly, they require numerous and time consuming face-to-face interviews with all the administrators, not allowing collaboration, resulting to the insufficient collection of all available security knowledge of all participants. -Most of available methodologies and frameworks for security testing [START_REF] Agarwwal | Owasp testing guide v3.0[END_REF], [START_REF] Stock | Owasp code review guide v1.1[END_REF], [START_REF] Wack | NIST SP800-42:Guideline on Network Security Testing -Recommendations of the National Institute of Standards and Technology[END_REF], [START_REF] Scarfone | Technical guide to information security testing and assessment[END_REF], [START_REF] Orrey | Penetration testing framework(ptf) v0.21[END_REF], [START_REF] Herzog | Osstmm:introduction and sample to the open source security testing methodology manual (osstmm 3 lite)[END_REF], [START_REF] Brunner | Information systems security assessment framework (issaf) draft 0.2.1[END_REF] describe test cases and they indicate tools that can be used in each test providing merely a description of their capabilities. Nevertheless, the tracing and the correct configuration of the required vulnerability assessment tools is a time consuming process which requires specific expertise. Therefore, there is a need for consolidated vulnerability assessment information pertaining to the proper configuration and installation of the VA tools as well as the provision of an integrated VA environment that offers a comprehensive and large collection of security-related tools. -Disaster Recovery and Business Continuity standards (i.e. BS 25999-1 [START_REF]Business continuity management[END_REF],

BCI GPG [START_REF]BCIGPG: A management guide to implementing global good practice in business continuity management[END_REF], ITIL V3 [START_REF] Clinch | Itil v3 and information security[END_REF], HB 292 -2006 [START_REF]Handbook: A practitioners guide to business continuity management[END_REF]) are unable to meet the needs of the current distributed IS's since they have not been implemented in an automated tool. -The renewal, updating and awareness of these security documents (security policy, Disaster Recovery and Business Continuity plans) is done manually every time something changes in the ICS or in the security procedures which are costly and time consuming processes requiring a variety of organizational resources.

Therefore, there is an imperative need for continuous, collaborative, holistic and effective security management of the ICS. The proposed STORM environment, described in the following sections is an open, cost-effective, collaborative approach to security management.

STORM collaborative environment

Because of the changing conditions under which an organization operates today (distributed, complex and diverse technological environment, globalization, economic crisis), the implementation and maintenance of an accepted level of ICS security is requiring a planned and organized task. STORM contributes to the creation, enhancement, monitoring and assessment of the security of the information and communication systems providing an innovative, interactive collaborative environment that encompasses a bundle of primitive services which allow the organization to:

-identify and depict the ICS infrastructure; -identify the applying security policies, procedures, standards and guidelines; -specify, evaluate and classify daily risks and threats of the ICS continuously collecting the security knowledge of all operational ICS participants (administrators, users, providers); -recognize the impacts (business, economical, technological, legal) of upcoming incidents on the operations of the ICS; -execute technical vulnerability assessment with live scenarios (based on accepted vulnerability assessment methodologies and techniques) identifying at real time the security needs of the ICS; -select reliable and appropriate countermeasures to achieve the confidentiality, availability and integrity of data; -on-line generation/formulation/monitor/renew/update all the security documents (security policy, Business Continuity and Disaster Recovery Plans); -continuously monitor new laws, standards and best practices.

In order to achieve these, the STORM collaborative environment is composed of four layers as depicted in the following Figure. STORM architecture, its basic components and their functionalities, are described in the following sections.

STORM Architecture and Services

STORM aims to become the harbinger of a new generation security management tool for ICS, stimulating the collaboration among all stakeholders. Figure 1 depicts the proposed architecture that encompasses the core participants and entities distributed in four distinct layers as follows:

Layer 1 -STORM Users: This first layer consists of the four groups of users namely, Security and Business Continuity Team, Administrators, local Users, external users. Considering the fact that local and cooperate users may not perceive critical security factors (e.g. threats, vulnerabilities, impacts) the same way as security experts, different access privileges to the STORM services have been applied to the aforementioned user groups. Remarkably, only the members of the Security and Business Continuity Team are responsible for properly and adequately providing initial content to the system and specifically all the primary information assets comprised at Layer 2 of its architecture, that are necessary for harmonizing security management procedures.

Layer 2 -The STORM Framework: The main components and the individual systems that comprise the core STORM environment.

Layer 3 -STORM Services: At this layer, an integrated bundle of security services is provided that aids the organization to apply an accurate, reliable and flawless corporate security management of ICS.

Layer 4 -STORM Primary Information Assets: All related standards, methodologies, best practices, related legislation are the assets of the STORM; typical examples are: Business Continuity and Disaster Recovery Standards, Security Management Standards methodologies, Risk Analysis questionnaires, Vulnerabilities scenarios, Security Policy, Disaster recovery/Business Continuity plans, Disaster Scenarios. These assets are structured documents in STORM Document Library.

Layer 1 -STORM Users

The STORM participants as described in Layer 1 are the following:

-The administrators of the IS who continuously inform the collaborative tool with all the necessary information (technical instructions, manuals, samples of business continuity and disaster recovery plans, international standards, best practices, open source security tools and scenarios etc.), create the questionnaires and the necessary recovery forms, define the responsibilities of users, control and renew the lists of the installed software and hardware of the information system. -The members of the security and business continuity team, make an assessment of the criticality of services, analysis and evaluation of risks, risk management using appropriate countermeasures and implement all the procedures of the security policy. They are able to continuously be informed with the new standards and best practices and apply them directly on the system.

-Local users of information systems (e.g. accounting user etc) will be able to actively participate in the collaborative security process, find information on technical and security procedures and as a result any difficulties may be treated effectively. Also they will be trained/informed about all the security procedures through the STORM communication module (with wiki/forum/polls). -Cooperate users which cooperate with the organizations (e.g. custom offices, banks, agencies, suppliers, service providers, other organizations) can be informed about security rules and conditions for safe interconnection and access to the information systems of the organizations. In this way there will be safeguards put in place, minimization of threats, and trust in the quality of services.

Layer 2 -The STORM Framework

The STORM framework consists of two central entities. The second major entity of the framework is STORM System that is comprised of the following components:

-Web portal: A Web Interactive System, which provides secure access to security related information and content, retrieved and processed from diverse sources, in a unified and user-friendly way. This system is based on collaborative Web 2.0 technologies and automated, open, interactive and reliable technological tools (such as collaborative forums, blogs, Wikis etc.).

The STORM system will actually provide a consistent look and feel with secure access control and procedures for the integrated applications of the project. The STORM Web portal will serve as a unified secure access and presentation point to the full range of security services. -Enterprise Service Bus (ESB): ESB is essentially a lightweight messaging framework integrating different technologies, devices and data transfer protocols, ensuring that different systems and applications communicate through a common channel to exchange information with other organizations. -Business Process Modelling (BPM): It undertakes the responsibility to monitor, manage, analyze and implement the business logic of complex and distributed workflows of the services provided by the STORM system. -Decision Support System (DSS): DSS facilitates the combination of a set of information in order to solve problems and reach tactical and strategic decisions in several security and privacy issues. These decisions can be considered more in the form of suggestions and recommendations rather than strict injunctions that should be followed. The users will be able to modify, complete, or refine these decision suggestions according to their needs.

Representative example is the definition of a security and privacy risk mitigation strategy taking into consideration the enterprise financial status and the applied countermeasures. -Ontologies and Semantic Structures (Knowledge Base): A collection of semantic structures (notably ontologies/taxonomies) modelling the STORM content as well as their semantic relationships will be designed, implemented and integrated within the STORM system. Thematic, security and privacy related ontologies/taxonomies will be defined to better organize the various quantities of the assets stored in the repository. These will bring context to words, topic areas and search results, providing a hierarchical structure of asset categories, from general to specific. We conveniently call the set of semantic structures of the STORM system, as the STORM Knowledge Base. -Content Management System (CMS) responsible for creating, editing, management and publication of all the primary and processed content in a consistent and structured way. It consists of:

-advanced content management tools (e.g. rich text editors, live page editing and scheduling, and advanced document managers) in order to provide the STORM friendly environment; -intuitive front end user interfaces that share a set of common characteristics to promote user friendliness and accessibility; -functionality for collecting, organizing and managing content from multiple sources (e.g., databases, repositories) and multiple formats; -STORM taxonomies for better access to the STORM primary assets and content. -STORM Repository: All STORM primary assets (all related standards, methodologies, best practices, legislation, Risk Analysis questionnaires, Security Policy, Disaster recovery/Business Continuity plans) are stored in a repository.

All the aforementioned elements are the backbone infrastructure of the STORM framework. They will be combined in an effective way to establish a highly agile automation Services Oriented Architecture (SOA) environment that can boost both re-engineering and the integration of a set of security and privacy related services that will be described in the following section.

Layer 3 -STORM Services

The services offered by STORM (Layer3) are depicted at the figure 2 and described in detail as follows:

Cartography module: The main objective of this module is to describe critical information and communication systems in order to depict all their securityrelated aspects. These aspects are not confined only to technical issues, but they are also concerned with the business processes in which the systems are embedded. In order to describe the information and communication systems, STORM has adopted and integrated an object modeling approach based on the ISO Reference Model for Open Distributed Processing systems (RM-ODP) [START_REF] Vallecillo | Rm-odp: The iso reference model for open distributed processing,dintel edition on software engineering[END_REF] standard in combination with the Unified Modeling Language (UML). The RM-ODP offers a general framework and a reference model based on five different viewpoints that identifies the crucial characteristics that qualify the systems while the UML provides the notation for representing the identified features.

The five viewpoints as described by RM-ODP and adopted by STORM are the following:

-Enterprise viewpoint. A viewpoint of the system and its environment that focuses on the technical guidelines and policies associated with the system as well as the system's purpose of operation, scope and business requirements. Also, it deals with aspects of the enterprise such as its organizational structure, which affect the system. -Information viewpoint. A viewpoint which specifies and describes the information structure of the system. Specifically, it focuses on the information that is stored, processed and exchanged in the system. -Computational viewpoint. A viewpoint which focuses on functional decomposition of the system into objects which interact at interfaces. -Engineering viewpoint. A viewpoint which describes the way different objects of the system interact with each other as well as the resources required for this communication. -Technology viewpoint. A viewpoint which focuses on the individual hardware and software components which compose the system.

The proper and accurate analysis and representation of the information and communication systems aid the early discovery of security vulnerabilities, inconsistencies and redundancies in these systems. Theoretical Risk Assessment Module: providing the following functionality:

-Online Forms for user identification (responsibilities, roles etc.), asset identification (servers, routers, switches, applications, databases etc), reporting of their interdependencies with other systems, description of applications, detailed record of operational procedures. -Collaborative Questionnaires. Embedded online questionnaires for the accomplishment of:

-IT assets (software and hardware) identification -impacts determination (based on various security scenarios related to availability, integrity and confidentiality loss), -threats, vulnerabilities and risk identification.

The posted questionnaires are filled in by all participants and are collected and analyzed by the corresponding users through charts .The participants, answering the questionnaires, will be able to give their knowledge from their own perspective (e.g. deficiencies, security incidents, backup procedures, countermeasures of their department). This allows the accumulation of objective information that can be used as input for the execution of the risk analysis and risk management procedures in an effective and efficient manner. Vulnerability (Practical Risk) Assessment module: This module consists of the following three subcomponents:

1. Methodologies repository. An inventory of the most wide-used and accepted vulnerability assessment (VA) methodologies and frameworks (i.e. OWASP [START_REF] Agarwwal | Owasp testing guide v3.0[END_REF], OWASP Code review [START_REF] Stock | Owasp code review guide v1.1[END_REF], NIST SP800-42 [START_REF] Wack | NIST SP800-42:Guideline on Network Security Testing -Recommendations of the National Institute of Standards and Technology[END_REF], Special Publication 800-115 [START_REF] Scarfone | Technical guide to information security testing and assessment[END_REF], Penetration Testing Framework (PTF) [START_REF] Orrey | Penetration testing framework(ptf) v0.21[END_REF], OSSTMM [START_REF] Herzog | Osstmm:introduction and sample to the open source security testing methodology manual (osstmm 3 lite)[END_REF], ISSAF [START_REF] Brunner | Information systems security assessment framework (issaf) draft 0.2.1[END_REF])defined and released by the standardization bodies and the research communities. This acts as a reference point of existing methods for network and web application security testing and assessment as well as for forensics analysis. 2. Tools Repository. An inventory of open source and freeware tools that can be used in combination with the VA methodologies and frameworks for the deployment of specific security tests. A set of tools-related information concerning installation guides for various operating systems, links to sources codes and executable files as well as expert notifications about capabilities, problems and limitations is also provided. Within STORM, the VA tools are divided in the following categories taking into account the provided functionality:

- [START_REF]Sleuth Kit (TSK[END_REF], Volatility [START_REF]Volatility: Volatility framework[END_REF]). In addition, a VA environment (VA platform) has been configured and is available in STORM providing a user-friendly access to a comprehensive and large collection of security-related tools ranging from sniffers and traffic analyzer to web scanner and WEP/WPA cracking. The preconfigured environment is a Linux distribution based on Debian 5 that is available as a Live DVD. This allows the potential users either to boot the platform directly from any portable media or to install it to the hard disk or even to run it as a virtual machine. Configuration guidelines of the platform are also available strengthening the trust of the potential users. The main aim of this inventory is to assist individuals and organizations to establish a well-defined security "laboratory" environment enabling them to perform self-assessment in order to improve the security level of their infrastructure. 3. Lesson Learned Repository. This component acts as an inventory of common attacks. Its main objective is to bring into focus some of the theoretical and practical concerns of the most common threats. In this context, a comprehensive description of a set of attacks is provided covering all their aspects including exploitable security flaws, applied scenarios, tools which can be used, as well as mitigation recommendations and countermeasures that can be adopted. The attacks have been categorized as follows:

-Network Attacks: include any methods, processes or means used to maliciously attempt to compromise the security of a network. Representative examples of this type are Distributed Denial of Services attacks, Spoofing attacks, Eavesdropping etc. -Application Attacks: include any methods, processes or means used to maliciously attempt to compromise the security of an application. Injection (e.g. sql, soap, ldap), Cross-Site Scripting (XSS), Buffer Overflow attacks are examples of this type. In addition, a number of case studies that can be considered as lesson learned can be provided in STORM. These are more in the form of challenges rather than strict rules that must be followed. The challenges are discriminated in two types. The first concerns case studies of attacks' deployment (e.g. Distribution Denial of Service (DDoS), Denial of Service (DoS)) aiming at the evaluation and validation of the security controls and countermeasures that are integrated in an infrastructure. The impact of the attacks on the target is calculated and recorded in the system as it has to be the prime consideration for further investigation. The second type of case studies gives the opportunity to the potential users (individuals and organization) to analyze the attacks and post their findings in STORM CMS. The challenges concern a wide range of forensic issues such as the detection and analysis of suspicious software/malware, hash analysis, image analysis, partition recovery, signature analysis, file header reconstruction, password recovery, registry analysis, steganography and encryption. Furthermore, the results of case studies conducted within the activities of a set of national initiatives such as HONEYNET [START_REF]Honeynet: Honeynet project[END_REF], CERT Exercises Handbook [19] can be also analyzed and presented in depth in the system. In this way, the users learn not only about the threats, but also how to deploy and analyze them.

Risk Management module: This module via online forms and library aid the organization for the selection of the appropriate taking into account the result of the risk assessment procedure. All participants will be able to give their opinion by using the communication module and agree or propose their new countermeasures.

Security Policy Module: This module provides the appropriate functionality for the design and creation of the security policy of the organization using the collaborative forms that are embedded in this STORM module. In addition, all the information related to security policies, procedures, guidelines, rules and responsibilities and credentials at the information and communication systems and services are also available and accessible by all the corporate users via this module.

Administrators and security team will edit and update this module so all the other users of the organization will be able to find information about the security procedures, rules and their responsibilities and credentials at the applications and services.

Disaster Recovery (DR) / Business Continuity (BC) Module: The aim of this module is to provide the functionality required for the design and creation of BC and DR plans. It also contains all the disaster recovery procedures and relevant information such as responsibilities and contact information that are necessary in case of disaster or an emergency event. Further, the module provides forms for building of possible disaster scenarios and for real time responsibilities assignment. More detailed, there have been implemented forms for:

-user responsibilities, -contact details, -supplier contact details, -incident report, -incident handling, -recovery procedures, -backup infrastructure and procedures Collaborative Communication Services: Provision of a group of communication services.

-Forum for exchanging ideas about security topics or reach consensus on evaluation of risks. This will help all participants to find quickly solutions about daily security or other problems so they will solve their difficulties quick. Also they will be able to discuss about security problems, accept or not the proposed countermeasures or recommend their security safeguards. -Polls so users will be able to discuss critical security issues allowing them to reach solutions in a collaborative, cost and time effective manner. -Wiki, based on which, all users will be able to find or propose their own solutions regarding security issues or find details about risk assessment, risk management and vulnerability and the security policy of their organization, so they will be able to solve any difficulty directly. -Interactive user screens which are used for collaborative risk management and for reporting protection measures.

Layer 4 -STORM Primary Information Assets

STORM users will be able to perform various actions depending of their roles e.g. local and cooperate users will be able to access the STORM assets which support the STORM services as described in Section 3.4. In particular the following assets will be included: the cartography analysis report of the organization as produced in the Cartography module; the risk assessment questionnaires provided by the Theoretical risk assessment module; all the security related information pertaining to the technical vulnerability assessment (VA) i.

Implementation

The development and integration of the main components of the STORM framework is based on the innovative integration of mature technological solutions and tools as follows:

-Social Networking Tool: A social networking open source solution that is based on Symfony Framework [START_REF]Symfony: Symfony framework[END_REF] has been adopted and integrated in the STORM system. This solution is an open source software platform available for social networking that provides a number of Web2.0 components such as, Document Library, Team Calendar, Wikis, Blogs, Forums (Message Boards), Private Site and separate secured areas, Instant Messaging, Announcements & Alerts and Email.

-Content Management System: The management of the content, documents, files, information and data related to the security services provided by the STORM system is performed by a CMS solution based on the Symfony Framework [START_REF]Symfony: Symfony framework[END_REF]. -Business Process Management (BPM): A holistic business process management tool, ADONIS [START_REF]ADONIS[END_REF], has been adopted for the composition of an integrated SOA environment. The tool utilizes notations like Business Process Execution Language (BPEL) standards in order to enable modelling, composition and deployment of service workflows. This tool is also be used in order to implement the Decision Support System that shall be integrated in the system. -SOA Environment: An open SOA strategy has been adopted based on XML technologies and web services-based standards and will be followed for the design, development and implementation of the STORM system. For the integration of the middleware infrastructure [START_REF] Karantjias | Advanced e-government enterprise strategies & solutions[END_REF] (i.e. application servers, enterprise service bus) an Open Source Enterprise Server, has been deployed that hosts the SOA environment. -Identity Management System (IMS): The STORM framework has incorporated a solution, Open SSO platform [44], that provides core identity services such as strong authentication and authorization mechanisms as well as support and implement a transparent single sign-on (SSO) procedure.

As indicated in the brief analysis of STORM main technological components, the proposed integration framework is totally based on open-source technologies and software tools, rendering the final product (STORM Environment) a costeffective and easily adopted innovative solution. This critical characteristic could be also considered as the fundamental benefit and added value of STORM, given that nowadays, key organisational decision makers and business managers (e.g. CIOs, CISOs, CFOs, etc.) are seeking urgently and massively, in a constantly evolving pace, for more efficient and cost-effective risk management solutions in order to reduce operational costs and resist the existing economic crisis. Especially in cases where security is falsely considered as a secondary need and disregarded due to the required additional costs (outsourcing to security consulting companies to perform risk assessment and management activities), an efficient solution that is able to provide reliable risk assessment and management services at extremely low cost is considered as an indispensable property. Achieving this, STORM constitutes an innovative security management platform that is able to confront and effectively manage the trade-off between low cost and security management expertise by harnessing corporate knowledge, leveraging existing infrastructures and boosting work productivity.

Conclutions -Future work

STORM is an open, innovative, collaborative security management environment, which can used in various organizations (from large organizations hosting critical infrastructures to SMEs and mEs) in order to effectively address their security and privacy needs.

The STORM environment has been proposed [START_REF] Ntouskas | A secure, collaborative environment for the security management of port information systems[END_REF] as the preferred solution in order to provide security management services to the port Information systems. It will also be implemented in the S-PORT project [START_REF]S-port project[END_REF] STORM has also been selected as the appropriate architecture for policy making in collaborative environments and it will be implemented in the E.C. FP7 project ImmigrationPolicy2.0 [30].

Fig. 1 .

 1 Fig. 1. STORM collaborative environment

Fig. 2 .

 2 Fig. 2. STORM Security Management Services

  funded by the National research program "Cooperation" (NSRF 2007-2013) of the GSRT (General Secretariat for Research and Technology Development Department) in three Greek commercial Ports (Piraeus Port Authority S.A., Thessaloniki Port Authority S.A, Municipal Port Fund Mykonos).

Acknowledgements. The authors would like to thank the GSRT for funding the S-Port project, and the E.C. for funding the ImmigrationPolicy2.0 project. Finally we thank the S-Port and ImmigrationPolicy2.0 partners for their contributions.


Michael Hutter
email: michael.hutter@iaik.tugraz.at

Martin Feldhofer
email: martinfeldhofer@iaik.tugraz.at

Johannes Wolkerstorfer
email: johannes.wolkerstorfer@xface.at

A Cryptographic Processor for Low-Resource Devices: Canning ECDSA and AES like Sardines

Keywords: Cryptographic Processor, ECDSA, ECC, AES, SHA-1, ASIC Implementation, Low-Resource Constraints

The Elliptic Curve Digital Signature Algorithm (ECDSA) and the Advanced Encryption Standard (AES) are two of the most popular cryptographic algorithms used worldwide. In this paper, we present a hardware implementation of a low-resource cryptographic processor that provides both digital signature generation using ECDSA and encryption/decryption services using AES. The implementation of ECDSA is based on the recommended Fp192 NIST elliptic curve and AES uses 128-bit keys. In order to meet the low-area requirements, we based our design on a sophisticated hardware architecture where a 16-bit datapath gets heavily reused by all algorithms and the memory is implemented as a dedicated RAM macro. The proposed processor has a total chip area of 21 502 GEs where AES needs only 2 387 GEs and SHA-1 requires 889 GEs.

Introduction

In a world where an innumerable amount of pervasive devices communicate with each other, the need for security increases heavily. Cryptographic services like secure symmetric and asymmetric authentication as well as confidentiality build the basis for contactless security applications like access control, mobile payment, and product authentication.

Most of the published hardware implementations of cryptographic services optimize a single algorithm or even a part of it and often do not account for higher-level protocols and applications. Turning such cryptographic primitives into a working product turns out to require a multiple of resources in the end. In this paper, we investigate the implementation of a cryptographic processor for low-resource devices. We present a complete integrated solution which is based only on standardized algorithms and protocols.

In particular, using standardized algorithms and protocols with an appropriate level of security is important to assure the interoperability between devices and to allow reuse of existing infrastructures in back-end applications. Even in the very cost-sensitive market, people get more and more convinced that standardized solutions are inevitable. Two of the most important standardized algorithms are the Elliptic Curve Digital Signature Algorithm (ECDSA) [START_REF]3: Digital Signature Standard (DSS)[END_REF] and the Advanced Encryption Standard (AES) [START_REF]Advanced Encryption Standard[END_REF]. ECDSA, which is for example used for secure identification in e-passports, generates digital signatures for message and entity authentication. AES is the successor of the Data Encryption Standard (DES) and today the most frequently used symmetric block cipher for encryption and authentication.

Hence, we target the implementation of our cryptographic processor on these two algorithms. The reason why we have chosen to implement both algorithms in one module is that the public-key scheme ECDSA can be used for offline authentication in open-loop applications while AES is much faster when the verifier has online access especially in closed-loop scenarios. Furthermore, with our approach of reusing components like the memory and the controlling engine we want to demonstrate that these high-security algorithms can be migrated to very resource-constrained devices such as mobile devices, embedded systems, wireless sensors, and RFID devices.

In this paper, we present the first ASIC hardware implementation of a cryptographic processor that is able to perform both the ECDSA using the NIST elliptic curve over F p192 and the AES (encryption and decryption) with 128-bit keys. Our implementation targets low-resource devices which implies fierce requirements concerning chip area (costs) and power consumption (due to a possible contactless operation). We meet the ambitious design goals by using a sophisticated hardware architecture where the main components memory, datapath, and controlling engine are reused by all implemented algorithms. Using a 16-bit datapath with a multiply-accumulate unit and a dedicated RAM macro instead of a flip-flop based memory minimizes the chip area. Next to several algorithmiclevel improvements, we present a very efficient arithmetic-level implementation of a modular multiplication with interleaved NIST reduction over F p192 . The entire processor needs 21 502 GEs where 2 387 GEs are required to support AES and 889 GEs are needed for SHA-1. This is because AES and SHA-1 reuse several components of our processor such as the microcontroller and the common memory.

The article is structured as follows. Section 2 summarizes related work on AES and elliptic-curve hardware implementations. An overview of the system is given in Section 3 and the hardware architecture is described in detail. Arithmeticlevel implementation are given in Section 4 where we describe the NIST modular multiplication. Section 5 shows the implemented algorithms such as SHA-1, AES, and ECDSA. Results of our work are presented in Section 6. Conclusions are drawn in Section 7.

Related Work

There exist many articles that describe hardware architectures for AES and elliptic-curve based algorithms. One landmark paper that reports a low-resource implementation of AES is due to M. Feldhofer et al. [START_REF] Feldhofer | Strong Authentication for RFID Systems using the AES Algorithm[END_REF] in 2004. Their implementation needs 3 595 GEs and performs a 128-bit encryption within 1 016 clock cycles. P. Hämäläinen et al. [START_REF] Hämäläinen | Design and Implementation of Low-Area and Low-Power AES Encryption Hardware Core[END_REF] presented an encryption-only AES architecture in 2006. Their design needs only 3 100 GEs. Similar results have been reported also by J.-Kaps et al. [START_REF] Kaps | Cryptography for Ultra-Low Power Devices[END_REF] and M. Kim [START_REF] Kim | Low Power AES Hardware Architecture for Radio Frequency Identification[END_REF] who presented an encryption-only AES implementation with around 4 000 GEs.

In view of elliptic-curve cryptography (ECC) there exist several implementations that propose efficient hardware architectures for scalar multiplication, e.g. S. Kumar et al. [START_REF] Kumar | Are standards compliant Elliptic Curve Cryptosystems feasible on RFID?[END_REF] and L. Batina et al. [START_REF] Batina | Low-Cost Elliptic Curve Cryptography for Wireless Sensor Networks[END_REF]. Architectures with implementations of also higher-level protocols have been proposed by A. Satoh et al. [START_REF] Satoh | A Scalable Dual-Field Elliptic Curve Cryptographic Processor[END_REF] and J. Wolkerstorfer [START_REF] Wolkerstorfer | Is Elliptic-Curve Cryptography Suitable for Small Devices?[END_REF] who proposed a dual-field ECC processor for low-resource devices. Y. K. Lee et al. [START_REF] Lee | Elliptic-Curve-Based Security Processor for RFID[END_REF] and D. Hein et al. [START_REF] Hein | ECC is Ready for RFID -A Proof in Silicon[END_REF] presented an ECC co-processor over binary fields F 2 163 . The work of Lee integrates a tiny microcontroller for higher-level arithmetics while the work of Hein includes a digital RFID frontend supporting the ISO 18000-3-1 standard protocol. ECDSA implementations have been realized by J. Wolkerstorfer [START_REF] Wolkerstorfer | Is Elliptic-Curve Cryptography Suitable for Small Devices?[END_REF], F. Fürbass et al. [START_REF] Fürbass | ECC Processor with Low Die Size for RFID Applications[END_REF], and E. Wenger et al. [START_REF] Wenger | Low-Resource Hardware Design of an Elliptic Curve Processor for Contactless Devices[END_REF]. They based their design on prime-field arithmetics to support ECDSA.

Our work is based on an ECDSA implementation of M. Hutter et al. [START_REF] Hutter | An ECDSA Processor for RFID Authentication[END_REF]. We extended the work by implementing AES-128 (supporting encryption and decryption) as a main contribution and show that it can be integrated into the processor with low resources. We further give a detailed description of the arithmetic-level and algorithmic-level implementation of the processor and discuss the results in Section 6.

System Overview

The implementation of our proposed processor is based on the recommended NIST Weierstrass elliptic curve over F p192 . This has mainly two reasons. First, our processor should be as flexible and scalable as possible while keeping the required chip area low. A processor over F p allows us to support different protocols and algorithms on the processor without the need of any additional logic circuits. However, the costs for that choice are a lower performance compared to binary-extension field processors. Second, fixing the implementation to a standardized elliptic curve provides interoperability with existing applications like X.509 public-key infrastructures (PKI), citizen cards, and e-passports. Furthermore, it allows several optimizations in hardware like the NIST modular reduction [START_REF] Hankerson | Guide to Elliptic Curve Cryptography[END_REF] to gain additional performance.

We decided to implement a 16-bit architecture. During our investigations, it has shown that a 16-bit data width provides an optimum for reducing the chip area and the power consumption while keeping the required number of clock cycles within limitations.

Hardware Architecture

In order to design a low-resource processor, we minimized the required hardware resources by reusing components like the memory and the controller for all implemented algorithms. Especially for the AES this means that the overhead is very low because the ECDSA dominates the memory requirements and the controlling effort. The cryptographic processor consists of three main components as depicted in Figure 1. The first component is the controller, which is responsible for sequencing the desired algorithms and the generation of the control signals for the memory and the datapath unit. The second module is the memory, which holds data during computation, constants like curve parameters, and also non-volatile data like the private key (for ECDSA) and the secret key (for AES). The third module is the datapath, which performs the arithmetic and logic operations for ECDSA and AES.

The memory of the processor can be accessed by a memory-mapped I/O. Via an AMBA interface it is possible to write and read data to and from the RAM (e.g. the message to sign or the generated signature) but also to access the EEPROM or the instruction register. In very complex algorithms and protocols like ECDSA with implicit SHA-1 calculation and random-number generation, the controlling effort in terms of design complexity and chip area gets more and more dominant. Hence, we investigated a totally new concept where a microcontrolled approach makes the implementation more flexible but keeps also the hardware complexity low compared to dedicated finite-state machines.

Memory Unit

The memory unit comprises the three types RAM, ROM, and EEPROM in a 16-bit linear addressable dual-port memory space. The 128 × 16-bit dual-port RAM is realized as a dedicated macro block. This halves the chip area of this memory resource. In detail, ECDSA needs 7 × 192 bits for calculating the point multiplication, one 192-bit value to store the message that has to be signed, and one 192-bit value for the ephemeral key k. Additionally, we reserved 192 bits for storing the seed that is used in both ECDSA and AES to generate the needed random numbers. The ROM circuit stores 128 16-bit constants like ECC parameters, SHA-1, and AES constants. It is implemented as an unstructured mass of standard cells. The EEPROM stores non-volatile data like the ECDSA private key, the public-key certificate, the AES secret key, and potentially other user-specific data up to 4K bits, which can be written in a personalization phase or during the protocol execution.

Datapath Unit The datapath of our processor is shown in Figure 2. It is mainly composed of an ECDSA and AES datapath. Both datapaths share one single 40-bit accumulator register which pursues the strategy of reusing components for ECDSA and AES. The 40-bit register is used as accumulator for ECDSA (multiply-accumulate unit) as well as intermediate storage for AES. The AES datapath is mainly composed of an S-box submodule, a Mix-Columns submodule, five multiplexers, one XOR gate, and two 16-to-8 bit converters. The converters are used since we decided to implement the AES operations with 8 bits instead of 16. The remaining 8 bits are used to store random values which are required to perform dummy operations3 . The AES datapath has been implemented similar to the work of M. Feldhofer et al. [START_REF] Feldhofer | Strong Authentication for RFID Systems using the AES Algorithm[END_REF]. For the S-box operation, we calculated the substitution values using combinatorial logic instead of a look-up table, which reduces the number of additional gates. Furthermore, the MixColumns operation has been realized as an individual submodule which generates one byte of the AES State using one single clock cycle. The ShiftRows and AddRoundKey operations, in contrast, have been realized without expensive logic circuits. These operations need several controlling signals and one XOR gate. The AES constant Rcon has been externally stored in the ROM memory. In addition, we integrated an operand-isolation technique (also often referred to as sleep logic) to reduce the power consumption of the processor. If AES in enabled, the operands for AES get isolated from the ECDSA datapath. This eliminates unnecessary power dissipation and reduces the power consumption of the processor by about 13 %.

The ECDSA datapath is mainly composed of a 16 × 16-bit multiplier, two 40-bit adders, and five multiplexers. For low-area reasons, we decided to use a 16bit multiply-accumulate (MAC) architecture to perform a finite-field multipleprecision multiplication. For this, partial products are calculated and accumulated in the common register to perform a multiplication. The implemented algorithm for the multiple-precision modular multiplication is described in Section 4.

SHA-1 is an integral part of ECDSA and is used to hash digital messages. Thus, we decided to integrate all needed components to perform SHA-1 operations into the ECDSA datapath. These are four additional 16-bit logic gates, i.e. AND, OR, XOR, and NOT. The logic operations are directly connected to port A and port B of the entire datapath. The bitop and mux multiplexer are then used to output the result of the appropriate operation. For a detailed description of the SHA-1 standard see the FIPS-180-3 [START_REF]Secure Hash Standard[END_REF] standard.

Low-Resource Microcontroller A sophisticated two-layer approach was necessary to efficiently implement the controlling of the cryptographic processor. The generation of control signals for various irregular algorithms and protocols, which require in total several 100 000 clock cycles, is very complex. The highest layer of the controller comprises an 8-bit microcontroller with a highly optimized instruction set. It performs higher-level functions like protocol handling, point multiplication, and invocation of round functions for SHA-1 and AES, for instance, due to its ability for looping and subroutine calls. The advantage of having a microcontroller is that it is very flexible because of extending the functionality by simple Assembler programming. Basically the microcontroller sets up and calls certain instructions which lie in a subsequent microcode ROM table (the second control layer). For the execution of such instructions, which can take up to 102 clock cycles, the start address in the microcode ROM has to be provided. While the microcode ROM provides instructions for the datapath and the memory via the instruction and the address decoder, the microcontroller can set up the next instruction. This avoids idle cycles of the datapath during execution of the algorithm.

Our proposed microcontroller is based on a Harvard architecture, i.e. program memory and data memory are separated. Such a design has the advantage that the program memory can have a different word size than the data memory. The microcontroller is a Reduced Instruction Set Computer (RISC) supporting 32 instructions that have a width of 16 bits. The instructions are mainly divided into four groups: logical operations like XOR and OR, arithmetic operations like addition (ADD) and subtraction (SUB), control-flow operations like GOTO and CALL, and microcode instructions (MICRO).

Arithmetic-Level Implementation

Modular multiplication is the most resource-consuming operation in an ECC implementation. In fact, more than 80 % of the execution time is due to finite-field multiplications. In the following, we describe the implemented modular multiplication with interleaved NIST reduction. Modular addition and subtraction have a minor impact on the overall performance and they have been implemented according to [START_REF] Hankerson | Guide to Elliptic Curve Cryptography[END_REF].

NIST P-192 Modular Multiplication

The given algorithm is based on a product scanning (Comba) method and performs a modular multiplication using Algorithm 1 Modular multiplication with interleaved NIST P-192 reduction.

Require: a, b ∈ [0, p -1], S ∈ [0, 2 3W -1], ε ∈ [0, t + t/3 -1]. Ensure: c = a * b (mod 2 192 -2 64 -1).
1. S ← 0. 2. for i from 0 to t -1 do 3.

for j from t -1 to i do 4.

S ← S + A[j]*B[i + t -j].

5.

end for 6.

C t 2 single-precision multiplications, where t represents the number of words of the processor, i.e. 12 in our case. In general, a multiplication by two 192-bit integers a, b ∈ [0, p < 2 W t ) will result in a 384-bit result c, where W represents the number of bits of a word (e.g. [START_REF] Kocher | Differential Power Analysis[END_REF]) and p represents the NIST prime p = 2 192 -2 64 -1. Instead of storing the 384-bit result in memory, we reduced the result during the multiplication (interleaved reduction and multiplication). Thus, no additional memory is needed for the multiplication. We make use of the following congruency [START_REF] Solinas | Generalized mersenne numbers[END_REF], i.e.

c ≡ c 5 2 128 + c 5 2 64 + c 5 (1)
+ c 4 2 128 + c 4 2 64 + c 3 2 64 + c 3 + c 2 2 128 + c 1 2 64 + c 0 (mod p),
where c i are 64-bit integers. Equation [START_REF] Batina | Low-Cost Elliptic Curve Cryptography for Wireless Sensor Networks[END_REF] shows that c can be reduced by simple additions. The first three lines reduce the higher part c high = c 5 2 320 + c 4 2 256 +c 3 2 192 . The result is then added to the lower part c low = c 2 2 128 +c 1 2 64 + c 0 .

The algorithm for the modular multiplication with interleaved NIST reduction is given in Algorithm 1. First, the higher part of the 384-bit result is calculated (line 1-8). Second, the higher part is reduced by subsequent additions to the lower part of c (line 9-21). After that, the lower part of the 384-bit result is calculated and added to the already reduced result (line 23-34). In line 27-31, the carry ε is reduced by adding ε to the accumulator variable S at word index 0 (line 22) and t/3 = 4 (line 28). Finally, a last reduction is performed in line 35-44 to reduce the final carry ε.

The modular multiplication has been implemented as a fully unrolled microcode instruction. It needs 204 clock cycles to perform a modulo multiplication of two 192-bit numbers. Modular addition and subtraction need 31 clock cycles.

Algorithm-Level Implementation

The SHA-1 Algorithm

For our ECDSA processor, we decided to sign messages with a fixed length of 16 bytes. This constraint allows us to reduce the SHA-1 implementation to only one 512-bit message block W . In addition, the message padding can be implemented a priori by storing the length of the message in ROM. Thus, the 16-byte message can be simply copied into the RAM before signature generation. Message padding is done during the computation of ECDSA by copying the length of the message at the end of the input block W .

We implemented 13 different microcode instructions for SHA-1 and made several modifications to improve the performance (see Algorithm 2). First, since line 13 and line 20 are the same, i.e. F ← (B ⊕ C ⊕ D), we implemented only one microcode instruction that is invoked two times during the computation. Second, Algorithm 2 The Secure Hash Algorithm (SHA-1) [START_REF]Secure Hash Standard[END_REF].

Require: 512-bit block W ; H0, H1, H2, H3, H4, T, F, A, B, C, D, E ∈ [0, 2 32 -1]. Ensure: h = SHA-1(W ). if (i ≥ 16) then 5.

W

[i] ← W[i-3] ⊕ W[i-8] ⊕ 6. W[i-14] ⊕ W[i-16] 1. 7. end if 8. T ← (A 5) + W[i]. 9.
if (i < 20) then 10.

F ← (B ∧ C) ∨ (B∧ D). 11.

T ← T + 0x5A827999. 12.

else if (i < 40) then 13.

F ← (B ⊕ C ⊕ D). 14.

T ← T + 0x6ED9EBA1. 15.

else if (i < 60) then

16. F ← (B ∧ C) ∨ (B ∧ D) ∨ 17.
(C ∧ D). 18.

T ← T + 0x8F 1BBCDC. instead of copying the values of the state variables (A,B,C,D,E,T) as shown in line 25+26, we simple rotated the addressing of the variables. Thus, no additional clock cycles are needed and the addresses get shifted by the microcontroller in every loop iteration. Third, all bit-shift operations are realized by multiplication. A left shift by one (line 6) is a simple multiplication with the constant 2, a shift by five (line 8) is a multiplication by 32, and a shift by 30 (line 24) is realized by a multiplication with 16 384. Thus, no dedicated shifting unit is necessary in the datapath of the processor and the multiplier of the ECDSA datapath gets simply reused by the design. Fourth, the constants K0...K4 and the initial values for H0...H4 are stored in ROM and are loaded by the microcode instructions. Fourth, the round loop i is done by the microcontroller which also performs the branching at certain loop indices. Since the microcontroller can prepare the loopindex calculation during the execution of a microcode instruction, additional clock cycles are saved. In total, our processor needs 3 639 clock cycles to hash a 512-bit message.

The AES Algorithm

For AES, we implemented 11 microcode instructions. As already stated in Section 3.1, we extended the 16×8-bit AES State to 16×16-bit where 8 bits are used to store the real State and the other 8 bits store random values (r 0 ...r 15 ).

Figure 3 shows the processing of the first AES State. The first operations are SubBytes and ShiftRows which transform the State column-wise, i.e. four byte blocks. First, each byte of the State is loaded and substituted by the S-box unit. In order to implicitly shift the bytes of the State for the ShiftRows operation, we simply addressed the appropriate bytes in the State. Thus, each byte of a column is addressed accordingly (address 0, 5, 10, and 15 in our example) and substituted afterwards. The result is stored in the accumulator of the datapath. After that, the bytes are loaded from the accumulator and processed by the MixColumns operation. The output is then XORed with the key within the AddRoundKey operation. Finally, the result is stored back into the AES State. Since we processed the bytes of a column without the ShiftRows operation (in fact the bytes have not been shifted before MixColumns), we stored the resulting bytes in the correct position within the State. However, to avoid overwriting of data, we simply swap the values of the real and dummy State. Thus, after the first round, the dummy values are stored in the lower 8 bits and the real values are stored in the higher 8 bits of the State.

In order to make the implementation less attractive to side-channel attacks, we integrated several countermeasures described in the following. As a first countermeasure, we integrated dummy operations before and/or after the actual Ad-dRoundKey operation. 16 dummy operations are performed in total where the actual operation is widespread over 17 different locations in time.

As a second countermeasure, we randomized the processing of the bytes in the AES State which is often referred as byte-shuffling countermeasure. For this, we randomized the byte position after the SubBytes operation. The transformed bytes are stored in the accumulator with a random offset. After MixColumns and AddRoundKey transformation, the offset is incorporated through the right addressing of the State. As a third countermeasure, we added 16 dummy rounds to the actual rounds. In fact, we performed dummy rounds only in the first and second round and the last two rounds of AES. This has its reason in the fact that side-channel attacks need to target intermediate values which can be generated by a model with less computational effort. Targeting intermediates of higher rounds would increase the computational effort significantly to generate values for each possible key. It is therefore sufficient to consider only the first and last two rounds of AES to obtain an appropriate protection.

All implemented countermeasures are commonly used in practice and provide a state-of-the-art protection for cryptographic devices. For a more detailed description about dummy operations and shuffling (hiding techniques), see the work of Mangard et al. [START_REF] Mangard | Power Analysis Attacks -Revealing the Secrets of Smart Cards[END_REF].

ECC Scalar Multiplication

We applied the Montgomery ladder as scalar multiplication method given in Algorithm 3. This is due to the fact that it provides security against several attacks, e.g. Simple Power Analysis (SPA) attacks [START_REF] Kocher | Differential Power Analysis[END_REF][START_REF] Mangard | Power Analysis Attacks -Revealing the Secrets of Smart Cards[END_REF] and safe-error attacks [START_REF] Yen | Checking Before Output May Not Be Enough Against Fault-Based Cryptanalysis[END_REF]. Furthermore, it allows to perform all group operations with x-coordinate only formulae [START_REF] Joye | The Montgomery Powering Ladder[END_REF].

We applied the idea of N. Meloni [START_REF] Meloni | Fast and Secure Elliptic Curve Scalar Multiplication Over Prime Fields Using Special Addition Chains[END_REF] and Y. Lee et al. [START_REF] Lee | Elliptic-Curve-Based Security Processor for RFID[END_REF] and performed the computations in a common-Z coordinate representation. The idea is to satisfy that the Z coordinate of each curve point is the same during each Montgomery ladder iteration. Only three coordinates have to be maintained during every differential addition and doubling operation instead of normally four, i.e. X 0 , X 1 , and Z. By applying the method, we did not reduce the needed number of intermediate registers but rather improved the point-multiplication performance. One Montgomery loop iteration needs therefore 12 finite-field multiplications, 4 squarings4 , 9 additions, and 7 subtractions. The memory stores three coordinates (X 0 , X 1 , and Z) and four intermediate values of 192 bits.

As a side-channel countermeasure, we applied the randomized projective coordinate (RPC) countermeasure as proposed by S. Coron [START_REF] Coron | Resistance against Differential Power Analysis for Elliptic Curve Cryptosystems[END_REF] in 1999. Before starting a point multiplication, we generate a random number λ and performed one finite-field multiplication to randomize the affine x-coordinate of the base point x P to obtain the randomized projective coordinates (X 0 , Z 0 ) = (λx P , λ).

After scalar multiplication, we perform a check if the point is still a valid point on the elliptic curve. For this, we recovered the coordinates (X 0 , Y 0 , Z 0 ) according to Izu et al. [START_REF] Izu | Improved Elliptic Curve Multiplication Methods Resistant against Side Channel Attacks[END_REF] and evaluated Z 0 (Y 2 0 -bZ 2 0 ) = X 0 (X 2 0 + aZ 2 0 ) according to N. Ebeid and R. Lambert [START_REF] Ebeid | Securing the Elliptic Curve Montgomery Ladder Against Fault Attacks[END_REF]. Finally, the projective coordinates (X 0 , Z 0 ) are transformed back into affine coordinates by applying a finite-field inversion and multiplication, i.e. x Q ← X 0 • Z -1 0 .

Algorithm 3 The implemented ECC scalar multiplication method based on the Montgomery ladder.

Require:

Base point P = (xP , yP ) ∈ E(Fp192), k ∈ [1, n -1], random λ Ensure: Q = kP , where Q = (xQ, yQ) ∈ E(Fp192) 1: (X0, Z0) ← (λxP , λ). 2: (X1, Z1) ← Dbl(P ). 3: X0 ← X0 • Z1, X1 ← X1 • Z0, Z ← Z0 • Z1. 4: for i = 190 downto 0 do 5: (X k i ⊗1 , X k i , Z) ← Dif f erentialAdditionAndDoubling(X k i , X k i ⊗1 , Z). 6: end for 7: (X0, Y0, Z0) ← Y recovery(X0, X1, Z, P ). 8: if Z 0 (Y 2 0 -bZ 2 0 ) = X 0 (X 2 0 + aZ 2 0 ) abort. 9: xQ ← X0 • Z -1
0 . 10: Return (xQ).

ECDSA Implementation

After scalar multiplication, all performed operations are done modulo the prime n. The implemented ECDSA signature generation algorithm is shown in Algorithm 4. Modulo multiplication has been implemented according to the Montgomery multiplication algorithm proposed by G. Hachez and J. J. Quisquater [START_REF] Hachez | Montgomery Exponentiation with no Final Subtractions: Improved Results[END_REF]. We implemented five microcode instructions to perform the operation. The Montgomery inversion has been implemented by the algorithm proposed by B. Kaliski [START_REF] Kaliski | The Montgomery Inverse and its Applications[END_REF]. For that operation we implemented seven microcode instructions.

Algorithm 4 Signature Generation using ECDSA.

Require: Domain parameters D = (q, F R, S, a, b, P, n, h), private key d, message m. Ensure: Signature (r, s) Random numbers have been generated according to the FIPS 186-2 [START_REF]3: Digital Signature Standard (DSS)[END_REF] standard. The standard describes a hash-based pseudo-random number generator that can be realized with the SHA-1 algorithm. Our decision has mainly two reasons. First, the process of random number generation is based on a standard specification and is considered to be cryptographically secure. Second, we already need a hash calculation for the message-digest calculation in ECDSA and we can simply reuse the implementation of the SHA-1 algorithm for that purpose. The prerequisite is to load a true-random seed from an external source into RAM. The random number is hashed and the message digest is stored as a seed key (XKEY). This seed key is then used in any higher-level protocol to generate any random numbers needed to provide the cryptographic service.

1: Select k ∈ [1, n -1] 2: Compute Q = kP = (xQ, yQ). 3

Results

We implemented our processor in a 0.35 µm CMOS technology using a semicustom design flow with Cadence RTL Compiler as synthesis tool. The summarized results are shown in Table 1 and Table 2. The total chip area of 21 502 GEs includes datapath, ROM, RAM macro, and controller for ECDSA, SHA-1, and AES (including microcontroller and microcode control and ROM). Note that we included a standard RAM macro needing 8 727 GEs that can be further minimized using an area-optimized RAM block.

We also synthesized our processor without the AES datapath microcode entries resulting in 19 115 GEs. This means that the integration of AES needs 2 387 GEs which is lower than existing stand-alone (and finite-state machine based) AES modules. The same has been done with SHA-1. Even though ECDSA required SHA-1 for signing of messages, we removed any SHA-1 related implementation to validate the overhead. These are program-ROM entries, microcode instructions, decoder circuits, and the logic operations in the ECDSA datapath. After synthesis, we obtain 20 613 GEs which means that SHA-1 needs an area of 889 GEs (180 GEs for program ROM, 546 GEs for microcode instructions, and 163 GEs for the datapath).

In view of ECC, our processor needs 753 393 clock cycles for one point multiplication. The entire ECDSA signing process needs 863 109 clock cycles including side-channel and fault-attack countermeasures (RPC and point-validity check). AES with byte shuffling needs 4 529 clock cycles and 15 577 cycles with 10 dummy-round operations enabled. Note that the number of clock cycles for AES thus varies depending on the number of added dummy rounds. The more dummy rounds, the higher the security level and the higher the needed number of clock cycles. SHA-1 needs 3 639 clock cycles for hashing a 512-bit message block. The SHA-1 algorithm has also been used to generate random numbers. For ECDSA, four SHA-1 computations are performed to generate the needed random numbers which needs 14 947 clock cycles. We also evaluated the critical path of our processor and determined a maximum clock frequency of 33 MHz.

The mean current of the circuit is 485 µA at 847 kHz and 3.3 V and has been simulated using Synopsis NanoSim. This value includes the power consumption of the entire processor including microcontroller, ECDSA, SHA-1, and AES datapath, and memory. Note that we based our design on a rather old CMOS process technology (0.35 µm) so that further power reductions can be achieved by using a smaller process technology (for example CMOS 0.13 µm).

We compare our implementation with existing ASIC solutions over primefield arithmetic. Since there does not exist any implementation of both ECDSA and AES within one processor, we have to compare it with ECC (or ECDSA) only implementations. The processor of F. Fürbass et al. [START_REF] Fürbass | ECC Processor with Low Die Size for RFID Applications[END_REF] needs 23 656 GEs and 502 000 clock cycles, J. Wolkerstorfer [START_REF] Wolkerstorfer | Is Elliptic-Curve Cryptography Suitable for Small Devices?[END_REF] needs 23 800 GEs and 677 000 clock

Conclusions

In this article we presented the first stand-alone cryptographic processor which performs ECDSA using the recommended NIST elliptic curve over F p192 and AES-128. We improved the state-of-art of building cryptographic processors for low-resource devices on the arithmetic level, on the architectural level (combined ECDSA, SHA-1, and AES module), and on the implementation level. The processor's architecture has an optimized 16-bit datapath and a controller with an integrated 8-bit microcontroller, both implemented in standard-cells. The entire chip has an area of 21 502 GEs where AES requires 2 387 GEs and SHA-1 requires 889 GEs. Currently, we are about to manufacturing the chip on a 0.35 µm CMOS process technology. The chip will be integrated in a passively powered Near Field Communication (NFC) device.

Fig. 1 .

 1 Fig. 1. Architecture of the Cryptographic Processor.

Fig. 2 .

 2 Fig. 2. Architecture of the ECDSA and AES Datapath.

1 .

 1 A = H0; B = H1; C = H2; 2. D = H3; E = H4. 3. for i from 0 to 79 do 4.

Fig. 3 .

 3 Fig. 3. The processing of the State in the first AES round.

:

  Compute r = xQ mod n. If r = 0 then go to step 1. 4: Compute e = SHA-1(m). 5: Compute s = k -1 (e + dr) (mod n). If s = 0 then go to step 1. 6: Return (r, s).

Table 1 .

 1 Area of chip components.

	Component	GE
	Datapath	3 393
	Memory without RAM	729
	RAM macro (128x16-bit)	8 727
	Controller	8 653
	ECDSA+SHA1+AES Total 21 502
	Overhead of AES	2 387
	Overhead of SHA-1	889

Table 2 .

 2 Cycle count of operations. Hutter et al. [10] need 19 115 GEs and 859 188 clock cycles. The work of A. Satoh et al. [24] needs 29 655 GEs and 4 165 000 clock cycles for the same size of prime-field arithmetic and E. Wenger et al. [26] need 11 686 GEs and 1 377 000 clock cycles. Note that a fair comparison is largely infeasible since the implementations differ in several ways, for example they do not use RAM macros and do not contain an AES implementation.

	Component	Cycles
	PRNG generation (4× SHA-1)	14 947
	Point multiplication	753 393
	Point-validity check	29 672
	Final signing process	65 097
	ECDSA Total	863 109
	SHA-1	3 639
	AES with shuffling	4 529

Dummy operations are types of hiding countermeasure techniques against sidechannel attacks (see[START_REF] Mangard | Power Analysis Attacks -Revealing the Secrets of Smart Cards[END_REF] for more details).

The squaring operation is realized by a simple multiplication operation.

Acknowledgements.

The work has been supported by the Austrian Government through the research program FIT-IT Trust in IT Systems (Project CRYPTA, Project Number 820843), and by the IAP Programme P6/26 BCRYPT of the Belgian State (Belgian Science Policy).