Identifying Food Fraud using Blockchain

Hoi Wen Leung, Adriane Chapman

and Nawfal F. Fadhel

School of Electronics and Computer Science, University of Southampton, Southampton, U.K.

Keywords:

Food Fraud, Food Supply Chain, Blockchain, Consensus Algorithm.

Abstract:

Cross-contamination, counterfeit ingredients, false packaging, and labelling are all issues that contribute to

food fraud which is a major concern undermining the integrity of the food supply chain and consumers health.

Therefore, there is a need for an on-demand traceable, transparent food supply chain. This is a universal

problem and blockchain presents itself as a means to maintain traceable, transparent food supply. This paper

presents an innovative consensus algorithm and simulates the usage of it to identify the precision and recall of

fraudulent food detection. This protocol aims to solve the issue of malicious leader node selection in common

voting-based consensus protocols while achieving efﬁciency. Thus, providing a single version of truth for

foods in a long food supply chain, preventing information asymmetries.

1 INTRODUCTION

With the demand for food product transparency on

the rise, existing product traceability systems are not

sufﬁcient to maintain an immediate and reliable food

analysis(Flari et al., 2014). This demand is mainly

due to the increasing number of food fraud cases

and incidents, such as the horse meat scandal and

organic food counterfeit. These scandals jeopardise

the credibility and consumer’s trust of the food sup-

ply chain, thus introducing reputational risk and brand

damage(Kamath, 2018). Upon investigating the scan-

dals, one of the fundamental issues identiﬁed in the

current food supply chain system is the serious delays

in tracing food products(Litke et al., 2019). This is

due to the complexity and fragmentation of the food

supply chain. However, the adoption of industry 4.0

can evolutionise the food supply chain with the inte-

gration of technologies. It aims to target food safety

and security in the hope of providing successful food

supply chain management(Ojo et al., 2018).

A contributing factor to food fraud is the lim-

ited peer-to-peer transparency resulting from infor-

mation asymmetries(Flari et al., 2014). In response

to achieving end-to-end visibility along the food sup-

ply chain, many companies turn to solutions involv-

ing blockchain. In addition to its functionality as

transparency in cryptocurrencies, many existing use

cases that utilise blockchain to manage supply chain

https://orcid.org/0000-0002-3814-2587

https://orcid.org/0000-0002-1129-5217

logistics and monitor food product ﬂow(Verhoeven

et al., 2018). For instance, IBM and Walmart utilise

blockchain to create a data exchange platform to

achieve food provenance(Kamath, 2018). A startup

called Bext360 also demonstrates a mindful use of

this technology by binding data to bags of coffee to

improve traceability(Verhoeven et al., 2018).

Although the current blockchain solutions in the

food supply chain offer product traceability and bet-

ter supply chain management(Verhoeven et al., 2018),

there is limited research on identifying food fraud

to safeguard the food supply chain. In this work,

we analyse protocol for detecting food fraud. One

problem with the current consensus protocols used in

blockchain is that they are designed mainly for cryp-

tocurrencies to validate transactions, such as Proof-

Of-Work. This method allows a high level of trust

to be developed between participants at the cost of

high energy consumption overhead. Another pop-

ular protocol within the cryptocurrencies domain is

Proof-Of-Stake, though less computationally expen-

sive, it has the ﬂaw of the “Nothing at Stake” prob-

lem, so blockchain participants can validate block

transactions without opportunity cost(Alzahrani and

Bulusu, 2020). Practical Byzantine Fault Tolerance

is a voting-based consensus algorithm where a pri-

mary node is responsible for publishing blocks and

their consensus(Litke et al., 2019), this suggests a ma-

jor weakness if this leader node is malicious which

in turn hinders the data integrity of the blockchain.

For instance, the attacker aims to manipulate the fre-

Leung, H., Chapman, A. and Fadhel, N.

Identifying Food Fraud using Blockchain.

DOI: 10.5220/0010423801850192

In Proceedings of the 6th International Conference on Internet of Things, Big Data and Security (IoTBDS 2021), pages 185-192

