Formalizing Attack Tree on Security Object for MySANi in Legal Metrology

Abstract

Illegal software manipulation is one of the biggest issues in software security. This includes the legally relevant software which are now crucial modules in weight and measuring instruments such as weighbridges. Despite the advancement and complexity of weight and measuring instruments, the inspection methodology is weak and lacks of innovation. The conventional inspection method is merely based on the observation printed certificate of the software. This paper introduces Malaysia Software-Assisted Non-Automatic Weighing Instrument (NAWI) Inspection (MySANI), a method used to enhance the software inspection scheme in legal metrology. MySANI introduces security objects in order to assist and enhance the inspection process. The security evaluation is based on the best practices in IT in metrology, where the attack model on relevant assets of the security objects is simulated for the Attack Probability Tree. The attack tree is verified by integrating formal notation and comparison with finite state transition system domain to verify the correctness properties of the tree design before the model can be further used in a risk analysis procedure within the Attack Probability Tree framework. Results show that the designed attack tree is consistent with the designed simulation.

1. Introduction

Pattern approval (PA) is an examination and evaluation of regulated measuring instruments conducted by an impartial body to design an instrument prototype against national or international standards or statutory requirements [1]. This exercise is part of the legal metrology (LM) ecosystem to determine whether the measuring instrument is suitable for the intended use and can retain its accuracy and function under various environmental and operating conditions [2].

During the PA process, software evaluation, verification, and assessment are crucial for guaranteeing a credible and seamless operation of weighing and measuring equipment and systems [3]. The penalty for using forged measuring instruments is outlined in Section 17 of the Weights and Measures Act 1972 [4].

Despite the sophistication and complexity of measuring instruments, software enforcement framework within LM is poor. Furthermore, based on our literature studies, we found that there lack of best practices in tree structure and comprehensive tree design.

This paper introduces Malaysia Software-Assisted Non-Automatic Weighing Instrument (NAWI) Inspection (MySANI) which is a designed method in inspecting the compliance of universal computer-based software for NAWI within the LM framework in Malaysia [5]. Security objects within MySANI are introduced, which is novel in the LM ecosystem. Thus, this proposed method enhances the overall inspection process within the LM framework in Malaysia. The paper demonstrates the use of SAND operator in the attack tree design and subsequently proving it using formal method against finite state transition which was impossible in the previous studies.

2. Related Works

In software engineering, risk analysis is one of the processes in risk assessment. It is a measuring stick for evaluating the effectiveness of security design of a system [6]. Around 50% of security problems are due to design weaknesses. Thus, the risk analysis performed at the design construction stage is very important for software security programs.

At the design stage, any risk analysis should be tailored to the software design [7]. Risks associated with threats can be modelled as risk = impact × likelihood.

Understanding the harm that an asset expose is necessary for effective asset protection. Risk assessment is used as a tool for information as an asset [8]. In information security, risk involves three main concepts: threat, vulnerability, and impact.

According to ISO/IEC 27005, the term risk is “combination of the consequences that would follow from the occurrence of an unwanted event and the likelihood of the occurrence of the event”. Figure 1 shows the components in risk analysis.

2.1. Security Evaluation in Legal Metrology

In LM, risk analysis is used as a tool to evaluate the security of a designed system or instrument. In a recent study, a method based on ISO/IEC 27005, 15408, and 18045 was developed by Esche and Thiel [9] to provide the foundation of security analysis in LM domain. However, this technique justifies the security of measuring instruments based merely on the device’s technical features alone.

This method later was improved by incorporating the attacker’s motivation. It was performed by integrating an attack tree modeling as part of the evaluation framework which is known as Attack Probability Tree (AtPT) [10].

2.2. Attack Tree

An attack tree is a model for visualizing and analyzing potential security threats [11]. This method has been adopted by the North Atlantic Treaty Organization (NATO) as well as the Open Web Application Security Project (OWASP) [12]. Several studies have been conducted by integrating attack trees with risk management methodologies such as supervisory control and data acquisition (SCADA), radio-frequency identification (RFID), and automated teller machine (ATM).

ATSyRA [13] made an approach by extracting a defined filter structure from an expert. This allows the semantic domain and structure of the filter to be found without intervention from experts. However, this method has imperfect (informal) label structure.

TREsPASS [14] applies the security knowledge base to the attack tree generated from the model system. However, the generic IT security knowledge base is incompatible for the LM situation.

Another formal design methodology is ADTool [15]. This method adopts the ADTree-based attack tree concept [16]. However, ADTree has a different approach with two types of players: strikers and defenders. This methodology, however, is not compatible with the AtPT scoring semantics used in the LM based on ISO/IEC 18045.

