Protection of image and measurement data in an open network for traffic enforcement

www.elsevier.com/locate/csi

Computer Standards & Interf

Protection of image and measurement data in an open network for

traffic enforcement

Frank Jager a,*, Ulrich Grottker a, Heike Schrepf a, Wolfgang Guse b

a Physikalisch-Technische Bundesanstalt (PTB), Braunschweig and Berlin, Germanyb ROBOT Visual Systems GmbH, Monheim, Germany

Available online 16 November 2005

Abstract

Efficient traffic enforcement requires measuring systems using digital cameras instead of wet film technology. The digital

file containing the image data and the measured speed and/or other values are transferred to a central office without personnel at

place. A type approval for such a system – as necessary in most countries – has to ensure the authenticity and integrity of these

data with the goal of being accepted as evidence at court. The company Robot has developed a speed-measuring instrument

using a digital camera system that has been type approved by PTB and is used by the German police since 2003. This paper

firstly presents the technique of this system as an example to protect these data. The second part describes the in-depth

validation method performed at PTB in the framework of the type approval procedure with the focus on the analysis of securing

means of the operating system and of the applied cryptographic algorithms. The basis is a detailed and structured set of

specifications and requirements that has been drafted by a consortium within the project VERA 2 funded by the EC.

D 2005 Elsevier B.V. All rights reserved.

Keywords: Digital imaging; Traffic enforcement; ROBOT SmartCamera; Speed measurement systems

1. Introduction

Digital imaging and networking technology are

increasingly used in many fields, particularly for mea-

surements in locations that are inconvenient to reach

or even inaccessible for personnel. Continuous traffic

enforcement in tunnels is a striking example. The

bodies in charge as well as the manufacturers who

develop measuring systems for traffic enforcement

0920-5489/$ - see front matter D 2005 Elsevier B.V. All rights reserved.

doi:10.1016/j.csi.2005.07.011

* Corresponding author.

E-mail address: [email protected] (F. Jager).

were aware of the advantages of the new technology

compared to the established isolated local systems.

Figs. 1 and 2 illustrate a digital imaging system that

utilises the advantages of a digital camera and a

network solution.

A sensor measuring the speed of the passing vehi-

cles triggers a digital camera. The image data and the

measured speed and some other data are combined to

an event file that is compressed, if necessary, and then

transferred to a central office via a network (ISDN or

Ethernet). This transfer is protected by a digital signa-

ture and encryption. In the office the correctness of the

aces 28 (2006) 327–335

Fig. 1. Digital imaging system with automated transfer of traffic enforcement data from the situation of the offence to a central office.

F. Jager et al. / Computer Standards & Interfaces 28 (2006) 327–335328

signature must be checked before using the file for

enforcement purposes (see Fig. 3).

Various obstacles had to be overcome before such a

system could be implemented. In particular certain

constraints in legal metrology have to be observed.

In Germany and many other countries measuring

instruments and their auxiliary devices used for traffic

enforcement run through a two-step legal procedure.

Firstly a pattern of the measuring system is examined

and approved by a Notified Body with the result of a

homologation. Secondly each batch-produced instru-

ment is legally verified before put into use. Legal

verification is repeated in fixed intervals.

Bodies in charge and manufacturers had to clarify

how digital images and data transferred via networks

could be sufficiently secured for the purpose of serving

as an evidence. From the manufacturer’s point of view

development of such complex system only would be

Fig. 2. SmartCamera installation and ruggedised

economically attractive, if this technology was accept-

ed in many countries. As there is no EC directive

harmonising traffic enforcement, authorities responsi-

ble for type approval and manufacturers from several

European countries joined in two EC funded projects

(VERA 1 and 2) for solving these problems. The

authors of this article were instrumental in contributing

to the result of these projects in developing a measur-

ing system conform to the requirements defined, and in

examining this measuring system.

2. The ROBOTsystem from the user’s point of view

2.1. Overview TraffiStar S330 components

The TraffiStar S330 speed measurement system

consists of three main components which are the

housing installed in a tunnel in Germany.

Fig. 3. Example of a digital image with a closed lock as a symbol

for integrity.

F. Jager et al. / Computer Standards & Interfaces 28 (2006) 327–335 329

Xenon flash bXF1Q to illuminate the scene, the Intel-

