Kumiko Tadano

Masahiro Kawato

Ryo Furukawa

Fumio Machida

Yoshiharu Maeno

Digital Watermarking of Virtual Machine Images

Keywords:

Introduction

In modern enterprise computing there is a growing trend toward consolidating virtual machines (VMs) in the server and client sides to reduce costs and enhance portability and security. Such environments require the means to export VM images to test software and to backup VMs. For example, Amazon's Elastic Compute Cloud [START_REF]Amazon Web Services, Amazon Elastic Compute Cloud[END_REF] and Simple Storage Service [START_REF]Amazon Simple Storage Service[END_REF] provide the command ec2-download-bundle to download VM images from a data center to local computers [START_REF]Amazon Web Services, ec2-download-bundle[END_REF]. Unfortunately, this technology also facilitates the unauthorized dissemination of VM images containing proprietary software.

One approach for addressing this issue is to use host-based intrusion detection systems such as TripWire, AIDE and XenFIT [START_REF] Quynh | A novel approach for a file-system integrity monitor tool for a Xen virtual machine[END_REF]. These systems monitor unauthorized file system changes to detect malicious activity involving VMs. However, it is difficult to identify VM images after they have been distributed outside of an enterprise network (e.g., using peer-to-peer file sharing software).

Another approach is to implement strict access control and copy control of VM images. However, these controls often hinder the legitimate use of VMs.

Therefore, it is necessary to address two issues: (i) identify VM images even after they have been illegally distributed; and (ii) facilitate legitimate use of VM images. Digital watermarking of VM images can address both these issues. However, as we discuss below, watermarking techniques used for audio and video files are not applicable to VM images.

Digital watermarking technologies typically modify redundant or unused digital content (e.g., inaudible frequency ranges for audio files) to embed watermarks. In the case of audio and video files, modifying the original information for digital watermarking produces imperceptible effects when playing the files [START_REF] Perez-Gonzalez | A tutorial on digital watermarking[END_REF]. In contrast, modifying a VM image can cause boot failures when the watermarked image is executed. Additionally, data on the watermarked VM is frequently changed because of software updates, logging, etc. Unlike an audio or video file whose content is unchanged, a VM image is essentially variable; consequently, in order to identify the VM image, the image has to be watermarked after every change.

Data hiding techniques [START_REF] Eckstein | Data hiding in journaling file systems[END_REF] can be employed for watermarking VM images. Data can be hidden in various locations: Areas marked as not in use by the partition table .   Extended file attributes such as alternate data streams.

Unused portions of the last data units of files (slack space).

Reserved i-nodes that are not used by the operating system.

Portions that are excluded during consistency checking of a journaling file system.

Files hidden via steganography using special file system drivers [START_REF] Mcdonald | StegFS: A steganographic file system for Linux[END_REF].

A major deficiency of existing data hiding techniques is the lack of platform-independence: the techniques work on specific file systems (e.g., NTFS), operating systems (e.g., Red Hat Linux) and OS kernel versions (e.g., Linux 2.2.x). It is difficult, if not impossible, to apply these techniques to VMs in heterogeneous environments where multiple file systems, operating systems and OS kernel versions are used.

To address this issue, we propose a digital watermarking scheme for VM images that is independent of file systems, file formats, operating systems, OS kernel versions and hardware. The scheme embeds a watermark derived from the names of the files present in a VM.

Basic Concepts

Our digital watermarking scheme for VM images uses file names as a watermark, not the contents of the files. A unique identifier is created for each VM image and a watermark corresponding to the identifier is embedded in the form of files in the file system of the VM image. These embedded files are called "watermark fragment files."

If the names of the watermark fragment files are randomly created, they would be readily distinguishable from the names of the pre-existing files on the VM, enabling an attacker to identify and subsequently remove the watermark fragment files. Thus, the watermarking scheme makes the fragment files difficult to detect by creating fragment files with names that are similar to pre-existing files in the VM and embedding the files in random directories in the VM. A secure database is used to store the identifier of each VM image and the corresponding watermark fragment files.

Design and Implementation

This section describes the design and implementation of the digital watermarking scheme.

System Components

The system has three components: (i) a watermark generator; (ii) a watermark detector; and (iii) a watermark information database. Figure 1 illustrates the watermark generation and detection processes.

Watermark Generator: The watermark generator employs the names of the watermark fragment files as the watermark for a VM image. It creates a watermarked VM image by embedding the watermark fragment files in the VM image and stores the generated file names in the watermark information database. The VM image to be watermarked is created by copying the template VM image file. Since the template VM images are used as the original data for watermarking, these images should be securely managed. The reason is that an attacker who obtains the VM image template Watermark Information Database: The watermark information database (WI-DB) stores the identifier of each VM image and its attributes. The identifier for a VM image is a universally unique identifier (UUID). The attributes include the names of the watermark fragment files, VM owner, etc. (Figure 2).

Only authorized users should be permitted to read and write WI-DB records. An attacker with read/write access could alter WI-DB records or identify and delete the watermark fragment files embedded in a VM image.

Watermark Detector: The watermark detector identifies a VM using the watermark fragment files embedded in the target VM image based on WI-DB records. When an unauthorized leak of a VM image is suspected, the administrator may perform the detection process to identify the VM image and its owner.

Watermark Generation Algorithm

This section briefly describes the process of generating the watermark fragment files for the target VM image. The algorithm has five steps.

Step 1: Input the parameters required for watermark generation.

Step 2: Number the directories in the target VM image in dictionary order.

Step 3: Select the directories to embed watermark fragment files.

Step 4: Generate the names of the watermark fragment files to be created.

Step 5: Generate the contents of the watermark fragment files for the directories selected in Step 3. Excluded Directories: Some directories (e.g., temporary directories) should be excluded because files in these directories change frequently.

Excluded Suffixes: These are suffixes that should be excluded from the names of the watermark fragment files.

Bit Length: The bit length is a parameter used by the Blum-Blum-Shub (BBS) algorithm [START_REF] Blum | Comparison of two pseudorandom number generators[END_REF] to generate cryptographically-secure pseudo-random numbers. This parameter affects the computational time and security, and is set to 1024 bits in our experiments.

