CRYPTANALYSIS AND ENHANCEMENT OF PASSWORD AUTHENTICATION SCHEME FOR SMART CARD

Raphael Nyirongo1, Solomon Kuonga1, Patrick Ali1, Levis Eneya1 and Hyunsung Kim1,2

 1Mathematical Sciences Department, University of Malawi, Chancellor College,Zomba, Malawi

2(Corresponding Author) Department of Cyber Security, Kyungil University, Kyungbuk, Korea

ABSTRACT

Password authentication with smart card is one of the simplest and efficient authentication mechanisms to ensure secure communication over insecure network environments. Recently, Tsai et al. proposed an improved password authentication scheme for smart card. Their scheme is more secure than the other previous schemes. In this paper, we show Tsai et al.’s scheme is vulnerable to password guessing attack and has computational overhead. Furthermore, we propose an enhanced password authentication scheme to eliminate the security vulnerability and enhance the overhead. By presenting concrete analysis of security and performance, we show that the proposed scheme cannot only resist various well known attacks, but also is more efficient than the other related works, and thus is feasible for practical applications.

KEYWORDS

Information Security, User Authentication, Password Authentication, Smart Card, Timestamp

1. INTRODUCTION

More resources are getting distributed over the network due to the rapid progress in information technology, which is managed by servers in distributed systems [1]. Many systems that control remote access to computer networks use password based authentication and many people researched about how to make secure authentication [2-4]. However, the password is easily exposed by guessing attacks [3]. However, there still exists challenges in both security and performance aspects due to the stringent security requirements and resource strained characteristics of the clients.

Since Chang et al. in [5] introduced the first remote user authentication scheme using smart cards, there has been many of such schemes proposed [6-9]. One prominent issue in this type of schemes is security against offline guessing attack. Traditionally, to prevent an adversary from launching offline guessing attack, one needs to make sure that the scheme is not going to leak any information useful about the client’s password to the adversary in the protocol run, even though the password is considered to be weak and low-entropy. By observing this, many schemes assumed that the smart card is tamper-resistant, i.e., the secret parameters stored in the smart card cannot be revealed. However, recent results have demonstrated that the secret data stored in the  smart card could be extracted by some means, such as monitoring the power consumption [10] or analyzing the leaked information [11]. Therefore, such schemes [6-8] based on the tamper resistance assumption of the smart card are at least vulnerable to offline password guessing attacks, once an adversary has obtained the secret data stored in a user’s smart card [12-14]. Consequently, a stronger notion of security against offline guessing attack is developed to require that compromising a client’s smart card should not help the adversary launch offline guessing attack against the client’s password.

Recently, Chen et al. proposed a smart card based user authentication scheme [15]. However, Li et al. pointed out some weaknesses in Chen et al.’s scheme and they also proposed an enhanced smart card based on a user authentication scheme to resist the above flaws existing in Chen et al.’s scheme [16]. However, Wei et al. showed that Li et al.’s scheme is powerless against the offline password guessing attack and they also proposed an efficient and secure smart card based remote user password authentication scheme [17]. Wei et al.’s scheme is more efficient and secure than other schemes.  owever, Tsai et al. unfortunately presented security weaknesses on password guessing attack, privileged insider attack and denial of service attack against Wei et al.’s scheme [18]. Furthermore, Tsai et al. proposed an improvement authentication scheme in [18] and argued that their scheme is secure against various attacks.

This paper provides security and performance analyses on Tsai et al.’s scheme focused on password guessing attack vulnerability and computational overhead concern after reviewing the scheme briefly. Addition to that, we propose an enhanced password authentication scheme (EPAS) as a remedy scheme, which is based on hash function and using biometric authentication. For the computational efficiency, the enhanced scheme tries to remove the expensive exponentiation operation, which is extremely slower than the symmetric key cryptosystem operation or hash function. We provide the security of the enhanced scheme based on the BAN logic and hash based oracle.

2. REVIEW OF TSAI ET AL.’S AUTHENTICATION SCHEME

In this section, we briefly review Tsai et al.’s improved password authentication scheme with smart card [18]. Tsai et al.’s scheme is composed of three phases, registration, login and authentication.

2.1. REGISTRATION PHASE

In this phase, the server SV makes a smart card SC for a new user, Ui. The smart card SC contains six parameters, {Ai, p, q, h(.), r, Wi}, where Ai= h(x||IDi)+h(IDi||h(PWi||r)); Wi = h(PWi||r); h(.) denotes a secure hash function (h(.): {0, 1}* -> Zp*); p and q are two large prime numbers such that p = 2q + 1; x denotes a master secret key (x ∈ Zq*); r is a random number; IDi and PWi are user’s identity and password, respectively. p, q, x, and h(.) are selected by SV. IDi , PWi and r are selected by Ui  Ui sends {IDi, h(PWi ||r)} to SV.  V does not know the random number r.

2.2. LOGIN PHASE

In this phase, Ui wants to login into SV for obtaining some services; Ui first attaches his (or her) smart card to a device reader and inputs his (or her) identity IDi and password PWi. The login phase is executed as follows:LP1) Ui sends the login request parameters, his (or her) identity IDi and password PWi to the smart card SC. SC computes Wi’ = h(PWi
||r) and checks whether Wi’ is equal to Wi . If it holds, SC executes the next steps. If Ui fails to verify IDi and PWi for 3 times, Ui will lock SC. LP2) SC computes Bi, Di, Fi, Mi as follows: Bi= Ai−h(IDi||h(PWi||r)) = h(x||IDi); Di= h(IDi) a mod p; Fi= Di+Bi; Mi = h(IDi||Fi ||T1)⊕Bi, where T1 denotes the current timestamp of SC and a denotes a random number. LP3) SC sends {IDi, Fi, Mi, T1} to SV.

The adversary only has three times to guess the user’s password in Step 2 of the login phase.

2.3. AUTHENTICATION PHASE

Upon receiving the authentication request message {IDi, Fi, Mi, T1} from Ui, SV executes this authentication phase as follows:

AP1) SV checks whether IDi format and the timestamp T1 are in valid time or not. If both of conditions hold, SV continuously authenticates the following steps.

AP2) SV checks whether Mi’ = h(IDi ||Fi ||T1)⊕h(x||IDi) is equal to Mi or not. If it does not hold, SV rejects the login request. Otherwise, SV computes Vi = h(IDi) b mod p and MS =h(IDi ||Di’||Vi ||Zi ||TS); where b is a random number, Di’ = Fi-h(x||IDi) = h(IDi) a mod p, Zi = (Di’) b mod p, and TS is the current time of SV. Finally, SV sends the message {IDi , Vi , MS, TS} to Ui.

AP3) After receiving the message, SC checks IDi and compares TS with TS’, where TS’ the time that the message is received. If IDi is valid and TS’-TS ≤ T, SC computes Zi’ = Vi a
mod p, MS’ = h(IDi ||Di ||Vi ||Zi’||TS). If MS’ ≠ MS, the session is terminated. Otherwise, SV is authenticated by Ui , and the shared session key is set as sk = h(IDi ||Di
||Vi ||Zi’). Furthermore, Ui gets the current time Ti new, and generates a response message Ri = h(IDi ||Di ||Vi ||Zi’||Ti new), and then sends the message {IDi , Ri , Ti
new} to SV.

AP4) Upon receiving the response message, SV checks IDi and Ti new. If they are valid, SV computes Ri’ = h(IDi ||Di’||Vi ||Zi ||Ti new). If Ri’≠ Ri , SV terminates the session. Otherwise, Ui is authenticated by SV, and the shared session key is set as sk’ = h(IDi ||Di’||Vi ||Zi). Finally, an agreed session key sk = sk’ is established between Ui
and SV.

3. ANALYSES OF TSAI ET AL.’S AUTHENTICATION SCHEME

In this section, we provide security analysis and computational overhead analysis. First of all, we will show that Tsai et al.’s scheme in [18] is weak against password guessing attack based on two adversary assumptions. Furthermore, it has big computational overhead due to exponentiation operations in the authentication phase.

3.1. PASSWORD GUESSING ATTACK FEASIBILITY

For the security analysis, we will follow Xu et al.’s two assumptions of the adversary’s
capabilities explicitly made in this kind of authentication scheme [19] :

A1) Adversary has total control over the communication channel between the users and the remote server in the protocol run, which means the adversary can intercept, insert, delete, or modify any message transmitted in the channel.

A2) Adversary may either steal a user’s smart card and then extract the information from it by the method introduced by Kocher et al. [20], or obtain a user’s password, but not both.

They have been widely accepted as the standard threat model for cryptographic protocols [21].

By A2, an adversary A can obtain Ui’s smart card and extract the data {Ai , p, q, h(.), r, i}.
Subsequently, A can launch off-line password guessing attacks as follows:
(1) A picks up a password candidate PWi’.

(2) A computes Wi′= h(PWi′ ||r). Note that if PWi ′ =PWi , then it holds that Wi ′ =Wi , which means that A can verify the validity of PWi ′ . Otherwise, A repeats the above procedure until the correct password is found.

In Tsai et al.’s scheme, the password is selected by the user, which indicates that it is value easy to remember and guess, rather than random numbers with high entropy. Thereby, Tsai et al.’s scheme is still weak against password guessing attack.

3.2. Computational Overhead Concern

For the computational overhead analysis, we need to check the following steps of LP2, AP2 and AP3 from Tsai et al.’s scheme.

