Analysis of the SYM2 Smart Meter Remote SoftwareDownload using formal methods reasoning

Andreas FuchsFraunhofer Institute for Secure Information

TechnologyRheinstrasse 75

Darmstadt, Germanyandreas.fuchs@sit.fraunhofer.de

Donatus WeberChair for Data Communications Systems

University of SiegenHölderlinstrasse 3Siegen, Germany

donatus.weber@uni-siegen.de

ABSTRACTThe extended use of clean electricity in the future requiresan intelligent distribution network, the so called Smart Grid.A main component of this grid are Smart Meters, which arecapable of providing services like the remote readout of theactual power consumption or the remote control of loads.Modern Smart Meters are Embedded Systems, running soft-ware on a microcontroller platform. Due to adding new fea-tures or fixing errors, it is necessary to remotely update thesoftware of Smart Meters in the field. Since Security plays amajor role for critical infrastructure components like SmartMeters, a Secure Software Download mechanism is stronglyneeded. The German SYM2 specification for Smart Metersproposes variants for the Secure Software Download of thelegally relevant modules as well as for the non-legally rele-vant modules.Both variants will be formally investigated and compared inregard to provided security properties using the FraunhoferSecure Modeling Framework (SeMF). The real world systemis mapped to a system model comprising all necessary ac-tions, requirements and assumptions. It serves as a basis forthe formal method reasoning. Security issues are pointedout and analysed towards possibilities for secure solutions.

Categories and Subject DescriptorsD.2.1 [Software Engineering]: Requirements Specifi-cations—Methodologies; D.2.4 [Software Engineering]:Software/Program Verification—Formal Methods

General TermsSecurity, Legal Aspects

KeywordsSmart Metering, Formal Methods, Security Requirements

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.S&D4RCES ’11 September 22, 2011, Naples, Italy.Copyright (c) 2011 ACM 978-1-4503-0882-3 ...$10.00.

1. INTRODUCTIONDuring the last years, the upcoming importance of clean

energy and legal regulations in the energy sector forced agrowing need for an intelligent, dynamically manageablepower grid (Smart Grid). For real-time load managing andthe use of wind and solar power, the Smart Grid needsperiodically updated information about the actual powerconsumption of all connected households and industries.This leads to a growing need for Smart Meters in theelectricity sector.

The Smart Electricity Meter is equipped with a communi-cation unit enabling the data transfer to the Remote Read-out Center or Measuring Point Operator over different kindsof networks. These networks range from internet connec-tions using the TCP/IP protocol over GSM/UMTS to built-for-purpose Power Line Communication (PLC) techniques.For the Network Operators as well as for the Energy Suppli-ers, it is of great importance to have updated values of thecurrent grid load. Typical time constants for the periodicalreadout of Smart Electricity Meters are 15 minutes. Theseperiodic readouts serve the Energy Suppliers as a basis tobalance loads in the grid, helping to avoid peaks in demand.

Beside the functionality of providing periodic readouts ofthe actual power consumption, modern Smart Meters of-fer the opportunity to remotely switch loads in householdsand industry. This service is needed for the Smart Grid toefficiently use clean energy at the time it is available. Inorder to be able to offer the required functionalities, an ana-logue, electromechanical setup for a meter is not sufficientany more. Modern Smart Meters are resource-constrainedembedded systems running different kinds of software. Typ-ical constraints are computation speed, memory size andenergy.

Furthermore, the Smart Electricity Meter is an importantcomponent of the critical energy supplying infrastructure.Security flaws in Smart Meters offer attackers a good oppor-tunity to manipulate data on the Smart Grid.

This effort may even result in financial profit. Mani-pulating the actual consumption information for a largernumber of Smart Meters can directly influence prices in theenergy exchange. Because of these potential risks, securityengineering is an important component in the developmentprocess of a Meter.

An interesting approach for harmonising the Smart Elec-tricity Meter domain is the SYM2 specification [12] pub-

lished by the German tLZ working group. SYM2 is thesynonym for Synchronous Modular Meter, a modular andnon monolithic concept for load profile meters with clockedregistration periods.

As Smart Meters run software, it may become necessaryto download a new software version on the Smart Meterfor fixing errors or adding new features. For providing thisfunctionality, the SYM2 specification offers Remote Soft-ware Download mechanisms. Work within this paper con-centrates on the investigation of the procedure in regard tosecurity. Basis for the formal investigation is the equallyyoung Secure Modeling Framework. Its methods and con-cepts are going to be applied to Smart Meters of the evenrelatively young Embedded Systems Metrology domain.

2. SYM2

The advent of different Smart Electricity Meter types,each with proprietary functionality and interfaces, led toa heterogeneous meter park for the Measuring Point Op-erators. Considerable expenditures for administration andmaintenance made heterogeneous parks cost intensive. Thiseffect was recognised by the different stakeholders of theElectricity domain, clearing the way for a common stan-dard. After some consolidations of domain partners, thetLZ project group was founded. tLZ is an abbreviation forthe German equivalent of clock synchronous Load ProfileMeter (taktsynchroner LastgangsZ ahler).The first version of the specification for the SynchronousModular Meter (SYM2) was issued in 2007. The actual ver-sion of the SYM2 general specification this paper will dealwith is v1.03 (6th of October 2009)[12].The goal of the SYM2 approach and the main characteristicsof the SYM2 general specification [12] are as follows:

”The general specification for Synchronous Mod-ular Meters (SYM2) serves to provide develop-ment engineers at the meter manufacturers andthe staff dealing with invoicing metering equip-ment at network operators, metering point op-erators and vendors with a harmonised work-ing document for load profile meters featuringa clocked registration period.The goals of the SYM2 have been defined as fol-lows under the paramount consideration of costreduction in operations management:

• Modularised device concept with mountedor integrated function units and a standard-ised interface, and thus installation of onlythose elements specifically required on siteplus continual easy adaptation to new de-velopments.• use of meter readings in place of increments/

power mean values,• dispensing with the maximum metering

mechanism,• dispensing with integrated tariff control,• reducing the influence of the device clock by

changing to a seconds index,• separation into a compulsory-calibration

register and additional modules not sub-ject to compulsory calibration for upgradingtransparency by returning to simple mea-sured values,

Entity Authorized for

Software Download

Main Unit (compulsory

relevant software)

Network

Communication Module

(Gateway)

Network Node Module

Other optional module

Other optional module