Attack tree design is a subjective procedure according to [17]. Esche in [10] emphasizes that in the field of LM, all measuring instruments share the same basic characteristics. Based on the fact that all instruments are based on the same technical solution it should be that the diversity of attack tree designs produce the same results.

Although the attack tree design is considered simple and intuitive, there is room for conceptual errors and a diversity of interpretations regarding the semantic refinement of the tree. Thus, there lack of best practices in tree structure and comprehensive tree design.

3. Research Methodology

Attack tree design in an AtPT framework is enhanced in this study where formal notation replaces the original version used only text to the name for each node [18]. We also improved the attack tree by adapting the SAND operator where the original model did not have it.

The attack tree decoration phases are formalized in mathematical notation in both the attack tree domain and finite state transition domain. This is to validate the correctness properties by using a method introduced by [19].

Table 1. Notation with description.

Notation	Description
Prop	Set of propositions
ι	Initial configuration
γ	Final configuration
Տ	State transition system
S	Finite transition set
s	Element/state
ℕ	A set of natural numbers
λ: Prop→2S	Labelling function
Π, ρ	Path
υ	Attack vector
T	Attack tree
α	Set of attributes
Ɽ	Risk scoring
⟨ιn,γn⟩	Leaf/goal
OP	Operator

shows the important notations that are used in the study.

3.1. Finite State Transition

Prop is a set of propositions containing all the variables representing a situation at one time. This Prop is in the form of ι, γ to denote the state before (ι) and after an event (γ). In this context the event is an attack vector υ.

A state transition system is a tuple Տ = (S, →, λ), where S is the finite transition set (elements of s, s_i) for i ∈ ℕ while → ⊆ S×S is the transition relation to the system and assumed to be the left total. The λ: Prop → 2S is the labeling function. A state s is labelled as p when s ∈ λ (p) and the size of S is |S | = |S | + |→|.

A path in system S is the state condition where it has non-empty sequences of states. The symbols such as π and ρ are used to depict the paths. A cycle in paths π ∈ Π(Տ) is a factor of π′ of π where π′(0) = π′(|π′|).

An elementary path is a path which has no cycle. A path π which is elementary, does not have any state that more than once. Therefore, |π| ≤ |Տ|, removing all the cycles from π iteratively until the resulting path is non-elementary.

Table 2. Attack tree critical analysis.

Description	Esche	Audinot
Tree Model	generic	formal
Refinement	OR, AND	OR, AND, SAND
Node Name	informal, ordinary text-based	formal notation ⟨ι, γ⟩
Node Description	action-based	state-based
Design validation	unavailable	finite state transition

summarizes the attack tree critical analysis.

3.2. Formalizing Attack Tree

In conjunction with the analysis of AtPT methodology [20], attack vector υ for attack tree T over a set of attack vector attributes (

Table 3. Attack vector attributes.

Symbol	Attribute
Du	time required
Ex	expertise
Kn	knowledge required
Wn	windows of opportunity
Eq	equipment required

) is the refinement for the path π from with the direction from ι to γ. Assuming υ ∈ →, where υ₁, υ₂,…υ_n is the attack vectors for each T₁, T₂,…T_n, for 1 ≤ i ≤ n. The size of attack vector is |υ| = |T | ∋ ∀ T_n ∃ υ_n. The attack vector evaluation consists of conditions OP ∈ {OR, AND, SAND) and has the number of arity n ≥ 2. The main goal of a an attack vector υ is γ where the original state is ι and where the operator is OP. The attack tree can be represented in the form of T = (⟨ι, γ⟩, OP)(T₁, T₂,…T_n). Where the size of an attack tree |T| is the number of attack vectors in T such that |⟨ι, γ⟩| = 1 and |(⟨ι, γ⟩, OP)(T₁, T₂,…T_n)| = $1+{{\displaystyle \sum }}_{i=1}^n\left|T_i\right|$.

Let the set of attributes α = {Du, Ex, Kn, Wn, Eq} for all υ₁, υ₂,…υ_n be the attack vectors for T₁, T₂,…T_n. While the Ɽ be the AtPT risk scoring calculation based on the OP over the set α. Therefore, υ _i = Ɽ (OP, α) where, OP ∈ {OR, AND, SAND | 1 ≤ i ≤ n }.

3.3. Attack Tree Correctness Property

According to [21], an attack tree is considered to have the meet property when:

⟦OP(⟨ι₁,γ₁⟩, ⟨ι₂,γ₂⟩,…⟨ι_n,γ_n⟩)⟧^Տ ∩ ⟦ ⟨ι,γ⟩ ⟧^Տ ≠ ∅

