Vulnerability Information Sharing Platform for Securing Hardware

Supply Chains

Kento Hasegawa

1 a

, Katsutoshi Hanahara

, Hiroshi Sugisaki

, Minoru Kozu

Kazuhide Fukushima

1 b

, Yosuke Murakami

and Shinsaku Kiyomoto

KDDI Research, Inc., Japan

KDDI Foundation, Japan

Keywords:

Supply Chain, Design, Hardware Trojan, Detection, Industry.

Abstract:

The rise of complex global supply chains has increased the risk of malicious actors attempting to insert mali-

cious functions, called hardware Trojans (HTs), into hardware components and devices. Although many HT

detection methods have been proposed over a decade, implementing them in industries may take a long time

due to concerns about these methods. In this paper, we propose a repository system to manage vulnerability

information for securing hardware supply chains and investigate the demand and barriers to introducing hard-

ware Trojan detection schemes in the industry. First, we design a scheme to share the results of HT detection

methods. Second, we design questionnaires to investigate the actual situation of the industry’s awareness of

the threat of HTs and other hardware security issues. We conclude that there is a gap between academics and

the industry, whereas many business operators are concerned about the threat of HTs.

1 INTRODUCTION

The rise of complex global supply chains has in-

creased the risk of malicious actors attempting to

insert malicious functions, called hardware Tro-

jans (HTs), into hardware components and de-

vices (Francq and Frick, 2015; Xiao et al., 2016). HTs

may leak internal conﬁdential information, degrade

performance, or alter the original functionality of

hardware components. Many HT detection methods

have been proposed for over a decade to defend hard-

ware products from the insertion of HTs. However,

these methods were proposed from the viewpoint of

academic research. The feasibility of HTs in the real

world and the industry’s awareness of the threat posed

by HTs have not been sufﬁciently assessed. Almeida

et al. investigated the feasibility of ransomware at-

tacks as HTs (Almeida et al., 2022). This feasibility

study demonstrated that there are no barriers for an

adversary to devise hardware ransomware in a hard-

ware product. Although this result suggests that HTs

can be easily realized, the actual awareness of busi-

ness operators across various industries has not been

investigated.

https://orcid.org/0000-0002-6517-1703

https://orcid.org/0000-0003-2571-0116

In this paper, we focus on the actual situation

of the industry as it relates to semiconductor supply

chains. First, we propose a scheme to share the re-

sults of HT detection methods in the hardware de-

sign phase. In terms of software management, vul-

nerability information for software is publicly shared

on several platforms, such as the National Vulnera-

bility Database (NVD) and Common Vulnerabilities

and Exposures (CVEs). Inspired by such platforms,

we design a framework to share vulnerability infor-

mation for hardware. Second, we design question-

naires to investigate the actual situation of the indus-

try’s awareness of the threat of HTs. Through the

questionnaires, we clarify the demand and concerns

with respect to HT detection methods and security as-

sessment schemes in industries.

The contributions of this paper can be summarized

as follows:

• We propose a repository operation scheme to

share vulnerability information of hardware prod-

ucts. The scenario using the repository is consid-

ered a use case for HT detection methods in in-

dustries.

• We designed questionnaires to conﬁrm the needs,

effectiveness, and concerns regarding the reposi-

tory operation scheme and conducted a survey tar-

Hasegawa, K., Hanahara, K., Sugisaki, H., Kozu, M., Fukushima, K., Murakami, Y. and Kiyomoto, S.

Vulnerability Information Sharing Platform for Securing Hardware Supply Chains.

DOI: 10.5220/0012351800003648

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 10th International Conference on Information Systems Security and Privacy (ICISSP 2024), pages 403-410

ISBN: 978-989-758-683-5; ISSN: 2184-4356

403

geting 15 companies.

• We found that HT detection methods are attractive

in industries, and the repository scheme will be

enhanced if the scheme covers the whole supply

chain, i.e., the whole lifecycle of semiconductor

products.

2 PRELIMINARIES

2.1 Hardware Trojan (HT)

HTs are malicious modiﬁcations inserted into inte-

grated circuits (ICs) during the manufacturing pro-

cess with the intention of causing harmful impacts for

manufacturers or IC users. They can be inserted by a

malicious adversary with access to the design or fab-