ISBN: 978-989-758-504-3

185

quency of them being the leader in order to impact the

validation outcome(Deirmentzoglou et al., 2019). De-

spite the decentralisation, transparency and security

that blockchain provides, there is a need for a more

suitable consensus protocol for food supply chain ap-

plication(Litke et al., 2019) as well as overcoming the

aforementioned vulnerabilities from other protocols.

To improve the detection of ingenuine products

within the food supply chain and provide a single ver-

sion of truth for the food products, we propose a new

voting-based consensus protocol where every inter-

mediary on the food supply chain can vote for the

truthfulness of the transaction block. With the aim

to prevent the existence of a single malicious leader

node, multiple node selection stages are carried out

which choose validators and validation master ran-

domly to validate blockchain participants’ votes and

block outcome respectively. In this work, we simulate

the usage of the blockchain consensus protocol in the

food supply chain to test the precision and recall of

fraudulent food detection, as well as the prevention of

various types of attacks. Our contributions include:

1. Identiﬁed a novel use case for blockchain to pro-

tect the food supply chain. See Section 3.

2. Created a new voting-based consensus protocol

that allows food supply intermediaries to vote for

the block truthfulness, using multiple node se-

lection stages to choose validators and validation

masters randomly. See Section 4.

3. The precision and recall of fraud detection high-

lighted by this approach, as well as the attacks

prevented. See Section 5.2.

4. Analysed the use of the proposed protocol for

fraud identiﬁcation through simulation. See Sec-

tion 5.3.

2 RELATED WORK

The problem of lack of transparency in the food

supply chain has been an ongoing issue. It is

clear that adopting blockchain technology brings sub-

stantial improvements in providing traceability in-

formation(Verhoeven et al., 2018; Kamath, 2018;

Shevchuk, 2019). Kamble et al. perform a quanti-

tative study through a combined methodology of In-

terpretive Structural Modelling (ISM) and Decision-

making Trial and Evaluation Laboratory (DEMA-

TEL) to evaluate the links between the enablers. In

particular, they introduce the importance for a con-

sensus mechanism to assure information authentic-

ity. Their result demonstrates blockchain’s potential

in enhancing traceability, auditability and provenance

in supply chains(Kamble et al., 2020).

Block-Supply is presented by Alzahrani and Bu-

lusu to target the problem of counterfeit goods. They

made use of the decentralised approach to track prod-

ucts to detect fraudulent activities. A new consensus

protocol based on Tendermint is also introduced. This

protocol employs the concept of voting-based consen-

sus protocols to eliminate the need for existing min-

ing which is commonly used in Blockchain(Alzahrani

and Bulusu, 2020). Another consensus protocol,

FireLedger examines the trade-off between ﬁnality

and latency when achieving agreement on a per-

missioned blockchain. Although FireLedger pro-

posed protocol is designed for cryptocurrencies ap-

plications, it emphasised the requirements of validity,

agreement and termination which are also identiﬁed

in this paper(Buchnik and Friedman, 2019).

Fadhel et al. utilises threat modelling to analyse

how the possible security issues of the Internet-of-

Things(IoT) can put the proposed blockchain-based

smart grid at risk. This approach provides informa-

tion of the involved parties and their activities so as

to assess the quality and reliability of the suggested

architecture(Fadhel et al., 2019). Similarly, our attack

vectors are modelled using agents with respect to the

food supply chain entities and their behaviours. This

approach enables us to evaluate the reliability of the

proposed protocol.

3 FOOD SUPPLY CHAIN USE

CASE

The food supply chain is a complex network that de-

scribes the process of food production from its origin

to the ﬁnal product. As food products have vastly dif-

ferent production procedures due to their distinctive-

ness(Shevchuk, 2019), for the purpose of understand-

ing how the proposed design impact fraud detection,

we narrow the focus to the milk supply chain. It is

a common practice for fraudulent actors to add for-

eign substances to the milk with the aim to increase

product quantity for illegal proﬁts(Hong et al., 2017).