While undermatch property has:

⟦OP(⟨ι₁,γ₁⟩, ⟨ι₂, γ₂⟩,…⟨ι_n, γ_n⟩)⟧^Տ ⊆ ⟦⟨ι,γ⟩⟧^Տ

And overmatch reflects:

⟦OP(⟨ι₁,γ₁⟩, ⟨ι₂,γ₂⟩,…⟨ι_n,γ_n⟩)⟧^Տ ⊇ ⟦⟨ι,γ⟩⟧^Տ

Finally, the match property is:

⟦OP(⟨ι₁,γ₁⟩, ⟨ι₂,γ₂⟩,…⟨ι_n,γ_n⟩)⟧^Տ = ⟦⟨ι,γ⟩⟧^Տ

In other words, the meet property is a minimum property for an attack tree before further analysis can be performed. This proves that at least one path can achieve the main goal and its refinements. This feature indicates that this tree model is essentially considered to be correct, and researchers can already begin to estimate the security of a system.

Undermatch shows that all paths that meet the refinement of a node also meet the goal itself. It can be considered as an underestimate for a set of scenarios and is enough to find the weaknesses of a system. While overmatch, on the other hand indicates that all paths that achieve the root node goal also met all decomposition to sub-goals. This is an assumption. If the tree characteristics are found to be a match, then it is considered that a tree has one hundred percent similarity with the system analyzed.

A tree should have a minimum of admissible and meet features for a tree design to be considered correct with respect to the analyzed systems.

4. Malaysian NAWI Software Inspection for Computer

Malaysia Software-Assisted Non-Automatic Weighing Instrument Inspection (MySANI) is a proposed method designed to enhance the inspection process within the framework of the LM ecosystem in Malaysia as depicted in Figure 2 [22]. It consists of two parts, which are PA and market surveillance.

In Malaysia, PA is stated in the Weights and Measures Act 1972 (Act 71) and the National Measurement System Act 2007 (Act 675). The PA is provided for the National Measurement Standard Laboratory (NMSL) to carry out inspection and evaluation activities of measuring equipment [23,24]. Each measuring equipment has its own set of rules and laws enforced by specialized government enforcement agencies. For example, smoke meters, axel scales, and speed traps are enforced by the Road and Transport Department. Meanwhile measuring instruments for trade purposes are under the jurisdiction of Ministry of Trade and Consumer Affairs. PA covers all trade and law enforcement activities to ensure that the instruments meet the requirements of legal and international standards. It also ensures that measurement accuracy, fair trade, and law enforcement function well in all environmental conditions and situations [25]. The instrument was tested and evaluated from various physical aspects in a variety of conditions, including software functionalities [26].

Illegal usage of software for NAWI is detected in the market during market surveillance once the pattern is approved [27]. This activity is carried out by regular inspections such as by a government-appointed third-party organization (as in the current situation). There are three elements to be checked on NAWI software during market surveillance:

• Printed certificate/hard copy certificate (HC) information;
• Certificate–software pairing is correct;
• Legally relevant (LR) part of the software is intact.

If any of these stated elements are in doubt, the surveillance check is considered failed. The enforcement officer can take further steps such as sealing the whole system and seizing the whole measuring instrument system for further investigation.

The details of MySANI workflow during pattern approval and for market surveillance are depicted in Figure 3 and Figure 4, respectively.

4.1. Security Object

To achieve the aforementioned objectives, security objects (SOs) are implemented within the MySANI method. SOs consist of two parts: (1) soft-certificate plaintext (SC_P); and (2) quasi file (QF) [5]. Figure 5 illustrates the components of the security object which are used in MySANI.

• Transformed polynomial checksum for Ȼ_KA;
• Plain checksum Č_LR for LR module which are recorded inside the SC_P.

QF is designed as the security carrier to the SC_P. It protects the information contained from modification. Attacks on the SC_P merely be focus on the QF security features. QF gathers several sections of data into single file. It consists of three main parts: ciphered soft certificate SC_E, public key K_A, and the checksum of K_A with a hidden polynomial Ȼ_KA. The SC_P is encrypted using the RSA private key K_P to become SC_E. K_A and K_P are generated by National Metrology Institute of Malaysia (NMIM) during certification process. K_P is not disclosed and is only known by NMIM. The QF = {SC_E, K_A, Ȼ_KA} consists of three sub-components as described in

Table 4. QF components.

Component	Description
SCE	Ciphertext of SCP
KA	Public Key (RSA)
ȻKA	Checksum of KA which undergone polynomial transformation Ť

.