rication process or by a rogue employee within hard-

ware supply chains. HTs can perform various mali-

cious functions, such as leaking conﬁdential internal

information, disabling critical functions, or causing

the device to malfunction. A speciﬁc trigger, such as

a particular input or a speciﬁc time, can activate HTs.

HTs are usually composed of small circuits, mak-

ing them difﬁcult to detect during the design phase.

HTs can also be designed to avoid detection by test-

ing methods and to remain dormant until a speciﬁc

trigger activates them. Adversaries can insert HTs in

any phase in hardware supply chains. Particularly, in-

serting HTs in the design phase is relatively easy and

effective because one modiﬁcation in a design spreads

many products.

2.2 Hardware Trojan Detection

In this paper, we focus on HT detection methods in the

design phase to detect HTs earlier in supply chains. A

hardware design is described in hardware description

languages (HDLs). An adversary may alter the de-

sign described in HDL to insert HTs or may provide

intellectual property that is infected with HTs.

There are several HT detection approaches in the

design phase. A promising method is a structural

feature-based approach, in which HT-speciﬁc features

are identiﬁed from a tested hardware design (Yang

et al., 2020). In a structural feature-based approach,

the structure of a circuit is extracted based on the

hardware design. According to (Oya et al., 2015),

speciﬁc features appear in HT circuits. For example,

a trigger circuit in an HT has many fan-ins to imple-

ment a rarely triggered condition. The method pro-

posed in (Oya et al., 2015) suggests that feature values

that help identify HTs can be extracted from hardware

designs.

Based on the ﬁndings, HT detection methods us-

ing machine learning have been proposed (Hasegawa

et al., 2017b; Hasegawa et al., 2017a; Li et al., 2020;

Huang et al., 2020). There are two phases for machine

learning-based HT detection: the feature extraction

phase and the machine learning phase. In the fea-

ture extraction phase, a set of possible features that

can help identify HTs are extracted from hardware

designs (i.e., program codes written in HDL). Then,

a model is trained with the extracted feature values in

the machine learning phase. The trained model is ex-

pected to identify HTs from a given hardware design.

However, there are barriers to implementing HT

detection in industries. A major barrier is the cost of

HT detection. Performing HT detection will consume

some time, thus delaying manufacturing processes.

Many vendors may doubt if the beneﬁt of HT detec-

tion is greater than the cost.

In this paper, we survey the awareness of HT de-

tection in industries from the perspective of these

points. First, to make HT detection beneﬁcial, we

propose a repository operation scheme to share the

vulnerability information between business operators.

Speciﬁcally, the list of hardware components and

their HT detection results are stored in the repository

system. Using this repository system and its opera-

tion scheme, we conduct questionnaires to investigate

the feasibility and effectiveness.

3 METHODOLOGY

In this section, we propose a repository system to

share vulnerability information, such as the reports of

HT detection. This repository aims to enhance the se-

curity of hardware supply chains, particularly in the

design phase.

3.1 Overview of the Repository

Operation Scheme

We propose a scheme to share the results of HT detec-

tion as a demonstration. Figure 1 shows an overview

of the repository operation scheme that we designed.

Based on the HT detection methods, we design the

scheme to share the hardware vulnerability informa-

tion between business operators. There are three roles

for the repository users: administrators, manufactur-

ers, and inspection agencies. Administrators manage

the users and contents of the repository. Manufactur-

ers can register their product information in the repos-

itory and view the design information registered by

other manufacturers. Inspection agencies can regis-

ter the inspection results of a product that has been

ICISSP 2024 - 10th International Conference on Information Systems Security and Privacy

404

Repository

Manage the repository

Inspection AgencyManufacturer

Administrator

/ View entries

Users

Permissions are granted based on the user’s role.

Request inspection

Figure 1: Overview of the repository operation scheme.

Repository

User

Management

User

Table

Affiliation, role, etc.

Product

Management

Manager

Product

Table

Inspection

Table

Product information, hash

values for attached files,

etc.

Designer

Inspection

Management

Inspector

Session Management

Add / Edit / Delete

View

Add / Edit / Delete

Inspection results of HT

detection, etc.

Relation

* UI: User Interface

Relation

Viewer

+Manage

Only viewing

+Manage