Step 2 (Number the Directories in the Target VM Image):

The watermark generator searches all the directories in the target VM image recursively and generates a "directory code list" (Table 1). The excluded directories identified in Step 1 are not numbered. The directory code of a template VM image can be reused when new watermarked VM images are created from the same template VM image because they have the same directory tree structure. This reduces the processing time.

Step 3 (Select Directories to Embed Watermark Fragment Files): The watermark generator produces pseudo-random numbers for the watermark fragment files input in Step 1. The values of the random numbers are limited to the range of directory codes. The watermark generator extracts the names of directories corresponding to the generated random numbers using the directory code list generated in Step 2. The BBS pseudo-random number generation algorithm is used to make the random numbers difficult for an attacker to predict. Although this algorithm is computationally intensive, the experimental results presented in Section 4.2 indicate that the overall performance of the watermarking scheme is acceptable.

Step 4 (Generate the Names of Watermark Fragment Files):

The watermark generator creates the names of the watermark fragment files that are embedded in the directories selected in Step 3. Portions of the names of pre-existing files in the directories are modified to create file names that are similar to those of the pre-existing files. A file name is generated according to the following steps.

Step 4.1: Get the names of existing files in the target directory. Only regular files (not subdirectories, hidden files, etc.) whose suffixes are not to be excluded are retrieved.

Step 4.2: Enumerate all the substrings corresponding to the file names. Each substring is obtained from the head (i.e., not including the suffix) of a file name retrieved in Step 4.1. The result of this step is the union of substrings for all the file names. For example, if the target directory has a file named abc.txt, the possible substrings are: abc, ab and a.

Step 4.3: Compute "similarity groups" for each extracted substring. A similarity group is a group of files in the target directory that meets the following conditions: (i) the file name starts with the substring (prefix) generated in Step 4.2; (ii) all the files have the common suffix (e.g., .txt); and (iii) a similarity group contains at least two files. For example, if there are five files in a target directory {s1.txt, s2.txt, s3.dat, s4.dat, s5.conf} and s is the substring, then two similarity groups can be computed: {s1.txt, s2.txt} and {s3.dat, s4.dat}.

Step 4.4: Compute the D sim score for each similarity group:

D sim = c 1 * l p + c 2 * n f -c 3 * l d
where l p is the length of the prefix of the similarity group; n f is the number of files in the similarity group; l d is the mean value of the difference between the length of the file name (excluding the suffix) and l p in the similarity group; and c 1 , c 2 , c 3 are parameters that are set to one. The similarity group with the highest D sim score is called the "prototype file group."

Step 4.5: Create the name of the new watermark fragment file. One or more random letters are added to the tail of the prefix of the selected prototype file group. The length of the added letters (l t ) is the length of the file name randomly selected from the prototype file group (excluding the suffix and prefix). Finally, the suffix of the files in the prototype file group is added to the file name. For example, if the prefix is sample and the prototype file group is {sample.dat, sample-bak.dat} and if sample-bak.dat is selected, then l t = 4 and a possible name is sampledbha.dat.

Step 5 (Generate the Content of the Watermark Fragment Files): The watermark generator creates the content and attributes corresponding to each watermark fragment file. The content of a watermark fragment file is a randomly-generated byte sequence. Attributes of a watermark fragment file are determined according to the following rules. For timestamps (creation/modification/access) and file size, the watermark generator assigns the mean values of the files in the prototype file group to the new watermark fragment file. For other attributes such as ownership and permission, the values corresponding to a randomly selected file in the prototype file group are used.

Implementation

The digital watermarking scheme was implemented in Java 1.5. The VMware Server virtualization software was employed. The command vmware-mount.pl was issued to the VMware Server to mount the file system on the VM image for embedding watermark fragment files. The VM image of any file system or operating system, including Windows and Linux, can be watermarked. The WI-DB was implemented using MySQL 5.0.

Experimental Setup and Results

This section describes the experimental setup used to evaluate the watermarking algorithm. Also, it presents the experimental results related to watermark generation and detection.

Experimental Setup

