AEEC | October 2011 1

Alpha Eritrean Engineers Community VOL. 3 NO. 2 JUNE 2012

FORMAL VERIFICATION OF AN ELECTRONIC PAYMENT SYSTEM

ALTERNATING CURRENT(AC) VS. DIRECT CURRENT(DC)

MOBILE AUTHENTICATION

LIST OF COMPANIES HIRING

AEEC e

AEEC | October 2011 1

CONTENTS AND CONTRIBUTORS

TOWARDS FORMAL VERIFICATION OF AN

ELECTRONIC PAYMENT SYSTEM

BY DR. TEMESGHEN KAHSAI

A LTERNATING CURRENT (AC) VS.D IRECT

CURREN(DC)

BY SAMUEL FESSEHAYE

MOBILE AUTHENTICATION

BY YARED NEGUSSIE

LIST OF COMPANIES OR GOVERNMENTAL

AGENCIES CURRENTLY HIRING

EDITORS

SEBLE GEBREMEDHIN, M.S. IN

PSYCHOLOGY

ADIAM WOLDEGERGISH, PH.D

SAMSON GONNETZ, B.A. IN CIVIL

ENGINEERING AND

YOSIEF WOLDEMARIAM, B.A. IN

ELECTRICAL ENGINEERING.

AEEC | October 2011 2

It is imprudent to mourn the men and women who gave everything they

had, including the ultimate sacrifice of life. Rather, we should be grateful

such heroic men and women lived.

We shall not and will not forget the sacrifice of our fallen fathers,

mothers, brothers and sisters without whom the dream of freedom

would not have materialized.

AEEC | October 2011 3

INTRODUCTION

In this paper we describe the formal analysis,

verification and testing of an electronic payment system

called EP2. Here, we illustrate the modeling of the EP2

specification in a formal specification language, namely

Csp-Casl. The latter allow us to describe in a

mathematically rigorous and expressive way the

important aspects and functionality of the system.

Having a formal specification of EP2 allows us to

verify interesting properties such as deadlock freedom.

Electronic payment systems are now very common and

these days we expect almost all shops to be able to take

payment by debit or credit card. The system comprises

of components such as back-end systems (e.g., the

shop’s and the bank’s computer systems), the point of

service (e.g., till), and the PIN-pad. A typical use case is

that the sales assistant instructs the till to take payment

by card, then you insert your card into the PIN-pad and

then enter your PIN number and if the PIN number is

correct then money is electronically transferred from

your bank account to the shops bank account.

Electronic payment systems represent an important

benchmark for both the theory and practice of system

specification. In theory, they provide a suitable

benchmark to demonstrate the abilities of formal

specification languages. In practice, they are classified

as critical systems and thus must be developed with due

diligence.

In this paper we consider such an application by

developing a formal specification, reason about its

correctness and finally test an actual physical payment

system.

Figure 1: Overview of EP2 architecture.

The EP2 system is such an electronic payment system

and it stands for ‘EFT/POS 2000’, short for ‘Electronic

Fund Transfer/Point Of Service 2000’, it is a joint

project established by a number of (mainly Swiss)

financial institutes and companies in order to define

EFT/POS infrastructure for credit, debit, and electronic

purse terminals in Switzerland.

TOWARDS FORMAL VERIFICATION OF AN ELECTRONIC PAYMENT SYSTEM

EL AND CONCRETE

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~

AEEC

AEEC | June 2011 4

The EP2 system, as illustrated in Figure 1, consists of

seven autonomous entities:

Acquirer: A system for processing electronic

payment transactions.

Card: Payment utility opened by a specific

cardholder.

Point of Service (POS): A system where a

cardholder may purchase goods and/or services.

POS Management System (PMS): System that

allows the merchant to administrate his terminal

population.

Service Center: A system component used for

configuration and maintenance of a terminal.

Terminal: A system used for processing

transactions.

Card: Utility to make payments.

These components are centered around an EP2 PIN-

pad. The different entities communicate with the

terminal and, to a certain extent, with one another via

messages in a fixed format. The messages contain

information about payment authorization, financial

transactions, as well as other aspects such as

maintenance and configuration of the components. The

state of each component heavily depends on the content

of the exchanged messages.

A formal specification language is a way of writing

down in a mathematically rigorous way, exactly what a

system should do. For this project we used one of many

formal specification languages, namely Csp-Casl [1].

Csp-Casl is tailored for the description of distributed

systems e.g., electronic payment systems. This language

can describe the different aspects involved in EP2 such

as data (e.g., amount of money, account numbers, PIN

numbers, etc.) and processes (e.g., the behavior of the

PIN-pad and other components).

Many systems have faults, in both software and

hardware; deadlock is a common example of such a

fault.

When a system deadlocks it appears to the user as if the

system has frozen (or crashed) and can be impossible to

interact with. We would like to establish whether our

formal specifications have certain desirable properties

such as deadlock freedom. We have developed an

infrastructure including tool support [2, 3] that can

verify that our formal specifications do indeed exhibit

such properties.

On the other hand, in order to increase our confidence

that a particular physical system actually fulfils its

specification, we have developed a testing

framework [4, 5]. This framework allows us to run tests

on the physical system and evaluate the result against

what the specification states should be the result.

In the next section we describe the modeling of EP2 in

Csp-Casl. We then discuss how we prove some

desirable properties such as deadlock freedom. Finally,

we illustrate how we test a physical EP2 PIN-pad in an

automated fashion.

FORMALLY SPECIFYING THE ELECTRONIC PAYMENT

SYSTEM

The (informal) EP2 specification [6] consists of twelve

documents (approximately 600 pages in total), each of