Figure 2: Overview of the repository architecture.

registered in the repository.

3.2 Repository Architecuture

Figure 2 shows an overview of the repository architec-

ture. In the repository, the database includes mainly

three tables: the user, product, and inspection ta-

bles. Since the repository targets the management of

the hardware design phase, the product here indicates

hardware design products.

The user table stores information regarding the

repository users, such as their names, afﬁliations,

email addresses, and roles. Administrators assign a

role to a user, and users without the administrator role

cannot change their role. The details of the user roles

are explained later.

The product table includes information regarding

hardware design products, such as the designs for pro-

cessors and interfaces. Users assigned to the man-

ufacturer role can register their product information

to the product table, and other users can only see

the product information. Users who are authorized

can register product information, such as the prod-

uct name, product version, and application category

of the product. Documents, including datasheets and

hardware design deliverables, can be attached to the

product information. The product management func-

tion in the repository system provides a user interface

that shows detailed product information and the part

lists used in the product. Since some attached ﬁles

cannot be disclosed, the user who registers product

information can determine whether the information is

disclosed.

The inspection table includes information regard-

ing the vulnerabilities found in hardware designs.

Users assigned to the inspection agency role can reg-

ister their inspection reports to the inspection table.

The inspection report includes the results of design

testing, such as HT detection and formal veriﬁcation,

and is associated with a product record. The inspec-

tion record includes the date of inspection and inspec-

tion result.

3.3 Scenario of Repository Operation

In this repository scheme, the following scenario is

considered.

• Step 1. A manufacturer registers their hardware

design products to the repository and requests an

inspection agency to inspect their products.

• Step 2. An inspection agency assesses the vulner-

ability of the products using HT detection meth-

ods and reports the evaluation results.

• Step 3. The evaluation results are attached to the

product on the repository. These results can be

seen by repository users.

When a manufacturer hopes to use an IC chip,

they can refer to the repository and check the vulner-

ability information. If they ﬁnd a vulnerability or risk

information, they can stop using the product. Other-

wise, they can feel secure in using the product.

4 EVALUATION

4.1 Implementation Result

We implemented the repository system as a web

application. The tables are stored as a MySQL

database, and the backend of the web application is

implemented using a Python framework. Using this

web application, users, including hardware designers,

manufacturers, and inspection agencies, can refer to

the information stored in the repository and edit in-

formation within their authority.

Vulnerability Information Sharing Platform for Securing Hardware Supply Chains

405

Figure 3: Example of a web form of the repository system.

Figure 4: Illustration of the part composition on the reposi-

tory system.

Figure 3 shows a form of the repository system

to register design information. Since the repository

is implemented as a web application, users can edit

records on a browser.

Figure 4 shows the part composition of a design

registered in the repository system. The repository

system visualizes the relationship of the parts.

4.2 Questionnaire Survey

To investigate the feasibility of the repository oper-

ation scheme, we designed questionnaires and con-

ducted a survey based on the designed questionnaires.

There are ﬁve categories in the designed question-

naires: (a) basic information, (b) current situations,

measures in supply chains. The questions are de-

scribed in Tables 1–6 along with the responses cor-

responding to the questions.

The questionnaires were conducted through a con-

sulting ﬁrm. For a questionnaire survey, we col-

Table 1: Questions and responses to QA – basic informa-

tion.

QA1 Business description.

• Electronics or Vehicle

QA2 Position in the supply chain.

• Semiconductor manufacturers, fabless ven-

dors, EDA vendors, or vehicle manufacturers

QA3 Revenue.

• More than 100 M USD: 12

• Less than 100 M USD: 3

QA4 Number of employees.

• More than 10000: 13

• Less than 10000: 2

QA5 Country of headquarters.

• North America: 5, EU: 4, Asia: 6

QA6 Department of the respondent.

• Design, Development, Solution or Marketing

QA7 Position of the respondent.

• Manager or Section head

lected 15 respondents from around the world, includ-

ing North America, Europe, and Asia. We covered

three business types: integrated manufacturer, hori-

zontally specialized manufacturer, and implementa-

tion vendor. When asking the questions, the purpose

of the survey and the repository scheme proposed in

Section 3 were explained to the respondents. The

requester of the questionnaires was not disclosed to