A test environment was created to evaluate the performance of the watermarking scheme. The environment included one physical host (Ta-

Experimental Results

This section presents our experimental results related to watermark generation and detection.

Watermark Generation

The VM image templates of Ubuntu and CentOS were copied and a total of 10 and 100 watermark fragment files were embedded in the two VM images. Each experiment was repeated 10 times and the average turnaround times were calculated. copying is essentially independent of the size of the template VM image. The turnaround times drop when faster storage devices are employed.

Table 4 lists the generated watermark fragment files. The file names snd-usb-INc.ko and hso.shared are relatively difficult to distinguish from the pre-existing files in the target directories. In contrast, file names such as kQGidyI are easily distinguishable. In general, when there are many files in the target directory whose names have common extensions and long common substrings, the generated file name(s) tend to be indistinguishable. For example, the file snd-usb-INc.ko belongs to /lib/modules/2.6.24-16-virtual/kernel/sound/usb/ whose pre-existing files are snd-usb-audio.ko and snd-usb-lib.ko. Meanwhile, if only a few file names have common substrings/extensions in the target directory, the generated file name(s) tend to be contrived.

Watermark Detection

Watermark detection experiments were conducted to identify 10 and 100 watermark fragment files from the watermarked Ubuntu 8.04 and CentOS 5.1 VM images. Table 5 presents the average turnaround times for watermark detection based on ten repetitions. The results indicate that the time taken to detect the watermark is almost independent of the size of the watermarked VM image and the number of watermark fragment files.

Conclusions

The digital watermarking scheme for VM images is independent of file systems, file formats, operating systems, kernel versions and hardware. Also, experiments demonstrate that watermark generation and detection are both fast and effective.

Our future work will focus on enhancing the tamper-resistant characteristics of the watermarking scheme. Several attacks could be devised to remove or modify VM image watermarks. For example, watermarks could be detected using a machine learning algorithm such text clustering [START_REF] Segaran | Programming Collective Intelligence: Building Smart Web 2.0 Applications[END_REF] to discriminate embedded files from pre-existing files based on file name string features. Another attack could use information from elsewhere in the VM such as the i-node numbers of files. Files installed at a given time are assigned successive i-node numbers; a file with an i-node number that is out of sequence could correspond to an embedded file. Other problems to be investigated include having the contents of embedded files resemble those of pre-existing files, and augmenting the scheme with other data hiding approaches to enhance tamper resistance. Finally, our research will investigate the application of the watermarking scheme to other digital content such as tar and zip archives.

Figure 2 .

 2 Figure 2. Sample records in the watermark information database.

Figure 3 .

 3 Figure 3. Watermark detection.

Figure 3

 3 Figure3illustrates the detection process. If the identifier of the target VM can be guessed, the watermark generator looks up the corresponding WI-DB record. Otherwise, the watermark detector compares the watermark fragment file names in WI-DB records with those in the target VM image. The watermark generator then outputs a certainty value of the identifier of the target VM image. The certainty value is computed as the percentage of the names of the watermark fragment files in the WI-DB record that match file names in the VM image. Note that some watermark fragment files may have been deleted or renamed on purpose or by accident.

  Watermark generation and detection.would be able to compute the watermark fragment files as the difference between the template VM image and the watermarked VM image files. Details of the watermark generation algorithm are presented in Section 3.2.

	Watermark Generation			Watermark Detection
	VM Image	Watermark	Watermarked	Watermark	Identifier
	Template	Generator	VM Image	Detector
						Certainty
	Watermark Information			Watermark Information
	Database			Database
	Figure 1. Watermarked VM Image Watermark Fragment Files
		/etc/yum/aaa.conf /var/log/dummy.log		ID: 5ac8183d-e2cb-4ad2-a185-5c3beb0c17b8
	Watermark Information Database Table
	ID		VM Name	Owner	Watermark Fragment Files
	5ac8183d-e2cb-4ad2-	foo-	foo	/etc/yum/aaa.conf,
	a185-5c3beb0c17b8	desktop		/var/log/dummy.log
	42be8a40-5e6d-4677-	bar-	bar	/usr/local/bin/cmd,
	84fb-e387f5638264	desktop		/etc/dummy.conf
	…		…	…	…

Directory Tree on VM 1. Obtain the names of the Watermark Fragment Files 2. Search the files in the VM Image

	Target VM Image	/var/
		/etc/
		/usr/
		/home/
	ID: unknown	/bin/
		…
	Watermark Information Database Table
	ID	VM Name	Owner	Watermark Fragment Files
	5ac8183d-e2cb-4ad2-	foo-desktop foo	/etc/yum/aaa.conf,
	a185-5c3beb0c17b8			/var/log/dummy.log
	42be8a40-5e6d-4677-	bar-desktop bar	/usr/local/bin/cmd,
	84fb-e387f5638264			/etc/dummy.conf
	…	…	…	…

Table 1 .

 1 Directory code list.Number of Watermark Fragment Files:The larger the number of watermark fragment files, the more tamper-resistant is the watermark. However, this increases the time required to generate watermark fragment files.

	Number Directory Name
	1	/
	2	/etc/
	3	/etc/init.d/
	4	/etc/ldap/
	5	/etc/skel/
	6	/etc/ssh/
	7	/etc/sysconfig/
	...	...
	Step 1 (Input Parameters for Watermark Generation): The
	following input parameters are required for watermark generation:

Table 2 .

 2 Test environment. Two template VM images of different sizes were used to clarify the impact of size on the watermarking scheme. The VM images used were an Ubuntu Linux 8.04 Server JeOS edition (minimum configuration for virtual appliances) and a default installation of CentOS 5.1.

		Physical Host
	CPU	Pentium 4 1.73 GHz Processor
	Memory	1 GB RAM
	Host OS	Ubuntu Linux 8.04 Server
	VMM	VMware Server 2.0
		Guest VMs
	Guest OS	Ubuntu Linux 8.04	CentOS 5.1
		(JeOS edition)	(default)
	VM Image Size 183 MB	2,750 MB
	(.vmdk file)
	Directories	1,120	7,429
	ble 2).

Table 3 .

 3 Turnaround times for watermark generation.

		Av. Generation Time (sec) Av. Copying
		10 Files	100 Files	Time (sec)
	Ubuntu Linux 8.04	13.121	24.001	6.903
	CentOS 5.1	168.382	177.270	142.284

Table 3

 3 presents the turnaround times for copying VM images and generating watermarks. The experiments used previously-created directory codes of template VM images because the codes are generated only the first time that the template VM images are used. The results indicate that the time for watermark generation excluding the time for

Table 4 .

 4 Generated watermark fragment files.

	File Names
	/usr/share/zoneinfo/Pacific/kQGidyI
	/etc/console-tools/v2uQizvontwL8
	/lib/modules/2.6.24-16-virtual/kernel/sound/usb/snd-usb-INc.ko
	/usr/lib/klibc/bin/hso.shared
	/usr/lib/perl/5.8.8/IO/Socket/vS9jkE.pm
	/usr/lib/python2.5/wsgiref/hG272nT.pyc
	/usr/share/debconf/jAGX7mQ.sh
	/usr/share/zoneinfo/Mexico/irQ7KA
	/usr/share/zoneinfo/posix/Chile/5XwjA

Table 5 .

 5 Turnaround times for watermark detection.

		Av. Detection Time (sec)
		10 Files	100 Files
	Ubuntu Linux 8.04	7.524	7.549
	CentOS 5.1	7.526	7.573


Mark Pollitt

A HISTORY OF DIGITAL FORENSICS

Keywords:

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

One of the important rules in public speaking is to never begin with an apology. I have often broken this rule when delivering speeches and will do so again in this paper. My audience for this paper will befor the most part -scientists, who expect well-documented foundations, reliable data and rigorous logic. Hence, my apology: there is little, if any, of these things in this paper.

It would be tempting to frame this exploration as historical research. And while I have done some research, which is duly referenced, this is fundamentally a personal history, which I have lived since the early 1980s. I am biased and less than fully informed; I have an unreliable memory and selective recall. Those of us who worked in this field from the beginning gave little thought to documenting a history. We were just trying to do our jobs.