which describe the different components or some aspect

common to the components. Each document is

comprised of a number of different informal

specification notations: plain English; UML-like

graphics (use cases, activity diagrams, message

sequence charts, class models, etc.); pictures; tables;

lists; file descriptions; encoding rules, etc. The top level

EP2 documents provide only an overview of the data

involved, while the presentation of further details for a

specific type is delayed to separate low-level

documents.

Informal specifications such as this have inherent

problems such as ambiguity and imprecision.

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~

AEEC

AEEC | June 2011 5

A formal specification language is a way of writing

down in a mathematically rigorous way exactly what a

system should do. A specification does not stipulate

“how” a system should do its job, just “what” it should

do. As formal specification languages (such as Csp-

Casl) are defined mathematically they are not

ambiguous and are precise, thus addressing some of the

shortcomings of informal specifications. Also, as formal

specifications are based on mathematics, reasoning

about them (using mathematical proofs) is possible.

The informal specification has various levels of

abstraction, which we mirror in our formal Csp-Casl

specification. At the highest level of abstraction (which

we call the architectural level) we capture the overall

view of the system and forget about all the technical

details. The abstraction level is the easiest to understand

and just specifies the individual components of the

system as black boxes (i.e., that they exist and we do

not state their behavior) and how such components are

connect together. Figure 1 shows the informal

architectural level, which we mirror in Csp-Casl.

Once the architectural level as been specified we move

to a more detailed description of the components at the

next level of abstraction, which we call the abstract

component level. Here we add detail about each of the

components and how each one should behave. This can

be thought of as sketching how a component works in a

rough sense, like what data it can send and expect to

receive at certain points in time. For instance you would

expect when making a payment at a shop that the PIN-

pad shows you the amount of money for your purchase,

then asks you for your PIN number, at which point you

enter your PIN number and then the PIN-pad takes

appropriate action if you entered the correct PIN

number. This is what we mean by specifying the

behavior of the PIN-pad. At this level of abstraction

our data (the messages) becomes more detailed, for

instance we state that messages contain data such as

account numbers and the monetary amounts of the

purchases.

At the most detailed level (that we consider here),

which we call the concrete component level; we specify

even more details about each component. We fill in all

the details about exactly how each component should

behave. The messages at this level are fully detailed and

contain further information on the data inside the

messages e.g., exactly how long account numbers

should be (in terms of digits).

These levels do not stand alone, they are related by

what we call refinement. The top level specification (the

architectural level) refines to the abstract component

level and the abstract component level refines to the

most detailed level, the concrete component level.

Refinement means that at a lower level we do not

contradict what we said at higher levels, but only add

more detail to the system specification. Any properties

that we expect to exist at higher levels of abstraction

should also hold at lower levels of abstraction. The

reader can refer to [7, 8] for the overall modeling of

EP2 in Csp-Casl.

The informal specifications have informal refinements between the levels of abstractions which cannot be verified mathematically. Whereas the formal specifications have formal refinements which can be verified mathematically. Such verification (i.e., mathematical proof) requires tool support, to this end we have developed tool support to help us carry out

refinement proofs in Csp-Casl.

TOOL SUPPORT

For quite a while, Csp-Casl existed only as a

‘blackboard language’: while the subject of several

papers, its syntax and semantics remained malleable,

allowing experimentation and discussion. In order to

achieve its full promise, however, it was clear that tool

support would be required. The first step towards such

tool support was to fix Csp-Casl’s syntax and static

semantics, and to implement them within an appropriate

tool [9].

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~

AEEC

AEEC | June 2011 6

We have developed Csp-Casl-Prover [3, 10], a tool,

which allows one to perform interactive theorem

proving on Csp-Casl specifications. Specifications can

contain refinements, which the specifier expects to

hold. Using Csp-Casl-Prover we can guarantee

mathematically that such formal refinements actually

hold. This task requires the user (specifier) to guide the

theorem prover through the mathematics until the

theorem prover can establish that the refinements

actually hold.

In the next section, we discuss how to verify properties

of Csp-Casl specifications. Verification is centered

around formal refinements and thus the tool Csp-Casl-

Prover is central to verification for Csp-Casl.

VERIFICATION

Having a formal specification of a system allow us to

verify certain properties. In the case of EP2, we have

verified that the refinement between the different levels

of abstraction is actually correct. This means that all

properties that have been outlined at the architectural

level are still present in the abstract component level

and finally in the concrete component level. Such

proofs are done systematically using Csp-Casl-Prover.

[2, 8] describes in more detail how such proofs are

carried out.

Moreover, we have proved that the communications

between the different EP2 components are deadlock

free. Deadlock is a phenomenon pertaining to networks

of communicating systems, which occur when two

systems cannot agree to communicate with each other,

thus the whole system becomes permanently frozen.

This is potentially catastrophic in the case of payment

systems, see [11]. Again the proofs of deadlock analysis

of EP2 are done systematically using Csp-Casl-Prover.

Figure 2: Overview of Csp-Casl based testing.

TESTING THE EP2 SYSTEM

In the previous section we have mentioned the

verification of interesting properties of EP2. Such

verification process is done at the specification level.

Here, using Csp-Casl-Prover we have proven that for

instance, according to the specification, that the

communication between a PIN-pad and the acquirer is

deadlock free. We now need to relate the physical EP2

PIN-pad with the formal specification. Such relation is

done through testing.

In [4, 5] a theory for Csp-Casl based testing has been

proposed. In [12] such theory has been applied to

formally test the starting system of the Rolls-Royce

BR725 jet engine. Figure 2 shows, in a nutshell, how

Csp-Casl based testing works.