ligent Piezo Pre-Amplifier bIPVQ to measure the speed

and the digital camera unit bSmartCameraQ to docu-

ment the incidents. The incident data is stored locally

in the SmartCamera and later transferred automatical-

ly to the central office for evaluation and to issue the

citations.

2.1.1. Xenon flash XF1

To illuminate the scene, the interior of the vehicle

(for driver recognition), and the number plate (for

owner identification) a flash in a separate housing is

used. This flash is triggered directly by the SmartCa-

mera. It may be equipped with different filters in order

to prevent irritation of the drivers. This is extremely

important in tunnel applications where the ambient

light is low and a bright flash would definitely dazzle

and thus endanger the driver.

2.1.2. Intelligent Piezo Pre-Amplifier

The ROBOT Intelligent Piezo Pre-Amplifier (IPV)

is designed to operate as a stationary speed measure-

ment device using input from three piezoelectric sen-

sors that are installed about 2 cm beneath the road

surface. When vehicles cross the sensors, signals are

sent to the IPV and the speed of the vehicle is calcu-

lated using the distance / time principle. The ROBOT

IPV digitises the signals from the piezoelectric sen-

sors. They are analysed and evaluated more accurately

compared to traditional analogue systems. Several

speed measurements are taken to ensure accuracy. As

soon as one of the measurement results differs from the

rest the measurement is discarded. The system auto-

matically differentiates between cars and trucks. The

speed and classification data are passed directly to the

SmartCamera.

2.2. ROBOT SmartCamera

The digital ROBOT SmartCamera is a unit which

incorporates the CCD camera, a frame grabber and a

complete PC. The PC is equipped with RAM and hard

disk or flash disk plus an Ethernet or ISDN interface.

All these parts are enclosed in one ruggedised camera

housing (Fig. 2).

The SmartCamera receives the measured speed

value from the IPV and decides whether the passing

vehicle is overspeeding or not. If the speed exceeds

the configured speed limit (which may be different for

cars and trucks or for the different lanes) the Smart-

Camera triggers the flash, captures the image, and

stores it together with all relevant incident data. All

the necessary information like for example location,

operator, speed limit is set with the control

programme and is stored in the camera itself. A link

to a variable speed limit system is possible. The

recorded incident data is completed by a digital sig-

nature, optionally encrypted and stored on the local

harddisk.

In the tunnel project on the A71 in Germany 16 of

these TraffiStar S330 speed measurement system with

their SmartCameras, IPV sensors and flashes are

connected to a private network. This private network

consists of an optical fibre ring connecting all devices

to a server in a central office. In regular time intervals

the stored incident data is transferred to that server.

The main task of the server is to store the original

incident data with the digital signature and the

corresponding public keys centrally (e.g. on a CD-

ROM). So the data is available for evidence in case of

later investigations or in case of revisions. Prior to

issuing the fine to the offender the evaluation of the

received incident data has be done either on the server

directly or on additional workstations. For this pur-

pose the evaluation software TraffiDesk is used. The

signature of every incident file is automatically

checked and a specifically trained personnel judges

the images (e.g. to examine the vehicle position in the

image).


3. Software requirements

3.1. Link to normative documents

All software requirements described here are

based on the WELMEC Guide 7.2 bSoftwareQ.This guideline comprises the following issues: clas-

sification of technical configurations of measuring

systems, definition of risk classes of applications in

legal metrology, definition of requirements, proposal

of validation steps, and proposal of technical solu-

tions. Due to the modular approach of the guide 7.2

it is possible to apply it to any configuration of a

measuring system by selecting the appropriate mod-

ules and to apply it in different areas by choosing

appropriate levels of risk classes (D. Richter et al.

The New European Software Guide for Legal Me-

trology: Basic Principles with the corresponding

reference in this volume). For traffic enforcement

a selection and an adaptation to the specific situa-

tion of digital enforcement systems has been made

in the framework of the EC project VERA, de-

scribed above.

It was agreed that for digital enforcement systems

with evidential measurements the highest risk class

(F) is appropriate. In terms of the guide 7.2 this

means: high protection against fraud and manipula-

tions of the system, high conformity to the pattern and

accordingly high intensity of software examination at

type approval.

3.2. Definition of standard configurations

The variety of configurations that are suitable for