According to European Union Food Legislation,

the food supply chain is composed of production, pro-

cessing, transport, distribution and supply

. This is

illustrated in Fig. 1 in the context of milk production,

and the following stakeholders and their responsibili-

ties are considered:

https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=

legissum:f80501

IoTBDS 2021 - 6th International Conference on Internet of Things, Big Data and Security

186

Production of

feed for cows

Milk

production

Milk

transportation

Processing

PackagingDistributionRetailConsumer

Figure 1: Milk supply chain.

1. Farmers: Responsible for converting raw mate-

rial (cows) to a product (milk) used as input to the

system.

2. Processors: In charge of transforming raw milk.

They also manage the packaging of the product.

They have the right to modify product details in

an authorised way.

3. Distributors: Organises milk product transporta-

tion to its destination.

4. Retailers: The receiving ends of the distribution,

such as supermarkets, restaurants etc.

3.1 Attack Vectors

A blockchain food traceability system can be utilised

further than product ﬂow monitoring to fraudulent

product prevention across the food supply chain.

Thus, it is important to outline the various existing

weaknesses and threats on the blockchain application

and the food supply chain. Table 1 describes the most

concerning attacks in the food supply chain.

Due to the possible existence of the aforemen-

tioned attacks in the blockchain network, trustful co-

operation must be established between the nodes.

Therefore, the role of consensus protocol is to enable

users to trust the blockchain output and its ability in

detecting fraud(Hammi et al., 2018).

Table 1: Attack vectors speciﬁc to blockchain application

and food supply chain.

Attack Description

Modiﬁcation

attack

The malicious actor tampers the

product details of a transaction

block in an unauthorised

way(Alzahrani and Bulusu, 2020).

Spooﬁng

attack

The attacker disguises as

legitimate food supply chain actor

and participate in block validation

process with the aim to disrupt the

blockchain’s operation(Hammi

et al., 2018).

3.2 Requirements

For the purpose of deﬁning the functionality of the

consensus protocol, a bottom-up approach is em-

ployed to elicitate the requirements from use cases.

This method allows emphasis on the food supply

chain actor’s goal of the proposed solution by cov-

ering both the leader node selection and voting mech-

anism. All stakeholders are considered as primary ac-

tors, and the following summarises the use cases:

1. Record Transaction: Once the ownership of the

milk product is transferred, the receiving actor

scans the product detail and proposes a block con-

taining the transaction and await for validation.

2. Local Block Validation: The blockchain partici-

pants receive a request to validate the newly pro-

posed block with their copy of the blockchain, and

decide on the genuinity of the block.

3. Global Block Validation: Validation leaders re-

ceive votes of the block from all live participants

and validate the votes in several stages and decide

on a ﬁnal outcome to commit or abort the block.

Based on the use cases, functional requirements

are derived and outlined below. They describe the

consensus protocol’s need for users to achieve a de-

sired result(Hammi et al., 2018):

1. Termination: The consensus process eventually

halts when all valid nodes reach an outcome.

2. Total Ordering: The sequence of votes and vali-

dation requests are processed in the correct order.

3. Agreement: The block on the blockchain must

be globally recognised through consensus from all

valid nodes.

4. Validity: If all valid nodes validate the same input

block, then all values voted must be the same.

5. Integrity: All honest nodes should have the same

shared state containing the agreed blocks.

6. Zero-knowledge: All nodes should have no

knowledge of other nodes’ votes and vote inde-

pendently. Also, the nodes should not be able to

predict the identity of leader nodes.

7. Randomness: Each validator is mapped to a val-

idation master randomly and fairly.

4 APPROACH

As the aim is to address food fraud detection in the

food supply chain, such consensus protocol should

Identifying Food Fraud using Blockchain

187

solve the general block transaction agreement prob-

lem with minimal energy consumption(Litke et al.,

2019). Hence, in this section, we propose a novel con-

sensus mechanism by considering the beneﬁts of the

existing techniques and overcoming their weaknesses.

4.1 Key Components

During the process of executing the consensus pro-