LP2) SC computes Bi, Di, Fi, Mi as follows: Bi = Ai−h(IDi ||h(PWi ||r)) = h(x||IDi); Di
= h(IDi) a mod p; Fi = Di+Bi; Mi = h(IDi ||Fi ||T1)⊕Bi , where T1 denotes the current timestamp of SC and a denotes a random number.

AP2) SV checks whether Mi’ = h(IDi ||Fi ||T1)⊕h(x||IDi) is equal to Mi or not. If it does not hold, SV rejects the login request. Otherwise, SV computes Vi = h(IDi) b mod p and MS = h(IDi ||Di’||Vi ||Zi ||TS); where b is a random number, Di’ = Fi-h(x||IDi) = h(IDi) a mod p, Zi = (Di’) b mod p, and TS is the current time of SV. Finally, SV sends the message {IDi , Vi, MS, TS}to Ui.

AP3) After receiving the message, SC checks IDi and compares TS with TS’, where TS’ the time that the message is received. If IDi is valid and TS’-TS ≤ T, SC computes Zi’ = Vi a mod p, MS’ = h(IDi ||Di ||Vi ||Zi’||TS). If MS’ ≠ MS, the session is terminated.  therwise, SV is authenticated by Ui , and the shared session key is set as sk = h(IDi ||Di ||Vi ||Zi’). Furthermore, Ui gets the current time Ti new, and generates a response message Ri =  (IDi ||Di ||Vi ||Zi’||Ti new), and then sends the message {IDi , Ri , Ti new} to SV.

The scheme requires modular exponentiation operations to compute Di, Vi and Zi , which requires a big overhead than the other operations.

4. ENHANCED PASSWORD AUTHENTICATION SCHEME

In this section, we propose a new enhanced password authentication scheme (EPAS) with smart card, which could solve all the security and overhead problems depicted in the previous section. Especially, EPAS uses biometrics to cope from the attack and removes the expensive operations to be computationally effective. EPAS has three phases, registration, login and authentication. Figure 1 shows the flows of EPAS.

Initially, the server SV initializes system parameters. SV chooses its master secret key x ∈ Zp* and two secure hash functions, h(.): {0, 1}* -> Zp* and H(.): {0, 1}* -> Zp*.

4.1. REGISTRATION PHASE

When a user Ui  wants to be a member of SV, this phase is performed as follows:

(1) Ui selects his (or her) identity IDi and password PWi after generating a random number r. Ui computes h(PWi ||r) and submits {IDi, h(PWi ||r)} to SV as the registration request message via a secure channel.

(2) After receiving the message, SV checks whether IDi is valid or not. If it is not, SV rejects the request. Otherwise, SV computes Ai = h(x||IDi)⊕h(IDi ||h(PWi ||r)) and issues a smart card SC to Ui via a secure channel, which stores {Ai , p, h(.), H(.)}.

(3) After receiving the SC, Ui inputs PWi and r, imprints his (or her) fingerprint b,  computes Wi = h(PWi ||r||H(b)) and stores r and Wi into SC.

4.2. LOGIN PHASE

In this phase, Ui logins into SV for some services; Ui first attaches his (or her) smart card to the smart card reader and inputs his (or her) identity IDi , password PWi and fingerprint b. The login phase is executed as follows:

(1) Ui inputs his (or her) identity IDi, password PWi and fingerprint b to SC. SC computes Wi′=h(PWi ||r||H(b)) and checks whether Wi ′ is equal to Wi . Only if it holds, SC executes the next steps. If Ui fails to verify IDi , PWi and b for 3 times, SC will be locked.

(2) SC computes Bi, Di, Fi and Mi as follows: Bi = Ai⊕h(IDi||h(PWi||r)) = h(x||IDi); Di
= h(IDi)⊕a;Fi= Di⊕Bi; Mi = h(IDi||Fi||Bi||T1), where a denotes a random number and T1 denotes thecurrent timestamp of SC.

(3) SC sends {IDi, Fi, Mi, T1} to SV.

The adversary only has three times chance to guess the user’s password in Step 1 of the login phase.

Capture

Figure 1. Enhanced password authentication scheme

4.3. AUTHENTICATION PHASE

Upon receiving the authentication request message {IDi, Fi, Mi, T1} from Ui, SV executes this authentication phase as follows:
(1) SV checks whether IDi format and the timestamp T1 are valid or not. If both of conditions hold, SV continuously performs the following steps.

(2) SV checks whether Mi′= h(IDi||Fi||h(x||IDi)||T1) is equal to Mi or not. If it does not hold, SV rejects the login request. Otherwise, SV computes Vi = h(IDi)⊕h(x||IDi)⊕v, sk =
h(IDi ||Di||Vi||a′||v) and MS = h(IDi||Di′||Vi||sk||a′||v||TS); where v is a random number, Di′=Fi⊕h(x||IDi) = h(IDi)⊕a, a′= Di′ ⊕h(IDi) and TS is the current time stamp of SV. Finally, SVsends the message {IDi, Vi, MS, TS} to Ui.

(3) After receiving the message, SC checks IDi and compares TS with TS ′ , where TS′ is the time stamp of SC when the message is received. If IDi is valid and TS′ -TS ≤ ∆T, SC computes v′=Vi⊕h(IDi)⊕Bi, sk′= h(IDi||Di||Vi||a||v′) and MS′= h(IDi||Di||Vi||sk′||a||v′||TS). If MS′≠ MS, SC terminates the session. Otherwise, SV is authenticated by Ui , and the shared session key is set as sk′ . Furthermore, Ui gets the current time Ti new, generates a response message Ri = h(IDi||Di||Vi||v′||sk′||Tinew), and sends the message {IDi, Ri, Tinew} to SV.

(4) Upon receiving the response message, SV checks IDi and Ti new. If they are valid, SV computes Ri ′= h(IDi||Di′||Vi||v||sk′||Tinew). If Ri′≠ Ri, SV terminates the session. Otherwise, Ui is authenticated by SV, and SV believes that an agreed session key sk = sk′
is established between Ui and SV.

4.4. PASSWORD CHANGE PHASE

In this phase, Ui changes his (or her) password PWi into PWnew after the success of user
authentication from SC. Ui first attaches his (or her) smart card to the smart card reader and inputs his (or her) identity IDi , password PWi and fingerprint b. The password change phase is executed as follows:

(1) Ui sends the password change parameters, his (or her) identity IDi , password PWi and fingerprint b to SC. SC computes Wi ′ = h(PWi ||r||H(b)) and checks whether Wi′ is equal to Wi. If it holds, SC asks an input of a new password PWnew to Ui. Otherwise, SC rejects the request.

(2) SC computes Bi= Ai⊕h(IDi||h(PWi||r)), Wnew = h(PWnew||r||H(b)) and Anew = Bi⊕h(IDi||h(PWnew||r)) and updates Wi and Ai with Wnew and Anew, respectively.

5. SECURITY ANALYSES

In this section, we provide security analysis based on BAN logic and formal security analysis. The security analysis of EPAS was conducted under the following assumptions:

1. An adversary A can be either a user or a server. Ui and as well as SC can act as an
adversary.

2. A can eavesdrop on every communication across public channels. He (or she) can capture any message that is exchanged between Ui and SC.

3. A has the ability to alter, delete or reroute the captured message.

4. Information can be extracted from the smart card by examining the power consumption of the card.

5.1. PROOF USING BAN LOGIC

Formal security analysis of EPAS is verified with the help of Burrows, Abadi and  Needham (BAN) logic [22]. The formal analysis of a network security protocol using BAN logic involves

following steps: (1) Converting original scheme statements to their idealized form. (2) Determining the assumptions about the initial state of the system. (3) Representation of the state of the system after executing each statement as logical assertions by attaching logical formulas to each statement. (4) Application of logical postulates to assumptions and assertions.

The following notations are used in formal security analysis using the BAN logic:

Capture.JPG

In addition, the following four BAN logic rules are used to prove that EPAS provides a secure mutual authentication between Ui and SV:

Capture

In order to show that EPAS provides secure mutual authentication between Ui
and SV, we need to achieve the following four goals:

Capture.JPG

Capture.JPG

PROOF:

In the following, we prove the test goals in order to show the secure authentication using the BAN logic rules and the assumptions.

Based on Message 1, we could derive:

 

Capture.JPG

Capture.JPG

Capture.JPG

According to Steps 14 and 20, EPAS successfully achieves both goals (Goals 1 and 2). Both Ui and SV believes that they share a common session key sk = h(IDi ||Di ||Vi ||a||v).

5.2. FORMAL SECURITY ANALYSIS

This subsection demonstrates the formal security analysis of EPAS and shows that it is secure. First of all, we define the hash function [23].

Definition 1. A secure one way hash function h(.): X=0, 1}* -> Y={0, 1}n , which takes an input as an arbitrary length binary string x∈{0, 1}* and outputs a binary string h(x)∈{0, 1}n , which satisfies the following requirements:

a. Given y∈Y, it is computationally infeasible to find an x∈X such that y=h(x).

b. Given x∈X, it is computationally infeasible to find another x′≠ x∈X such that h(x′)=h(x).

c. It is computationally infeasible to find a pair (x′, x)∈X′ ⨯X, with x′≠ x, such that h(x′)=h(x).

Theorem 1. Under the assumption that the one way hash function h(.) closely behaves like an oracle, EPAS is provably secure against an adversary A for the protection of Ui’s identity IDi , password PWi and fingerprint band SV’s secret value x that is selected by SV.

Proof. The formal security proof of EPAS is based on those in [24-26]. Using the oracle to construct A who has the ability to derive Ui’s identity IDi , password PWi and fingerprint b and SV’s secret value x.