practical enforcement may be reduced to some few

patterns. In the VERA project the following tech-

nical configurations have been identified that are

adequate to practical application situations.

3.2.1. Configuration I — compact instrument (direct

displaying)

A digital imaging enforcement system built for

this purpose and with all components in a common

housing (without long-term storage). This configu-

ration is intended for direct enforcement, i.e. with

an officer present to stop the vehicle and demon-

strate the image and the speed to the offending

driver on a display.

3.2.2. Configuration II — closed local system (direct

displaying)

A digital imaging enforcement system built for this

purpose consisting of more than one component (e.g.

sensor, camera, control unit and printer) connected

locally. This configuration is also intended for direct

enforcement.

3.2.3. Configuration III — system with removable

storage for deferred displaying




locally and storing the file on a removable long-term

storage (e.g. CD-ROM) in the device on site but

displaying the file in the office.

3.2.4. Configuration IV — system with open transmis-

sion and storage for deferred displaying




locally and transferring and storing the file via a net-

work to the office where the file is displayed.

3.3. Specific requirements for the system under

consideration

For a system with a digital camera as described in

chapters 2 and 4, a combination of configurations III

and IV is applicable. In the following the requirements

specific for this configuration are described.

(a) The software shall be clearly identified. An

identification of the software shall be inextrica-

bly linked to the software itself. It shall be

presented on command or during operation.

Some countries may require the possibility for

a bit to bit comparison to ease the conformity

check as part of legal verification of each single

system in the field.

(b) Software comprises programmes, data and para-

meters. Functions of a measuring system are real-

ised by programmes. The requirements apply to

all programmes that perform functions of the

digital imaging system that are defined above

and all software security features. Parameters

fix adjustable or changeable features of a system.


(c) Legally relevant programmes, data and para-

meters shall be protected against accidental and

unintentional changes and they shall be secured

against inadmissible modification or loading as

well as against swapping of memory hardware.

(d) Commands entered via user interfaces or elec-

trical interfaces shall not inadmissibly influence

the measurement data, measuring functions and

parameters. There shall be an unambiguous

assignment of each command to an initiated

function or data change. There shall be no

undocumented commands.

If a universal computer is part of the system at the

measurement location, the following means are nec-

essary (leading to a system that is equivalent to a

built-for-purpose device):

(e) It shall be ensured by technical means that on

the universal computer only the software ap-

proved for the measuring purpose can perform

the legally relevant functions.

(f) It shall be ensured that loading of software or

programming is blocked by technical means

(e.g. by sealing).

(g) It shall be ensured by technical means that the

legally relevant software (programmes, data and

parameters) cannot be inadmissibly influenced

by other software existing on the computer.

Due to the transmission and storing provided in the

configurations under consideration the following ad-

ditional requirements apply:

(h) The stored or transmitted data must contain all

relevant information necessary to prove the ev-

idence of the measurement result, e.g. the image

assigned to the measured speed.

(i) The system shall ensure by technical or house-

keeping means that the authenticity – i.e. genu-

ineness and origin – of the stored or transmitted

data is evident when it is evaluated in the office.

(j) Legally relevant data to be stored or transmitted

shall be protected against accidental and unin-

tentional changes and shall be secured against

intentional modification during storing or trans-

mission. Data that are detected as having been

corrupted shall not be used as evidence.

(k) If cryptographic keys are used in the system

they shall be treated as legally relevant data

and shall be kept secret by technical or house-

keeping means (in public key systems this

applies only to the bSecret KeyQ).

For the component in the office to be used for

displaying of the stored measurements and images

the following requirement applies:

(l) There shall exist a programme for retrieving and

presenting the transmitted and stored measure-

ment results including all accompanying infor-

mation. The programme used in the office shall

check the integrity and authenticity of the data

and shall present the result of this check.

For this component loading of software or program-

ming does not need to be blocked as required in (f), if

retrieving, displaying, and checking of the integrity,

and where applicable authenticity, is repeatable with

reference software at any time.

Encryption of the stored data is required in many

countries to prevent unauthorised access and abuse and

to ensure confidentiality.

4. Software solutions for digital data security

Dedicated security mechanisms, based on standar-

dised, globally accepted methods and algorithms pro-

tect any digital primary evidence generated by the

ROBOT SmartCamera. The security technology is

