Identifying Food Fraud using Blockchain
Hoi Wen Leung, Adriane Chapman
a
and Nawfal F. Fadhel
b
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 efficiency. 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
sufficient 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 identified 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
a
https://orcid.org/0000-0002-3814-2587
b
https://orcid.org/0000-0002-1129-5217
logistics and monitor food product flow(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 flaw 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
Copyright
c
2021 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
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. Identified 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 identification 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 finality
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 identified
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 final 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 profits(Hong et al., 2017).
According to European Union Food Legislation,
the food supply chain is composed of production, pro-
cessing, transport, distribution and supply
1
. This is
illustrated in Fig. 1 in the context of milk production,
and the following stakeholders and their responsibili-
ties are considered:
1
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 flow 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 specific to blockchain application
and food supply chain.
Attack Description
Modification
attack
The malicious actor tampers the
product details of a transaction
block in an unauthorised
way(Alzahrani and Bulusu, 2020).
Spoofing
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 defining 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 final 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 benefits 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 redefined 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
|B
data
(1)
B
header
= Hash
cur
|Hash
prev
|Timestamp (2)
B
data
= P
data
|Role|S ig|Address
s
|Address
d
(3)
P
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
prev
) 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
fields 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 modification attacks if block’s fields are mod-
ified 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 workflow 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 first 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
s
) and private keys (PR
s
) from the source which is
the farmer along with the public key (PU
d
) from the
destination node which is the processor. The product
data (P
data
) as follows:
Sig = Sign
PR
s
(PU
s
|PU
d
|P
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 efficiently.
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 modification attacks
since product details and the block’s digital signature
are considered. The proposed block (Block
i
) is only
considered to be valid if the following are satisfied:
1. Given B
data
of Block
i
, the digital signature is ver-
ified using PU
s
.
2. P
data
on Block
i
is the same as the ones on the
last block from the node’s copy of the blockchain
(BC).
3. P
data
is modified only in an authorised way.
4. Hash
cur
of Block
i
is calculated correctly.
5. Hash
prev
of Block
i
is the same as Hash
cur
of
Block
i-1
.
Algorithm 1: Block validation.
Require: Block
i
!= NULL
if Block
i
!= 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
i
then
return false
end if
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
1
n
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
m
). 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
n
) 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
m
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.
SV
m
random no. up to lim
threshold n ×
2
3
timeout n × 10 seconds
for round 1 to 3 do
Multicast(ASK 0) all voters
while !timeout do
valueList.insert(received SV
n
)
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
n
- 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
spoofing 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 satisfies 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
i
.
2. The proposer broadcasts Block
i
to the blockchain
network, so each voter executes the local valida-
tion algorithm and vote for Block
i
. This stage
should prove validity of the protocol.
3. Voters prepare for validation master selection by
generating SV
m
. Then the network uniformly and
randomly selects two masters. This SV
n
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)
2
valida-
tors randomly. The masters multicasts a request
for acknowledgement to the chosen validators.
6. After confirmed selection of the validators, each
validator requests vote from all voters and decides
on an outcome if there are at least
2n
3
responses.
Block
i
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
n
3
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. Specifi-
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
2
. This blockchain
is modelled to be a permissioned because confiden-
tiality and privacy of the food supply chain actors
need to be protected against their competitors.
Test scenario cases were defined based on the at-
tack vectors. These cases are used as input files for
the simulation of the food supply chain. The actors
are modelled as agents in the simulation with
n
3
or
less actors performing malicious behaviours to mimic
the possible threats. The cases are defined in a way
that all the aforementioned attacks are covered and
with various levels of difficulties 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
Modification
attack
Malicious node alters
fields of the products
before proposing the a
new block.
36
Spoofing
attack
Attacker act as genuine
nodes and perform
activities to disrupt the
consensus protocol.
12
As modification attack defines the illegitimacy of
the new block, so all honest nodes should vote the
block as invalid to maintain protocol’s validity. As
for spoofing 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
2
https://www.bouncycastle.org/
IoTBDS 2021 - 6th International Conference on Internet of Things, Big Data and Security
190
Undetected
Spoofing
Modify
Name
Modify
Ingredients
Modify
ID
Modify
Farmer
Undetected
Spoofing
Modify
Name
Modify
Ingredients
Modify
ID
Modify
Farmer
Defined
Detected
0
5
10
15
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 defined test scenarios case is no fraud, modi-
fication attack or spoofing attack. Therefore, our aim
is to produce the same label as the defined 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 identified as having no threats incorrectly.
These cases occur because there are more than
1
3
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
defined fraudulent scenarios, given by TP plus FN.
Precision =
k
i=1
T P
i
T N
i
+FP
i
k
(6)
Recall =
k
i=1
T P
i
T P
i
+FN
i
k
(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 defined by the test scenarios.
This indicates a high frequency of the model being
correct when fraud is detected. For recall, 93.3% of
the defined fraud scenarios are able to be detected by
the system correctly. Thus, recall demonstrates the
implemented protocol’s ability in returning most of
the defined scenarios. Subsequently, the high values
indicate the consensus protocol’s good performance
in detecting modification and spoofing 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 modification 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
modification 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
spoofing 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 modification, spoofing 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
1
3
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 identification like bar-
code and Radio-frequency identification (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