tocol, each node takes on different duties. Thus, the

following roles are considered:

1. Proposer: This node proposes a block recording

the current transaction and broadcasts it for vali-

dation. There is only one proposing node for each

consensus protocol execution.

2. Voter: Voting node performs local validation of

the proposed block and decide the block’s validity.

All nodes except the proposing node are voters.

3. Validator: Validating node receives votes from

all voters and return an outcome for the block.

The number of validating nodes depends on the

total number of nodes.

4. Validation Master: This node is responsible for

performing the random selection of validation

nodes. The master node also acts as a safety net

to verify the outcome generated by validators.

Once consensus of the block is achieved success-

fully, it represents a valid milk product transaction on

the blockchain network. We also redeﬁned the block

structure slightly for it to be suitable for blockchain in

the food supply chain. A valid block consists of two

main parts, the block header (B

header

) and the block

data (B

data

). The block follows a structure:

Block

valid

= B

header

data

(1)

header

= Hash

cur

|Hash

|Timestamp (2)

data

= P

data

|Role|S ig|Address

|Address

(3)

data

= ID|Name|Origin|Farmer|Ingredients (4)

The blockchain is ensured to be well-chained in

the correct order using hashes of the current (Hash

cur

)

and previous (Hash

) blocks. The timestamp guar-

antees data immutability by preventing blockchain

manipulation, thus enhancing information complete-

ness. B

data

contains the product data (P

data

) which has

ﬁelds such as Origin and Farmer to allow food to be

traced from farm-to-fork. Role indicates the type of

food supply chain actors and their modify rights of the

product. This provides the ability for the protocol to

detect modiﬁcation attacks if block’s ﬁelds are mod-

iﬁed in an unauthorised way. In addition, the digital

signature Sig is an essential part of blockchain. It is

generated using the cryptographic algorithm, ECDSA

which does not require much computational power.

The addresses of source and destination allows moni-

toring of the product’s workﬂow and assure traceabil-

ity.

4.2 Proposed Consensus Protocol

The protocol consists of three phases: a local valida-

tion phase where voters determine the truthfulness of

a transaction block, a selection phase where validat-

ing nodes are chosen in a randomised and dynamic

way, and a consensus phase where all participating

nodes’ votes are considered collectively to determine

the validity of the proposed block.

For the protocol to provide Byzantine fault toler-

ance, it is assumed that the blockchain network has

two-third of non-malicious nodes. We also introduced

a timeout consistently throughout the protocol. This

timeout is relative to the size of the network to guaran-

tee the liveness of the protocol and allow the detection

of any malfunctioned or disconnected nodes.

4.2.1 Local Validation Phase

This phase is executed by all voters when after a node

receives the food product and proposes a block. Each

voter individually validates the proposing block and

generates a vote accordingly.

To understand what criteria needs to be checked

whilst validating a transaction, we lay out how the

genesis block is created with an example. Con-

sider the ﬁrst stage of the milk supply chain, when

the farmer produces raw milk from cows. Once the

product is created, there is a digital label attached

which represents the physical form of the product.

The farmer scans this label storing information about

the product, acting as the preliminary input into the

blockchain system. The system then creates a propos-

ing block with content listed in Section 4.1.

The proposed block is digitally signed with Sig. In

this case, ECDSA generates Sig by utilising the public

(PU

) and private keys (PR

) from the source which is

the farmer along with the public key (PU

) from the

destination node which is the processor. The product

data (P

data

) as follows:

Sig = Sign

(PU

|PU

data

) (5)

As the farmer is the proposer of the genesis block,

their digital signature is attached to the block. Hence-

forth, the ECDSA-generated digital signature can act

as a means to verify the authenticity of the block con-

tent efﬁciently.

IoTBDS 2021 - 6th International Conference on Internet of Things, Big Data and Security

188

The local validation process is explained in Algo-

rithm 1. This validation detects modiﬁcation attacks

since product details and the block’s digital signature

are considered. The proposed block (Block

) is only

considered to be valid if the following are satisﬁed:

1. Given B

data

of Block

, the digital signature is ver-

iﬁed using PU

2. P

data

on Block

is the same as the ones on the

last block from the node’s copy of the blockchain

(BC).

3. P

data

is modiﬁed only in an authorised way.

4. Hash

cur

of Block

is calculated correctly.

5. Hash

of Block

is the same as Hash

cur

Block

i-1

Algorithm 1: Block validation.

Require: Block

!= NULL

if Block

!= calculateHash() OR !verifySigna-

ture(Sig) OR Block

i-1

hash != previousHash then

return false

end if

if modifyRight == false then

if ProductD

i-1

!= ProductD

then

return false

end if

return true

4.2.2 Selection Phase

This phase occurs after local validation is completed.

It highlights how the validation master and valida-

tors are selected in a random and fair manner. This

randomised node selection prevents malicious nodes

from predicting who the selected node are.

The algorithm presented in Algorithm 2 shows

the validation master selection process. To be-

gin, each node has the probability of

from be-

ing selected as validation master, with n being

total number o f nodes − 1. All non-proposing nodes

generate a random selection value (SV

). Addition-

ally, the upper limit of the selection value range can

be changed to adjust the randomness.

To universally decide on the validation masters,

each node requests other’s selection value (SV

) and

executes a comparison between all these values and

a randomly generated deciding value (DV), so the re-

sulting two nodes with the closest SV

are chosen to

be validation masters. This selection process is per-

formed by all non-proposing nodes to ensure correct-

ness of the chosen master, so no malicious nodes can

claim the role of validation masters.

Algorithm 2: Validation master selection.

n ← total no. of nodes − 1

lim ← static random no.

← random no. up to lim

threshold ← n ×

timeout ← n × 10 seconds

for round ← 1 to 3 do

Multicast(ASK 0) → all voters

while !timeout do

valueList.insert(received SV

)

end while

if valueList size == n OR valueList size ≥

threshold then

Break

end if

round++

end for

if round > 3 OR valueList size < threshold then

Exit

end if

DV ← lim ÷ random no.

valueList.map(SV

- DV)

valueList.sort()

master1 ← valueList[0]

master2 ← valueList[1]

After successful mapping of validation masters to

a proposer, the validators selection is carried out. The

masters share the workload of selecting the valida-

tors and handling the communication between them.

Consequently, each master selects half of the required

number of validators. The number of validators was

determined to be log(n), with four nodes being the

minimum number of validators required to tolerate

single Byzantine fault(Alzahrani and Bulusu, 2020).

The size given by the logarithm allows communi-

cation overhead to be optimised while making sure

spooﬁng attack can be protected against. This pro-

cess is similar to the validation master selection but

without the use of selection and decision values.

It is important to note that the visibility of com-

munication between validators and validation master

is not open to all milk supply chain participants, so

only the validators have knowledge of who the master

nodes are. Furthermore, each master does not share

the same validators as they execute the validators se-

lection algorithm independently to prevent collusion

of the selection. Therefore, this satisﬁes the require-

ments of zero-knowledge and randomness.

4.2.3 Consensus Phase

When validation masters and validators are selected,

the protocol is ready to enter the consensus phase.

Identifying Food Fraud using Blockchain

189

The following details the process from the milk sup-

ply chain actor receiving the product, to validation

masters considering all the votes to decide collec-

tively whether the proposed block should be on the

ledger. It is worth mentioning that all types of mes-

sages are signed by the private key of the sender, and

each message has a timestamped ID attached to pre-

serve total ordering.

1. A node receives the milk product from the previ-

ous actor of the milk supply chain. This node then

becomes a proposer and proposes Block

2. The proposer broadcasts Block

to the blockchain

network, so each voter executes the local valida-

tion algorithm and vote for Block

. This stage

should prove validity of the protocol.

3. Voters prepare for validation master selection by

generating SV

. Then the network uniformly and

randomly selects two masters. This SV

exchange

also acts as acknowledgements from other nodes,

so each voter keeps track of non-Byzantine nodes.