embedded by default in each SmartCamera and can

be activated or deactivated by initial configuration of

the system. The central processing unit of the Smart-

Camera and the software itself as well are protected

against unauthorised access and tampering. So the

three possible targets for an attack (processing unit,

software and the evidence data) are protected by indi-

vidual means.

4.1. General access control: user/operator passwords

The operating system of the SmartCamera uses

passwords of a length up to 8 characters. Each directory

and every file (both programme and data) has been

assigned specific and well-defined permissions. The


standard access mechanism ftp and telnet are disabled

for the administrator accounts in the homologated ver-

sion. New accounts cannot be generated. Consequently

there is no chance for any tampering. Even with ded-

icated host software an individual password of up to 10

characters is required to be able to connect to a Smart-

Camera. The SmartCamera control programme itself

supports 3 different user groups with specific permis-

sions and requires a password at start-up. For the

homologated version of the SmartCamera all critical

configuration parameters of the camera software have

been fixed to well defined values. These values are

checked (and in case of differences overwritten by the

fixed values) each time the values are used.

4.2. SmartCamera software application protection

The ROBOT SmartCamera software itself is pro-

tected against changes by a cyclic redundancy check

(CRC32), which is calculated and checked, whenever

and each time the SmartCamera software starts. In

case of a mismatch the software stops and does refuse

operation effectively. The same mechanism is imple-

mented for the software on the host, which is intended

to be used for the verification of the digital signature

with the appropriate public key.

During the homologation process the complete data

of the internal storage device is compared bit by bit

with an accepted master device on CD-ROM by a

notified body. This check includes executables, scripts,

directory structure, settings, permissions, user accounts

and configuration data. The result of this homologated

procedure is a unified checksum which is calculated at

the end of the procedure. This checksum may be recal-

culated and verified at any time.

4.3. Common procedures to provide secure primary

evidence

The evidence data is protected against unrecognised

falsification by a digital signature which is added to

each file.

If the measured speed exceeds the specified limit the

camera is triggered and an image is captured, at first in

RAM. All data related to the incident (measured speed,

image(s), time, date, etc.) are to be combined in a single

file with a proprietary format. Each trigger will create at

least one individual file. Cyclic redundancy checksums

(CRC32) are calculated over all image data and the

measurement data. They are stored together within a

single incident file. After this procedure the digital

signature is calculated and added to the file.

The complete file can be encrypted optionally with

the RC4 algorithm.

The digital signature is based on RSA, an asym-

metric encryption algorithm. This requires a random

asymmetric key pair that is generated inside the cam-

era using a random seed. Each key pair consists of a

secret and a public key. The secret key always remains

inside the SmartCamera and is used to sign and

encrypt.

For each digitally documented offence a message

digest (MD5 hash) is calculated over all the data. The

digest is encrypted with the secret key inside the

SmartCamera and appended to the data. The result of

all these calculations is the message digest; it is called

the digital signature. It is included optionally in the

incident container file and acts as a fingerprint or

watermark for each individual case. The homologation

regulations in Germany and other countries require

this security feature of the ROBOT SmartCamera to

be engaged mandatory. The public key – that is nec-

essary for verifying the signature and for decryption in

the office – can be retrieved from the camera.

Incident container files can be read by a custom

software application. With this tool any manipulation

since creation of the file can be detected safely, i.e. the

CRC32 checksums are checked as well as the digital

signature is verified with the appropriate public key

from the SmartCamera source. This way, any change

of even a single bit can be reliably detected and the

authenticity of the original data can be proven.

Any key management is extremely simplified be-

cause each camera acts as its own key server and does

by default require no external key management IT

infrastructure, e.g. PKI.

This approach is widely accepted by various ho-

mologation authorities, the software implementation

itself has been verified in detail.

5. Functional tests

A key issue of a digital imaging system to be used

for traffic enforcement is the correct assignment of the

speed measured by the sensor to the image captured


by the camera. This task seems to be relatively easy

but problems may arise when many vehicles in a

multilane situation have to be detected. Due to the

complex communication between the components of

the system a corruption of data arises as a possible

problem in practice.

To ensure the correct function of the digital imag-

ing system a combination of specific tests is required

for the type approval procedure. In a first step an

overall test is done in real traffic by comparing the

results of the device under test with those of a refer-