Specification, Implementation (physical system) and

Test Cases are mutually related artifacts. Specifications

and Test Cases are written in Csp-Casl, the

Implementation is treated as a black box. A test case is

simply an experiment that is run on the system.

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~

AEEC

AEEC | June 2011 7

Test cases can be constructed either from the

specification – as shown in the triangle – or

independently from it. The specification determines the

alphabet of the test cases (e.g., the type of messages the

EP2 components exchange), and the expected result of

each test case. The expected result is coded in a

coloring scheme of test cases. If a test case is

constructed which checks for the presence of a required

feature (according to the specification), we define its

color to be green. If a test case checks for the absence of

some unwanted behavior, we say that it has the color

red. If the specification does neither requires nor

disallows the behavior tested by the test case, i.e., if a

system under test may or may not implement this

behavior, the color of the test case is defined to be

yellow. During the execution of a test on a particular

system under test, the verdict is determined by

comparing the color of the test case with the actual

behavior.

A test fails, if the color of the test case is green but the

system under test does not exhibit this behavior, or if

the color is red but the behavior can be observed in the

system under test. The execution of a yellow test case

yields an inconclusive verdict. Otherwise, the test

passes.

In selecting test cases for the EP2 system, we have

adopted some general guidelines based on the informal

EP2 specification and the Csp-Casl specifications. Here,

we use some general test purposes; for instance we have

selected test cases in order to experiment the main

functionality of the EP2 components, e.g., the PIN-pad

is able to process a payment transaction. Other test

purposes are related to the security features of the EP2

system. Here, we have selected test cases in order to

make sure that the security features outlined in the

specifications are actually present in the physical

system.

In order to execute test cases on the physical EP2

system, we have implemented a tool called TEV (test

evaluator) [8, 13].

Such tool is a hardware-in-a-loop testing framework.

Hardware-in-a-loop testing is a well-established

approach to validate complex systems, where the

correct integration of software with its underlying

hardware is essential [14].

The overall testing process of EP2 is done in two

stages:

1. In the first stage, we classify the test case in

terms of a coloring scheme, i.e., green, red or

yellow. The proof of coloring a test case is done

in Csp-Casl-Prover.

2. In the second stage, the colored Csp-Casl test

case is first translated to the input language of

TEV, and then this is directly executed on the

physical EP2 system.

TEV determines automatically if a particular test case

has passed or failed. The test execution is conducted in

a network environment, where two different machines

are connected with a crossed Ethernet cable. Figure 3

illustrates this setting. Here, the EP2 terminal software

is running on the black laptop (Windows OS), where a

PIN-pad is attached on the serial port. TEV is running

on the white laptop (Mac OS).

Figure 3: Testing a physical EP2 PIN-pad.

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~

AEEC

AEEC | June 2011 8

CONCLUSION

In this paper we have described the formal analysis,

verification and testing of EP2 – an electronic payment

system. Here, we have described the modeling of the

EP2 specification in the formal specification language

Csp-Casl. Having a formal specification of EP2 allowed

us to verify interesting properties such as deadlock

freedom. Finally, we have presented a tool that tests a

physical EP2 payment system in an automatic fashion.

Overall this industrial application of the theoretical

framework of Csp-Casl, demonstrates the feasibility of

modeling, verification and testing in Csp-Casl. This

includes many aspects: (1) Scalability: It is possible to

completely model a non-trivial system like EP2. (2)

Expressiveness: Csp-Casl is expressive enough to

capture the different aspect of such system.

The reactive behavior and the complex data types. (3)

Clarity: Csp-Casl is able to mirror the informal

specification and to capture the different levels of

abstraction. The refinement between the different levels

are then proven using Csp-Casl-Prover. (4) Verification:

Having a formal specification made it possible to prove

interesting properties of the system. (5) Testing: Our

testing framework is able to effectively test a physical

EP2 PIN-pad.

Future research will include the automatic selection and

generation of test cases from the Csp-Casl specification

and the studies of novel strategies to test new security

features of EP2.

~ Dr. Temesghen Kahsai (SE)

Reference:

[1]M. Roggenbach, “Csp-Casl: A new integration of process algebra and algebraic specification,” Theoretical Computer

Science, vol. 354, no. 1, pp. 42–71, 2006.

[2]T. Kahsai and M. Roggenbach, “Property preserving refinement notions for Csp-Casl,” in WADT 2008, LNCS 5486,

pp. 206–210, 2009.

[3]L. O’Reilly, M. Roggenbach, and Y. Isobe, “Csp-Casl-Prover: A generic tool for process and data refinement,” Electron.

Notes Theor. Comput. Sci., vol. 250, no. 2, pp. 69–84, 2009.

[4]T. Kahsai, M. Roggenbach, and B.-H. Schlingloff, “Specification-based testing for refinement,” in SEFM 2007

(M. Hinchey and T. Margaria, eds.), pp. 237–247, IEEE Computer Society, 2007.

[5]T. Kahsai, M. Roggenbach, and B.-H. Schlingloff, “Specification-based testing for software product lines,” in SEFM

2008, pp. 149–159, IEEE Computer Society, 2008.

[6] E. Consortium, “EFT/POS 2000 specification, version 4.0.0,” 2008. Project Overview available at

http://www.eftpos2000.ch. Last accessed June 2010

[7]A. Gimblett, M. Roggenbach, and B.-H. Schlingloff, “Towards a formal specification of an electronic payment systems

in Csp-Casl,” in WADT’04, LNCS 3423, Springer, 2005.

[8]T. Kahsai, Property Preserving Development and Testing for Csp-Casl. PhD thesis, Swansea University, 2010.