So why should anyone read this paper? There are several reasons. For those who currently work in digital forensics and the students who are just entering the field, it is important to understand how we got here. During my tenure as a criminal investigator, one of my wisest informants insisted on teaching me the history of Baltimore, its ways and its people. He said, very correctly, that if I did not understand how people got where they did, I would not understand what they were doing now, what they might do in the future and why.

To those of us who have an interest in history, especially related to cyber crime and digital forensics, this paper is merely a starting point with many gaps that have to be filled. In some small measure, I hope this paper will serve as motivation to correct and expand the history as well as begin a dialog about the field, its past and its future. We must not delay -digital forensics is almost three decades old and many of the original players are moving on.

Epochs and Lenses

Even the simplest history has to have at least three phases: before, during and after. It may be called something more prosaic, but there is an inherent need for logical structure, even in something as illogical as history. For this story, I have chosen to use the notion of "epochs." It is, of course, entirely arbitrary on my part but it has both factual and logical bases. The epochs are: pre-history, infancy, childhood and adolescence.

Like traditional history, it is useful to explore a time period using a particular perspective. These are often called "lenses," as a metaphorical attempt to focus both the writer and the reader on specific elements of the historical data. In reviewing the history of digital forensics, I realized that there were some critical elements that combined to create the discipline. In my view these are: people, targets, tools, organizations and the community as a whole. I make no assertions that they constitute the totality of the history, but they are key vectors that help capture the essential elements of the history.

Modern electronic computers evolved during the second half of the 1900s. The History of Computing Project defines 1947 as the beginning of the Industrial Era of Computing [START_REF]The History of Computing Project, Timeline: Chronology of the history of computing, The History of Computing Foundation[END_REF] and we are still in the midst of this era. So much has happened in computing since 1947 that it is helpful to break it down into manageable chunks. In particular, digital forensics -or forensic computing as some like to call it -has a shorter history. As a result, I choose to make some further arbitrary divisions based on events that were significant to the digital forensic community.

Pre-History

The first epoch, which I label as pre-history, covers the period prior to 1985. It is not surprising that this is the least documented epoch because much of what happened was not focused on digital forensics. In fact, the term simply did not exist. From the 1960s until the early 1980s, computers were primarily an industrial appliance, owned and operated by corporations, universities, research centers and government agencies. They required a large physical infrastructure, including massive amounts of power and air conditioning, and highly skilled, dedicated staff. Their function was largely data processing. It is in this role that computers first became of interest to the information security, legal and law enforcement communities. Donn Parker's 1976 book, Crime by Computer, is perhaps the first description of the use of digital information to investigate and prosecute crimes committed with the assistance of a computer. System administrators were, for the most part, responsible for the security of their own systems, most of which were not significantly networked to the outside world. System audits were designed to ensure the efficiency and accuracy of data processing, which was very expensive at the time. In effect, these audits constituted the first systematic approach to computer security. A byproduct of these efforts was that information collected during audits could be used to investigate wrongdoing [START_REF] Parker | Crime by Computer[END_REF]. This was not totally lost on the law enforcement community.

Organizations such as the Department of Defense, Internal Revenue Service (IRS) and Federal Bureau of Investigation (FBI) created ad hoc groups of volunteer law enforcement agents, who were provided with rudimentary mainframe and mini-computer training. These computertrained investigators would assist other case investigators in obtaining information (primarily) from mainframe computers -stored data and access logs. Usually, the computer-trained investigators would work in cooperation with systems administrators. Cliff Stoll's 1990 book, The Cuckoo's Egg [START_REF] Stoll | The Cuckoo's Egg: Tracking a Spy Through the Maze of Computer Espionage[END_REF], captures the practice and the ethos of early digital forensics. It also highlights the reluctance of government agencies to engage in this new area. It was difficult for traditional managers and investigators to grasp the potential of computers to be both tools and victims of crime. Stoll, then a Unix systems administrator, was attempting to reconcile two system accounting programs that were reporting a small difference in usage. After much investigation, he realized that hackers were accessing a large number of computers, including some sensitive systems. Using system administration tools and considerable experimentation, he developed, on his own initiative, a method for recording the hackers' malicious activities in real time.

Ad hoc and individual are the defining characteristics of the first epoch. There were virtually no dedicated organizations, procedures, training or tools specifically designed for digital forensics. Operating system tools and utilities were utilized along with traditional scientific and investigative problem-solving approaches.

4.

Infancy (1985)(1986)(1987)(1988)(1989)(1990)(1991)(1992)(1993)(1994)(1995) The advent of the IBM PC in the early 1980s resulted in an explosion of computer hobbyists. The PCs, while powerful, had relatively few applications and were not, despite the advertising copy, user-friendly. Many of these hobbyists had previously worked with Commodore 64s, Radio Shack TRS-80s and Ataris. These early computers enabled hobbyists to write program code and access the internals of the operating systems and hardware. These skills were channeled to the new IBM PCs and PC-compatible computers.

Among the hobbyists were law enforcement personnel from a wide variety of organizations. Some of the key individuals were Mike Anderson, Danny Mares and Andy Fried from the IRS; Ron Peters and Jack Lewis from the U.S. Secret Service; Jim Christy and Karen Matthews from the Department of Defense; Tom Seipert, Roland Lascola and Sandy Mapstone from local U.S. law enforcement agencies; and the Canadians, Gord Hama and Steve Choy. Many of them became charter members of the first organization (to my knowledge) dedicated to digital forensics -the International Association of Computer Investigative Specialists (IACIS).

There were many other individuals as well. What they all shared was an understanding that computers would play a critical role in criminal investigations and, specifically, that computers are important sources of evidence. All these individuals believed this to the extent that they spent much of their own time and money to learn about new computing technologies. Their agencies were not supportive of their efforts, but we owe these individuals a debt of gratitude for the personal and financial investments that they made. Without their inspired and timely efforts, much of what we do today in the discipline of digital forensics would not be possible.