Let decr decryption and encr be the encryption function, K_A as public key and K_P as private key. SC_E is the ciphered text of SC_P. Therefore, SC_P = decr(SC_E, K_A) = decr(encr(SC_P, K_P), K_A) is the plaintext certificates which contain approval information that is important for inspection. It contains some of the plaintext information of static HC without security features ∀SC_P ∶ SC_P ⊆ HC where it uses an XML format based on the proposed DCC format [28].

4.2. Process Workflow

During the PA certificate preparation stage, the certificate number and approval of related information along with the important information are used in the preparation of the SC_P. The information in this is important and sufficient for field inspection purposes. This SC_P is then encrypted for the QF preparation process at the later stage. The checksum for the LR module Č is generated for the purpose of printed certificate HC preparation. Some important information is used in the preparation of the SC_P. The information in this is important and sufficient for field inspection purposes. This SC_P is then encrypted for the QF preparation process at a later stage.

Table 5. Information inside plaintext certificate.

Field	Description
Certificate owner	Name of approval
Approval number	Approval number
Approval mode	Mode of approval (full/conditional)
Date of approval	Effective date of approval
Validity period	The duration of approval validity
Software name	The official software name
LR module	List of LR module

shows the information inside the plaintext certificate.

The MySANI workflow during pattern approval is shown in Figure 3. After a software passes the conformity assessment, while the certificate and approval information are being prepared for printed certificate HC, a pair of keys consisting of K_A and private key K_P are generated. The polynomial Ȼ for K_A is also calculated and placed inside HC. The soft certificate plaintext SC_P contains approval information as well as the plain checksum for legally relevant module Č. The SC_P is then encrypted by using K_P and becomes the ciphered certificate SC_E. The three elements (SC_E, K_A and Ȼ_KA) are then combined to form the QF. The QF is passed to the applicant or undergoes an embedding process to its main executable (ME) depending on the approval mode for distribution.

A special tool, MySANI inspection software (MySANI-IS), is developed to assist the enforcement officer to verify the security objects. The MySANI first tries to locate the QF; whether it is embedded within the main executable ME or as a standalone QF file. If it is embedded, then extraction procedures are performed to pull out the QF out of the ME. The QF is then extracted into three parts: SC_E, K_A, and Ȼ_KA. The Ȼ_KA is used to determine the key’s integrity and authenticity before it is used to extract the SC_E to form the SC_P. The approval information is then extracted from the SC_P and is displayed to the examiner for inspection. The plain Č is used to determine whether the legally relevant part of the software is intact or not.

4.3. Polynomial Transformation

The polynomial transformation Ť = {St₁, St₂, ƭ} is an algorithm function to generate a checksum with hidden polynomial Ȼ instead of a standard plain checksum Č, for alignment with the LM requirements. Ť is realized by first calculating the checksum of two concatenated strings (St₁ and St₂) to become the Ȼ′ and then performing bitwise XOR off the resulting checksum with secret bytes ƭ.

Č_KA is the unknown plain checksum of K_A where Ť(K_A, S_S, ƭ): Č_KA → Ȼ_KA. The Ȼ_KA is in different form of Č_KA with equivalent strength of the checksum algorithm such that Č_KA ⇔ Ȼ_KA. Any modification that changes Č_KA also changes the Ȼ_KA.

Ȼ_KA′ checksum is calculated over the concatenated string of j = K_A ⧺ S_S, where S_S is secret string and j contains both strings in the form of st₁ and st₂ where the st₁ is the string of K_A while st₂ is the string S_S such that K_A ⧺ S_S = {st₁ st₂: st₁ ∈ K_A, st₂ ∈ S_S}. Then, Ȼ_KA′= crcf (j) and Ȼ_KA = Č_KA′⊕ ƭ. The Ȼ_KA′ can be retrieved back for integrity comparison purposes by Ȼ_KA′= Č_KA ⊕ ƭ.

Information within the SC_P is retrieved back and displayed to the inspector during market surveillance to confirm the correctness of the printed certificate information. Inspection is considered failed if the information displayed within SC_P is not the same as the information on the printed certificate.

The checksum of the legally relevant software is generated (Č_LR′) in real time for the purpose of comparison with the stored Č_LR to check the integrity of the legally relevant module. Let the extr be the QF extraction function such that ((Č_LR′ = Č_LR→extr(QF)) ∧ (¬Č_LR′ = Č_LR))→FAIL!.

5. Modelling Attack Scenario for MySANI

The attack tree is used to visualize the attack vectors that an attacker might perform. In order to model an attack tree, an attack scenario is required to be established in the first place. The attack scenario describes how the attacker might access the protected information and try to fake the information within the SO.