4. The validation masters perform handshakes with

each other to verify their identities.

5. The validation master each selects

log(n)

valida-

tors randomly. The masters multicasts a request

for acknowledgement to the chosen validators.

6. After conﬁrmed selection of the validators, each

validator requests vote from all voters and decides

on an outcome if there are at least

responses.

Block

is only determined to be genuine or ingen-

uine if all received votes align. Otherwise, the

outcome is inconclusive. If the number of rounds

is still within the limit, validators request the vot-

ers to perform local validation again and send the

new votes. However, if there are

or less nodes

with votes different to the rest of the voters, these

voters are concluded to be malicious. It is worth

noting that the use of rounds limit avoids never-

ending loops and ensures the protocol terminates.

7. When each validator has decided on an outcome,

the validation masters are informed of the out-

come by their chosen validators. If the valida-

tors consistently give mismatched responses, this

signals a possible existence of malicious valida-

tors. A master-outcome is then determined by

each master if each receives the same outcome

from their set of validators.

8. Finally the validation masters communicate with

each other to check if their master-outcome

matches. A master with different master-outcome

signals a possible malicious validation master

node. Otherwise, the block is committed to the

ledger or aborted accordingly.

5 EVALUATION

This section describes the simulation used to evaluate

the performance of our consensus protocol. Speciﬁ-

cally, we considered the attack vectors mentioned in

Section 3 to determine the protocol’s ability in detect-

ing food fraud on the blockchain application.

5.1 Simulation Setup

Due to the lack of platform to simulate blockchain,

we implemented a basic blockchain network in Java.

Also, various cryptography functions from Bouncy

Castle was used to generate keys pair, calculate

hashes and apply digital signatures

. This blockchain

is modelled to be a permissioned because conﬁden-

tiality and privacy of the food supply chain actors

need to be protected against their competitors.

Test scenario cases were deﬁned based on the at-

tack vectors. These cases are used as input ﬁles for

the simulation of the food supply chain. The actors

are modelled as agents in the simulation with

less actors performing malicious behaviours to mimic

the possible threats. The cases are deﬁned in a way

that all the aforementioned attacks are covered and

with various levels of difﬁculties to be detected. Cor-

respondingly, the simulation of the attack model are

introduced in Table 2.

Table 2: Attack modelling overview.

Attack How it is modelled Case

count

Modiﬁcation

attack

Malicious node alters

ﬁelds of the products

before proposing the a

new block.

Spooﬁng

attack

Attacker act as genuine

nodes and perform

activities to disrupt the

consensus protocol.

As modiﬁcation attack deﬁnes the illegitimacy of

the new block, so all honest nodes should vote the

block as invalid to maintain protocol’s validity. As

for spooﬁng attack, the types of activities depends on

the node’s role during the consensus protocol. Con-

sider an attacker posing as a genuine voter to disor-

ganise the consensus protocol, this node would mis-

behave in the voting process. For instance, they would

vote valid regardless of the result from the local val-

idation, threatening the data integrity and validity of

the blockchain network. If the node is a malicious

validator, it determines the block outcome to be valid

https://www.bouncycastle.org/

IoTBDS 2021 - 6th International Conference on Internet of Things, Big Data and Security

190

Undetected

Spooﬁng

Modify

Name

Modify

Ingredients

Modify

Farmer

Undetected

Spooﬁng

Modify

Name

Modify

Ingredients

Modify

Farmer

Deﬁned

Detected

Figure 2: Error matrix of consensus protocol.

without considering any votes received from the vot-

ers. Similarly, for a corrupted validation master, they

would set the master-outcome to be valid and disre-

gard the outcome generated from validators. As a

result, we have modelled dishonest nodes to always

determine the proposed to be valid regardless of the

actual authenticity of the block.

5.2 Detection of Fraud

To answer how reliable the consensus protocol is in

detecting food fraud, we evaluate this based on the

output generated from running the test cases. There

are labels associated with the test cases which indi-

cate if a deﬁned test scenarios case is no fraud, modi-