The early efforts were by no means limited to North America. Law enforcement officials in Europe, Asia and Oceania were struggling with the same problems and making the same personal commitment to prepare themselves and their organizations for the future that they knew was coming. In 1993, the FBI hosted the First International Conference on Computer Evidence at the FBI Academy in Quantico, Virginia, which was attended by representatives from 26 countries. At this conference, it was agreed that the community needed to band together at the agency level to coordinate efforts, share experience and provide assistance to each other. In 1995, the second conference was held in Baltimore and the International Organization on Computer Evidence (IOCE) was founded [START_REF] Whitcomb | A historical perspective of digital evidence[END_REF].

The cases investigated by these pioneers were very basic by today's standards. Much of the focus was on recovering data from standalone computers. Data recovery was a major issue because storage was costly and users routinely deleted data and re-formatted media. The Internet was not yet popular, but criminals were using dial-up access to compromise computers.

The use of inexpensive computers to hack the telephone system was a new dimension of fraud. Telephone service was billed by distance and use. Criminals and adolescents found that by hacking telephone networks they could obtain "free" telephone service as well as previously unavailable levels of anonymity [START_REF] Hafner | Cyberpunk: Outlaws and Hackers on the Computer Frontier[END_REF].

The subjects of computer crime investigations were generally traditional criminals who used computers to support their activities or young people who used their technical skills to illegally obtain computer access and software. While IBM PCs and PC-compatible computers running DOS and early Windows variants were the most commonly encountered devices, early Apple products as well as Commodore and Atari computers were often encountered.

The tools used by the pioneering investigators included home-grown, command line tools and commercial products adapted to forensic use. Andy Fried's IRS Utilities, Steve Mare's Maresware, Steve Choy's IACIS Utilities and Gord Hama's RCMP Utilities were all command line tools that were distributed within the law enforcement community. Each of these tools tended to solve a specific digital forensic problem, such as imaging or identifying deleted files. Some of the later variants, like Hama's REDX, allowed for multiple operations and rudimentary piping. Norton Utilities and PC Tools, both commercial products designed for data recovery and file management, proved to be very powerful tools for digital forensics and virtually all the forensic training during the epoch utilized one or both of these tools. Another noteworthy product of this period was SafeBack, which was created by Chuck Guzis in 1991 to acquire forensic images of evidence. SafeBack may well have been the first commercial digital forensic product.

During this epoch, digital forensic practitioners conducted their examinations wherever they could find space. Often it was at their desks, in their basements at home or in unused storage space. The notion of a purpose-built laboratory was years away. Even large law enforcement agencies had hardly any funds for equipment -examiners had to use surplus equipment or the very equipment that they seized.

At the time, digital forensics was an arcane area that operated in direct conflict with the geographically-and statutorily-bound practice of criminal investigations. Criminals operated across city, state and national boundaries in almost real time, but investigators had no choice but to communicate and work directly with their peers, wherever they were located.

Digital forensic practice also operated in direct conflict with the traditional, laboratory-based practice of forensic science. However, some agencies did see the need for digital forensic capability. The IRS created the Seized Computer Evidence Recovery Specialist (SCERS) Program, the U.S. Secret Service its Electronic Crimes Special Agent Program (ECSAP), the FBI its Computer Analysis Response Team (CART), and the U.S. Air Force Office of Special Investigations its Computer Crime Investigator (CCI) Program and what eventually became the Defense Computer Forensic Laboratory (DCFL). Each agency adopted a different model of selection, training and operations based on its structure and culture. But these agencies were the exception; the majority of digital forensic investigations were performed by individual officers with minimal training, often using personal equipment, and without any supervision or formal quality control.

But the digital forensic community was growing. In addition to IACIS, many grassroots efforts were underway to pool knowledge, resources and talent. In the Midwestern United States, the Forensic Association of Computer Technologists (FACT) created training opportunities and a network of geographically-dispersed practitioners. In the Baltimore area, forensic practitioners from the FBI, U.S. Secret Service, Maryland State Police and Baltimore County Police started an ad hoc organization called "Geeks with Guns." In the United Kingdom, practitioners from many law enforcement agencies formed the Forensic Computing Group (FCG) under the auspices of the Association of Chief Police Officers (ACPO). It was during this epoch that the High Tech Crime Investigation Association was formed.

Forensic training was developed and offered by these organizations as well as by some of the larger law enforcement agencies. The demand for quality, affordable training far exceeded the availability, a situation that continued to plague the field of digital forensics for many years (some would argue that it continues to this day). During this period, the academic community was almost totally disinterested in the field, with two notable exceptions: Gene Spafford, from Purdue University and Dorothy Denning, then at Georgetown University. These two professors encouraged many law enforcement agents and students to venture into this important new field.

5.

Childhood (1995)(1996)(1997)(1998)(1999)(2000)(2001)(2002)(2003)(2004)(2005) The next decade proved to be one of tremendous growth in size and maturity. This growth had numerous drivers, but there were three that had the most significance.

The first driver was the explosion of technology that occurred during the epoch. Computers became ubiquitous, cell phones became essential and the Internet became the world's central nervous system. At the beginning of the epoch, most voice calls were via landline, most computer network connections were via dial-up and most people had not heard of the Internet. By the end of the epoch, almost everyone had an email address, a cell phone, relied on the Internet, and most homes and businesses had networks. Computer technology was embedded in virtually every element of daily life and that included criminal activities.