In this simulation, the attacker’s main target is to modify the content of QF. The attacker himself is the owner of the software and indirectly also owns the QF (worst case scenario). The attacker has unrestricted access to the target artifact. The attacker is assumed to already possess MySANI-IS used by the inspector as the second target of attack.

The attacker realizes that the K_P is required to encrypt back the amended SC_P′. Since the key pair uses the RSA algorithm and the original K_P is not placed in the inspection’s software, the only way is by generating the fake private key pair of K_P′ and the fake public key of K_A′. K_P′ is used to re-encrypt SC_P′ while K_A′ is placed back into QF replacing the original K_A.

In order for the status of the QF to remain valid during the field inspection, the attacker must find a way to perform reverse engineering on the software used by the inspector to obtain the Ť algorithm which protects the K_A as part of QF. Suppose the attacker succeeds in breaking the Ť algorithm: in that case, the attacker can recalculate the fake hidden polynomial Ȼ′ and once again, the attacker can reconstruct the fake QF (QF′) by reassembling the above three parts, namely SC_P′, K_A′ and Ȼ′. If this happens, the inspection is in valid status even if the QF’s contents are changed. The inspector is not able detect the irregularities of the QF.

The analysis is started by studying the attack vectors on QF. An attacker will not carry out an attack motivated by damaging or destroying the availability of the QF or altering any QF structure as this causes the status check to fail and the enforcement officer may immediately seize the entire system for further investigation.

5.1. Attack Simulation

The root of the attack tree is υ_t, when it is the ultimate goal for the attacker with intention to fake the QF with fabricated information and leave no trace of evidence during the market surveillance inspection. The tree consists of three main branches (υ₁, υ₂, and υ₃). Attack vector υ₁ is about obtaining the QF, attack vector υ₂ is about modifying the content, while υ₃ is about hiding the trace. Figure 6 shows the attack tree designed for the simulation. The details of each of attack vector is described in

Table 6. Summary of attack vectors.

Field	Description
υt	Attacker wants to fake the QF without any trace.
υ1	Attacker wants to obtain the QF.
υ11	The attacker extracts QF which is embedded inside the ME and tries to rebuild it into a single file.
υ12	Attacker tries to obtain the QF which is already in a single file form.
υ2	Attacker tries to amend the SCP information inside the QF.
υ21	Attacker tries to obtain the KA which is part of elements in QF.
υ22	Attacker decrypts the SCP using KA.
υ23	Attacker amends the information inside SCP into SCP′.
υ3	Attacker reorganize, reform the QF into fake QF′.
υ31	Attacker generates fake KP′.
υ32	Attacker encrypts the SCP′ using KP′.
υ33	Attacker tries to obtain the Ť algorithm and recalculate the transformed polynomial based on SCP′ and KA′.
υ34	The attacker reforms and rebuilds the QF’ again using fake components.

.

5.2. Security Object State Modelling

The formal validation method is performed by using a finite state transition system to validate the attack tree T design model. Before analysis can be performed, the attack tree must also be presented in the form of formal notation.

Q = {Q⁻, Q⁺, Qg, Qt}: This variable specifies the state of QF. Where, Q⁻ indicates the state where the attacker does not have QF and it is embedded in the ME target of evaluation (TOE), Q⁺ indicates the state of the attacker does not have QF and is in the form of an individual file, Qg is the state where the attacker already has QF and is ready for attack, and Qt is the state where the attacker rearranges the QF with false elements.

PKey = {NaC, AcG, AcF}: This variable specifies the state of public key. NaC indicates the attacker does not yet obtain the original public key K_A, AcG indicates the original public key of the K_A is successfully obtained, and AcF the situation where the attacker generates and possesses a fake key pair.

S_CP = {Up, Oe, Oc}: This variable indicates the condition of plaintext certificate. It consists of three states: Up is the situation where the SCP plaintext soft certificate is not opened, Oe is the situation where the SCP plaintext soft certificate is successfully opened, and Oc is the situation where the SC_P plaintext soft certificate is amended with fake information.

TpRev = {tt, ff} is the variable which indicates the states of Ť algorithm cracks, whether the attacker successfully cracks the algorithm (tt) or not (ff).

5.2.1. State Transition Modelling

Let the Ƶ system consist of two parties, namely the attacker and the QF. The system is modeled using a state variable, i.e., where its value determines the configuration possibilities for the system. In the initial settings, the attacker is assumed to not yet have a QF and intends to attack the QF by modifying the SC_P without being able to be detected by the inspecting officer. To model the dynamic properties for the system, let the system be (z_i−1, z_i) ∈→, for every 1 ≤ i ≤ 9. For the initial condition for the QF, q = (Q =Q⁻) ∨ (Q =Q⁺) while the q′ = (Q =Qg) ∨ (Q =Qt) and z₀, z₁ ∈ λ (q). For each state z_i ∈ λ (q′) for 3 ≤ i ≤ 9.