Capture.JPG

Capture.JPG

6. PERFORMANCE ANALYSIS

In this section, we summarize the performance analysis of EPAS in terms of the computation complexities. We thus present a performance evaluation to compare EPAS to the other related schemes [17, 18]. We present a comparison of the computational costs, and measure the execution time. The computational analysis of an authentication scheme is generally conducted by focusing on operations performed by each party within the schemes. Therefore, for analysis of the computational costs, we concentrated on the operations that are conducted by the parties in the network: namely a user and a server. In order to facilitate the analysis of the computational costs, we define the following notation.

• Th: the time to execute a one-way hashing operation

• Te: the time to compute a modular exponentiation operation

In addition, in order to achieve accurate measurement, we performed an experiment. This experiment was performed using the Crypto++ Library [27] on a system using the 64-bits Windows 7 operating system, 3.2 GHz processor, 4 GB memory, Visual C++ 2013 Software, the SHA-1 hash function, the AES symmetric encryption/decryption function, and the ECC-160 function. According to our experiment, Th is nearly 0.0002 seconds on average and Te is nearly 0.6 seconds on average.

Capture

7. CONCLUSION

This paper first examined Tsai et al.’s improved password authentication scheme for smart card. Our cryptanalysis showed that the scheme is vulnerable to password  uessing attack once the private information stored in the smart card has been disclosed. In addition, we also pointed out that Tsai et al.’s scheme has computational overhead problem. Subsequently, to overcome the defects existing in the scheme, we proposed an enhanced password authentication scheme for smart card. By presenting the concrete analysis of security, we demonstrated that our proposal is not only free from various well known attacks, but also is more efficient than the other previous related works. Thus, our scheme is more feasible for practical applications.

ACKNOWLEDGEMENTS

Corresponding author is Hyunsung Kim. This research was supported by Basic Science
Research Program through the National Research Foundation of Korea (NRF) funded by
the Ministry of Education (NRF-2017R1D1A1B04032598)

REFERENCES

[1] Prabhakar, M.,(2013)“Elliptic Curve Cryptography in Securing Networks by Mobile Authentication”, International Journal on Cryptography and Information Security, Vol. 3, No. 3, pp 31-46.

[2] Valluri, M. R.,(2012)“Authentication Schemes using Polynomials over Non-commutative Rings”, International Journal on Cryptography and Information Security, Vol. 2, No. 4, pp 51-58.

[3] Lee, C.-C. Liu,C.-H.&Hwang, M.-S.,(2013)“Guessing Attacks on Strong-Password Authentication Protocol”, International Journal of Network Security, Vol. 15, No. 1, pp 64-67.

[4] Belgacem, N.,Nait-Ali, A., Fournier, R. & Bereksi-Reguig, F., (2012) “ECG based human
Authentication using Wavelets and Random Forests”, International Journal on  cxryptography and Information Security, Vol. 2, No. 2, pp 1-11.

[5] Chang,C.C.& Wu,T.C.,(1991) “Remote password authentication with smart cards,” IEE ProceedingsComputers and Digital Techniques, Vol. 138, No. 3, pp 165-168.

[6] Chen,T.,Hsiang, H. & Shih, W., (2011) “Security enhancement on an improvement on two remote user authentication schemes using smart cards,” Future Generation Computer Systems, Vol. 27, No. 4, pp 377–380.

[7] Khan, M., Kim, S. & Alghathbar, K., (2011) “Cryptanalysis and security enhancement of a more efficient & secure dynamic id-based remote user authentication scheme,” Computer Communications, Vol. 34, No. 3, pp 305–309.

[8] Wang, Y.,Liu,J., Xiao, F.& Dan,J.,(2009) “A more efficient and secure dynamic id-based remote user authentication scheme,” Computer communications, Vol. 32, No. 4, pp 583–585.

[9] Kim, H.S.& Lee,S.W.,(2010) “Robust Remote User Authentication Scheme using Smart Cards”, Journal of Security Engineering, Vol. 7, No. 5, pp 495-502.

[10] Bogdanov,A.& Kizhvatov, I., (2012) “Beyond the limits of dpa: Combined side-channel collision attacks,” IEEE Transactions on Computers, Vol. 61, No. 8, pp 1153–1164.

[11] Kasper,T.,Oswald,D.& Paar,C.,(2012) “Side-channel analysis of cryptographic RFIDs with analog demodulation,” Lecture Notes in Computer Science, Vol. 7055, pp 61–77.

[12] Chen, B., Kuo, W. & Wuu, L., (2012) “Robust smart-card-based remote user password authentication scheme,” International Journal of Communication Systems, doi: http://dx.doi.org/10.1002/dac.2368. [13] Wen,F.& Li,X.,(2012)“An improved dynamic id-based remote user authentication with key agreement scheme,” Computers & Electrical Engineering, Vol. 38, No. 2, pp 381–387.

[14] Xiang, T.,Wong,K.& Liao,X.,(2008) “Cryptanalysis of a password authentication scheme over insecure networks,” Journal of Computer and System Sciences, Vol. 74, No. 5, pp 657–661.

[15] Chen, B.L.,Kuo,W.C.& Wu, L. C.,(2014) “Robust smart-card-based remote user password authentication scheme”, International Journal of Communication Systems, Vol. 27, No. 2, pp 377– 389.

[16] Li, X.,Niu,J., Khan, M. K. & Liao, J., (2013) “An enhanced smart card based remote user password authentication scheme”, Journal of Network and Computer Applications, Vol. 36, No. 5, pp 1365– 1371.

[17] Wei, J., Liu, W. & Hu, X., (2016) “Secure and efficient smart card based remote user password authentication scheme”, International Journal of Network Security, Vol. 18, No. 4, pp 782–792.

[18] Tsai, C. Y., Pan, C. S. & Hwang, M. S., (2016) “An Improved Password Authentication Scheme for Smart Card”, Recent Development in Intelligent Systems and Interactive Applications, Vol. 541, pp 194-199.

[19] Xu, J.,Zhu, W. T. & Feng, D. G., (2009) “An improved smart card based password authentication scheme with provable security”, Computer Standards and Interfaces, Vol. 31, No. 4, pp 723-728.

[20] Kocher, P., Jaffe, J. & Jun, B., (1999) “Differential power analysis”, Lecture Notes in Computer Science, Vol. pp 388-397.

[21] Dolev,D.& Yao, A. C. (1983) “On the security of public key protocols”, IEEE Transactions on Information Theory, Vol. 29, No. 2, pp 198-208.

[22] Burrow, M.,Abadi, M. & Needham, R., (1990) “A Logic of Authentication”, ACM Transactions on Computer Systems, Vol. 8, No. 1, pp 18-36.

[23] Jung, J.,Kang, D., Lee, D. & Won, D., (2017) “An Improved and Secure Anonymous BiometricBased for Authentication with Key Agreement Scheme for the Integrated EPR Information System,” PLOS One, DOI:10.1371/journal.pone.0169414.

[24] Lu, Y.,Li, L.,Yang, X. & Yang, Y., (2015) “Robust biometrics based authentication and key agreement scheme for multi-server environments using smart cards,” PLOS One, 10(5):e0126323. Doi:10.1371/journal.pone.0126323.

[25] Moon, J.,Choi,Y.,Jung,J.& Won, D., (2015) “An Improvement of Robust Biometrics-Based Authentication and Key Agreement Scheme for Multi-Server Environment Using Smart Cards,” PLOS One, 10(12):e0145263. Doi:10.1371/journal.pone.0145263.
[26] Das,A.K.,Paul, N. R. & Tripathy, L., (2012) “Cryptanalysis and improvement of an access control in user hierarchy based on elliptic curve cryptosystem,” Information Sciences, Vol. 209, No. 20, pp 80- 92.

[27] Dai, W., Crypto++ Library 5.6.1, Available online: http://www.cryptopp.com (accessed on 5 Dec. 2016).

AUTHORS

Capture.JPG

Capture

Advertisements

Hardware Trojan Identification and Detection

 

Samer Moein1, Fayez Gebali1, T. Aaron Gulliver1, and Abdulrahman Alkandari2

1Department of Electrical and Computer Engineering

University of Victoria, Victoria, BC, Canad

2Department of Computer Science

Public Authority for Applied Education and Training, Kuwait City, Kuwait

 

 

ABSTRACT

 

The majority of techniques developed to detect hardware trojans are based on specific attributes. Further, the ad hoc approaches employed to design methods for trojan detection are largely ineffective. Hardware trojans have a number of attributes which can be used to systematically develop detection techniques. Based on this concept, a detailed examination of current trojan detection techniques and the characteristics of existing hardware trojans is presented. This is used to develop a new approach to hardware trojan identification and classification. This identification can be used to compare trojan risk or severity and trojan detection effectiveness. Identification vectors are generated for each hardware trojan and trojan detection technique based on the corresponding attributes. Vectors are also defined which represent trojan risk or severity and trojan detection effectiveness.

 

KEYWORDS

 

Hardware trojan detection, hardware trojan identification, trojan severity, trojan risk, trojan detection effectiveness

 

1. INTRODUCTION

 

With the increasing globalization of Integrated Circuit (IC) design and production, hardware trojans have become a serious threat to manufacturers as well as consumers. The use of ICs in critical applications makes the effects of these trojans a very dangerous problem. Unfortunately, the use of untrusted foundries and design tools cannot be eliminated since the complexity of ICs and the sophistication of their manufacture has grown significantly. Establishing a trusted foundry for fabrication is beyond the capabilities of most IC producers. Therefore, it is essential that effective hardware trojan detection techniques be developed.