Figure 1: Smart Electricity Meter modular designas proposed in [12]

• reducing the complexity of the individualmodules,• firmware download utilising the concepts of

the WELMEC guideline.” [13]

Modular approaches like SYM2 feature a structure shownin figure 1. The Smart Meter consists of a main modulewith sensors for measuring the power consumption andlogging the readout values. Due to lawful regulations likethe Measuring Instruments Directive (MID 2004/22/EC) [3]from the European Council, the software running the mainmodule directly involved in the measurement aggregation,is compulsory relevant. This means the hardware moduleitself, as well as the software part has to pass a typeapproval before being placed on the market. Additionaldocuments concerning lawful regulations and guidelines fortheir realisation in Smart Meters are the PTB-A 50.7 [10],the WELMEC 7.2 Software Guide [13], [14] and the OIMLD31 [9].For receiving a type approval, the MID offers differentassessment procedures. Notified Approval Bodies in themember states of the European Union have the task toaccomplish these procedures. When providing a firmwareupdate for the main unit of existing meters in the field, the

meter manufacturer has to forward it to the Approval Bodyfor type approval. Only approved software is allowed to beflashed to the meter. Beside the main unit, a SYM2 Metercan also contain internal modules like a Communicationmodule, a Pulse Emitting module or a Network Nodemodule. Other customer specific modules are possible too,underlining the modular approach of SYM2.

2.1 Software Download ConceptsBoth variants of modules mentioned in the chapter be-

fore, the ones subject to compulsory calibration (main unit),as well as other optional modules (Communication module,Pulse Emitting module, Network Node module, etc.) canbe updated in the field by using Software Download mech-anisms. In the following they are explained using sequencecharts.

2.1.1 Software Download (compulsory calibrationrelevant)

Figure 2 taken from the SYM2 general specification showsthe concept of the Software Download for the main module(compulsory calibration relevant software) of the meter.The main characteristic is the use of asymmetric cryptog-raphy for digital signatures and their verification. Basic re-quirement is a A public/private key pair from the ApprovalBody. The Approval Body uses its private key for signing

Figure 2: SYM2 Software Download concept (com-pulsory calibration relevant software) from [12]

the new software image for the meter. The meter itself is inpermanent possession of the corresponding public key fromthe Approval Body, enabling the verification of signaturesfor new firmwares.It is of great importance, that the public key is depositedin a secure storage of the meter, making any kind of ma-nipulation impossible. The exact chronological order of theprocedure is depicted in figure 3. The sequence chart showsaction lines for three roles, the Approval Body, the Measur-ing Point Operator and the Smart Meter. The first actionof a complete Software Download sequence is the provisionof a new software image by the Measuring Point Operator.The image is then forwarded to the Approval Body and runsthrough the type approval process.

In case of success, the Approval Body calculates a hashover the software image, signs it, and returns it to the Mea-suring Point Operator. After receiving the Approval Body’ssignature, the Measuring Point Operator transmits it to the

Smart Meter, together with the software image.The Smart Meter receives image and signature. Afterwards,the signature is verified with the public key of the ApprovalBody, which is stored in the secure memory of the SmartMeter. The new software image is solely accepted if thesignature can be successfully verified. For starting the newfirmware, the Smart Meter initiates the local software up-date routine. The final step comprises the action of theSmart meter to boot the new firmware. The security mech-

Entity Authorized ForSoftware Download Smart Meter

Transmit Software Image and Signature

Verify received Software Image and Signature using the Public key from the Approval Body

If verification is successful, accept new firmwareInitiate local Software Update routine and boot new firmware

Approval body

Provide new Software Image

Forward Software Image for Approval

Type approval processIf successfull, calculate Hash over Software ImageSign Hash with Approval body’s Private key

Return Signature

Figure 3: Sequence diagram of SYM2 SoftwareDownload mechanism (compulsory calibration rel-evant software)

anism used to assure the correct origin of the software imageis a digital signature using asymmetric cryptography.

2.1.2 Software Download (Non-compulsory calibra-tion relevant)

For optional modules with non-compulsory relevant soft-ware, the SYM2 general specification proposes a second vari-ant of software download. Figure 4 shows the general mech-anism. Since the software is non-compulsory relevant, itdoesn’t have to be approved by an Approval Body.The requirement for the correct origin of the new firmwareexists in the same way as for the compulsory relevant parts.The Measuring Point Operator has to be sure only his soft-ware images can be flashed to the Smart Meter. This is ac-complished by using secrets, only known to the Smart Metermanufacturer or Measuring Point Operator and the Smart

Figure 4: SYM2 Software Download concept (non-compulsory calibration relevant software) from [12]

Meter itself. Precondition for the software update sequenceshown in figure 5 is an already existing secret (between theMeasuring Point Operator and the Smart Meter) in a securestorage of the Smart Meter, which cannot be manipulated.Of course, this secret must be known to the Measuring PointOperator. Every time he provides a new software image, anew secret is generated and embedded into the image. Inthe next step, the software image containing the new secretis enhanced by extending the old secret (the same as in thesecure storage of the meter) and a hash is calculated.Hash and software image with embedded new secret aretransmitted to the Smart Meter in the field. After success-fully receiving the image and hash, the Meter appends theold secret to the image. The correct hash value is verifiedby recalculating it with identical parameters. If both hashvalues are equal, the new firmware is accepted and the oldsecret in the Meter is replaced by the new one from the im-age.Afterwards, the Meter initialises the local software updateroutine and boots the new firmware.

The technique of using a shared secret to ensure authentic-ity and integrity of the firmware image is known as MessageAuthentication Code (MAC) and will be referred to duringthe formal investigation in section 4.

3. THE SECURITY MODELLING FRAME-WORK SEMF

In this section we briefly introduce the Security ModelingFramework SeMF and, based on this, the formal definitionof the properties and implications amongst them to be usedin the investigation of the SYM2 specification.

SeMF is a framework based on formal language theorythat provides a formal semantics for the specification of mod-els of systems, for the definition of security properties interms of these models, and for the reasoning about securityproperties holding or not holding in certain system mod-els. In contrast to e.g. Temporal Logics [11] that aims atmore general properties, SeMF specifically targets securityproperties. Work on SeMF started in the early 2000s with[6, 7, 8] and the framework is continuously being extended.As opposed to e.g. BAN [1] properties are defined based onthe underlying formal language framework to allow in depthanalysis of implications amongst them.