avoid bias. The survey was conducted from August

2022 to January 2023. In the following section, we

provide the questions and responses. Due to page lim-

itations, the representative responses are shown in the

response tables.

4.2.1 QA: Basic Information

In this part, we asked for basic information about the

respondents’ afﬁliation and themselves.

Table 1 shows the summary of the responses to the

QA section. The business areas covered semiconduc-

tor manufacturers, fabless vendors, EDA vendors, and

vehicle manufacturers. The headquarters’ countries

cover major regions, including North America, Eu-

rope, and Asia. To collect feedback from production

and development ﬁelds, the respondents were mainly

stakeholders from the development and solution de-

partments. Since the questionnaires are related to ac-

tual design or manufacturing processes, the respon-

dent is chosen from a manager or a section head who

understands actual situations.

ICISSP 2024 - 10th International Conference on Information Systems Security and Privacy

406

Table 2: Questions and responses to QB – current situations.

QB1 Does your company investigate the IPs and parts from a security viewpoint before introducing them

to the design?

• We do not verify IPs introduced to products. Instead, we verify the ﬁnal products.

• We rigorously inspect products when purchasing. We also certify vendors. However, we use the evalu-

ation metric of quality (i.e., defective rate), not of security.

QB2 Are there any schemes to share alerts when doubt about some IPs or products occurs?

• A scheme has been established to respond to an issue and to address the issue with internal and external

parties.

QB3 Are there any schemes to share alerts when doubt about your product occurs?

• We have not experienced any problems regarding our products. If this happens, we leverage the scheme

to share information about the issues of products.

4.2.2 QB: Current Situations

In this part, we conﬁrmed the current situation regard-

ing the industry’s awareness of HTs. Speciﬁcally, we

aim to clarify that IPs are investigated from a security

viewpoint. In general, hardware design houses aim to

provide hardware designs that have sufﬁcient perfor-

mance and functionality according to speciﬁcations.

However, the awareness of security incidents, such as

being infected with HTs, has not been investigated.

We expect the questions in this part to reveal the cur-

rent attitude toward security perspectives.

Table 2 shows the summary of the responses to

the QB section. Few companies investigate IPs when

introducing them. Instead, the ﬁnal products are suf-

ﬁciently veriﬁed in terms of satisfying the speciﬁca-

tions and quality. However, such veriﬁcation aims to

conﬁrm the quality of the products, not in terms of

security. Remember that HTs are stealthily inserted

into products. Thus, it is difﬁcult to detect HTs under

current situations.

Most companies have schemes to share issues

with their products. When an issue is found, the in-

formation is shared with the whole company through

the scheme. The scheme can be utilized if a problem

in hardware designs, such as an HT, is found.

In summary, currently, there is a scheme to share

vulnerability information with the whole company.

However, a security-speciﬁc investigation has not

been sufﬁciently conducted.

4.2.3 QC: Needs

In this part, we conﬁrmed the need for HT detection

methods without considering feasibility. Since hard-

ware supply chains are exposed to geopolitical risks,

hardware vendors and manufacturers may pay atten-

tion to such security concerns. Security assessment

processes, such as HT detection, can be a solution to

this concern. In this situation, the cost of introducing

a security assessment process can be a problem. This

section clariﬁes these questions.

Table 3 shows the summary of the responses to the

QC section. Most companies were interested in secu-

rity assessment tools for hardware designs. In partic-

ular, identifying counterfeit products is desired. To

ensure the neutrality and reliability of the security as-

sessment, many companies expect third-party organi-

zations to perform the security assessment. However,

the cost of the security assessment is a major prob-

lem. Due to the competition over price, design houses

cannot cover the cost. Instead, it would be better for

business operators or industry organizations to cover

the cost.

4.2.4 QD: Effectiveness and Feasibility

In this part, we exhibited several examples of HT

detection methods and asked the respondents for an

evaluation regarding the efﬁciency and feasibility of

these methods. Although many HT detection meth-

ods have been studied in recent years, the feasibil-

ity of such methods has not been discussed. In this

section, we collected opinions on HT detection from

business operators.

In the QD4 question, we asked what level of de-

sign information your company can provide for the

security assessment process. Although the security

assessment process requires the analysis of hardware

designs, hardware design information is conﬁdential