[9]A. Gimblett, “Tool support for Csp-Casl,” Master’s thesis, Swansea University, 2008.

[10]L. O’Reilly, “Developing proof technology for Csp-Casl,” Master’s thesis.

[11]“Barclays computer glitch shuts down cash machines and online banking for three-and-a-half hours,” 2009.

http://www.dailymail.co.uk/news/article-1193440/. Last accessed June 2010.

[12]T. Kahsai, G. Holland, M. Roggenbach, and B.-H. Schlingloff, “Towards formal testing of jet engine Rolls-Royce

BR725,” in Concurrency, Specification and Programming, pp. 217–229, 2009.

[13]L. B. Chuan, “Towards hardware-in-a-loop testing for an international standard of an electronic payment system,”

Master’s thesis, University of Wales Swansea, 2005.

[14]S. Nabi, M. Balike, J. Allen, and K. Rzemien, “An overview of hardware-in-the-loop testing systems at Visteon,” SAE

Technical Paper Series, 2004

AEEC | June 2011 9

Comments & Suggestions

Page

Wow…, what a great job!!! I am really proud of you guys. I just got the email and start reading it, it sounds really good. Thank you for your hard work and making it happen. Great job!!! Engineer Mekonen Hadgu It is really nice to see the project issuing its first output. Great work and keep it up. Hope it will inspire lots of Eritrean Engineers and may be it will be a venue for attaining engineering carries for a lot of young Eritrean and the like. Engineer Filipos Abreha Bravo. This is really wonderful and your effort and those of others is much appreciated and needed. I hope the best for the future of AEEC and its members. I also want to thank you for your kind words in the 1st edition. I am very humbled and honored. I believe that if we are in a position to lend a helping hand to our fellow people, then the fruits of that simple effort are enjoyed by many. Engineer Daniel Woldeselasie

A

E

E

C

Hi,

Congratulations on the issuance of professional magazine & sorry for

taking time to respond while I have actually read all on time.

Working in group with people in related discipline like this might

seem meaningless in the short term but if you continue working

harder and specially get linked with institutions at home there could

be possibility to fill a gap especially in consultancy services.

Many thanks for including my name in the circulation list.

Yohannes GebreAb Hello,

Thank you for working hard work to make this happen. But I noticed

minor error on Yared's educational background. Yared graduated

from Chico State in Computer engineering, not computer science.

Samson Gonets ALPHA ERITREAN ENGINEERS

Comments & Suggestions

Page

AEEC | June 2011 10

BACKGROUND

Thomas Edison is known to many as the heroic

American inventor of light bulb. During the initial years

of electricity distribution, Edison's direct current was the

first standard for the United States. Direct current (DC)

worked well with incandescent lamps; the principal load

of the day worked well with motors. Direct-current

systems could be directly used with storage batteries,

providing valuable load-leveling and backup power

during generator operation interruptions. Direct-current

generators could be easily paralleled, allowing

economical operation by using smaller machines during

light load periods, and improving reliability. At the

introduction of Edison's system, no practical AC motor

was available.

Alternating current (AC) was first developed in Europe.

In North America, one of the believers in the new AC

technology was George Westinghouse. Westinghouse

was willing to invest in the technology, and hired other

engineers to work on an AC distribution system-using

step up and step down transformers of a new design in

1886. In the later years, Nikola Tesla joined the

company. Tesla partnered with Westinghouse Electric to

commercialize his particular AC system.

Figure – 1

Fig - 1 Nikola Tesla's AC dynamo used to generate AC

which is used to transport electricity across great

distances.

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~

AEEC

ALTERNATING CURRENT (AC) VS. D IRECT CURREN(DC)

“Engineering problems are under-defined; there are many solutions, good, bad and indifferent. The

art is to arrive at a good solution. This is a creative activity, involving imagination, intuition and

deliberate choice.”

- Ove Arup -

AEEC | June 2011 11

During the "War of Currents" era in the late 1880s,

George Westinghouse and Thomas Edison became

adversaries due to Edison's promotion of direct current

(DC) for electric power distribution over alternating

current (AC), advocated by several European companies

and Westinghouse Electric based out of Pittsburgh, PA.

Nicolas Tesla, an electromechanical engineer, initially

was hired by Edison. Edison promised him money for

what he was going to do, yet refused to pay him. Tesla

eventually quit Edison’s company and joined the

company of G. Westinghouse. This event marked the

beginning of the war of currents. At Westinghouse, Tesla

developed the system of AC generators. DC power was

very expensive especially with long distance

transmission. This was due to the tremendous loss of

power in transmission; on the other hand, AC

transmission had less power loss and more effective.

Hence, this behavior made AC affordable even to

remote areas. Edison became jealous of Tesla’s

achievement and campaigned against Tesla’s new AC

generation system, stating that it was dangerous. He

tried to prove this by electrocuting live animals in front

of audiences. Tesla became successful, and the

Westinghouse Company went on bankruptcy to fight the

AC propaganda.

Tesla designed the first major hydroelectric power plant

in the world using his poly phase system of AC

electricity. As a result, in 1896 the city of Buffalo was lit

by AC electric generated from Niagara Falls, which he

developed utilizing his AC system. The system was

efficient and cheap compared to Edison’s DC system.

Therefore, this marked the end of the “War of Currents.”

Finally, Thomas Edison gave up on the competition and

the AC electricity was recognized as the standard

electric system in the United States.

THE RETURN OF DC CURRENT

AC transmission allows the electricity system to cover

larger geographical areas, bringing into play huge grid

networks and the possibility of electricity generation

from more remote sources such as hydroelectric power

stations even though the rules are changing.