The path ρ, shows the scenario for the attacker to execute an attack from the beginning of the situation to the end of the goal in the ρ system.

Table 7. State transition summary.

Variable	z0	z1	z2	z3	z4	z5	z6	z7	z8	z9
Q	Q−	Q+	Qg	Qg	Qg	Qg	Qg	Qg	Qg	Qt
PKey	NaC	NaC	NaC	AcG	AcG	AcG	AcF	AcF	AcF	AcF
ScP	Uo	Uo	Uo	Uo	Op	Oe	Oe	Oc	Oc	Oc
TpRev	ff	ff	ff	ff	Ff	ff	ff	ff	tt	tt

summarized the state transition.

For the transition system, only one variable changes at a time. z₀ indicates a situation where the QF is not yet owned, is embedded, and needs to be extracted into an individual file, the attacker does not have any cryptographic keys, while the content of the soft certificate are in its original form. The state can be represented as Q = Q⁻ while the PKey = NaC, z₀, z₁ ∈ λ (q) and TpRev = ff.

The transition is as follows:

• z₁ is the same as z₀ but QF is in the form of a separate file that needs to be identified by the attacker. The Q = Q⁺ state transition occurs;
• z₂ is the same as z₀ but QF is successfully owned by the attacker. The Q = Qg state transition occurs;
• z₃ is the same as z₂ but the attacker managed to obtain the K_A public key from the QF element. The PKey = AcG state transition occurs;
• z₄ is the same as z₃ but this time the attacker managed to open the SC_P by decrypting the SC_E using K_A. The ScP = Op state transition occurs;
• the z₅ is the same as the z4 but the attacker generates a fake key pair that matches the original public key configuration. The following PKey = AcF variable change occurs;
• z₆ is the same as z₅ but the attacker amended SC_P to SC_P′. The ScP = Oe variable values are changed;
• z₇ is the same as z₆ but the attacker encrypted SC_P′ using fake private key. The ScP = Oc values are changed;
• z₈ is the same as z₇ except at this point the attacker successfully cracked the Ť algorithm, TpRev = tt;
• And finally, z₉ is the same last state as the z₈ but the attacker reformed the QF with fake elements Q = Qt.

5.2.2. Attack Tree Formal Modelling

A similar attack is being modeled as attack tree T for the system Ƶ as discussed, which has a goal in the form T = (⟨ι, γ⟩, SAND)(T₁, T₂, T₃). Where the formal representation of each sub-tree:

T₁ = (⟨ι₁,γ₁⟩), OR)(⟨ι₁₁,γ₁₁⟩,⟨ι₁₂,γ₁₂⟩);
T₂ = (⟨ι₂,γ₂⟩), SAND)(⟨ι₂₁,γ₂₁⟩, ⟨ι₂₂, γ₂₂⟩, ⟨ι₂₃,γ₂₃⟩);
T₃ = (⟨ι₃, γ₃⟩), SAND)(⟨ι₃₁, γ₃₁⟩,⟨ι₃₂, γ₃₂⟩,⟨ι₃₃, γ₃₃⟩, ⟨ι₃₄, γ₃₄ ⟩).

Each sub-tree T_i has the atomic goal in the form of ⟨ι_i, γ_i⟩. The same variables are applied to the state transition notation. Figure 7 shows the attack tree with formal notations.

For the formal model the attack tree is as follows:

• The original situation is where the attacker does not yet have a QF, does not have a public key, is not able to access plaintext soft certificates, and did not successfully crack the Ť algorithm.

  ι:= (Q = Q⁻) ˄ (PKey = NaC) ˄ (ScP = Uo) ˄ (TpRev = ff);
• The ultimate goal for the attacker is to be able to amend the plaintext soft certificate, possess a fake key pair, re-encrypt using a fake private key, and put a fake public key back in the amended QF.

  γ:= (Q = Qt) ˄ (PKey = AcF) ˄ (ScP = Oe);
• Atomic target ⟨ι₁, γ₁⟩: In the original state, the attacker does not yet have QF and needs to identify a QF as the target first. The goal is to have the QF in the form of individual file. Assuming ⊤ represents an empty configuration, therefore:

  ι₁:= ⊤ and γ₁:= (Q = Qg);
• Atomic goals ⟨ι₁₁, γ₁₁⟩: QF is embedded in the ME and the attacker must first extract it into a single file. Therefore:

  ι₁₁:= (Q = Q⁻) and γ₁₁ = γ₁;