A hardware trojan is defined as a malicious component embedded in an IC which causes abnormal behavior [1]. Hardware trojans can be implemented in microprocessors, microcontrollers, network and digital signal processors, Field Programmable Gate Arrays (FPGAs), Application Specific Integrated Circuits (ASICs), and other ICs. Figure 1 presents the classification of hardware trojan detection techniques proposed in [2]. They can be classified as destructive or non-destructive. Destructive techniques (i.e. reverse engineering), are primarily used to obtain a trojan free chip, referred to as a Golden Chip (GC), and can be extremely expensive and time consuming [3]. Therefore, it is often not practical to test chips using destructive techniques. Further, Process Variations (PVs) can result in false positives for trojan free chips when they are compared to a GC, and testing only a portion of the chips may be ineffective as an adversary can insert a trojan in only a small percentage of the chips.

 

U5v2iFaP_img1

 

Figure 1: Existing Hardware Trojan Detection Classification

Non-destructive techniques can be classified as testing or run-time monitoring methods. Testing can be supported by design for security circuits, e.g. scan chains and self-test circuitry. This improves trojan detection effectiveness but requires that the test circuitry not be compromised. A trojan may not be triggered during testing or it may be designed to avoid activation until after testing is completed. Therefore, a trojan that does not change the chip layout or design can be very difficult to detect during testing.

Testing approaches can be classified as logic testing or side-channel analysis. Logic testing methods employ random test vectors in an attempt to activate trojan circuits and observe their effect at the chip outputs. The difficulty with this approach is the complexity of testing all internal nodes and logic values as chips can have very high gate densities which makes comprehensive testing intractable. Side-channel analysis is based on the fact that any modification to a chip should be reflected in parameters such as the dynamic power [4–8], leakage current [9,10], path-delay characteristics [11–13], Electromagnetic (EM) radiation [14], or a combination of these parameters [15, 16]. However, side-channel techniques suffer from sensitivity to errors due to PVs and noise. This creates false positives and allows infected chips to go undetected. A good detection technique should have a high probability of detecting an infected chip and a low false positive probability. The advantage of side-channel techniques over logic-testing approaches is not having to activate a trojan to detect it. For example, parametric or inactive trojans require an internal or external trigger to become active.

Side-channel techniques are commonly employed and are very effective when ICs have low complexity and are not dense. However, detecting small or distributed trojans in complex or dense chips can be a significant challenge. For this reason, trojan circuits are typically very small compared to the IC design. They are often inserted in blank areas in the chip layout during the fabrication phase or implemented by rewiring existing circuitry.

Run-time monitoring is used to continuously monitor chip operation to detect the effects of malicious circuitry and initiate mitigation techniques. This can be achieved by exploiting pre-existing circuit redundancy such as a reconfigurable core [17] in a multicore system [18] to avoid infected parts of the circuit [2]. However, this can increase the chip area and delay leading to reduced performance. Run-time monitoring approaches greatly improve chip reliability when trojans pass the test phase [19]. Another approach is to use self-destructive packaging to disable chips or discard the output when a trojan is detected.

The high complexity of chips and the effects of PVs make many detection techniques proposed in the literature ineffective. Therefore, new techniques must be developed or approaches combined to improve performance. Most detection methods have been developed for a trojan designed specifically to test the effectiveness of the technique. This is problematic as even a small change in the trojan circuitry can result in detection failure. A better approach is to systematically examine the properties of existing trojans and design detection techniques based on the results of this investigation. This is important, as designing a detection technique that can protect against multiple trojans is a challenging task.

The contributions of this paper are as follows:

  1. The relationships between trojan attributes are examined and values assigned to each attribute to indicate the associated risk and effectiveness of detection techniques.
  2. Identification vectors are determined for hardware trojans and trojan detection techniques which represent the corresponding trojan attributes.
  3. Vectors are also given to represent trojan severity or risk and detection effectiveness, respectively.

The remainder of this paper is organized as follows. Section 2 reviews hardware trojan attributes and existing hardware trojan detection techniques to illustrate the proposed approach to trojan identification. The trojan attributes are studied and risk and detection effectiveness values are assigned in Section 3. Section 4 presents examples of hardware trojan vectors, and Section 5 gives examples of hardware trojan detection vectors. Finally, Section 6 provides some concluding remarks.

2. HARDWARE TROJANS AND THEIR DETECTION

Any attempt to address hardware security concerns should begin with a classification of the threats based on the processes involved in the IC production life cycle. A comprehensive model for trojan classification was presented in [20] which is based on eight categories: insertion, abstraction, effect, logic type, functionality, activation, physical layout, and location. A classification of attributes based on this model is illustrated in Figure 2. The relationships between these attributes were presented in [21] and used to identify the attributes that can be detected using a given technique. For example, a technique that can detect a sequential trojan circuit can also detect a combinational trojan circuit, or a technique that can detect a small trojan can also detect a large trojan. Methods used to detect a trojan in one category may also be useful in detecting trojans in other categories. As an example, a trojan introduced during the specification phase may affect attributes in other categories, so to be effective a technique should detect if a specification attribute has been compromised. In this paper, hardware trojans and hardware trojan detection techniques are examined based on the corresponding trojan attributes and their relationships.

U5v2iFaP_img2

 

Figure 2: Classification of Hardware Trojan Attributes

 

Most hardware trojan detection techniques are based on side-channel analysis. However, noise and PVs can affect the accuracy of side-channel information. Thus, multiple parameters are typically measured to improve the detection performance [15]. For example, in [8] power consumption and delay were measured and combined with gate level characteristics. The use of multiple techniques is shown as combined and hybrid blocks in Figure 3. This approach to trojan detection was presented in [30]. Table 1 [30] provides a summary of the attributes for the detection techniques considered in this paper. Each technique can detect hardware trojans with certain attributes. The letter C indicates that a technique can protect against the attribute, M means the technique may provide protection, while an empty entry means it cannot protect against trojans with this attribute. In addition, a technique may require results from a golden chip to compare with measurements from a Chip Under Test (CUT). This is indicated by R in the GC column. If a technique considers PVs, this is indicated by C in the PV column.

 

3. HARDWARE TROJAN ATTRIBUTES

 

A comprehensive investigation of hardware trojan attributes was presented in [20]. These attributes provide a complete characterization of trojans. In [21], the relationships between the attributes were studied and used to describe the trojan life cycle from the insertion phase to the location phase. Assigning weights to these attributes was also considered. The goal was to identify related combinations of attributes and exploit these connections for detection purposes.

 

U5v2iFaP_img3

 

Figure 3: Proposed Hardware Trojan Detection Classification

 

Table 1: Classification of Hardware Trojan Detection Techniques

 

 

U5v2iFaP_img4

 

Each hardware trojan has a number of attributes, and detection techniques have been developed to detect trojans with some or all of these attributes. However, the combinations of attributes that can lead to detection have not been considered. In this paper, the trojan attributes are examined in detail, and they are ranked within each category.

 

The attributes in each category are used to identify trojans and evaluate their risk or severity. They can also be used to identify trojan detection techniques and evaluate their effectiveness. Each trojan is assigned two vectors IT and CT. The first identifies the corresponding attributes, while the second presents the attributes in terms of their risk or severity. Each trojan detection technique also has two vectors ID and CD. ID identifies the attributes that can be detected, while CD presents the attributes in terms of the effectiveness of the technique. Thus there are four vectors corresponding to trojan identification IT, trojan detection identification ID, trojan risk or severity CT, and trojan detection effectiveness CD.

 

A hardware trojan is identified by the following vector based on the attributes involved in the trojan

                                                     IT = IR IA IE IL IF IC IP IO,                                                                 (1)              

where {IR, IA, IE, IL, IF, IC, IP, IO} represents the {Insertion, Abstraction, Effect, Logic type, Functionality, Activation, Physical layout, Location} category values, respectively. Each value specifies the attributes involved in the trojan within the category.

 

The attributes that identify a trojan detection technique is given by the vector

 

                                                                   ID = IT IG,                                                                   (2)

where {IT, IG} represents the {Trojan parameters, Chip attribute} category values, respectively. IG is used to specify if the technique requires a golden chip and/or considers process variations. Each value specifies the attributes that the detection technique can be used against.

 

The risk level of a trojan is given by the vector

 

                                                             CT = CR CA CE CL CF CC CP CO,                                                          (3)

where {CR, CA, CE, CL, CF, CC, CP, CO} represents the {Insertion, Abstraction, Effect, Logic type, Functionality, Activation, Physical layout, Location} category risk values, respectively.

 

The effectiveness of a trojan detection technique is given by the vector

 

                                                                   CD = CT CG,                                                                            (4)

where {CT, CG} represents the {Trojan parameters, Chip attribute} category effectiveness values, respectively. CG determines if a trojan detection technique requires a golden chip and/or considers process variations.

 

The values for each category are determined as described in the following sections.

3.1 Insertion (R) Category

The insertion category consists of five attributes: specification (1), design (2), fabrication (3), testing (4), and assembly (5).

 

3.1.1.Insertion Identification (IR)

 

The identification parameters for the attributes in this category are based on the fact that starting from specification, the existence of a trojan in an attribute may affect subsequent attributes in the category. Thus, the number of attributes that may be affected is used for identification. Column IR in Table 2 shows that the value 5 is assigned to the specification attribute, which means that a trojan inserted during the specification phase may affect all other attributes. Further, a trojan inserted in the design phase can affect the three subsequent attributes.