The basic assumptions of efficiency and security of

supply that underpin big networks are now being

questioned. Large generating plants are becoming less

competitive compared to small-scale technologies.

Power failures more commonly originate in the

electricity grid than in the generating technology.

The discovery of semiconductors and the invention of

the transistor triggered a revolution in how we use

electricity. Machines and appliances such as computers,

video recorders and microwave ovens operate internally

on DC power. Individual inverters on each appliance

convert the incoming AC electricity into DC.

The cheapest, cleanest, and most reliable power could

be generated by technologies at home. Solar

photovoltaic (PV) panels convert sunlight directly into

electricity. They can replace roof tiles and building

facades, they have no moving parts and they generate

electricity without emissions of greenhouse or other

gases. Fuel cells are a developing technology, generating

electricity from hydrogen and oxygen and emitting only

water vapour.

The development of bio-diesel, biomass electrical,

combined heat and power generators is also progressing,

since it works on small-scale wind turbines. All these

technologies generate DC electricity. With inverter

efficiencies of around 90%, each switch of electricity

between AC and DC means that less electricity is

available for use. Do AC electric systems still make

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~

AEEC

AEEC | June 2011 12

Sense with more appliances using DC and more

technologies generating it? And if the electricity output

is used close to where it is generated, what gains are

there in inverting it to AC for transmission?

Fig – 2

Although still costly at the moment, technologies such

as solar photovoltaic (PV) panels and fuel cells have real

potential for delivering a low-polluting energy system.

This has been recognized by governments and

businesses, and grants are on offer to encourage uptake.

As uptake increases, costs should come down with

further developments to the technology, and economies

of scale kicking in.

From the perspective of developing countries, a DC-

based electrical system could provide access to

electricity without the mass of towers and wires that are

necessary for an AC system. Locally managed, smaller

scale, and more environmentally benign technologies

such as solar PV and small hydro-electric schemes allow

communities to have control over how their electricity

system is developed and utilized.

For something as important as electricity, we have little

influence on its production. Presently, it comes from

remote, large-scale, uncontrollable networks, routed by

people who have never heard of solar PV. By installing

low-polluting power plants at home or in communities,

energy does not necessarily need to be tied to the global

power politics of oil and gas any longer.

Thomas Edison’s original vision was a direct current,

locally based electricity system. Over 100 years later,

the technologies have started to emerge with motivation.

~ Engineer Samuel Fessehaye

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~

AEEC

Reference:

1. Cheney, Margaret (2001). Tesla: man out of time. Simon and Schuster. p. 21. ISBN 978-0-7432-1536-7. "Everyone in London is talking about the New Wizard of the West—and they don't mean Mr. Edison"

2. AC Power History: http://www.edisontechcenter.org/AC-PowerHistory.html

3. McNichol, Tom (2006). AC/DC: the savage tale of the first standards war. John Wiley and Sons. p. 80. ISBN 978-0-7879-8267-6.

4. Great Barrington Historical Society, Great Barrington, Massachusetts 5. "AC vs DC". IEEE Global History Network. IEEE. Retrieved 21 July 2011.

AEEC | June 2011 13

Eritreans who are currently looking for Engineering/Technical jobs

Name Degree Experience Email Phone

Number

Kibrom Hadgu Electrical Engineer 17 years kibromwoldehaimanot@yahoo.com (415) 678-7179

Samuel Fessehaye Electrical Engineer Eight years SBFessehaye14@gmail.com (510) 830-7082

Thomas Araya Computer Science Seven ears thomasaraya@yahoo.com (510) 757-7352

Samson Gonetz Civil Engineer Five Year samigonnetz@yahoo.com (510) 495-4538

Simon Haile Electrical Engineer One year dhaile8@gmail.com (678) 982-0147

AEEC | June 2011 14

Comparison of Transient and Location Based Mobile Authentication

Because of the pervasiveness of mobile devices, people

are increasingly relying on their mobile devices to do

business. This business includes connecting to online

financial services such as banks and to corporate office.

When connecting to online banks or corporate offices

an individual is required to type in a user name and

password. Then, the information is transmitted securely

to the destination intended. This process requires two

events to happen. First, the user must be authenticated,

which means the user needs verification to make sure

the individual is who he claims to be and second, the

information needs to be transmitted securely.

There have been many proposals of authentication

methods to mobile devices. Some of the proposed

methods are: 1) token based authentication –where

tokens are used to authenticate user, 2) transient

authentication – where tokens are used to authenticate

users and the connection is terminated as the token is

further than few meters away from the device (Anthony

N, Mark R, and Brian N., 2006) and 3) location based

authentication – where the authentication is based on

the users current location. Traditionally, authentication

relies on what user knows and/or what user has.

Location based authentication is an addition to the

traditional authentication by adding where user is and

when. Barbecaru (2011) shows how this approach can

be cost effective and secure.

TRANSIENT AUTHENTICATION:

The main goal of transient authentication is to alleviate

authentication problems that are prone to persistent

sessions. There are two major issues with persistent log

in sessions. The first one is in an event when one is

away from the device and the log in the session is

active, anyone will be able to accessing the computer.

The second problem is when the device is lost or stolen.

In both cases, someone can gain access to the session

that in progress and access confidential information and

data. Since mobile devices are small, they are prone to

the second problem and thus the focus of this paper and

compare transient mobile authentication method and the location based mobile authentication.

Transient authentication ameliorates this problem by

terminating connection to the mobile device if user is

away from the device a few meters. This especially

prevents access to the mobile device when the device is

stolen or lost. A proposal by (Anthony et. Al, 2006)

provides not only authenticating users with transient