• Atomic goals ⟨ι₁₂, γ₁₂⟩: QF is available as an individual file. The attacker needs to identify the location of the QF file. Therefore:

  ι₁₂:= (Q = Q⁺) and γ₁₂:= (Q = Qg);
• Atomic goal ⟨ι₂, γ₂⟩: The attacker aims to modify the SC_P in the QF. Therefore:

  ι₂:= (Q = Qg) ∧ (PKey = AcG) ∧ (ScP = Uo) ∧ (TpRev = ff) and γ₂:= γ;
• Atomic goal ⟨ι₂₁, γ₂₁⟩: Attacker obtains K_A. Therefore:

  ι₂₁:= (Q = Qg) ∧ (PKey = NaC) and γ₂₁:= (PKey = AcG);
• Atomic goal ⟨ι₂₂, γ₂₂⟩: Attacker decrypts SC_E using K_A. Therefore:

  ι₂₂:= γ₂₁ and γ₂₂:= (ScP = Op);
• Atomic goal ⟨ι₂₃, γ₂₃⟩: Attacker modifies the contents of the SC_P. Therefore:

  ι₂₃:= γ₂₂ and γ₂₃:= (ScP = Oe);
• Atomic goal ⟨ι₃, γ₃⟩: The attacker aims to reconstruct the QF using modified plaintext data and fake keys. Therefore:

  ι₃:= (PKey = AcF) ∧ (ScP = Oe) ∧ (TpRev = ff) and γ₃:= γ;
• Atomic goal ⟨ι₃₁, γ₃₁⟩: Attacker generates fake K_P′. Therefore:

  ι₃₁:= ⊤ and γ₃₁:= (PKey = AcF);
• Atomic goals ⟨ι₃₂, γ₃₂⟩: The attacker encrypts the SC_P′ by using fake key K_P′. Therefore:

  ι₃₂:= (PKey = AcF) ∧ (ScP = Oe) and γ₃₂:= (ScP = Oc);
• Atomic goals ⟨ι₃₃, γ₃₃⟩: Attack polynomial transformations based on K_P′ and SC_P. Therefore:

  ι₃₃:= (TpRev = ff) and γ₃₃:= (TpRev = tt);
• Finally, the atomic goal ⟨ι₃₄, γ₃₄⟩: The attacker reconstructs all elements into a false QF. Therefore: ι₃₄:= (PKey = AcF) ∧ (ScP = Oe) ∧ (TpRev = tt) and γ₃₄:= γ₃.

5.3. Formal Analysis and Discussion

T₁ is defined as ⟦⟨ι₁, γ₁⟩⟧^Տ while for the sub-trees, are ⟦⟨ι₁₁, γ₁₁⟩⟧^Տ and ⟦⟨ι₁₂, γ₁₂⟩⟧^Տ, respectively. Therefore, because of ⟦OR(⟨ι₁₁, γ₁₁⟩, ⟨ι₁₂, γ₁₂⟩)⟧^Տ = ⟦⟨ι₁₁, γ₁₁⟩⟧^Տ ∪ ⟦⟨ι₁₂, γ₁₂⟩⟧^Տ while ⟦⟨ι₁, γ₁⟩⟧^Տ ∩ ⟦OR(⟨ι₁₁, γ₁₁⟩, ⟨ι₁₂, γ₁₂⟩)⟧^Տ ≠ ∅, then the tree is considered to have the meet property.

Since the ⟦OR(⟨ι₁₁, γ₁₁⟩, ⟨ι₁₂, γ₁₂⟩)⟧^Տ ⊇ ⟦⟨ι₁, γ₁⟩⟧^Տ, thus the T₁ is also has the overmatch property.

For T₂, it is defined as ⟦⟨ι₂, γ₂⟩⟧^Տ and all the sub-trees can be refined as ⟦ SAND(⟨ι₂₁, γ₂₁⟩, ⟨ι₂₂, γ₂₂⟩, ⟨ι₂₃, γ₂₃⟩)⟧^Տ; therefore, the sub-trees are equivalent to ⟦⟨ι₂₁, γ₂₁⟩⟧^Տ ⋅ ⟦⟨ι₂₂, γ₂₂⟩⟧^Տ ⋅ ⟦⟨ι₂₃, γ₂₃⟩⟧^Տ. From a quick analysis, the ⟦SAND(⟨ι₂₁, γ₂₁⟩, ⟨ι₂₂, γ₂₂⟩, ⟨ι₂₃, γ₂₃⟩)⟧^Տ ≠ ∅ and thus, T₂ is considered to have the meet property. Moreover, ⟦SAND(⟨ι₂₁, γ₂₁⟩, ⟨ι₂₂, γ₂₂⟩, ⟨ι₂₃, γ₂₃⟩)⟧^Տ = ⟦⟨ι₂, γ₂⟩⟧^Տ; therefore, T₂ also has the match property.