3.1 Basis of SeMF

Measuring Point Operator Smart Meter

Provide new Software ImageGenerate new SecretEmbed Secret in Software ImageCalculate Hash over Software Image with embedded new Secret and appended old Secret

Transmit Software Image and Hash

Append old Secret to the received Software ImageCalculate Hash over Software ImageCheck if received Hash and calculated Hash are the same

If Hash values are the same, accept new firmwareInitiate local Software Update routine and boot new firmware

Figure 5: Sequence diagram of SYM2 SoftwareDownload mechanism (non-compulsory calibrationrelevant software)

The behaviour B of a discrete system S can be formallydescribed by the set of its possible sequences of actions(traces). Therefore B ⊆ Σ∗ holds, where Σ (called the al-phabet) is the set of all actions of the system, Σ∗ is the setof all finite sequences (called words) of elements of Σ, in-cluding the empty sequence denoted by ε. Subsets of Σ∗ arecalled formal languages. Words can be composed: if u andv are words, then uv is also a word. For a word x ∈ Σ∗, wedenote the set of actions of x by alph(x). For more detailson the theory of formal languages we refer the reader to [2].

We further extend the system specification by two com-ponents: agents’ initial knowledges about the global systembehaviour and agents’ local views. The initial knowledgeWP ⊆ Σ∗ of agent P about the system consists of all tracesP initially considers possible, i.e. all traces that do not vio-late any of P ’s assumptions about the system. Every tracethat is not explicitly forbidden can happen in the system.An agent P may assume for example that a message thatwas received must have been sent before. Thus the agent’sWP will contain only those sequences of actions in whicha message is first sent and then received. Further we can

assume B ⊆ WP , as reasoning within SeMF primarily tar-gets the validation and verification of security properties interms of positive formulations, i.e. assurances the agents ofthe system may have. Other approaches that deal with mal-function, misassumptions and attacker models cannot relyon this assumption.

In a running system, P can learn from actions that haveoccurred. Satisfaction of security properties obviously alsodepends on what agents are able to learn. After a se-quence of actions ω ∈ B has happened, every agent Pcan use its local view λP – an alphabetic language homo-morphism λP : Σ∗ → Σ∗

P – of ω to determine the se-quences of actions it considers to have possibly happened.Examples of an agent’s local view are that an agent cansee only its own actions, or that an agent P can see thatan action send(sender,message) occurred but cannot seethe message, in which case λP (send(sender,message)) =send(sender), or an agent may see a message on anetwork bus and is not able to determine the senderλP (send(sender,message)) = send(message).

For a sequence of actions ω ∈ B and agent P ∈ P (Pdenoting the set of all agents), λ−1

P (λP (ω)) ⊆ Σ∗ is the set ofall sequences that look exactly the same from P ’s local viewafter ω has happened. Depending on its knowledge aboutthe system S, including underlying security mechanisms andsystem assumptions, P does not consider all sequences inλ−1P (λP (ω)) possible. Thus it can use its initial knowledge

to reduce the set: λ−1P (λP (ω)) ∩ WP , which describes all

sequences of actions P considers to have possibly happenedwhen ω has happened.

In order to model these boot cycles, we use the definitionof a phase provided in [5]. A phase V ⊂ Σ∗ is a prefix closedlanguage consisting only of words which, as long as they arenot maximal in V , show the same continuation behaviorwithin V as within B.

Definition 1. Let B ⊆ Σ∗ be a system. A prefix closedlanguage V ⊂ Σ∗ is a phase in B if the following holds:

1. V ∩ Σ 6= ∅2. ∀ω ∈ B with ω = uv and v ∈ V \(max(V )∪{ε}) holds:ω−1(B) ∩ Σ = v−1(V ) ∩ Σ

Thus a phase as defined above is essentially a part of thesystem behaviour that is closed with respect to concatena-tion. In analogy to the maximal words of a phase V whichare those v ∈ V for which exists ω, u ∈ B with ω = uv suchthat for all a ∈ Σ with ωa ∈ B holds va 6∈ V , we define theminimal words of a phase as all v ∈ V with |alph(v)| = 1.

A phase can be a very complex construct. However, inmany cases phases are of interest that can be defined bytheir starting and ending actions. Since an action can occurmore than once in a word, it is not sufficient to identifythe starting and terminating actions for determining wherea particular phase starts and where it ends. The followingdefinition takes this into account.

In the following, we denote the number of occurrences of aset of actions Γ ∈ Σ in a word ω by card(Γ, ω). If Γ consistsof only one action a, we simply say card(a, ω).

Definition 2. Let s1, . . . , sk, t1, . . . , tl ∈ Σ be actions.Then V ({s1, . . . , sk}, {t1(j1), . . . , tl(jl)}) (with j1, . . . , jl ∈IN) defines a phase in B that starts with actions s1, . . . , skand terminates with actions t1, . . . , tl in the following sense:

• For all ω ∈ B for which exists sj ∈ {s1, . . . , sk}such that ωsj ∈ B follows sj ∈ V ({s1, . . . , sk},

{t1(j1), . . . , tl(jl)}) (i.e. sj is minimal inV ({s1, . . . , sk}, {t1(j1), . . . , tl(jl)})).• For all ω ∈ B for which exists ti(ji) ∈{t1(j1), . . . , tl(jl)} and u, v ∈ Σ∗ with ω =uvti, vti ∈ V ({s1, . . . , sk}, {t1(j1), . . . , tl(jl)}), andcard(ti, vti) = ji follows that vti is maximal inV ({s1, . . . , sk}, {t1(j1), . . . , tl(jl)}).

The ∅ as start action will thereby denote those phases start-ing at the beginning of the system lifetime, whilst ∅ as endaction will denote phases not stopping once startet.In the above definition, the starting action(s) need to befixed so that starting from these the terminating actionsoccurring in the phase can be counted in order to identifythose ones that actually terminate the phase. Note that inthe cases where no cardinality is assigned to terminatingactions, we assume a cardinality of 1.

3.2 PropertiesSecurity properties can now be defined in terms of the

agents’ initial knowledges and local views. In [8] a variety ofdefinitions of security properties (e.g. authenticity, proof ofauthenticity, confidentiality) is introduced. For this paperonly a subset of these properties, that do not respect agentassurance but only investigate functional correctness, will beused.

In order to express that a certain action never happenswithin the complete system lifetime or only within a phase,we use the following properties:

Definition 3. For a system with behaviour B ⊆ Σ∗, A ⊆Σ, nothappens(A) holds if for all ω ∈ B: A ∩ alph(ω) = ∅.

Definition 4. For a system with behaviour B ⊆ Σ∗ anda phase V in B, a ⊆ Σ, nothappens-wi-phase(A, V ) holdsif for all v ∈ V : A ∩ alph(v) = ∅.

Further we need to express, that whenever an action outof the set B has happened, an action out of the set A musthave happened (before):

Definition 5. For a system with behaviour B ⊆ Σ∗,A,B ⊆ Σ, precede(A,B) holds if for all ω ∈ B, ifB ∩ alph(ω) 6= ∅ then a ∩ alph(ω) 6= ∅.Note that since the property needs to hold for all ω in B,it holds in particular for an ω with an action from B as thelast action. Hence an action from A must happen before thisaction from B.

And finally we provide a specialization of this property tofurther confine the point in the system lifetime when suchan action from A shall have happened:

Definition 6. For a system with behavior B, V ⊆ Σ∗,a, b ⊆ Σ, precedephase(a, b, V ) holds if ∀ω ∈ B withb ∩ alph(ω) 6= ∅, there exists u, v, w ∈ Σ∗ such that ω =uvw, v ∈ V and a ∩ alph(v) 6= ∅.

3.3 ImplicationsWe will now provide a set of Theorems and Lemmata that

represent implications to be used in the later proof attempts,starting with an obvious relation between nothappens prop-erties:

Lemma 1. Given a system S and actions A,B ⊆ Σ andphase V , if nothappens(A) and nothappens(B) hold in S,then nothappens(A ∪B) holds in S.

Next we investigate the transitivity of precede andprecedephase respectively.

Theorem 1. Given a system S and actions a, b, c ∈ Σ, if

precede(a, b) and precede(b, c) hold in S, then precede(a, c)holds in S as well.

Proof 1. precede(b, c) states that for all ω ∈ B with c ∈alph(ω) it holds that b ∈ alph(ω). precede(a, b) states forexactly those ω that a ∈ alph(ω), which can be expressed asprecede(a, c).

Lemma 2. Given a system S and actions a, b, c ∈ Σ,if precedephase(a, b) and precede(b, c) hold in S, thenprecedephase(a, c) holds in S as well.

Finally, we investigate the relations between precede andnothappens

Theorem 2. Given a system S and actions a, b ∈ Σ, ifnothappens(b) holds in S, then precede(a, b) holds in S.

Proof 2. Assuming precede(a, b) would not hold in S,then there must be ω ∈ B with b ∈ alph(ω) and a 6∈ alph(ω).b ∈ alph(ω) however is a contradiction to nothappens(b).

Theorem 3. Given a system S and actions a, b, c ⊆Σ, if precede(a, b) and nothappens(c) holds in S, thenprecede(a, b ∪ c) holds in S.

Proof 3. precede(a, b ∪ c) states that ∀ω ∈ B withalph(ω) ∩ (b ∪ c) 6= ∅ that also alph(ω) ∩ a 6= ∅. For thecase of alph(ω) ∩ b 6= ∅ we know from precede(a, b) thatalph(ω) ∩ a 6= ∅. For the case of alph(ω) ∩ c 6= ∅ we knowthat this case never happens due to nothappens(c).

Theorem 4. Given a system S and actions a, b ∈Σ, if precede(a, b) and nothappens(a) hold in S, thennothappens(b) holds in S.

Proof 4. Assuming nothappens(b) would not hold in S,then there must be ω ∈ B with b ∈ alph(ω). precede(a, b)would further require, that a ∈ alph(ω), which would be acontradiction to nothappens(a).

Lemma 3. Given a system S, actions a, b ∈ Σ and aphase V , if precede(a, b) and nothappens-wi-phase(a, V )hold in S, then nothappens-wi-phase(b, V ) holds in S.

Theorem 5. Given a system S and action a ∈ Σ, ifnothappens(a) holds in S then for all phases V in Snothappens-wi-phase(a,V) holds as well

Proof 5. Assuming nothappens(a, V ) would not hold inS, then there must be v ∈ V with a ∈ alph(v). Therefore ac-cording to the definition of phases, there must be ω ∈ B suchthat a ∈ alph(ω) which is a contradiction to nothappens(b).

4. FORMAL INVESTIGATIONThe formalisms given in Section 3 serve as basis for the

investigation of important security requirements towards aSecure Software Download. For both variants, the correctorigin of the software image, as well as the freshness of thisimage will be investigated. Note that this is only an in-vestigation and not a validation as the latter would requiresignificantly more effort.

4.1 Software Download (Compulsory calibra-tion relevant)

The first investigation approach demonstrates the the cor-rect origin of the software image downloaded to the SmartMeter.

4.1.1 Investigating Correct OriginBasis for the formal investigation is the SYM2 Secure Soft-

ware Download Sequence for the compulsory relevant soft-ware (see Figure 2) and the actions denoted in the sequencechart (see Figure 3).

System Definition.The Software Download variant for compulsory relevant

parts of the meter software involves the following agents andtheir abbreviations:

• Approval Body (AB)The Approval Body is the national Notified Body incharge of the compulsory calibration. Basis for thecalibration is the MID [3] with its different assessmentmodules. Only software approved by this body is al-lowed to be downloaded to the meter.• Measuring Point Operator (MPO)

The Measuring Point Operator is the owner of theSmart Meter. He is in charge of administrating andmaintaining the device in the field. He is in the posi-tion to download software to the meter.• Smart Meter (SM)

The Smart Meter is the device in the field being sup-plied with a new software image. Download of thissoftware image is initiated by the Measuring Point Op-erator using the Secure Software Download sequence.

P = {AB,MPO, SM}

These agents are able to perform the following set of actions:

• provide(MPO, fwi)Measuring Point Operator MPO provides a newfirmware fwi to the AB for approval.• approve(AB, fwi)

Approval Body AB performs a type approval forfirmware fwi.• sign(AB, fwi, P rivKj , sigj(fwi))

Approval Body AB signs a firmware fwi with its pri-vate key PrivKj and returns signature sigj(FWi) ofthe firmware fwi. Note that the relation betweenthe signature and the utilised private key is denotedthrough their indexes.• transmit(MPO, fwi, sigj(fwk))