authentication method, but also protecting data while

the connection is terminated. This protection of data

includes encryption, overwriting and flushing data

when necessary. In the case where the user is away

from the system, all the necessary confidential

information will be dealt with appropriately until the

user returns, at which time, the connection

automatically resumes and system is restored to where

it was before the termination.

Transient application works as follows: user carries a

wearable token on his body, which constantly

communicates with the mobile device. The token uses

Bluetooth technology to communicate with the mobile

device. When the token departs from the device within

certain range, then data in the mobile device is

protected by using encryption, overwriting and/or

flushing system.

Principles: Transient authentication is based on the

following four principles:

1. Sensitive computation is performed only when

the user is near the token. That is, the user is the

only one who has access to the device as he

carries the token. All encryption keys will

present on the users wearable token. When the

pairing is broken, any credential that is stored in

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~

AEEC

Mobile Authentication

AEEC | June 2011 15

the devices cash, for performance reason, must

be flushed, and everything else needs to be

secured.

2. There should be no excessive security overhead

that will frustrate and overwhelm users. This

prevents users from disabling their security

features because they are aggravated or

frustrated.

When the user departs from the device, system should

be protected within reasonable time. Upon returning to

the device, the system should restore within short time

period.

The token must be explicitly authenticated. User must

enter PIN to login to the token.

AUTHENTICATION ARCHITECTURE:

The main part of the system is the link between the

device and the token. The link is established via short

range wireless communication. The wearable token

contains the server process, which includes public key

encryption keys and the mobile device has the client

process. The server continually polls the client and if

there is no response, then all data in various locations of

the device must be protected by encryption, overwriting

or flushing depending on what needs to be protected.

One of the components of authentication architecture is

key management. To protect attacker from easily

decrypting encryptions, to prevent unnecessary latency

and performance degradation, the key management has

to be handled very carefully. To access the data that

was encrypted, the device must have appropriate

decryption key as the user departs. To avoid low

performance by the device as well as others getting hold

of encryption keys, these keys are stored in the token.

To further protect degrading performance, the device

caches decrypting keys avoids unwanted

communication between the token and device. These

cashed encryption keys are flushed when the token and

device are separated.

Besides encryption, one important aspect is what

happens if the token is lost. This problem must be

handled cautiously since the token holds the decryption

key. Two scenarios are explained by (Anthony et. Al,

2006), With tokens require PIN or password to work a

user must enter his personal identification number t

least once. When the time expires, the token is

unusable unless the user enters password. On the other

hand, how does a token distinguishes one device from

another? This is handled by requiring binding. A user

can select which devices he would like to bind during

the authentication. If there is no selection from the user

for a particular device, then there will be no

communication between token and the device.

When a device is apart from the token, all confidential

file locations must be secured and one has to determine

which locations need to be secured. Some types of data

have inherently short life time. Files in registers and

Translation Lookup Buffers (TLB) have data that is

constantly overwritten or flushed out by the operating

system, thus being handled by the operating system.

The challenge is then to determine which locations of

the system will be secured. As data passes from one

location to another, parts or all of the data may be

cached in different part of the system. Once the device

and the token are separated, data that may lie within

different part of the system must be secured. The

following locations are identified by (Anthony et. Al,

2006), as areas where system must be secured:

a. Persistent locations: flash memories, hard drives

and other persistent locations need to be

secured. Since deleting files is not enough to

get rid of confidential material these persistent

areas must be encrypted.

b. Virtual memories: This process utilizes ram and

disk storage devices for paging, used by the

virtual memory needs to be secured. The

transient authentication framework encrypts

content of RAM in place when token departs

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~

AEEC

AEEC | June 2011 16

preventing latency. The system already secures

disks; therefore, it will not be ideal to try to

encrypt data stored in the disk by the virtual

memory.

c. Peripherals: This system does not encrypt, or

flush the system since it is difficult to encrypt in

this locations and it is not accessible externally.

To secure data that may be in peripherals the

recommendation is to use end-to-end encryption

such as NIC.

d. Displays: Securing data, which is in video card

buffers requires overwriting buffers which

leaves the displays blank.

ZERO INTERACTION FILE SYSTEMS:

When the device reconnects with the token, all secured

data is unlocked and the device is available for work

leaving the device in unsafe mode. These locking and

unlocking of the device happens when the user enters

his password. To alleviate such problem, some systems

may force re-authentication; however, doing so

decreases the usability of the system by creating

annoyance. A new file system, Zero Interaction File

System (ZIAfs) was created in response to the

authentication problem. ZIAFs provides an effective

file encryption and because the encryption keys are

stored in the file directory which is encrypted, accessing

file creates latency. This latency is created as a result of

the communication between the token and device to

encrypt and decrypt information. To ease the improper

performance burden, ZIAfs keeps cached copies of all

decrypted keys in the device. When the connection

with the token is broken, this information is flushed and

has to be repopulated again. This method keeps

performance in check while making sure security is

maintained by not exposing the keys to public and how

granular file and directory structure affects

performance. Assigning each file or chunk its own

symmetric key this will create massive amount of keys

and performance issues and will deal with performance

tradeoff ZIAfs employs per-directory keys.

LOCATION BASED AUTHENTICATION:

While token based authentication is a strong

mechanism, there has been some resistance in using it.

The resistance is mainly because of cost, server

synchronization and worry to carry multiple tokens for

multiple solutions (Tanvi, Sonal, Kumar, 2011). Tokens

can also be lost and they may be difficult to replace

once compromised.

To mitigate the issue of tokens, strong authentication

mechanism is needed. Location based authentication

provides a solution as an alternate means of token based