in most cases. We provided several examples for the

question to clarify the possible resources to be dis-

closed. Table 4 shows the possible resources for the

QD4 question. Since hardware designs written in

HDL (the QD4-a option) are highly conﬁdential in-

formation for most vendors, we provide QD4-b as an-

other option. The QD4-b option shows feature ex-

traction techniques from a hardware design. The ex-

tracted features can be used for HT detection, and

original designs cannot be restored using the extracted

Vulnerability Information Sharing Platform for Securing Hardware Supply Chains

407

Table 3: Questions and responses to QC – needs.

QC1 Are you interested in security assessment tools for hardware designs?

• Security assessment tools are interesting.

• The market expects to identify counterfeit products everywhere in the supply chain.

QC2 Does your company investigate the delivered products from the security viewpoint?

• We do not conduct any security-oriented assessment. Instead, we verify and test our products before

shipment.

• Specialized veriﬁcation processes are conducted for security-related products.

QC3 Who should operate the security assessment process?

• Third-party agencies should operate the security assessment process. It is difﬁcult to maintain the

reliability of the assessment in the case of in-house assessment.

QC4 How do you consider the cost of the security assessment process?

• Business operators or industry organizations should cover the cost of the security assessment tools.

Table 4: Resources for the QD4 question.

# Item

QD4-a Hardware designs written in HDL.

QD4-b Feature values extracted from hardware

designs. Speciﬁcally, there are three

types of feature values: structural fea-

ture values (Oya et al., 2015; Dong et al.,

2020), SCOAP feature values (Salmani,

2017; Tebyanian et al., 2021), and graph

neural network-based embedding (Yu

et al., 2021; Hasegawa et al., 2023).

QD4-c Product information, such as the cate-

gory of IC.

QD4-d Application information, such as for

communication devices or for industrial

devices.

QD4-e Bill of materials or the component list of

the product.

QD4-f Report of inspection.

QD4-g Others (free comment).

features.

Table 5 shows the summary of the responses to

the QD section. Although the repository scheme cov-

ers the design process, most companies expect that

the repository scheme should cover all the processes,

including the manufacturing process. Since skill-

ful knowledge is required for the security assessment

process, many companies hope that an impartial and

professional organization should operate the reposi-

tory scheme. Speciﬁcally, government or industry or-

ganizations would be appropriate candidates for the

operator.

Since the hardware design information is conﬁ-

dential, providing designs, bills of materials, and in-

spection reports is extremely difﬁcult. However, in-

terestingly, the features extracted from hardware de-

signs (QD4-b explained in Table 4) can be disclosed

for security assessment if necessary. In this case, the

extraction process does not affect the existing produc-

tion process and is sufﬁciently supported by an extrac-

tion tool vendor. Although the design process should

be highly conﬁdential, feature extraction is a possi-

ble way to adapt security assessment to semiconduc-

tor supply chains. Some companies commented that

the scope of the disclosure must be restricted when

the information is disclosed.

From the results, it can be seen that the demand

for identifying counterfeit products is increased. To

meet the demand, The repository operation scheme

covering the whole supply chain is expected. In the

repository operation scheme, the feature extraction

process is interesting. Information regarding its cost

and benchmarks is useful for considering the process.

In terms of legal regulations, most companies are

concerned about geopolitical issues. These issues sig-

niﬁcantly affect business processes. Business opera-

tors in the automotive industry comply with interna-

tional standards that are more rigorous compared to

other industries.

4.2.5 QE: Risk Measures in Supply Chains

In this section, we investigated the concerns and risk

measures in semiconductor supply chains in terms of

legal regulations.

Table 6 shows the summary of the responses to

the QE section. For any company, the challenge lies

in balancing compliance with local laws and regula-

tions and maintaining stable production. Many com-

panies consider decentralizing production bases and

multi-sourcing of supply sources to address the risks

in semiconductor supply chains.

In case vulnerability assessment in hardware de-

vices is standardized, there is a concern about the

burden on business operators in terms of the cost and

measures they must take.

ICISSP 2024 - 10th International Conference on Information Systems Security and Privacy

408

Table 5: Questions and responses to QD – effectiveness and feasibility.

QD1 What information is helpful when using the repository scheme?