Measuring Point Operator MPO transmits a newfirmware fwi and signature sigj to the Smart Meter.• deploy(MPO,SM(fwi))

Measuring Point Operator MPO deploys a Smart Me-ter SM with a firmware fwi.• verify(SM(fwi), fwj , sigk(fwj), PubKk)

Smart Meter SM running firmware fwi verifies a newlyreceived firmware fwj with signature sigk(fwj) usinga public key PubKk. Note that the relation betweenthe signature and the utilised public key is denotedthrough their indexes. Only equal indexes allow forthis action to occur.• flash(SM(fwi), fwj)

Smart Meter SM running firmware fwi flashes the newfirmware fwj to the memory.• boot(SM, fwi)}

Smart Meter SM boots firmware fwi.

Σ = {provide(MPO, fwi),

approve(AB, fw),

sign(AB, fwi, P rivKj , sigj(fwi)),

transmit(MPO, fwi, sigj(fwk)),

deploy(MPO, fwi, sigj(fwk)),

verify(SM(fwi), fwj , sigk(fwj), PubKk),

f lash(SM(fwi), fwj),

boot(SM, fwi)}

Requirement.It is stated in the SYM2 specification, that only approved

firmwares are allowed to be flashed to the Smart Meter.We will interpret this as: Every firmware Firmware(FWi)flashed on a smart meter must have been approved by theApproval body:

precede(approve(AB, fwi), f lash(SM(fwj), fwi))(Req1)

Assumptions.The following set of assumptions will be used for the proof:

1. The properties of elliptic curve cryptography (ECC)used in the metrology domain, ensure that a signa-ture sigj verified with a public key PubKj must havebeen generated with the corresponding private keyPrivKj . (Note that we disregard the investigation ofthe PrivK’s confidentiality here)

precede(sign(AB, fwi, P rivKj , sigj(fwi)),

verify(SM(fwk), fwi, sigj(fwi), PubKj))

2. Every firmware is approved before it is signed by theApproval Body:

precede(approve(AB, fwi),

sign(AB, fwi, P rivKAB , sigAB(fwi)))

3. The Measuring Point Operator will only deploySmart Meters to the customers’ sites with approvedfirmwares:

precede(approve(AB, fwi), deploy(MPO,SM(fwi))

4. The Smart Meter can only boot the firmware that itwas deployed with or that has been flashed:

precede({flash(SM(fwi), fwj),

deploy(MPO,SM(fwj))},boot(SM, fwj))

5. A Smart Meter running an approved firmware will ver-ify a newly received firmware’s signature with the Ap-proval Body’s public key before flashing it.

∀fwk ∈ appr-fws :

precede({verify(SM(fwk), fwi, sigj(fwi), PubKj)

| j = AB},f lash(SM(fwk), fwi))

6. The execution of an action by the Smart Meter undera given firmware fwi requires the Smart Meter to havebooted this firmware:

precede(boot(SM, fwi),Σ/SM(fwi))

Proof.We define that any firmware that is approved by the Ap-

proval Body belongs to the set of approved firmwares:

nothappen({approve(AB, fwi)

| fwi 6∈ appr-fws}) (1)

From Assumptions 2. and 1. we may conclude with Theo-rem 1 that whenever a verification of a firmware’s signaturewith the public key of the Approval Body succeeds, thisfirmware has been approved by the Approval Body.

precede(approve(AB, fwi),

verify(SM(fwk), fwi, sigAB(fwi), PubKAB))(2)

Therefore using the Proof Step (1) any firmware successfullyverified with the Approval Body’s Public Key is an approvedFirmware through Theorem 4:

nothappen({verify(SM(fwk), fwi, sigAB(fwi), PubKAB)

| fwi 6∈ appr-fws}) (3)

Through Assumption 5. we may further conclude using The-orem 4 that an approved firmware will only flash firmwaresthat are approved as well:

∀fwk ∈ appr-fws :

nothappen({flash(SM(fwk), fwi)

| fwi 6∈ appr-fws}) (4)

Proof Statement (1) and Assumption 3. imply throughTheorem 4 that only approved firmwares are deployed bythe MPO:

nothappen({deploy(MPO,SM(fwi)) | fwi 6∈ appr-fws})(5)

This is of course especially true for the phase from systemstart up to the first boot of the Smart Meter by Theorem 5:

nothappen-wi-phase({deploy(MPO,SM(fwi))

| fwi 6∈ appr-fws},V (∅, boot(SM, fwj)(1))) (6)

As boot(SM, fwj) is the last action within this phase, wemay trivially conclude from Assumption 6. that no otheractions Σ/SM(fwi) of the Smart Meter happen within thisphase:

nothappen-wi-phase(Σ/SM(fwi) \ {boot(SM, fwj)},V (∅, boot(SM, fwj)(1))) (7)

This is especially true for flash(SM(fwi), fwk) ∈Σ/SM(fwi) \ {boot(SM, fwj)}.

This statement together with Assumption 4. let us con-clude throug Lemma 3 that the first boot is performed withan approved firmware:

nothappen-wi-phase({boot(SM, fwi) | fwi 6∈ appr-fws},V (∅, boot(SM, fwj)(1))) (8)

We will use this as the anchor for an inductive proof overthe number of boot cycles of the smart meter.

As induction step, we start by assume that up to andincluding the n-th boot cycle, only approved firmwares havebeen booted.

nothappen-wi-phase({boot(SM, fwi) | fwi 6∈ appr-fws},V (∅, boot(SM, fwj)(n))) (9)

We know from Assumption 6. through Lemma 3 that onlyapproved firmwares’ actions will performed up to the n+1 -th boot cycle

nothappen-wi-phase({a ∈ Σ/SM(fwi) | fwi 6∈ appr-fws}V (∅, boot(SM, fwj)(n+ 1))) (10)

which is especially true for {flash(SM(fwk), fwi) | fwk 6∈appr-fws} ⊆ {a ∈ Σ/SM(fwi) | fwi 6∈ appr-fws}.

According to Proof Statement (4) this means by The-orem 5 and Lemma 1 that only approved firmwares wereflashed:

nothappen-wi-phase({flash(SM(fwk), fwi)

| fwi 6∈ appr-fws},V (∅, boot(SM, fwj)(n+ 1))) (11)

By Assumption 4. and Lemma 3 this means that also then+1 -th boot cycle is performed with an approved firmware:

nothappen-wi-phase({boot(SM, fwi) | fwi 6∈ appr-fws},V (∅, boot(SM, fwj)(n+ 1))) (12)

Taking Proof Statement (8) as an anchor and the con-clusion from Proof Statement (9) to (12) as a step we canperform an inductive proof over the number of boot cycles ofthe smart meter to conclude that only approved firmwaresare booted by the Smart Meter:

nothappen({boot(SM, fwi) | fwi 6∈ appr-fws}) (13)

With this information it is easy to use Assumption 6. andTheorem 4 to conclude

nothappen({a ∈ Σ/SM(fwi) | fwi 6∈ appr-fws}) (14)

and then to generalize Assumption 5. and conclude usingProof Statement (2) that only approved firmware is flashedon the Smart Meter:

precede(approve(AB, fwi), f lash(SM(fwj), fwi)) (15)

q.e.d.

Analysis.The above proof of a certain aspect of the software down-

load yields the following possibility for analysis:

• It can be seen that given the presented assumptions,the requirement can be fulfilled.• However especially Assumption 5. will be difficult to

fulfil in practice. It describes a certain behavior of ap-proved firmwares that may be prone to errors throughexploitable bugs in practical applications.• This is especially important as the proof requires the

inductive iteration through all boot cycles of the SmartMeter and all firmwares it has been booted with in thepast. This may be circumvented by establishing e.g.hardware based concepts for secure and/or authenti-cated boot following Trusted Computing concepts.

• Further it is not assured that a given firmware suitsa given Smart Meter. Cross-flashing of actually in-compatible firmwares and Smart Meters may furtherharden the aforementioned issues. A possible coun-termeasure could be to include type information intothe firmware and check this as well, or to use a givenPubKAB for a single type of Smart Meters only.• Finally, downgrading and upgrade cycling attacks of

firmwares are possible. This will be further investi-gated in the following section.

4.1.2 Investigating Correct and Fresh OriginAs mentioned during the analysis in the previous section

we will now further investigate the freshness requirementsof the firmware download. We will use the same system andassumptions as defined in Section 4.1.1.

Requirement.The new requirement to be investigated is the correct and

fresh origin of the flashed firmware. Fresh here means thatthe firmware was issued after the firmware currently runningon the Smart Meter:

precedephase(approve(AB, fwi),

f lash(SM(fwj), fwi),

V (approve(AB, fwj), ∅)) (Req2)

Proof.The proof can be performed the same as in Section 4.1.1.

However this time, the resulting property

precede(approve(AB, fwi), f lash(SM(fwj), fwi)) (15)

does not meet the requirement. Further there are no meansor assumptions to further constraint the phase in which theapprove(AB, fwi) action is performed. fail

Analysis.This failed proof attempt demonstrates the following mis-

use cases:

• An attacker could “downgrade” a Smart Meter to anolder version. This cannot be detected by the SmartMeter.• An attacker could “boot cycle” a Smart Meter with

the same version. As the commands to download anew firmware and activate (boot) it are “Level 0” com-mands, they are not protected by any further meansthan the firmware’s signature. Assuming a Smart Me-ter will only reboot, when it flashed a new firmware,an attacker could command the Smart Meter to down-load the same firmware over and over and boot it eachtime.• This attack could be used to undermine the availability

of a Smart Meter, possibly obfuscating client consump-tion or confusing the smart grid.• This attack could also be used to fill the flash log,

triggering possible overrun attacks there or obfuscatingother attacks, such as the downgrading of flashing ofan unapproved firmware.• These attacks could be circumvented by adding a ver-

sion number to the firmware and checking it againstthe current firmwares version during flash. This coun-

termeasure will be further investigated in the followingsection.

4.1.3 Improved Correct and Fresh OriginIn order to circumvent the aforementioned attacks of

downgrading and boot cycling we will improve the speci-fication by adding a version number to the firmware.

Extended System.The new system still consists of the same agents as in

Section 4.1.1:

P = {AB,MPO, SM}

The agents’ action are also the same, however each occur-rence of fw has been extended by a version number:

Σ ={provide(MPO, fwi(vi)),

approve(AB, fwi(vi)),

sign(AB, fwi(vi), P rivKj , sigj(fwi(vn))),

transmit(MPO, fwi(vi), sigj(fwk(vk))),

deploy(MPO, fwi(vi), sigj(fwk(vk))),

verify(SM(fwi(vi)), fwj(vj), sigk(fwj(vj)), PubKk),

f lash(SM(fwi(vi)), fwj(vj)),

boot(SM, fwi(vi))}

Requirement.The requirement to be investigated is the correct and fresh

origin of the flashed firmware. Fresh here means that thefirmware was issued after the firmware currently running onthe smart meter:

precedephase(approve(AB, fwi),

f lash(SM(fwj), fwi),

V (approve(AB, fwj), ∅)) (Req2)

Extended Assumptions.We will utilise all the assumptions from Section 4.1.1, but

extend them by the following additional assumptions:

7. Any approved firmware will only flash firmwares thathave a version number higher than their own:

∀fwi ∈ appr-fws :

nothappen({flash(SM(fwj(vj)), fwi(vi)) | vj >= vi})

8. The Approval Body will only issue firmwares with ver-sion information in ascending order, expressed as:

nothappen-wi-phase({approve(AB, fwi(vi))

| vi > vj},V (∅, approve(AB, fwj(vj))))

Proof.This proof includes all the proof steps from Section 4.1.1’s

proof up to Proof Statement (15) expressed for the new setof actions:

precede(approve(AB, fwi(vi)),

f lash(SM(fwj(vj)), fwi(vi))) (15)

This is especially true for those flash actions, where vi > vj .Note that we split the index i into i and k for now.

precede({approve(AB, fwi(vi)) | vi = vk > vj},{flash(SM(fwj(vj)), fwk(vk))) | vk > vj}) (16)

As we know from Assumption 7. that a flash-action willnot happen with the first firmware version bigger than thesecond anyways. Therefore we can conclude with Theo-rem 3:

precede({approve(AB, fwi(vi)) | vi = vk > vj},f lash(SM(fwj(vj)), fwk(vk)))) (17)

We know from Assumption 8. that a firmware with versionvi will not be approved in the phase from system start untilapprove(AB, fwl(vl)) with a version vl < vi. Accordingly,if an approve with a version vi is known of have preceded,it must have been within the phase after the approve withvl. We may therefore conclude