3.1.2.Insertion Risk/Effectiveness (CR)

The risk and effectiveness values for the attributes in this category are based on the effect on subsequent attributes. For example, a trojan inserted in the specification phase can affect the design and propagate through the remaining sequence of attributes so that fabrication, testing, and assembly may also be affected. Table 2 gives the insertion attributes with the corresponding identification IR and risk/effectiveness CR values

From a trojan perspective, IR = 3 means that the trojan is inserted during fabrication, and CR = 3 means that the fabrication attribute is infected, and both the testing and assembly attributes may also be infected. From a trojan detection perspective, IR = 3 means that the detection technique can detect a trojan inserted during the fabrication phase, and CR = 3, means that detecting a trojan that has infected the fabrication attribute also protects the chip from trojans in the remaining attributes within the category

Therefore, the IR and CR ranges for the attributes within the insertion category are

.

                                                              1 IR 5,                                                                         

                                                            1 CR ≤ 5                                                                                         (5)

Table 2: Insertion Attribute Values

U5v2iFaP_img53.2 Abstraction (A) Category

The abstraction category consists of six attributes: system (6), RTL (7), development environment (8), logic (9), transistor (10), and physical (11).

 

3.2.1.Abstraction Identification (IA)

The identification parameters for the attributes in this category are based on the fact that starting from system, the existence of a trojan in an attribute may affect subsequent attributes within the category. Thus, the number of attributes that may be affected is used for identification. Column IA in Table 3 shows that the value 6 is assigned to the system attribute, which means that a trojan inserted at the system level may affect all other attributes. Further, a trojan inserted in the RTL can affect the 5 subsequent attributes

3.2.2.Abstraction Risk/Effectiveness (CA)

The risk and effectiveness values for the attributes in this category are also based on the effect on subsequent attributes. For example, a trojan inserted at the system level can affect the RTL and thus also the development environment, logic, transistor, and physical attributes.

Table 3 shows the abstraction attributes with their assigned values. From a trojan perspective, IA = 5 means that the trojan is inserted at the RTL level, and CA = 5 means that if the RTL attribute is infected, all subsequent levels (development environment, logic, transistor, and physical), may also be infected. From the trojan detection perspective, IA = 5 means that the detection technique can detect a trojan inserted at the RTL level, and CA = 5 means that a trojan inserted at the RTL level can also be detected in the remaining attributes within the abstraction category.

The IA and CA ranges for the attributes within the abstraction category are    

                                                              1 IA 6,                                                                         

                                                            1 CA ≤ 6                                                                                         (6)

Table 3: Abstraction Attribute Values

K

Attribute

IA

CA

6

System

6

6

7

RTL

5

5

8

Development Environment

4

4

9

Logic

3

3

10

Transistor

2

2

11

Physical

1

1

3.3 Effect (E) Category

 

The effect category consists of four attributes: changes in functionality (12), information leakage (13), reduced reliability (14), and denial of service (15).

 

3.3.1.Effect Identification (IE)

For n trojan effect attributes, there are 2n-1 different combinations. From [21], n=4 different effects are considered, so there are 15 combinations. These combinations are assigned the values 1 to F to uniquely identify them. Column IE in Table 4 shows that the value 5 identifies a trojan that can change the system functionality and leak information from the system.

3.3.2.Effect Risk/Effectiveness (CE)

The effect category attributes are assigned severity values based on the affected system, and thus can differ between systems. Thus, the values assigned here are for illustration purposes only. If the system is located in a government agency, information leakage is the most critical attribute in this category. This is followed by change in functionality and denial of service, and then reduced reliability. Based on these assumptions, CE = {2, 4, 1, 2} are assigned to {Change in functionality, Information leakage, Reduced reliability, Denial of service}, respectively, and these are shown in Table 4.

 A trojan with a combination of attributes within this category has a severity which is the sum of the corresponding severity values. For example, column CE in Table 4 contains the value 5 twice. The first is when a trojan has the effects information leakage and reduced reliability so that CE (13) + CE (14) = 4 + 1 = 5, while the second is when a trojan has the effects change in functionality, reduced reliability, and denial of service so that CE (12) + CE (14) + CE (15) = 2 + 1 + 2 = 5. In terms of identification, the first of these combinations is assigned IE = 8 while the second is assigned IE = D.

 Table 4 shows the effect attributes with their assigned values. For example, IE = C and CE = 8 means that from a trojan perspective, it has the effects change in functionality, information leakage, and denial of service. From a trojan detection perspective, IE = C means that the detection technique can detect a trojan that has the attributes change in functionality, information leakage, and denial of service, and CE = 8 means that the technique can detect a trojan with the effects change functionality, information leakage, and denial of service.

 The IE and CE ranges for the attributes within the effect category are

                                                              1 IE F,                                                                        

                                                            1 CE ≤ 9                                                                                         (7)

 

Table 4: Effect Attribute Values

             K

Attribute

IE

CE

              12

Change in Functionality

1

2

              13

Information Leakage

2

4

              14

Reduced Reliability

3

1

              15

Denial of Service

4

2

12 & 13

 

5

6

12 & 14

 

6

3

12 & 15

 

7

4

13 & 14

 

8

5

13 & 15

 

9

6

14 & 15

 

A

3

12 &13 & 14

 

B

7

12 &13 & 15

 

C

8

12 &14 & 15

 

D

5

13 &14 & 15

 

E

7

12 &13 & 14 & 15

 

F

9

3.4 Logic Type (L) Category

The logic type category contains two attributes: sequential (16), and combinational (17).

 

3.4.1.Logic Type Identification (IL)

 

A trojan can have one of these attributes or both, so three values are needed for this category. As shown in Table 5, IL = 1 denotes a combinational logic trojan, IL = 2 denotes a sequential logic trojan, and IL = 3 denotes a trojan with both combinational and sequential logic.

3.4.2.Logic Type Risk/Effectiveness (CL)

Sequential logic consists of combinational logic and memory, so combinational logic is contained in sequential logic. Thus, a sequential logic trojan is more dangerous than a combinational logic trojan because there are more factors that can be used for activation. These factors are unknown and unexpected, while a combinational logic trojan is always on which makes detection easier. Therefore, here the sequential logic attribute is assigned a severity value twice that of the combinational logic attribute, as shown in Table 5. These values can be modified based on the particular circumstances, but the value for sequential logic should be higher. In Table 5, CL = 1 for a combinational logic trojan, CL = 2 for a sequential logic trojan, and CL = 3 for a trojan designed with both logic types.

The IL and CL ranges for the attributes within the logic type category are 

                                                              1 IL 3,                                                                         

                                                            1 CL ≤ 3                                                                                         (8)

Table 5: Logic Type Attribute Values

K

Attribute

IL

CL

16

Sequential

2

2

17

Combinational

1

1

16 & 17

Both

3

3

3.5 Functionality (F) Category

The functionality category consists of two attributes: functional (18), and parametric (19).

3.5.1.Functionality Identification (IF)

This category consists of two attributes, and a trojan can be designed to have one or both types. Therefore, to identify the attributes within this category, three different values are needed. As shown in Table 6, IF = 1 is used to identify a functional trojan, IF = 2 is used to identify a parametric trojan, and IF = 3 is used to identify a trojan which is both parametric and functional.

 

3.5.2.    Functionality Risk/Effectiveness (CF)

 

Both attributes have different capabilities, but parametric trojans can affect system operations, which means that they include functional trojan effects. Further, some parametric trojans are designed to leak sensitive information without affecting the system functionality, which makes them more dangerous than functional trojans. In fact, a trojan designed with both features will be more dangerous. Therefore the severity value for the parametric attribute should be higher than the value for the functional attribute, and a trojan with both attributes should have the highest severity, and this is reflected in Table 6.

 

These values are only for illustration purposes and others can be assigned based on the system risks associated with the attributes. From a trojan perspective, IF = 2 means that a parametric trojan has been inserted, while CF = 2 means that if a parametric trojan is inserted, it has a severity of 2 out of a maximum of 3. From a trojan detection perspective, IF = 2 means that the trojan detection technique can detect a parametric trojan, while CF = 2 means that if a detection technique is designed to detect only parametric trojans, the effectiveness is 2 out of a maximum of 3.

The IF and CF ranges for the attributes within the functionality category are

                                                             1 IF 3,                                                                         

                                                            1 CF ≤ 3                                                                                         (9)

Table 6: Functionality Attribute Values

K

Attribute

IF

CF

18

Functional

1

1

19

Parametric

2

2

18 &19

Both

3

3

3.6 Activation (C) Category

 

The activation category consists of three attributes: always on (20), internally triggered (21), and externally triggered (22).

 

3.6.1.Activation Identification (IC)

There are three different activation mechanisms, giving 7 possible combinations. A different value is assigned to each combination to uniquely identify them, as shown in Table 7. This shows that a value of 6 in column IC identifies a trojan that can be internally or externally activated.

3.6.2.Activation Risk/Effectiveness (CC)

The risk (severity) of the activation category attributes depends on the system affected, and so can differ between systems. Thus, values are assigned here only for illustration purposes. It is assumed that a trojan which is externally triggered is the hardest to detect because it is unlikely to be activated during testing. An internally triggered trojan is more likely to be detected during testing as this can occur accidentally. Further, an always on trojan that is not triggered is the easiest to detect. Based on these assumptions, CC = {4, 2, 1} is used to represent {Externally triggered, Internally triggered, Always on}, respectively, as shown in Table 7.

 