authentication. With the growing popularity of the

Internet, social media and Smartphone, one can easily

see the potential of location based authentication

without delving too much into the details of how it

works.

Location based authentication can be used in addition to

one of the traditional authentication methods: what user

knows or what he is. Location based authentication

avoids issues with loosing tokens or keys. (Jansen &

Korolev, 2009) list benefits of using location based

authentications as follows.

An authentication attempt from an authorized

location is rejected

If an authentication attempt is made from

outside the defined territory, the authentication

mechanism can require for additional

authentication mechanisms to satisfy the

requirement

If a user attempts to initiate specialized

authentication, the authentication mechanism

can require such activity be conducted only

from approved location.

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~

AEEC

AEEC | June 2011 17

If a user moves from a defined territory,

automatic trigger of authentication mechanism

can be initiated in order to grant or deny access.

Many types of location based authentications have been

proposed. (Francis, Mayes, Hancke and Markanonakis,

2010) propose location based authentication based on

intelligent location agents installed on mobile devices.

In this model, the location of the device is the basis of

authentication to the network system and available

network services. This part of the document examines

LRAP: A location based remote client authentication

protocols for mobile devices proposed by (Berbecaru,

2011)

In location based authentication, major problem exists

in resolving the location. The location provided by the

location sensing device needs to be authenticated by

third party in order to be considered reliable (Berbecaru,

2011). Two classes of solution are provided by (Jansen

and Korsov, 2009) are the first class of solution where

the location is known by the device and not the

infrastructure. Infrastructure is explained as the set

collection of sensor equipment such as GPS satellite or

mobile network tower. The second class of solution

relies on the infrastructure.

(Berbecaru, 2011) provides few solutions of for location

authentication problem. The first solution presented is

to use the U.S. space-based GPS system. This system

provides accurate location information regardless of the

weather; however, from security stand point, it has its

drawback. There are several GPS simulators that

provide location information designed to appear as if it

came from GPS satellite, which means this is prone to

spoofing attack.

LSS – location signature sensor is a solution that was

proposed to mitigate the GPS signal authentication

problem. This tamper proof device would create and

verify a location signature ‘containing geodetic position

and valid for a short time.

This would be a onetime unpredictable password.

Galileo Local Element – the LE (Local Element) is an

important part of Galileo which is in charge of

certifying the time and accuracy of the location. By

gathering data from GPS and Galileo this system

provides much accurate position information.

One Time Codes (OTC) – In authentication based on

one time codes, the prover and verifier both share a

secret. The prover presents this secret to the provider.

This secret is one time code. The one time code can be

generated by the user, or it can be generated by the

prover and sent to the user.

LRAP—is based on three factors: 1) what the user

knows, 2) where the user is and 3) when and what the

user has. The architecture is composed of several

components: the user, the User Terminal (UT), the

Service Provider (SP) and the Galileo LE. This

protocol consists of two phases: registration phase and

operational phase. Before a remote client wants to

establish a connection, he must have a unique ID that

will be given upon successful completion of the

registration phase (Limkar, Jha, Pmpalkar, Darde, 2011)

The service provider generates an OTC encrypted with

a key derived from the UT location and sends it to the

UT for authentication. Several data is provided to the

SP by the client during the registration. To check the

accuracy of the data, SP might collect more data.

The UT is authenticated based on OTC, ownership of

the UT and the position of the UT. Using location

based encryption algorithm, the author combined the

position information with OTC. This will guarantee

that the user can only recover the information if he is in

certain position and has access to the UT.

In LRAP location dependent data encryption algorithm

is used to drive the LDEA-key; however symmetric key

encryption with shared key is used to generate the

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~

AEEC

AEEC | June 2011 18

Final-key; however, since the location information

provided by the GPS receiver can be inaccurate,

additional parameter Toleration Distance (TD) is

introduced. TD must be known both by the sender and

receiver.

Implementation of LRAP: In this section, the

document describes implementation of LRAP-based

payment service at self-service gas station. The

payment operations are performed via UT

communicating with POS.

Architecture: the SP such as bank is part of private

payment system, which can manage multiple types of

payment methods. The user assumes the UT is secure

device. Two types of communication can be initiated

by the UT: short range channel which is used to

exchange information with the POS device at the gas

station, and long range channel which is used to

communicate with the PS and with the LE.

Phases: the service is composed of registration and

operational phase. In the registration phase, the client

and the gas station provider are registered with the

service provider by providing several data about

themselves.

In the operational phase is where the position of the

device determined. This phase is composed of 11 steps.

The first of which is to get the location coordinates of

the UT from the GPS system or from the LE. The LE

calculates the position of the UT based on the

information that it gathers from the UT. Once the

coordinates are taken care of, the UT opens secure

connection with the SP to receive token. At this point

all communication to the SP has to be done securely.

The UT sends user authentication credentials over this

channel; therefore, it is important that the

communication is highly secured and encrypted. The

SP first checks to see if the UT has been declared lost or

stolen before providing the token. Once information is

checked, token is provided which is then can recover

the OTC.

COMPARISON OF THE AUTHENTICATION METHODS

Security is not just important feature of mobile

computing. It is mandatory that information is secured

while information is being transferred through

unsecured medium. There is no clearly defined strong

authentication. In this paper, transient authentication

and location based authentications have been explained.

Two specific implementations of transient

authentication and location based authentication were

examined.

The proposed transient authentication is basically token

based authentication system, which provides

authentication and encryption method.

Advantages:

The proposed transient authentication method is very

secure. In order for anyone to get authenticated, the

user must have the token. The token is wearable which

prevents issues such as loosing password, or forgetting

the password.