• Tools or schemes to identify counterfeit products are interesting.

• It is useful if the repository can cover the manufactured products to identify counterfeit products.

QD2 Who should operate the repository scheme?

• Institutions considering introducing a repository operation scheme.

• The government or industry organizations should design the system, and an impartial and professional

organization should operate it.

QD3 Is it acceptable if hardware designs are requested for the security assessment process?

• Generally, no companies provide circuit design information.

• It is unavailable due to license issues with IP vendors.

QD4 What level of design information can you provide for the security assessment process? (Possible

resources are listed in Table 4)

• If the repository scheme is operational, we can provide the resources QD4-c and QD4-d.

• QD4-b can be introduced, but it is necessary to examine issues such as the introduction burden of the

feature extraction tool regarding QD4-b.

• QD4-a and QD4-b are necessary for the repository operation scheme. However, QD4-a is not available.

QD4-b needs to be considered. For others, we think that QD4-c or QD4-d can be provided.

QD5 What kind of business operators would use the repository scheme?

• The communication infrastructure market is likely to have a high demand for security.

Table 6: Questions and responses to QE – risk measures in supply chains.

QE1 What are the risks in semiconductor supply chains?

• Counterfeit products.

• Geopolitical issues.

QE2 What measures do you take to avoid supply chain risks?

• Purchasing semiconductor materials from multiple companies and decentralizing production bases.

• We are responding to export control measures in each country.

• Strengthening public relations, especially by enhancing the relationship with the government.

QE3 What will affect your business if vulnerability assessment in hardware devices becomes mandatory

or is standardized?

• The concern is the burden on semiconductor manufacturers, such as the cost and measures taken.

• If the vulnerability assessment is standardized, we respond if it is necessary for our business.

The major barriers to implementing a security as-

sessment process in semiconductor supply chains are

commercialization and showing the beneﬁt of security

assurance. Although most companies are concerned

about security problems and interested in security as-

sessment tools, they do not clearly ﬁnd the beneﬁt of

security assessment. Considering the price competi-

tion of semiconductor products, the cost of security

is unacceptable. It would be difﬁcult to change this

mindset in the semiconductor market. Therefore, if

security assessment is necessary, legal regulation is a

solution to solve the problem.

4.3 Discussion

To secure hardware supply chains, a method using a

blockchain or smart contract platform has been pro-

posed (Chang and Chen, 2020). In supply chain man-

agement, traceability, transparency, and stakeholder

involvement are major concerns. A platform using

blockchain or smart contracts is expected to address

the concerns. The major feature of the blockchain

technology is decentralization. This technology al-

lows peer-to-peer exchange or transactions, such as

digital currency, without trusted authorities. This

mechanism also applies to a supply chain context.

However, implementing a blockchain-based mecha-

nism faces several issues from the perspective of reli-

ability, throughput, and computational cost.

A supply chain management method using a

knowledge graph has been proposed (Zhang et al.,

2019). In this method, a knowledge graph is con-

structed to analyze the risks of a supply chain. Based

on the constructed knowledge graph, the connection

Vulnerability Information Sharing Platform for Securing Hardware Supply Chains

409

between business operators and the bottleneck in the

supply chain can be visualized. However, collecting

standardized and reliable information from multiple

business operators is difﬁcult in the real world.

5 CONCLUSION

In this paper, we focus on the demand and aware-

ness of security assessment for hardware designs in

industries. First, we propose a repository opera-

tion scheme to share security assessment results with

inter-companies. Next, we design questionnaires to

conﬁrm the needs, effectiveness, and concerns based

on the repository operation scheme and summarize

the results of the questionnaires.

From the survey, we found that HT detection

methods are attractive for protecting semiconductor

supply chains. However, the barriers to implementing

HT detection in industries lie in commercialization

and in cultivating awareness of security in the indus-

try. Speciﬁcally, identifying counterfeit products and

covering the whole supply chain are expected. For ex-

pectations, future work should cover the whole supply

chain and clarify the beneﬁts of the scheme in indus-

tries.

ACKNOWLEDGMENTS

The questionnaire survey was conducted by Omdia,

a part of Informa Tech as a consulting project for

the original questionnaire survey belongs to Omdia.

The results reported in this paper were obtained from

“The Contract of Research for Detection Techniques