A trojan with a combination of these attributes has a severity equivalent to the sum of the values for the attributes. For example, the value 5 in column CC in Table 7 indicates that a trojan is always on but activated externally, as CC (20) + CC (22) = 1 + 4 = 5. From a trojan perspective, IC = 4 means that the trojan is always on and activated internally, while CC = 3 means that if the trojan is always on and activated internally, it has a severity of 3 out of a maximum of 7. From a trojan detection perspective, IC = 4 means that the technique can detect a trojan if it is always on and activated internally. CC = 3 means that if a detection technique is designed to detect always on trojans that may or may not be internally triggered, the effectiveness is 3 out of a maximum of 7.

       The IC and CC ranges for the attributes within the activation category are

                                                           1 IC 7,                                                                           

                                                            1 CC ≤ 7                                                                                        (10)

Table 7: Activation Attribute Values

K

Attribute

IC

CC

20

Always On

1

1

21

Internally Triggered

2

2

22

Externally Triggered

3

4

20 & 21

 

4

3

20 & 22

 

5

5

21 & 22

 

6

6

20 & 21 & 22

 

7

7

3.7 Physical Layout (P) Category

 

The physical layout category consists of six attributes: large (23), small (24), changed layout (25), augmented (26), clustered (27), and distributed (28).

3.7.1.Physical Layout Identification (IP)

It is clear that there are related attributes within this category. For example, if a detection technique is able to detect a small trojan then it is also able to detect a large one. Further, a trojan can be classified as either small or large. This argument also applies to changed layout and augmented, and clustered and distributed. A trojan has one attribute from each of these groups, so the individual attributes are not assigned identification values, as shown in Table 8. Eight different combinations of attributes need to be identified, so the values 1 to 8 are used in the table. For example, the value 4 in column IP in Table 8 indicates a large trojan inserted without changing the chip layout which is distributed throughout the chip.

3.7.2.Physical Layout Risk/Effectiveness (CP)

A trojan has three attributes related to the three groups within this category. It is clear that a small trojan is harder to detect than a large one. If the chip layout is changed, it is a strong indication that the chip is infected. On the other hand, if the layout is not changed it may still be infected, so additional effort is required to decide if a chip is trojan free or infected. Further, a distributed trojan is more dangerous than a clustered one.

 

For example, a trojan may be large but distributed so it is a number of small circuits, each of which can have different effects and activation mechanisms. Therefore, the small, augmented, and distributed attributes have greater risk than the large, changed layout, and clustered attributes, so CP = {1, 2, 1, 2, 1, 2} are assigned to {Large, Small, Changed layout, Augmented, Clustered, Distributed} respectively, as shown in Table 8. Every trojan has a combination of three attributes (one from each group), so the severity for a trojan is the sum of the values for the associated attributes. For example, the value of 6 in column CP in Table 8 indicates that a small trojan has been inserted without changing the layout and is distributed throughout the chip CP (24) + CP (26) + CP (28) = 2 + 2 + 2 = 6. It is clear that a small, augmented, and distributed trojan is the worst case for this category.

 

From a trojan perspective, IP = 3 means a large, clustered trojan has been inserted without changing the chip layout, while CP = 3 means a large, clustered trojan has been inserted, and it has changed the chip layout. From a trojan detection perspective, IP = 3 means that the trojan detection technique can detect a large, clustered trojan even if it has not changed the chip layout, while CP = 3 means that if a detection technique is designed to detect a large, clustered trojan that changed the chip layout, it has an effectiveness of 3 out of a maximum of 6.

The IP and CP ranges for the attributes within the physical layout category are

                                                                               1 ≤ IP ≤ 8,                                        

                                                                                     3 CP ≤ 6                                                                              (11)

Table 8: Physical Layout Attribute Values

K

Attribute

IP

CP

23

Large

1

24

Small

2

25

Changed Layout

1

26

Augmented

2

27

Clustered

1

28

Distributed

2

23 & 25 & 27

 

1

3

23 & 25 & 28

 

2

4

23 & 26 & 27

 

3

4

23 & 26 & 28

 

4

5

24 & 25 & 27

 

5

4

24 & 25 & 28

 

6

5

24 & 26 & 27

 

7

5

24 & 26 & 28

 

8

6

3.8 Location (O) Category

 

The location category consists of five attributes: processor (29), memory (30), I/O (31), power supply (32), and clock grid (33).

 

3.8.1.Location Identification (IO)

 

The five possible trojan locations result in 31 possible combinations, and each is assigned a unique identifier from 1 to V. A trojan is inserted in one of these locations, while a trojan detection technique may have the ability to detect a trojan in more than one location. The first five values 1 to 5 are used to identify single locations. The remainder are used only with detection techniques to indicate in which locations a trojan can be detected. The value 2 in column IO in Table 9 means that the trojan is located in the memory and the detection technique can detect a trojan in the memory. IO = F indicates that the detection technique can detect a trojan located in the power supply or clock grid.

 

3.8.2.Location Risk/Effectiveness (CO)

 

In general, each particular location attribute has similar risk, so they are assigned CO = 1. The value of CO is defined as the number of locations affected by the trojan. For example, a trojan inserted in the I/O may receive commands (external trigger) to activate some processor actions or leak data stored in memory, so it is assigned CO = 2.

 

For detection techniques, the effectiveness is defined as the number of locations in which a trojan can be detected, e.g. the value 2 in column CO in Table 9 indicates that a technique can detect a trojan inserted in two different locations. The specific locations are given by IO. For example, if IO = 8, the technique can detect a trojan in the processor or power supply. From a trojan perspective, IO = 3 means that it is inserted in the I/O, while CO = 5 means that the trojan affects all five locations, namely processor, memory, I/O, power supply, and clock grid.

From a trojan detection perspective, IO = 3 means that the technique can detect a trojan inserted in the I/O only, while CO = 5 means that it can detect a trojan in the processor, memory, I/O, power supply, or clock grid, which is the maximum effectiveness.

The IO and CO ranges for the attributes within the physical layout category are

 

                                                  1 IO V,                                                                      

                                                                                   1 CO ≤ 5                                                                                   (12)

3.9 Chip Attribute (G) Category

The chip attribute category consists of two attributes: golden chip (GC) and process variation (PV). This category only pertains to detection techniques.

 

3.9.1.Chip Attribute Identification (IG)

The two attributes result in 4 possible combinations, so the values 0 to 3 are used to uniquely identify them. The value of 3 in column IG in Table 10 indicates that the detection technique requires a golden chip (GC) and considers process variations (PVs).

3.9.2.Chip Attribute Effectiveness (CG)

Obtaining reference measurements using a golden chip is an expensive process that requires reverse engineering to ensure that the chip is trojan free. Process variations are important to consider as they can affect detection reliability, resulting in false positives and false negatives. Therefore, a detection technique that can detect a trojan without the need for a golden chip but considers the process variations is the best, and so is assigned CG = 4. Conversely, a detection technique that requires a golden chip but does not consider process variations is the most expensive and least effective, and so is assigned CG = 1.

A detection technique that neither requires a golden chip nor considers process variations is assigned CG = 2, while a technique that requires a golden chip but considers process variations is assigned CG = 3. The IG and CG ranges for the attributes within the activation category are

                                                   0 IG 3,                                                                      

                                                                                     1 CG ≤ 4                                                                                (13)

 

Table 9: Location Attribute Values

 

K

 

Attribute

IO

CO

 

29

 

Processor

1

1

 

30

 

Memory

2

1

 

31

 

I/O

3

1

 

32

 

Power Supply

4

1

 

33

 

Clock Grid

5

1

29

& 30

 

6

2

29

& 31

 

7

2

29

& 32

 

8

2

29

& 33

 

9

2

30

& 31

 

A

2

30

& 32

 

B

2

30

& 33

 

C

2

31

& 32

 

D

2

31

& 33

 

E

2

32

& 33

 

F

2

29 &

30

& 31

 

G

3

29 &

30

& 32

 

H

3

29 &

30

& 33

 

I

3

29 &

31

& 32

 

J

3

29 &

31

& 33

 

K

3

29 &

32

& 33

 

L

3

30 &

31

& 32

 

M

3

30 &

31

& 33

 

N

3

30 &

32

& 33

 

O

3

31 &

32

& 33

 

P

3

29 & 30

& 31 & 32

 

Q

4

29 & 30

& 31 & 33

 

R

4

29 & 30

& 32 & 33

 

S

4

29 & 31

& 32 & 33

 

T

4

30 & 31

& 32 & 33

 

U

4

29 & 30 &

31

& 32 & 33

 

V

5

 

Table 10: Chip Attribute Values

Attribute

IG

CG

none

0

2

GC

1

1

PV

2

4

GC & PV

3

3

 

 4. HARDWARE TROJAN EXAMPLES

A hardware trojan is assigned two vectors {IT, CT} each consisting of eight elements. Each element represents the corresponding category value for the trojan. IT identifies the attributes associated with the trojan while CT indicates the severity of the trojan based on the attributes. These vectors provide a complete characterization of the trojan, and can be used to compare trojans. The vectors for two hardware trojan are shown in Table 11. Trojan A has identification IT = {2 6 2 1 2 1 7 7} and severity CT = {2 6 4 1 2 1 5 2}, while trojan B has identification IT = {3 3 1 2 1 2 8 1} and severity CT = {3 3 2 2 1 3 6 1}.

 

These trojans can be compared based on the severity for each category in CT. CR = 2 for trojan A and CR = 3 for trojan B means that trojan A is inserted during the testing phase (attribute 4), and it may affect the assembly phase (attribute 5), whereas trojan B is inserted in the fabrication phase (attribute 3), and it may affect the testing and assembly phases (attributes 4 and 5). The insertion of trojan B may affect more phases than trojan A, so it has higher severity.