∀vi, vl with vi > vl :

precedephase({approve(AB, fwi(vi))

| vi = vk > vj},f lash(SM(fwj(vj)), fwk(vk))),

V (approve(AB, fwl(vl)), ∅)) (18)

This property especially includes the case of l = j and leadsto

precedephase({approve(AB, fwi(vi))

| vi = vk > vj},f lash(SM(fwj(vj)), fwk(vk))),

V (approve(AB, fwj(vj)), ∅)) (19)

We may now unite the indices k = i again.

precedephase(approve(AB, fwi(vi))

flash(SM(fwj(vj)), fwi(vi))),

V (approve(AB, fwj(vj)), ∅)) (20)

which proofs the requirement. q.e.d.

Analysis.It could be shown that the improvement of adding a ver-

sion number check assures freshness of the firmware. How-ever the other issues such as the reliance on an inductionover all previously booted firmwares remain.

4.2 Software Download (Non-compulsory cal-ibration relevant)

We will now investigate the non-relevant software down-load as described in Section 2.1.

4.2.1 Investigating Correct and Fresh OriginWe will directly investigate the stronger property of cor-

rect and fresh origin of firmwares.

System.The Software Download variant for non compulsory rele-

vant parts of the meter software involves the following agentsand their abbreviations:

• Measuring Point Operator (MPO)

The Measuring Point Operator is the owner of theSmart Meter. He is in charge of administrating andmaintaining the device in the field. He is in the posi-tion to issue new software and download software tothe meter.• Smart Meter (SM)

The Smart Meter is the device in the field being sup-plied with a new software image. Download of thissoftware image is initiated by the Measuring Point Op-erator using the Secure Software Download sequence.

P = {MPO,SM}

These agents are able to perform the following set of actions:

• provide(MPO, fwi(SSi))The MPO provides (program, compile and package) anew firmware including a new Shared Secret.• sign(MPO, fwi(SSi), SSj ,macj(fwi(SSi)))MPO signs a firmware fwi(SSi) with its shared se-cret SSj and returns message authentication codemacj(FWi(SSi)) of the firmware. Note that the re-lation between the message authentication code andthe utilised key is denoted through their indexes.• transmit(MPO, fwi(SSi),macj(fwk(SSk)))

Measuring Point Operator MPO transmits a newfirmware fwi(SSi) and message authentication codemacj(fwk(SSk)) to the Smart Meter.• deploy(MPO,SM(fwi(SSi)))

Measuring Point Operator MPO deploys a new SmartMeter SM with a firmware firmware fwi including ashared secret SSi.• verify(SM(fwi(SSi)), fwj(SSj),maci(fwj(SSj)))

Smart Meter SM running firmware fwi(SSi) verifiesa newly received firmware fwj with message authen-tication code mack(FWj) using its shared secret SSi.Note that the relation between the message authen-tication code and the utilised key is denoted throughtheir indexes. Only equal indexes allow for this actionto occur.• flash(SM(fwi(SSi)), fwj(SSj))

Smart Meter SM running firmware fwi flashes the newfirmware fwj to the memory.• boot(SM, fwi(SSi))}

Smart Meter SM boots firmware fwi.

Σ = {provide(MPO, fwi(SSi)),

sign(MPO, fwi(SSi), SSj ,macj(fwi(SSi))),

transmit(MPO, fwi(SSi),macj(fwk(SSk))),

deploy(MPO,SM(fwi(SSi))),

verify(SM(fwi(SSi)), fwj(SSj),maci(fwj(SSj))),

f lash(SM(fwi(SSi)), fwj(SSj)),

boot(SM, fwi(SSi))}

Requirement.The requirement to be investigated is the correct and fresh

origin of the flashed firmware. Fresh here means that thefirmware was issued after the firmware currently running on

the Smart Meter:

precedephase(provide(MPO, fwi(SSi)),

f lash(SM(fwj(SSj)), fwi(SSi)),

V (provide(MPO, fwj)(SSj), ∅)) (Req3)

Assumptions.The following set of assumptions will be used for the proof:

1. Message Authentication Code: Whenever a mac of afirmware is verified using a shared secret it must havebeen generated with the same shared secret by theMPO. (Note that we disregard the investigation ofthe Shared Secret’s confidentiality here and assume itto be confidential.)

precede(sign(MPO, fwi(SSi), SSj ,macj(fwi(SSi)))

verify(SM(fwj(SSj)), fwi(SSi),macj(fwi(SSi))))

2. The MPO (i) signs only firmwares provided by itselfand (ii) signs only with shared secrets of firmwares thatwere provided before the firmware to be signed.