ﬁcation attack or spooﬁng attack. Therefore, our aim

is to produce the same label as the deﬁned label after

the simulations.

The result generated from the simulations after

running all the test cases is visualised using an er-

ror matrix in Figure 2. This two-dimensional contin-

gency table shows to show whether the correct types

of food fraud are detected correctly.

The diagonal elements show correct fraudulent

scenarios detected by the system, whereas the other

cells are missorted entries. It is obvious that some

cases are identiﬁed as having no threats incorrectly.

These cases occur because there are more than

ma-

licious nodes which the model is not designed to toler-

ate. Otherwise, the shaded diagonal elements provide

evidence that the model is very effective in identifying

food fraud cases.

To interpret the results better, we used the perfor-

mance metrics that can be derived from the error ma-

trix. These metrics are precision and recall. Precision

assesses the proportion of correctly detected fraudu-

lent scenarios cases amongst the fraud detected by the

protocol. It is a useful indicator of how precise the

consensus protocol is out of the detected fraud. Preci-

sion calculates the number of true-positives (TP) over

the the sum of TP and false-positives (FP), across

fraud of all labels. The formula for precision is given

in Equation 6.

On the other hand Equation 7 presents recall, this

is used because of the high cost of false-negatives

(FN). In the context of food fraud, this cost is the

cost when a fraud is mislabelled as non-fraud. Recall

looks at the proportion of fraudulent scenarios that are

actually detected by the protocol over the number of

deﬁned fraudulent scenarios, given by TP plus FN.

Precision =

∑

i=1

T P

T N

+FP

(6)

Recall =

∑

i=1

T P

+FN

(7)

The values of precision and recall were computed

to be 0.941 and 0.933 respectively. The precision

means that 94.1% of the detected fraudulent cases are

actually fraudulent as deﬁned by the test scenarios.

This indicates a high frequency of the model being

correct when fraud is detected. For recall, 93.3% of

the deﬁned fraud scenarios are able to be detected by

the system correctly. Thus, recall demonstrates the

implemented protocol’s ability in returning most of

the deﬁned scenarios. Subsequently, the high values

indicate the consensus protocol’s good performance

in detecting modiﬁcation and spooﬁng attacks.

5.3 Analysis of Available Attack Vectors

As blockchain is a trustless network, security is an es-

sential factor. Hence, we provide analysis of the pos-

sible attacks presented in Table 2 and how our pro-

posed protocol mitigate them.

In the proposed protocol, the local validation is

mainly responsible for detecting modiﬁcation attack

which is the most vulnerable during block’s transac-

tion data generation. Therefore, the placement of the

local validation algorithm enables honest voters to re-

ject the ingenuine block, improving the detection of

modiﬁcation attack. Besides, as each block utilises

digital signature, this guarantees block originality. If

anyone attempts to modify the content, the signature

will be invalidated and the attack is detected.

Our consensus protocol is also protected against

spooﬁng attacks. As each node can only have a single

identity and the feature of permissioned blockchain

only allows approved nodes to join the network, the

attacker cannot disguise as a genuine blockchain node

Identifying Food Fraud using Blockchain

191

without their identity authenticated. Furthermore,

each legitimate node holds a public-private key pair,

so the attacker cannot spoof another node’s identity

since they do not have the required private key.

6 CONCLUSIONS

In this paper we presented a novel consensus proto-

col suitable for the food supply chain. We utilised

validation, selection and consensus mechanisms to

achieve validity, randomness and agreement. This

protocol can detect modiﬁcation, spooﬁng attacks on

blockchain used in the food supply chain. Our simu-

lation shows that the protocol is very capable of tol-

erating such attacks, but scalability and latency have

yet to be evaluated. Additionally, further work are re-

quired to assess the consensus protocol’s performance

in detecting other attacks. Nevertheless, this proves

the protocol’s reliability in detecting food fraud.

7 FUTURE WORK

Apart from the concerned attack vectors suggested in

Section 3, there are other security threats that our pro-

tocol can be protected against. Therefore, these at-