CA = 6 for trojan A and CA = 3 for trojan B means that trojan A is inserted at the system abstraction level (attribute 6), and the other levels RTL, development environment, logic, transistor, and physical (attributes 7, 8, 9, 10, and 11) may be affected, whereas trojan B is inserted at the logic abstraction level (attribute 9), so it may also affect the transistor and physical abstraction levels (attributes 10 and 11). The insertion of trojan A may affect more abstraction levels than trojan B, so it has higher severity.

CE = 4 for trojan A and CE = 2 for trojan B means that the effect of trojan A is to leak information (attribute 13) from a chip, whereas the effect of trojan B is to change the system functionality or cause denial of service (attributes 12 or 15). Although trojan B can change the chip functionality or prevent it from working as expected, trojan A is considered more serious.

 

Table 11: Hardware Trojan Examples

 

Identification (IT)

Severity (CT)

Trojan

IR

IA

IE

IL

IF

IC

IP

IO

CR

CA

CE

CL

CF

CC

CP

CO

Trojan A [21]

2

6

2

1

2

1

7

7

2

6

4

1

2

1

5

2

Trojan B [21]

3

3

1

2

1

2

8

1

3

3

2

2

1

3

6

1

 CL = 1 for trojan A and CL = 2 for trojan B means that the logic type of trojan A is combinational (attribute 17), while that of trojan B is sequential (attribute 16). The severity of trojan B is higher than trojan A since a sequential trojan is harder to detect than a combinational one.

CF = 2 for trojan A means that it is a parametric trojan (attribute 19), which means it could change the chip functionality, leak information, and/or reduced reliability (attributes 12, 13, and/or 14), CF = 1 for trojan B indicates that it is a functional trojan (attribute 18), which typically changes the chip functionality (attribute 12). Trojan B has a lower severity because the effects of trojan A are hidden and the victim is less likely to be aware of its existence.

CC = 1 for trojan A and CC = 3 for trojan B means that trojan A is always on (attribute 20), while trojan B is always on and is internally triggered (attributes 20 and 21). The severity for trojan B is higher since it is internally triggered.

CP = 5 for trojan A means that it has one of the following physical layout attributes: large, augmented, and distributed (attributes 23, 26, and 28), small, changed layout, and distributed (attributes 24, 25, and 28), or small, augmented, and clustered (attributes 24, 26, and 27). The trojan physical layout identifier IP = 7 specifies that it is the last of these combinations. On the other hand, CP = 6 for trojan B indicates that the physical layout attributes are small, augmented, and distributed (attributes 24, 26, and 28). The severity of trojan B is higher than trojan A because it has a worse combination of attributes.

CO = 2 means that trojan A can be inserted in two locations. The trojan location identifier IO = 7 indicates that these locations are the processor or memory (attributes 29 or 30). On the other hand, CO = 1 for trojan B means it can be inserted in only one location. From IO, this location is the processor (attribute 29). Thus the severity of trojan A is higher since it can be inserted in more locations.

Typically, some vector elements will be higher for trojan A than trojan B, while others will be lower for trojan A than trojan B. Attackers and defenders must therefore decide which are the more important. This decision is based on the attacker capabilities and the system under consideration. For example, if the testing phase is done in-house and so is considered secure, trojan A cannot be inserted in the system. However, if the attacker is part of the testing group, trojan A can be inserted. Further, if the fabrication stage is not secure, as required for trojan B, then any modification at this stage could affect the testing phase even if the attacker is not in the testing group. Therefore, the comparison should also be based on assumptions regarding the attacker and defender. For example, if the system deals with sensitive information, trojan A will be more dangerous than trojan B because it was designed to leak information. However, if the system is located in an aircraft, trojan B will be more dangerous as a denial of service attack or change in functionality could cause a crash.

5. Trojan Detection Technique Examples

 

A trojan detection technique is assigned two vectors {ID, CD}, each consisting of nine elements. The first identifies the trojan attributes that the technique is effective against. The second specifies the effectiveness against trojans which have these attributes. These vectors provide a complete description of the trojan detection technique. Table 12 presents the identification and effectiveness vectors for a number of hardware trojan detection techniques. The effectiveness of the detection techniques can easily be compared using this information to determine which is best for a given system. We consider a comparison of the two techniques given in Table 13.

 

The first technique is from [8] and has identification ID = {3 3 B 1 2 4 7 V 1} and effectiveness CD = {3 3 7 1 2 3 5 5 2}, while the second technique is from [16] and has identification ID = {3 3 1 3 1 4 7 V 4} and effectiveness CD = {3 3 2 3 1 3 5 5 3}.

From Table 13, both techniques have the same values of CR, CA, CC, CP and CO, but differ in in the other four effectiveness parameters. CE = 7 for the first technique means that it can detect trojans that affect three attributes, and IE = B indicates that these attributes are change in functionality, information leakage, and reduce reliability (attributes 12, 13, and 14). On the other hand, CE = 2 for the second technique means that it is designed to detect a trojan inserted to change functionality or create a denial of service (attributes 12 or 15). IE = 1 indicates that it is change in functionality (attribute 12). A defender should choose the first technique if the target system deals with sensitive information so that a trojan designed to leak information is the main threat.

Table 12: Hardware Trojan Detection Techniques

 

Identification

Effectiveness

Technique

IR

IA

IE

IL

IF

IC

IP

IO

IG

CR

CA

CE

CL

CF

CC

CP

CO

CG

[4]

4

1

C

3

3

4

7

V

3

4

1

8

3

3

3

5

5

4

[5]

2

6

2

1

2

1

7

V

3

2

6

4

1

2

1

5

5

4

[6]

5

6

2

1

2

1

7

V

4

5

6

4

1

2

1

5

5

3

[7]

3

3

1

1

1

4

7

V

2

3

3

2

1

1

3

5

5

1

[8]

3

3

B

1

2

4

7

V

1

3

3

7

1

2

3

5

5

2

[9]

4

3

1

2

1

2

8

V

4

4

3

2

2

1

2

6

5

3

[10]

4

5

1

3

3

4

8

V

4

4

5

2

3

3

3

6

5

3

[11]

3

4

5

3

3

4

5

V

4

3

4

6

3

3

3

4

5

3

[12]

4

4

A

1

2

1

8

V

3

4

4

3

1

2

1

6

5

4

[13]

4

4

5

1

3

1

8

V

2

4

4

6

1

3

1

6

5

1

[14]

4

4

4

2

1

3

8

V

2

4

4

2

2

1

4

6

5

1

[15]

3

5

5

3

3

2

8

V

4

3

5

6

3

3

2

6

5

3

[16]

3

3

1

3

1

4

7

V

4

3

3

2

3

1

3

5

5

3

[19]

3

4

6

3

1

7

8

G

4

3

4

3

3

1

7

6

3

3

[22]

4

5

5

2

1

2

8

V

3

4

5

6

2

1

2

6

5

4

[23]

4

3

5

3

3

4

8

V

4

4

3

6

3

3

3

6

5

3

[25]

5

5

4

3

1

2

3

V

4

5

5

2

3

1

2

4

5

3

[26]

4

5

1

1

1

1

8

V

4

4

5

2

1

1

1

6

5

3

[27]

4

3

1

1

1

4

8

V

4

4

3

2

1

1

3

6

5

3

[28]

4

5

9

3

1

7

2

V

2

4

5

6

3

1

7

4

5

1

[29]

4

4

1

3

1

2

7

V

1

4

4

2

3

1

2

5

5

2

 

CL = 1 for the first technique means that it is designed to detect only combinational trojans (attribute 17), while CL = 3 for the second technique means that it can detect both combinational and sequential trojans (attributes 16 and 17). A defender should choose the latter technique as it can protect against both types of trojans.

CF = 2 for the first technique means that it can only detect parametric trojans (attribute 19), while CF = 1 for the second technique indicates that it can only detect functional trojans (attribute 18). If information leakage is the main concern, a defender should choose the latter technique.

CG = 2 for the first technique means that it does not consider process variations and does not need reference measurements for detection. On the other hand, CG = 3 for the second technique means that it considers process variations but also requires reference measurements for detection. A defender should choose the latter technique if false alarms due to process variations are important to avoid.

Table 13: Hardware Trojan Detection Technique Examples

 

Identification (ID)

Effectiveness (CD)

Technique

IR

IA

IE

IL

IF

IC

IP

IO

IG

CR

CA

CE

CL

CF

CC

CP

CO

CG

[8]

3

3

B

1

2

4

7

V

1

3

3

7

1

2

3

5

5

2

[16]

3

3

1

3

1

4

7

V

4

3

3

2

3

1

3

5

5

3

 

Trojan detection techniques should be compared based on the effectiveness values. Typically, some values are higher for one technique while others are higher for another technique. A defender must decide which attribute categories are more important based on the target system and which attributes are secure for this system.

6. CONCLUSION

The sophistication of hardware trojan detection techniques has been increasing in an attempt to improve detection rates. However, this makes it difficult to compare different methods and their effectiveness. A comprehensive evaluation of the attributes of hardware trojans is used here to classify detection techniques. This evaluation is also used to measure and compare the severity of these trojans. The attributes are ranked and weighted according to their importance in the detection process. The proposed approach provides a means of evaluating existing as well as new trojan detection techniques. In addition, it can be used to compare detection techniques and determine their effectiveness.

 