precedephase(provide(MPO, fwi(SSi)),

sign(MPO, fwi(SSi), SSj ,macj(fwi(SSi)),

V (provide(MPO, fwj(SSj)), ∅))

3. The Measuring Point Operator will only deploy SmartMeters with firmwares provided by itself.

precede(provide(MPO, fwi(SSi)),

deploy(MPO,SM(fwi(SSi)))

4. The Smart Meter can only boot the firmware that itwas deployed with or that has been flashed.

precede({deploy(MPO,SM(fwi(SSi)),

f lash(SM(fwj(SSj)), fwi(SSi))},boot(SM, fwi(SSi))

5. A Smart Meter running an approved firmware will ver-ify a newly received firmware’s MACs with the currentshared secret before flashing it. The set provfw de-notes the set of firmwares that were actually providedby the MPO.

∀fwj ∈ provfw :

precede(verify(SM(fwj(SSj)), fwi(SSi),

macj(fwi(SSi))),

f lash(SM(fwj(SSj)), fwi(SSi)))

6. The execution of an action by the Smart Meter undera given firmware fwi requires the Smart Meter to havebooted this firmware:

precede(boot(SM, fwi(SSi)),Σ/SM(fwi(SSi)))

Proof.Assumption 2. can be limited to its first aspect (i) to imply

the following property:

precede(provide(MPO, fwi(SSi)),

sign(MPO, fwi(SSi), SSj ,macj(fwi(SSi))) (0)

With this, the proof can be conducted similar to Sec-tion 4.1.1’s proof using provide instead of approve and theMPO instead of the AB up to Proof Statement (13).

nothappen({boot(SM, fwi(SSi)) | fwi 6∈ provfw}) (12)

Using this knowledge we can conclude through Theorem 4with Assumption 6. that the Smart Meter only performsactions with provided firmwares:

nothappen({a ∈ Σ/SM(fwi(SSi)) | fwi 6∈ provfw}) (13)

Therefore Assumption 5. extends to the whole SM’s life cycle

precede(verify(SM(fwj(SSj)), fwi(SSi),

macj(fwi(SSi))),

f lash(SM(fwj(SSj)), fwi(SSi))) (14)

Through Theorem 1 with Assumption 1. and furtherLemma 2 with Assumption 2. it is possible to conclude

precedephase(provide(MPO, fwi(SSi)),

f lash(SM(fwj(SSj)), fwi(SSi)),

V (provide(MPO, fwj(SSj)), ∅)) (15)

which is the requirement. q.e.d.

Analysis.

• From the formal proof it can be seen that the Sym2

specification foresees not only the correctness but alsothe freshness for non-compulsory relevant firmwares.The explicit mentioning of changing the shared secretwith every release suggests that the designers wereaware of the problem of downgrading and boot cy-cling, but decided to only specify counter measures innon-compulsory relevant software download.• Besides this fact, also this mechanism has all the weak-

nesses of the improved Software Download for compul-sory relevant software.• Additionally, because of the nature of MAC, the con-

fidentiality of the shared secret is very important asit not only allows for verification but also for genera-tion of Message Authentication Codes. An encryptionof the firmware during download should be foreseen inorder to protect it. Using the shared secret for au-thenticating encryption schemes could be the easiestsolution with fewest alteration.However this aspect was not included in the above in-vestigation.

5. CONCLUSIONSWithin this paper, an interesting formal investigation

of the SYM2 Remote Software Download mechanisms wasmade. As a basis for the formal methods reasoning servedthe Fraunhofer Secure Modeling Framework (SeMF).Applied to the relatively young SYM2 general specificationfor Smart Electricity Meter Embedded Systems firmwareupdate mechanisms, valuable results were obtained.Bothproposed variants for Remote Software Download, the onefor compulsory calibration relevant software as well as theone for non-compulsory relevant software showed to roughlymeet the defined requirements of correct, fresh origin of thesoftware image.The compulsory calibration relevant mechanism showed

a vulnerability for downgrade and upgrade cycle attacks.Using the ”boot cycling” attack, an attacker is able toundermine the availability of the meter. Furthermore, en-suring the secure boot of the Smart Meter is an issue. Thisbecomes clear with the pre-proof assumption, that a SmartMeter can only boot the firmware that is was deployedwith or that has been flashed. Experience, especially inthe Embedded Systems domain has shown severe securityflaws in the boot sequences of different devices. Remedycan be found by using Trusted Computing concepts for boot.

The compulsory calibration relevant Remote SoftwareDownload mechanism of SYM2 can be improved by addinga version number to the software image and checking itagainst the current firmwares version before flashing. Thiseffect is shown in section 4.1.1 with an improved andextended SeMF system model. Freshness of the firmwareis to be guaranteed in this case. But secure boot relatedissues remain.

For the non-compulsory calibration relevant Remote Soft-ware Download mechanism, freshness and correct origin ofthe firmware image is shown. Compared to the compulsorycalibration relevant variant, downgrade or ”boot cycling”attacks are not possible. This is founded by the fact ofusing changing shared secrets, which is slightly comparablewith software version numbers embedded in the softwareimages.The difficulty in assuring a secure boot remains for thisvariant, too. It may also be solved by adding Trusted Com-puting functions to the system, enabling an authenticatedboot mechanism.Another weakness is the confidentiality of the shared secret.When transmitting the software image without encryption,it could be eavesdropped by an attacker and analysed forthe position of the shared secret.

Using formal methods reasoning for Software Downloadconcepts of Embedded Systems is an interesting and valu-able approach. This is not limited to the Metrology domainand can also be applied to other Embedded Systems do-mains, such as Automotive or Industry Control.

6. REFERENCES[1] M. Burrows, M. Abadi, and R. Needham. A Logic of

Authentication. ACM Transactions on ComputerSystems, 8, 1990.

[2] S. Eilenberg. Automata, Languages and Machines.Academic Press, New York, 1974.

[3] European Parliament. Directive 2004/22/ec of theeuropean parliament and of the council of 31 march2004 on measuring instruments.http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?-uri=OJ:L:2004:135:0001:0080:EN:PDF, 32004.

[4] A. Fuchs, S. Gurgens, D. Weber, C. Bodenstedt, andC. Ruland. Formalization of smart meteringrequirements. In Proceedings of S&D4RCES 2010Workshop, in the Proceedings of the InternationalWorkshop on Security and Dependability for ResourceConstrained Embedded Systems (SAFECOMP 2010).ACM DL Digital Library, 2010.

[5] R. Grimm and P. Ochsenschlager. BindingCooperation, A Formal Model for ElectronicCommerce. Computer Networks, 37:171–193, 2001.

[6] S. Gurgens, P. Ochsenschlager, and C. Rudolph.Authenticity and Provability – a Formal Framework.GMD Report 150, Fraunhofer Institute for SecureTelecooperation SIT, 2002.

[7] S. Gurgens, P. Ochsenschlager, and C. Rudolph.Parameter confidentiality. In Informatik 2003 –Teiltagung Sicherheit. Gesellschaft fur Informatik,2003.

[8] S. Gurgens, P. Ochsenschlager, and C. Rudolph. On aformal framework for security properties. InternationalComputer Standards & Interface Journal (CSI),Special issue on formal methods, techniques and toolsfor secure and reliable applications, 27(5):457–466,June 2005.

[9] OIML. Oiml d 31 general requirements for softwarecontrolled measuring instruments.http://www.oiml.org/publications/D/D031-e08.pdf,2008.

[10] Physical-Technical Federal Institute of Germany(PTB). Requirements for software-based meteringdevices. http://www.ptb.de.

[11] A. Pnueli. The temporal logic of programs. In 18thAnnual Symposium on Foundations of ComputerScience, pages 46–57. IEEE, 1977.

[12] SYM2-project. Functional specification document forelectricity metering devices. http://www.sym2.org.

[13] WELMEC. Welmec 7.2 issue 4 software guide.http://www.welmec.org//fileadmin/user files/publications/7-2 Issue4.pdf, 52009.

[14] WELMEC. Welmec geography.http://www.welmec.org/welmec/welmec-tour/welmec-geography.html, 122009.