In an event in which a device is stolen or lost,

encryption is immediately applied to all sensitive areas.

Decryption of device and return to normal state is

relatively easy. User needs only to be within vicinity in

order for the device to decrypt and connection is

restored. Very detailed security measures are taken in

order to secure the system while the token and device

are parted. Every part of the system is secured. Data

that is cached is overwritten or flushed.

Transient authentication framework leverages the

operating system’s security features. It avoids

redundant actions by allowing the operating system

handle some of the security issues that are originally

taken care of by the operating system.

The design of the transient system also took in to

consideration of the overall system usability. It avoided

forcing authentication repeatedly which will annoy

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~

AEEC

AEEC | June 2011 19

users and would cause them to disable the important

security features.

DISADVANTAGES;

Since the tokens are separately worn, they are prone to

theft or loss. In case there is loss of token, the article

(what article??) made no proposal what the monitory or

time cost is.

Implementation of the transient authentication can be

costly. There are many components involved: device,

token, servers and software which have to be constantly

maintained and updated.

On the other hand, the location based authentication

system uses completely different model. It relies on the

location of the device. The location is calculated based

on signal from GPS.

ADVANTAGES OF LOCATION BASED AUTHENTICATION:

This authentication method does not require carrying a

token or any other third device.

It provides strong authentication method. It also is

powerful because it is used in addition to other factors

such as password.

Since location can be different within short period of

time, it will be very difficult for an attacker to fabricate

an attack.

DISADVANTAGES OF LOCATION BASED AUTHENTICATION

The main drawback of location based authentication is

that it relies on the feeds it receives about location of

the device. The location can be spoofed. That means

data can be presented as if it is in one location while it

is really not in that location.

Implementation of the location based system is

complex. There are lots of ‘players’ involved in the

implementation. It requires that SP is aware of the

authentication scheme in order for the authentication to

work.

~ Engineer Yared Nugssie

References

Anthony N, Mark R, and Brian N, (2006)Mobile Device Security Using Transient Authentication. Transactions on

mobile computing. Computer Society. 1489-1502.

Berbecaru, D. (2011). A Location-Based Remote Client Authentication Protocol for Mobile

Environments.Proceedings: 19th International Euromicro Conference on Parallel, Distributed, and Network-Based

Processing: Aiya Napa, Cyprus, 8-11 February 2011 (pp. 141-145). Los Alamitos, Calif.: IEEE Computer Society Press.

Parekh Tanvi, Gawshinde Sonal, Sharma Mayank Kumar, "Token Based Authentication Using Mobile Phone," csnt,

pp.85-88, 2011 International Conference on Communication Systems and Network Technologies, 2011

Suresh V. Limkar, Rakesh Kumar Jha, Shilpa Pimpalkar, Santosh Darade, "Geo-Encryption - A New Direction to Secure

Traditional SSL VPN," itng, pp.1070-1071, 2011 Eighth International Conference on Information Technology: New

Generations, 2011

Wayne Jansen, Vlad Korolev, "A Location-Based Mechanism for Mobile Device Security," csie, vol. 1, pp.99-104, 2009

WRI World Congress on Computer Science and Information Engineering, 2009

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~ A

EE

C ~

AE

EC

~

AEEC

AEEC | June 2011 20

Current Job Opportunities Companies or Government Jobs Location & Number

Closing Date

Software Engineering

http://jobs-boeing.com/wright-patterson-afb/software-engineering/jobid2493061-java-j2ee-software-engineer-1-jobs

Wright Patterson, Ohio, 12-1013095 07/09/2012

http://jobs-boeing.com/houston/software-engineering/jobid2493157-software-engineer-1_2-jobs

Houston, Texas, 12-1012236 07/09/2012

http://jobs-boeing.com/huntsville/software-engineering/jobid2490412-modeling-and-simulation-software-engineer-1_2-jobs

Huntsville, AL, 12-1012750 07/09/2012

System Engineering

http://jobs-boeing.com/oklahoma-city/systems-engineering/jobid2493059-systems-engineer-1_2-jobs

Oklahoma City, OK, 12-1013074 09/04/2012

http://jobs-boeing.com/oklahoma-city/systems-engineering/jobid2493062-systems-engineer-1_2-jobs

Oklahoma City, OK, 12-1013108 09/04/2012

http://jobs-boeing.com/oklahoma-city/systems-engineering/jobid2493066-systems-engineer-2-jobs

Oklahoma City, OK, 12-1013126 09/04/2012

Mechanical Engineering

http://jobs-boeing.com/st-louis/mechanical-and-structural-engineering/jobid2493035-structural-analysis-engineer-2-st.-louis-bma-%EF%B9%A0-phantom-works-jobs

Saint Louis, MO, 12-1012779 09/04/2012

A

E

E

C

Bringing the best and the brightest together

Hard to reach doesn’t have to mean hard to do

AEEC | June 2011 21

About the authors

Temesghen Kahsai lememta@gmail.com received his PhD in

computer science from Swansea University and

currently a software developer at Microsoft

(Skype division) and also a visiting researcher at

the University of Iowa.

Samuel Fessehaye SBFessehaye14@gmail.com earned his B.S. in

Electrical Engineering from Asmara University.

Currently he is working (volunteering) with

Caltrans as an engineer.

Yared Nugssie negussie@gmail.com received his B.S. in Computer Engineering from Chico California State University and currently he is Sr. Technical Support Specialist at Pearson.

If you need an updated information

or discussions or got an

Engineering experiences that you

want exchange your knowledge or

ideas with your fellow

professionals.

You will find us on

www.linkedin.com/groups/Alpha-

Eritrean-Engineers-Community