The second driver was the explosion of child pornography cases. This can be traced back to the George Stanley Burdynski, Jr. case in 1993. The investigation revealed that computers were used to traffic in illegal images of minors and led to the establishment of an online undercover operation called Innocent Images in 1995. Ten years later, there was a separate child pornography task force in half of all FBI offices; many other law enforcement agencies also operated their own task forces. This "new" violation resulted in the seizure of ever-increasing volumes of digital evidence and was a major driver in the growth of digital forensics [4,[START_REF] George | The Charley Project[END_REF].

The highly anticipated Y2K problem proved to be a non event from a computer perspective, but the events of September 11, 2001 rocked the digital forensic world, just as it did the world at large. While computers played little direct role in the hijackings, investigators would find bits and pieces of evidence on computers around the world. The terrorists were using computers in the same ubiquitous ways as everyone else. This was further reinforced on the battlefields of Iraq and Afghanistan. The intelligence community, law enforcement and the military realized that the lack of digital forensic capabilities was a blind spot that needed immediate attention. The amount of time, money, people and resources devoted to digital forensics increased to massive levels.

At the beginning of this epoch, digital forensic practitioners were typically self-declared professionals or "resident experts," a term used to describe individuals who were seemingly effective computer users. With increasing volume, technical sophistication and legal scrutiny, it became increasingly important to carefully select and train digital forensic practitioners. The field itself began to become even more specialized. Digital audio, video and embedded devices such as cell phones required specific knowledge and training, separate from traditional storage media and network-focused forensics. Even these two fields were beginning to diverge at some levels, as the study of network intrusions became ever more complex. The discipline of digital forensics began to be driven by government agencies and professional organizations rather than by individuals.

The formalization of digital forensics made great strides during this epoch. The IOCE, G-8 High Tech Crime Subcommittee and Scientific Working Group on Digital Evidence (SWGDE) all published digital forensic principles between 1999 and 2000 [START_REF] Downing | G-8 initiatives in high tech crime[END_REF][START_REF]International Organization on Computer Evidence, G8 Proposed Principles for the Procedures Relating to Digital Evidence[END_REF][START_REF] Noblett | Report of the Federal Bureau of Investigation on the development of forensic tools and examinations for data recovery from computer evidence[END_REF][START_REF]Scientific Working Group on Digital Evidence, Digital evidence: Standards and principles[END_REF]. Going beyond mere principles, the American Society of Crime Laboratory Directors -Laboratory Accreditation Board (ASCLD-LAB), in cooperation with the SWGDE, recognized digital evidence as a laboratory discipline. In 2004, the FBI's North Texas Regional Computer Forensic Laboratory became the first ASCLD-LAB accredited digital forensic laboratory [1,11].

Meanwhile, forensic tools underwent a metamorphosis. The homegrown, command line tools of the earlier epoch became complex, graphical user interface suites. The first of the new tools was Expert Witness, a product designed by Andy Rosen for Macintosh forensics that evolved into EnCase. EnCase, along with Forensic ToolKit (FTK), became commercial successes and are now standard forensic tools.

Several U.S. Government agencies also took on the task of developing tools. The FBI's Automated Case Examination System (ACES) and IRS's iLook tool had some success. However, the ability of commercial entities to evolve their products in step with advancing technology doomed the agency-developed tools to obsolescence. Meanwhile, the open source community stepped up, developing Linux tools such as Helix, Sleuth Kit and Autopsy Browser.

The digital forensic community likewise underwent a maturation process. Forensic services were being provided by a wide variety of entities, organized in a wide array of structures. Traditional forensic laboratories began offering digital examinations. The Department of Defense created its central Defense Computer Forensic Laboratory (DCFL) to service the law enforcement, intelligence and operational needs of the U.S. military [START_REF][END_REF]. The FBI started building a constellation of joint (federal, state and local law enforcement) laboratories dedicated to digital forensics -the Regional Computer Forensic Laboratories (RCFLs) [13]. Each laboratory would provide service to a geographic area and operate according to ASCLD-LAB standards. The U.S. Secret Service established a network of Electronic Crimes Task Forces, modeled on the highly-effective New York entity [START_REF]Secret Service, Electronic Crimes Task Forces and Working Groups[END_REF]. These task forces would provide investigative and forensic services within their area of operations. Many law enforcement agencies also developed dedicated units to handle digital forensic investigations.

6.

Adolescence (2005-2010)

Since 2005, digital forensics has grown in depth and breadth. It has far more practitioners, performing many more examinations of a wider variety, involving ever larger amounts of evidence. In 2006, the United States Courts adopted new Rules for Civil Procedure that defined digital information as a new form of evidence and implemented a mandatory system, called electronic discovery or "eDiscovery," for dealing with digital evidence [START_REF]Federal Judicial Center, Materials on Electronic Discovery: Civil Litigation[END_REF]. The workload in traditional law enforcement mushroomed. In Congressional testimony, the FBI announced that its Computer Analysis and Response Team (CART) examined more than 2.5 petabytes of evidence in 2007 alone [START_REF] Mason | Congressional Testimony, Statement before the House Judiciary Committee[END_REF].

Information security professionals now recognize digital forensics as a core skill area. While their objectives and needs often differ from those of law enforcement, the concepts and tools are often identical.

The digital evidence practitioners of today are far more likely to have had academic preparation in addition to formal training. They are likely to hold an array of certifications. Digital forensics is now considered "career enhancing," a far cry from just a few years ago.

Academic programs continue to spring up across the globe. While research funding for digital forensics lags other more traditional disciplines such as information security, colleges and universities have recognized the popularity and marketability of digital forensic education. Recently, the Forensic Education Program Accreditation Commission (FEPAC) took the first steps toward accrediting U.S. academic programs in digital forensics. The American Society of Testing Materials (ASTM) Technical Committee E-30 formulated a draft standard for digital forensic education and training programs [START_REF]ASTM E2678-09 Standard Guide for Education and Training in Computer Forensics[END_REF].

Another measure of the academic health of a field is the number and quality of conferences. The Digital Forensic Research Workshop (DFRWS) is in its tenth year. The International Federation for Information Processing (IFIP) Working Group 11.9 on Digital Forensics is in its seventh year and the International Conference on Systematic Approaches to Digital Forensic Engineering just celebrated its fifth anniversary.

The materials that are being examined have also matured. Virtually every device that uses electricity now has some form of digital storage. Wired or wireless networks connect many of the devices that we use in our daily lives. This, in turn, has driven the development of many network-and web-based services, including cloud computing. Some of these services, such as Facebook and Twitter, are changing the way in which people interact. This change is starting to drive how digital evidence is collected. Email has already become a major source of probative information and a forensic and information management challenge [START_REF] Iwata | Enron case could be the largest corporate investigation[END_REF].

During this epoch, forensic suites, most notably EnCase and FTK, have moved into the network/enterprise environment. They are being deployed in a prospective fashion in enterprises for corporate security and electronic discovery purposes. These same tools are being adapted to work in the emerging forensic environment of virtualized laboratories (using products such as VMWare) and storage area networks (SANs). Meanwhile, high-speed networks are being utilized to support the online review of evidence by investigators and prosecutors. The market for electronic discovery is booming, with vendors developing proprietary tools to automate the extraction and review of digital information. This is an interesting time for the digital forensic community as a whole. The law enforcement, military and intelligence communities have designed organizational structures and processes to support their mission view. While there are some in these communities that are considering the impact of future technologies, there is far less emphasis on how targets will utilize these technologies and how customers will utilize the forensic products. Defining the forensic products of the future is another challenge. A strong tactical approach exists, but a long-term strategic plan is missing.

7.

The Future

Predicting the future is a fool's game. Knowing that I will be wrong about many of my predictions, I will play the fool.

Digital forensics is a complex and evolving field. The practitioners of the future will be even better educated and trained; they will be team players trained to perform specific aspects of the forensic process. Forensics will no longer be a linear process focused on recovering data, but an evidence-based knowledge management process that will be integrated into investigations, intelligence analysis, information security and electronic discovery. There will be career digital forensic educators and researchers in addition to practitioners and managers. I fear that this new generation will be unaware of the early history and pioneering spirit that propelled the early years.

Our adversaries will be better organized, funded and educated. Criminals have recognized the value of distributed and collective efforts. Their payoffs will be significantly larger as the value of access and information grows along with society's dependence on the information infrastructure. Everyone (and their information) everywhere will be at risk at all times. Safety and security will be constantly threatened.

To counter these threats, digital forensic tools will have to improve. To overcome the sheer volume, the tools will have to be automated. In addition to performing data recovery, the tools will need to have built-in analytical capabilities, enabling important items to be identified without having to view every item. The tools will have to be semiotic, understanding human language and communications, and able to interpret content and context.

The organizations that employ digital forensic practitioners and those who rely on them will have to evolve as well. They will need to be accredited, with strong quality management and individual certifications. Much will ride on their reported results. Society needs assurance that the information collected and the conclusions reached are reliable. Organizations will have to cooperate and support the interoperability of people, tools and processes. Given the global scope of the problem, international legal standards will have to evolve.

Conclusions

In less than thirty years, digital forensics has blossomed from the germ of an idea, nurtured by brave pioneers, developed and expanded by professionals, to its current state. Many individuals have contributed their efforts, knowledge and enthusiasm to give the discipline a solid foundation for the future.

I apologize to the many worthy people who I have failed to mention in this narrative out of ignorance or forgetfulness. I earnestly hope that others will correct my errors, fill in the gaps and extend this work. Recording a complete history of digital forensics will benefit those who come after us. In the immortal words of George Santayana, "Those who cannot remember the past are condemned to repeat it" [START_REF] Santayana | Reason in Common Sense, Life of Reason[END_REF].


Amelia Carolina Sparavigna

Two Roman Towns in Germany Having a Solstitial Orientation of Their Urban Planning

Keywords: Archaeology, Archaeoastronomy, Solar Orientation, Solstices, Urban Planning, Satellite

Here we discuss the orientation of the urban planning of two Roman towns in Germany, Kastell Kesselstadt and Mogontiacum, the Roman Mainz. As all the Roman military camps and coloniae, these towns were planned according to an ideal pattern, based on a grid of parallel and perpendicular streets. Using a software giving the sunrise azimuths on satellite maps, we show that Kastell Kesselstadt and Mogontiacum have the main axis of the grid oriented along the direction of the sunrise on the summer solstice, that is, that the towns have a solstitial orientation.

Images, Google Earth.

It is generally known that the Roman surveyors based the planning of their new towns on a regular grid of parallel and perpendiculars streets. Actually, the surveyors were applying to the towns the same layout that they used for the military camps, the "castra", and for the limitation (centuriation) of the land [START_REF] Sparavigna | Roman Centuriation in Satellite Images[END_REF]. For what concerns the orientation of the grid of the streets, that is the orientation of the main of them, the Decumanus, many scholars, such as the Italian architect Gaetano Vinaccia for instance, proposed a strict relationship to the local environmental conditions [START_REF] Vinaccia | Il problema dell'orientamento nell'urbanistica dell'antica Roma[END_REF][START_REF] Giovagnorio | The environmental elements of foundations in Roman cities: A theory of the architect Gaetano Vinaccia[END_REF][START_REF] Chiri | Gaetano Vinaccia's (1881-1971) Theoretical Work on the Relationship between Microclimate and Urban Design[END_REF][START_REF] Chiri | Microclimate and Forma Urbis. The Topicality of Gaetano Vinaccia's Theoretical Work[END_REF]. Besides the scholars that argued the Decumani oriented according to the opportunity and environmental conditions of the places, other scholars have proposed the possibility of a solar or astronomical orientation of them [START_REF] Haverfield | Ancient town-planning[END_REF][START_REF] Barthel | Römische Limitation in der Provinz Africa[END_REF][START_REF] Bonine | Romans, Astronomy and the Qibla: Urban Form and Orientation of Islamic Cities of Tunisia[END_REF][START_REF] Magli | On the orientation of Roman towns in Italy[END_REF].

As specified by Francis Haverfield in his book on the ancient town-planning [START_REF] Haverfield | Ancient town-planning[END_REF], it is possible that the orientation of the Decumanus could have been established towards the sunrise on the day of the foundation, according to a ritual of Italic or Etruscan origin [START_REF] Aveni | Orientation and Etruscan ritual[END_REF]. For this reason, the orientation of the Decumanus of the Roman towns could span the range of sunrise azimuths between the extremal directions on solstices, directions that Columella, the most important writer on agriculture of the Roman Empire, mentioned as the "oriens brumalis" (southern sunrise, winter solstice) and the "oriens aestivalis" (northern sunrise, summer solstice) [START_REF] Fallanca | Gli dèi della città. Progettare un nuovo umanesimo: Progettare un nuovo umanesimo[END_REF].

Actually, several examples of Roman towns and forts oriented along the sunrise on solstices exist [START_REF] Sparavigna | Roman Towns Oriented to Sunrise and Sunset on Solstices[END_REF][START_REF] Sparavigna | The Town Planning of Pompeii and Herculaneum Having Streets Aligned Along Sunrise on Summer Solstice[END_REF][START_REF] Sparavigna | I Castra Albana Orientati Verso Il Solstizio D' Estate (The Castra Albana Oriented to the Summer Solstice)[END_REF][START_REF] Sparavigna | L'antico tracciato urbano di Venafro ed il solstizio d'estate[END_REF][START_REF] Sparavigna | The Walled Town of Alife and the Solstices. Philica, Philica[END_REF][START_REF] Sparavigna | Solstices at the Hardknott Roman Fort[END_REF][START_REF] Sparavigna | The Solstices and the Orientation of the Roman Fort of Segontium[END_REF][START_REF] Sparavigna | Wien and the Winter Solstice[END_REF], possessing as a consequence a grid of streets with a solstitial orientation. Since, in many cases, the solstitial orientation is close to the best possible choice with respect to the geographical position of the site, we can argue that this orientation could have been used to add a symbolic meaning to the geolocal site. This could be also the case of two Roman towns in Germany: Kastell Kesselstadt and Mogontiacum, the Roman Mainz. Besides having a strategic position, these towns had probably a solstitial orientation too. Using a software which is giving the sunrise azimuths on satellite maps, we can see that these towns were oriented along the direction of the sunrise on the summer solstice. For this reason, we like to add them to the towns mentioned in the Refs.12-19.

Kastell Kesselstadt

Kastell Kesselstadt was a Roman fort of Upper German-Raetian Limes. It corresponds to the center of the old town of Hanau-Kesselstadt in the Main-Kinzig-Kreis in Hessen. The Roman fort was situated on a slight elevation on the northern bank of the river Main. Today it is covered by the center of Kesselstadt, as well as by a part of the Philippsruhe Castle. As explained in [START_REF] Vv | Wikipedia[END_REF], the place of the fort was determined for its strategic position.

By the first half of the 19th century, due to the name of the town (Kessel-Kastell), the presence of a Roman fort was considered as highly probable. First, some Roman tombs were found and studied during the construction of the Frankfurt-Hanauer Eisenbahn in 1847. Further excavations and studies led to the map given in the Figure 1 [START_REF] Vv | Wikipedia[END_REF], with the Roman fort covering an almost square area of 375 × 375 meters. As told in [START_REF] Vv | Wikipedia[END_REF], the Jakob-Rullmann-Strasse corresponds essentially to one of the main streets of the fort. Let us consider this street as the old Decumanus, in order to investigate the possibility of a solstitial orientation of Kastell Kesselstadt (actually the Figure 1 is suggesting an orientation towards the oriens aestivalis, that is, the northern sunrise on summer solstice). To verify this orientation we can use some software applications which can give us information about time and azimuth of sunrise and sunset. Very useful are those applications that are showing solar azimuths on satellite images: among them, we have Sollumis at sollumis.com and SunCalc at suncalc.net that we have largely used in the previous works on the Roman towns. Here we use SunCalc. First of all, let us see the orientation of Jakob-Rullmann-Strasse: the result is given in the Figure 2. From the Figure 2 we can see that a part of the Jakob-Rullmann-Strasse is oriented along the sunrise on the summer solstice. In the case that this part of the street is also a part of the main street of the Roman town, we can argue that the town had a solstitial orientation.

We can also use a satellite image, as in the Figure 3, left panel, and mix it with the map in the Figure 1: we have the Roman fort of Kastell Kesselstadt displaying the abovementioned orientation.

Mogontiacum, the Roman Mainz

Mainz has a Roman precursor, the castrum of Mogontiacum, founded by the Roman general Drusus in 13/12 BC [START_REF] Vv | Wikipedia[END_REF]. For what concerns the name of the castrum, in [START_REF] Vv | Wikipedia[END_REF] it is told that it was derived from that of a Gallic god. The "Roman soldiers defending Gallia had adopted the Gallic god Mogons (Mogounus, Moguns, Mogonino)", "the great one", similar to Latin "magnus", the god of "might" personified [START_REF] Vv | Wikipedia[END_REF].

As explained by [START_REF] Vv | Wikipedia[END_REF], Mogontiacum was an important military town, probably due to its strategic position at the confluence of the Main and the Rhine. The civil town grew up between the fort and the river (Figure 4), and became the provincial capital of Germania Superior. Let us repeat for Mogontiacum the approach we did for the Figure 3; the result is given in the Figure 5. It seems that the axis of the fort and of the civil town was oriented along the sunrise on the summer solstice. Kastell Kesselstadt and Mogontiacum have an evident strategic position, which is conditioning their orientation. However, as we have seen using the SunCalc software they had also a solstitial orientation. Probably, they were deduced with this specific orientation to add a symbolic meaning to the site, linking the fort to the period of the year when the sun is more powerful and strong, that is, "magnus", perhaps in honor of the god of the "might" personified.

Figure 1 -

 1 Figure 1 -The Roman fort (Courtesy, Haselburg-mueller, Wikipedia)

Figure 2 -

 2 Figure 2 -Thanks to SunCalc.net, we can see that the direction of sunrise on June 21 is coincident with a part of the Jakob-Rullmann-Strasse. The yellow line represents the direction of the sunrise, the red one that of the sunset. The orange arc shows the apparent motion of the sun in the sky.

Figure 3 -

 3 Figure 3 -Using the SunCalc simulation on the satellite map and the Figure 1, we can have SunCalc applied to the Roman fort as in the right panel.

Figure 4 -

 4 Figure 4 -Map of Mogontiacum. In it, 1 is the fort and 2 the civil town (Courtesy, DaniDF1995, Wikipedia).

Figure 5 -

 5 Figure 5 -Using SunCalc, we see that the axis of the fort and of the civil town is oriented along the sunrise on the summer solstice.