REFERENCES

 

  1. M. Banga and M. Hsiao, “A region based approach for the identification of hardware trojans,” in Proc.

IEEE Int. Workshop on Hardware-Oriented Security and Trust, pp. 40–47, 2008.

  1. S. Narasimhan and S. Bhunia, “Hardware trojan detection,” in Introduction to Hardware Security and Trust, M. Tehranipoor and C. Wang (Eds.), Springer, New York, NY, pp. 339–364, 2012.
  2. C. Bao, D. Forte, and A. Srivastava, “On reverse engineering-based hardware trojan detection,” IEEE Trans. Comput.-Aided Design Integr. Circuits and Sys., vol. 35, no. 1, pp. 49–57, 2015.
  3. C. Marchand and J. Francq, “Low-level implementation and side-channel detection of stealthy hardware trojans on field programmable gate arrays,” IET Computers Digital Tech., vol. 8, no. 6, pp. 246–255, 2014.
  4. Y. Liu, K. Huang, and Y. Makris, “Hardware trojan detection through golden chip-free statistical side-channel fingerprinting,” in Proc. ACM/EDAC/IEEE Design Automation Conf., pp. 1–6, 2014.
  5. Y. Liu, Y. Jin, and Y. Makris, “Hardware trojans in wireless cryptographic ICs: Silicon demonstration & detection method evaluation,” in Proc. IEEE/ACM Int. Conf. on Computer-Aided Design, pp. 399–404, 2013.
  1. D. Karunakaran and N. Mohankumar, “Malicious combinational hardware trojan detection by gate level characterization in 90nm technology,” in Proc. Int. Conf. on Computing, Commun. and Networking Tech., pp. 1–7, 2014.
  2. M. Potkonjak, A. Nahapetian, M. Nelson, and T. Massey, “Hardware trojan horse detection using gate-level characterization,” in Proc. IEEE/ACM Design Automation Conf., pp. 688–693, 2009.
  3. Y. Cao, C. Chang, and S. Chen, “A cluster-based distributed active current sensing circuit for hardware trojan detection,” IEEE Trans. Inform. Forensics Security, vol. 9, no. 12, pp. 2220–2231, 2014.
  4. X. Mingfu, H. Aiqun, and L. Guyue, “Detecting hardware trojan through heuristic partition and activity driven test pattern generation,” in Proc. Commun. Security Conf., pp. 1–6, 2014.
  5. Y. Jin and Y. Makris, “Hardware trojan detection using path delay fingerprint,” in Proc. IEEE Int. Conf. on Hardware-Oriented Security and Trust, pp. 51–57, 2008.
  6. M. Li, A. Davoodi, and M. Tehranipoor, “A sensor-assisted self-authentication framework for hardware trojan detection,” in Proc. Design, Automation and Test in Europe Conf. and Exhibition, pp. 1331–1336, 2012.
  7. P. Kumar and R. Srinivasan, “Detection of hardware trojan in SEA using path delay,” in Proc. IEEE Students’ Conf. on Elect., Electronics and Computer Sci., pp. 1–6, 2014.
  8. O. Soll, T. Korak, M. Muehlberghuber, and M. Hutter, “EM-based detection of hardware trojans on FPGAs,” in Proc. IEEE Int. Symp. on Hardware-Oriented Security and Trust, pp. 84–87, 2014.
  9. A. Nowroz, K. Hu, F. Koushanfar, and S. Reda, “Novel techniques for high-sensitivity hardware trojan detection using thermal and power maps,” IEEE Trans. Comput.-Aided Design Integr. Circuits and Sys., vol. 33, no. 12, pp. 1792–1805, 2014.
  10. S. Narasimhan et al., “Hardware trojan detection by multiple-parameter side-channel analysis,” IEEE Trans. Comput., vol. 62, no. 11, pp. 2183–2195, 2013.
  11. M. Abramovici and P. Bradley, “Integrated circuit security: New threats and solutions,” in Proc. Workshop on Cyber Security and Inform. Intelligence Res., article no. 55, 2009.
  12. D. McIntyre, F. Wolff, C. Papachristou, and S. Bhunia, “Dynamic evaluation of hardware trust,” in Proc. IEEE Int. Workshop on Hardware-Oriented Security and Trust, pp. 108–111, 2009.
  13. T. F. Wu et al., “TPAD: Hardware trojan prevention and detection for trusted integrated circuits,” IEEE Trans. Comput.-Aided Design Integr. Circuits and Sys., vol. 35, no. 4, pp. 521–534, 2016.
  14. S. Moein, S. Khan, T. A. Gulliver, and F. Gebali, and M. W. El-Kharashi, “An attribute based classification of hardware trojans,” in Proc. Int. Conf. on Computer Engineering and Sys., pp. 351–356, 2015.
  15. S. Moein, T. A. Gulliver, F. Gebali, and A. Alkandari, “A new characterization of hardware trojans,” IEEE Access, vol. 4, pp. 2721-2731, 2016.
  16. S. Narasimhan et al., “TeSR: A robust temporal self-referencing approach for hardware trojan detection,” in Proc. IEEE Int. Symp. on Hardware-Oriented Security and Trust, pp. 71–74, 2011.
  17. X. Wang, H. Salmani, M. Tehranipoor, and J. Plusquellic, “Hardware trojan detection and isolation using current integration and localized current analysis,” in Proc. IEEE Int. Symp. on Defect and Fault Tolerance of VLSI Systems, pp. 87–95, 2008.
  18. C. Lavin et al., “RapidSmith: Do-it-yourself CAD tools for Xilinx FPGAs,” in Proc. Int. Conf. on Field Programmable Logic and Applic., pp. 349–355, 2011.
  19. P. Kitsos and A. G. Voyiatzis, “FPGA trojan detection using length-optimized ring oscillators,” in Proc. Euromicro Conf. on Digital System Design, pp. 675–678, 2014.
  20. X. Zhang and M. Tehranipoor, “RON: An on-chip ring oscillator network for hardware trojan detection,” in Proc. Design, Automation and Test in Europe Conf. and Exhibition, pp. 1–6, 2011.
  21. A. Ferraiuolo, X. Zhang, and M. Tehranipoor, “Experimental analysis of a ring oscillator network for hardware trojan detection in a 90nm ASIC,” in Proc. IEEE/ACM Int. Conf. on Computer-Aided Design, pp. 37–42, 2012.
  1. D. Forte, C. Bao, and A. Srivastava, “Temperature tracking: An innovative run-time approach for hardware trojan detection,” in Proc. IEEE/ACM Int. Conf. on Computer-Aided Design, pp. 532–539, 2013.
  2. X. Cui, K. Ma, L. Shi, and K. Wu, “High-level synthesis for run-time hardware trojan detection and recovery,” in Proc. ACM/EDAC/IEEE Design Automation Conf., pp. 1–6, 2014.
  3. S. Moein, J. Subramnian, T. A. Gulliver, and F. Gebali, and M. W. El-Kharashi, “Classification of hardware trojan detection techniques,” in Proc. Int. Conf. on Computer Engineering and Sys., pp. 357–362, 2015.

Authors

1.jpg

 

 

International Journal on Cryptography and Information Security (IJCIS)

ISSN : 1839 – 8626

http://wireilla.com/ijcis/index.html

Scope & Topics

International Journal on Cryptography and Information Security ( IJCIS) is an open access peer reviewed journal that focuses on cutting-edge results in applied cryptography and Information security. It aims to bring together scientists, researchers and students to exchange novel ideas and results in all aspects of cryptography, coding and Information security.

Topics of interest include but are not limited to, the following

  • Cryptographic protocols
  • Cryptography and Coding
  • Untraceability
  • Privacy and authentication
  • Key management
  • Authentication
  • Trust Management
  • Quantum cryptography
  • Computational Intelligence in Security
  • Artificial Immune Systems
  • Biological & Evolutionary Computation
  • Intelligent Agents and Systems
  • Reinforcement & Unsupervised Learning
  • Autonomy-Oriented Computing
  • Coevolutionary Algorithms
  • Fuzzy Systems
  • Biometric Security
  • Trust models and metrics
  • Regulation and Trust Mechanisms
  • Data Integrity
  • Models for Authentication, Trust and Authorization
  • Wireless Network Security
  • Information Hiding
  • Data & System Integrity
  • E- Commerce
  • Access Control and Intrusion Detection
  • Intrusion Detection and Vulnerability Assessment
  • Authentication and Non-repudiation
  • Identification and Authentication
  • Insider Threats and Countermeasures
  • Intrusion Detection & Prevention
  • Secure Cloud Computing
  • Security Information Systems Architecture and Design and Security Patterns
  • Security Management
  • Security Requirements (threats, vulnerabilities, risk, formal methods, etc.)
  • Sensor and Mobile Ad Hoc Network Security
  • Service and Systems Design and QoS Network Security
  • Software Security
  • Security and Privacy in Mobile Systems
  • Security and Privacy in Pervasive/Ubiquitous Computing
  • Security and Privacy in Web Sevices
  • Security and Privacy Policies
  • Security Area Control
  • Security Deployment
  • Security Engineering
  • Security for Grid Computing
  • Security in Distributed Systems

Paper Submission

Authors are invited to submit papers for this journal through Submission system. Submissions must be original and should not have been published previously or be under consideration for publication while being evaluated for this Journal.

Important Dates

  • Submission Deadline : November 04, 2017
  • Authors Notification : December 04, 2017
  • Final Manuscript Due : December 12, 2017

Contact Us

Here’s where you can reach us: ijcisjournal@yahoo.com or ijcisjournal@wireilla.com