For the last branch T₃, ⟦⟨ι₃, γ₃⟩⟧^Տ where the sub-trees can be refined as ⟦SAND(⟨ι₃₁, γ₃₁⟩, ⟨ι₃₂, γ₃₂⟩, ⟨ι₃₃, γ₃₃⟩, ⟨ι₃₄, γ₃₄⟩)⟧^Տ where it is equivalent to ⟦⟨ι₃₁, γ₃₁⟩⟧^Տ ⋅ ⟦⟨ι₃₂, γ₃₂⟩⟧^Տ ⋅ ⟦⟨ι₃₃, γ₃₃⟩⟧^Տ ⋅ ⟦⟨ι₃₄, γ₃₄⟩⟧^Տ. By removing non-elementary paths ⟦⟨ι₃, γ₃⟩⟧^Տ ∩ ⟦SAND(⟨ι₃₁, γ₃₁⟩, ⟨ι₃₂, γ₃₂⟩, ⟨ι₃₃, γ₃₃⟩, ⟨ι₃₄, γ₃₄⟩)⟧^Տ ≠ ∅. Thus, the T₃ has the meet property and since ⟦⟨ι₃, γ₃⟩⟧^Տ = ⟦SAND(⟨ι₃₁, γ₃₁⟩, ⟨ι₃₂, γ₃₂⟩, ⟨ι₃₃, γ₃₃⟩, ⟨ι₃₄, γ₃₄⟩)⟧^Տ; therefore, T₃ also has the match property.

For the final path semantics of goal expression T, ⟦⟨ι, γ⟩⟧^Տ, can be refined as ⟦SAND(⟨ι₁, γ₁⟩, ⟨ι₂, γ₂⟩, ⟨ι₃, γ₃⟩)⟧^Տ and is equivalent to ⟦⟨ι₁, γ₁⟩⟧^Տ ⋅ ⟦⟨ι₂, γ₂⟩⟧^Տ ⋅ ⟦⟨ι₃, γ₃⟩⟧^Տ. By removing non-elementary paths, similar to the previous sub-trees, ⟦⟨ι, γ⟩⟧^Տ ∩ ⟦ SAND(⟨ι₁, γ₁⟩, ⟨ι₂, γ₂⟩, ⟨ι₃, γ₃⟩)⟧^Տ ≠ ∅, thus the T has the meet property and ⟦⟨ι, γ⟩⟧^Տ = ⟦SAND(⟨ι₁, γ₁⟩, ⟨ι₂, γ₂⟩, ⟨ι₃, γ₃⟩) ⟧^Տ; therefore, T has the match property.

Considering the main tree T = (⟨ι, γ⟩, SAND)(T₁, T₂, T₃), and considering all the following sub-branches, the (⟨ι₁, γ₁⟩, OR)(T₁₁, T₁₂) ≠ ∅, (⟨ι₂, γ₂⟩, SAND)(T₂₁, T₂₂, T₂₃) ≠ ∅ and (⟨ι₃, γ₃⟩, SAND)(T₃₁, T₃₂, T₃₃, T₃₄) ≠ ∅ as well as the main tree (⟨ι, γ⟩, SAND)(T₁, T₂, T₃) ≠ ∅, the tree T is considered to have the Global Admissible property.

The design of attack tree T is found to be consistent and correct with respect to the system Ƶ in its finite transition system domain. Each of the sub-trees have match property except the sub-tree T₁, which has the overmatch property. This however does not affect the overall security features of QF since all the sub-branches of T relate to OP = SAND thus complementing each other. Thus, the attack tree T modelling can be used to further analyze the security features of QF.

6. Conclusions

This paper discussed MySANI, the enhanced method in regulating the software used for NAWI within the LM framework in Malaysia. This method is realized by introducing QF, which is used as a secondary information source of LR information of the TOE and secured via public cryptography. The security design is validated by using attack tree modelling where the attack tree is described using formal notation and the correctness validation is achieved via comparison against the finite state transition system. As part of security analysis in LM, this paper also demonstrated the possibility of the formalization design of attack tree before it could be integrated with the AtPT framework analysis. This enables the attack tree to be verified prior to further security risk analysis evaluation. The issue of scalability is not studied in this paper due to the nature of the LR part of NAWI, which is usually very small. However, in the future, if the security objects in this paper are to be implemented for other types of measuring instruments, the scalability issues of the formal method approach might be considered.