ence system that also measures the speed of the

passing cars and that documents the complete scenario

with a video system. These comparisons cover several

thousand vehicles, no single deviation exceeding the

error limits of 3 km/h (for a speed b100 km/h) or 3%

(for a speed N100 km/h) is allowed. The vehicle

parameters assumedly relevant for the piezoelectric

sensors are in particular weight of the vehicle and

shape and hardness of the tires. The complete range

of all these parameters is covered by the comparisons.

The comparisons are therefore the essential test for the

correctness of the speed measuring function.

The reference system of PTB, however, is not

applicable to dense traffic. Therefore dense traffic is

simulated extensively. For this purpose the signals of

all sensors in two lanes are simulated using signal

generators delivering analogue signals with specified

shape and time delays. The time delays have been

specified fitting to the simulated speed and gap of the

vehicles. No malfunction of the digital imaging sys-

tem was found.

6. Software verification

In the following the most important parts of the

software evaluation in the framework of the type ap-

proval performed at PTB are described. It is required

(see Chapter 3.3) that no unauthorised person is able

to manipulate the software of the measuring system

i.e. neither the programmes of the digital camera nor

the data stored or transmitted. In Chapter 6.1 the

securing means needed to meet this requirement and

their verification are discussed (requirements Chapter

3.3(c)–(g)). In Chapter 6.2 the examination of the

implementation of cryptographic algorithms is ex-

plained (Chapter 3.3(h)–(k)).

6.1. Securing against manipulations and fraudulent

use

The SmartCamera presented in Chapters 2 and 4

has a UNIX-based operating system. Even a standard

installation of this multi-user operating system offers a

quite good security against manipulation by users.

However, in the application discussed here, additional

measures have been taken by the manufacturer of the

camera to reach a sufficient level of protection. The

most important is that all crucial security features have

been assigned to the role of the badministratorQ of theoperating system. The role of the administrator can

only be activated if two conditions are fulfilled: the

correct password is known and a keyboard is con-

nected to an internal interface (therefore protected by

sealing). The role of the administrator is never activat-

ed in normal use. The administrator password is cho-

sen by an authorised person (verification officer) when

the measuring system is legally verified. To avoid

careful housekeeping of passwords the authorised per-

son writes the password on a sheet of paper and puts it

into an envelope that is sealed and put into the housing

of the instrument afterwards. By this combination of

conventional mechanical sealing and utilisation of the

mature protection measures of the operating system, a

sufficient security level could be reached.

Though the UNIX derivative used is rather lean,

nevertheless great effort was required to establish a

really secure configuration of the operating system –

which was the task of the manufacturer – and on the

other hand to verify this configuration during exami-

nation. The main examination steps were:

o checking the boot sequence

o checking the correctness of initialisation scripts and

configuration files by code inspection

o verification that all crucial parameters, configura-

tions, and scripts have the correct permissions i.e.

only the badministratorQ is able to write and exe-

cute files

o selection in co-operation with the manufacturer

which parameters could be accessed by users with-

out having permissions of an administrator e.g. for

controlling certain functions of the camera

o examine the implemented procedures that check

automatically the configuration during use and

make evident each change of the software


The configuration found to be secure was fixed and

compiled to a bdump imageQ at PTB. This dump

image serves as a reference for the second step in

the legal procedure: i.e. each specimen of the Smart-

Camera in the field gets an identical copy of the dump

image containing all configuration data etc. By a

specific procedure an authorised person can easily

supervise or verify the complete software including

the configuration.

6.2. Correctness of the implementation of crypto-

graphic algorithms

The software examination of the cryptographic

functions included two main test steps: the test of the

functions themselves, and the examination of their

calling conditions.

The first test step was the test of the cryptographic

functions themselves. The aim of this step was to

answer the following questions: Does the manufactur-

er use a recommended cryptographic algorithm (by

NIST, BSI etc.)? Does the implementation fully cor-

respond to this algorithm? If not, what are the devia-

tions and their consequences?

Since cryptographic algorithms nowadays are

broadly discussed and evaluated in the cryptographic

community, one may consider these public standard

algorithms working and secure. Each deviation made

by a non-specialist and not being evaluated by the

crypto community must be considered insecure. This

would also apply to small changes made by a software

engineer to improve e.g. time behaviour. The software