of Hardware Vulnerabilities” (Ministry of Internal Af-

fairs and Communication, Japan in FY2022).

REFERENCES

Almeida, F., Imran, M., Raik, J., and Pagliarini, S. (2022).

Ransomware attack as hardware trojan: A feasibility

and demonstration study. IEEE Access, 10:44827–

44839.

Chang, S. E. and Chen, Y. (2020). When blockchain meets

supply chain: A systematic literature review on cur-

rent development and potential applications. IEEE Ac-

cess, 8:62478–62494.

Dong, C., Liu, Y., Chen, J., Liu, X., Guo, W., and Chen,

Y. (2020). An unsupervised detection approach for

hardware trojans. IEEE Access, 8:158169–158183.

Francq, J. and Frick, F. (2015). Introduction to hardware

trojan detection methods. In 2015 Design, Automa-

tion & Test in Europe Conference Exhibition (DATE),

pages 770–775.

Hasegawa, K., Yamashita, K., Hidano, S., Fukushima, K.,

Hashimoto, K., and Togawa, N. (2023). Node-wise

hardware trojan detection based on graph learning.

IEEE Transactions on Computers, pages 1–13.

Hasegawa, K., Yanagisawa, M., and Togawa, N. (2017a).

Hardware trojans classiﬁcation for gate-level netlists

using multi-layer neural networks. In Proc. IEEE In-

ternational Symposium on On-Line Testing and Ro-

bust System Design (IOLTS), pages 227–232.

Hasegawa, K., Yanagisawa, M., and Togawa, N. (2017b).

Trojan-feature extraction at gate-level netlists and its

application to hardware-trojan detection using random

forest classiﬁer. In Proc. IEEE International Sympo-

sium on Circuits and Systems (ISCAS), pages 1–4.

Huang, Z., Wang, Q., Chen, Y., and Jiang, X. (2020). A

survey on machine learning against hardware trojan

attacks: Recent advances and challenges. IEEE Ac-

cess, 8:10796–10826.

Li, S., Zhang, Y., Chen, X., Ge, M., Mao, Z., and Yao, J.

(2020). A xgboost based hybrid detection scheme for

gate-level hardware trojan. In Proc. IEEE Joint Inter-

national Information Technology and Artiﬁcial Intel-

ligence Conference (ITAIC), volume 9, pages 41–47.

Oya, M., Shi, Y., Yanagisawa, M., and Togawa, N. (2015).

A score-based classiﬁcation method for identifying

hardware-trojans at gate-level netlists. In 2015 De-

sign, Automation & Test in Europe Conference & Ex-

hibition (DATE), pages 465–470.

Salmani, H. (2017). Cotd: Reference-free hardware trojan

detection and recovery based on controllability and

observability in gate-level netlist. IEEE Transactions

on Information Forensics and Security, 12:338–350.

Tebyanian, M., Mokhtarpour, A., and Shaﬁeinejad, A.

(2021). Sc-cotd: hardware trojan detection based on

sequential/combinational testability features using en-

semble classiﬁer. J. Electron. Test., 37(4):473–487.

Xiao, K., Forte, D., Jin, Y., Karri, R., Bhunia, S., and Tehra-

nipoor, M. (2016). Hardware trojans: Lessons learned

after one decade of research. ACM Transactions on

Design Automation of Electronic Systems, 22.

Yang, Y., Ye, J., Cao, Y., Zhang, J., Li, X., Li, H., and

Hu, Y. (2020). Survey: Hardware trojan detection

for netlist. In 2020 IEEE 29th Asian Test Symposium

(ATS), pages 1–6.

Yu, S.-Y., Yasaei, R., Zhou, Q., Nguyen, T., and Faruque,

M. A. A. (2021). Hw2vec: a graph learning tool for

automating hardware security. In 2021 IEEE Interna-

tional Symposium on Hardware Oriented Security and

Trust (HOST). IEEE.

Zhang, W., Liu, Y., Jiang, L., Shah, N., Fei, X., and Cai,

H. (2019). The construction of a domain knowledge

graph and its application in supply chain risk analy-

sis. In IEEE International Conference on E-Business

Engineering, pages 464–478.

ICISSP 2024 - 10th International Conference on Information Systems Security and Privacy

410