tacks will require further modelling and evaluation in

our future work.

In mining-based consensus protocol, bribery at-

tack is introduced(Alzahrani and Bulusu, 2020). At-

tackers deliberately present invalid transaction and

bribe the dishonest nodes to vote it as valid. This can

majorly diminish other node’s trust in the blockchain.

Our protocol mitigates this by introducing a ran-

domised multiple node selections. To test this, we can

model this attack with the malicious proposing node

communicating off-chain with

corrupted nodes and

bribe them.

Another problem is the food supply chain’s poor

ability in early fraud detection(Flari et al., 2014).

This is closely related to the inadequate food authen-

ticity checks.(Hong et al., 2017). Commonly these

checks only involve product identiﬁcation like bar-

code and Radio-frequency identiﬁcation (RFID), but

further analysis into food composition is required to

identify adulterated products so as to serve as an im-

portant means to assure food safety. As a result, we

aim to explore the use of sensor technology in better

representing the physical product state in the future.

ACKNOWLEDGEMENTS

This work was funded by EPSRC (EP/S028366/1).

REFERENCES

Alzahrani, N. and Bulusu, N. (2020). A new product anti-

counterfeiting blockchain using a truly decentralized

dynamic consensus protocol. Concurrency and Com-

putation: Practice and Experience, 32(12):e5232.

Buchnik, Y. and Friedman, R. (2019). Fireledger: A

high throughput blockchain consensus protocol. arXiv

preprint arXiv:1901.03279.

Deirmentzoglou, E., Papakyriakopoulos, G., and Patsakis,

C. (2019). A survey on long-range attacks for proof

of stake protocols. IEEE Access, 7:28712–28725.

Fadhel, N., Aniello, L., Margheri, A., Lombardi, F., and

Sassone, V. (2019). Towards a semantic modelling

for threat analysis of iot applications: a case study on

transactive energy.

Flari, V., Hussein, M., Maeder, R., Hubar, B., Marvin, H.,

and Neslo, R. (2014). Report on analysis of histori-

cal cases of food fraud. Ensuring the Integrity of the

European food chain.

Hammi, M. T., Hammi, B., Bellot, P., and Serhrouchni, A.

(2018). Bubbles of trust: A decentralized blockchain-

based authentication system for iot. Computers & Se-

curity, 78:126 – 142.

Hong, E., Lee, S. Y., Jeong, J. Y., Park, J. M., Kim, B. H.,

Kwon, K., and Chun, H. S. (2017). Modern analytical

methods for the detection of food fraud and adulter-

ation by food category. Journal of the Science of Food

and Agriculture, 97(12):3877–3896.

Kamath, R. (2018). Food traceability on blockchain: Wal-

mart’s pork and mango pilots with ibm. The Journal

of the British Blockchain Association, 1(1):3712.

Kamble, S. S., Gunasekaran, A., and Sharma, R. (2020).

Modeling the blockchain enabled traceability in agri-

culture supply chain. International Journal of Infor-

mation Management, 52:101967.

Litke, A., Anagnostopoulos, D., and Varvarigou, T. (2019).

Blockchains for supply chain management: Architec-

tural elements and challenges towards a global scale

deployment. Logistics.

Ojo, O. O., Shah, S., Coutroubis, A., Jim

enez, M. T., and

Munoz Ocana, Y. (2018). Potential impact of industry

4.0 in sustainable food supply chain environment. In

2018 IEEE International Conference on Technology

Management, Operations and Decisions (ICTMOD),

pages 172–177.

Shevchuk, A. (2019). Traceability technology: fruits and

vegetables trader case study. In International Confer-

ence on Digital Technologies in Logistics and Infras-

tructure (ICDTLI 2019). Atlantis Press.

Verhoeven, P., Sinn, F., and Herden, T. T. (2018). Exam-

ples from blockchain implementations in logistics and

supply chain management: Exploring the mindful use

of a new technology. Logistics.

IoTBDS 2021 - 6th International Conference on Internet of Things, Big Data and Security

192