tests had to show the absence of such intended devia-

tions (bimprovementsQ) made by the manufacturer,

and of course also the absence of software bugs

(unintended deviations from specification).

In case of the SmartCamera software, the manufac-

turer used the well-known RSA algorithm combined

withMD5 as hashing function. The algorithms are pub-

lished in standards, technical papers, and lecture notes.

The software tests began with a short check of all

specifications for consistency. Then they were com-

pared to implementation path by path, condition by

condition, and assignment by assignment. The func-

tions for long-term arithmetic were checked by dy-

namic function black-box tests. After that the

implementation was checked for additional software

security means, e.g. for checks of pointers being not

null pointers, or for checks of divisors being not zero.

As a result of this test step the code was improved.

The second test step of the examination of the

cryptographic functions was the check of the calling

conditions, the so-called bcontextQ. The aim of this

test step was to answer the following questions: Are

the cryptographic functions really in use when the

camera is switched on? May a user or a system switch

off the functions under certain conditions? Are there

unsupported or unknown interfaces to the software?

The answers were found performing a detailed code

inspection of the camera software. Especially, each

control path between programme entry point and the

calls of the cryptographic functions was recorded and

checked for conditions. These conditions (path predi-

cates) were analysed. It was found, that the calls of the

cryptographic functions were strongly dependent on

half a dozen out of some 130 programme options.

These programme options allow the remote control of

the camera after installation. The programme options

are stored in a license file (license options) and a

configuration file (config options) on the internal disk

of the camera. The camera software reads these files at

programme start and maintains a copy of all options in

its working memory during run time. Both, the files on

the camera disk, and the copy of the options in the

working memory, may be changed any time by remote

access.

As some of these options turned out to be essential

for cryptographic functions, the software tests had to

show, that these essential options are excluded from

remote changes.

It was found, that no user and no system is able to

switch the cryptographic functions off as long as the

camera itself (and its seal) stays intact.

7. Outlook

The vision of a digital imaging system as illustrated

in Fig. 1 is discussed since the first digital cameras

came to the consumer market. The advantages of such a

technique are easy to understand, especially for sys-

tems permanently installed. It has taken, however,

more than a decade to bring this vision to reality. One

of the many obstacles was the optical performance of

the first cameras. In particular the limited resolution of

the images did not allow to identify the number plate


and the driver what is necessary at least in Germany.

Another obstacle was the question of an appropriate

securing of the data and the corresponding proof nec-

essary for type approval. This topic has been described

in detail in this paper. We expect that digital cameras

very soon will be the first choice for nearly every user

of traffic enforcement systems. In the future we even

expect that the data are transferred securely via radio

communication.

Frank Jager has studied physics at the

Technical University in Braunschweig and

got his Ph.D. in 1991. Since then he is

working at PTB in the field of type approval

for many speed enforcement systems – now

using digital cameras – in Germany. He was

work package leader of the EC funded proj-

ect VERA, a cooperation with several repre-

sentatives of European type approval

authorities.

Ulrich Grottker, has studied communica-

tions engineering at the Technical Univer-

sity of Braunschweig. His doctor thesis

dealt with traffic safety. At PTB he was

engaged with developing IT systems suit-

able for legal metrology and concepts for

requirements on national and European

level in legal metrology. He is head of the

PTB working group that is responsible for

software examination in legal metrology.

Heike Schrepf received a master degree in

physics at Technical University of Magde-

burg. After working a couple of years as a

physicist, she changed to information tech-

nology. She joined PTB in 1991, the Ger-

man National Metrology Institute, and is

working since that time as a software engi-

neer in the software testing laboratory of

PTB.

Wolfgang Guse studied communications

engineering at the RWTH Aachen. He re-

ceived his Ph.D. in 1992 in the area of

object oriented image coding. Until 1995

he was with the development department of

BOSCH. He worked on the MPEG2 speci-

fications, the transmission of digital video

via terrestrial and cable networks and the

necessary multiplexing techniques. Since

April 1995 he is with the company

ROBOT Visual Systems GmbH. He is re-

sponsible for a technical department. His tasks are the development

of traffic surveillance products.

Protection of image and measurement data in an open network for traffic enforcement

Documents

Transcript of Protection of image and measurement data in an open network for traffic enforcement