VERS Standard Electronic Record Format PROS 99/007 Specification 3. Public Record Office Victoria

Transcription

1 VERS Standard Electronic Record Format PROS 99/007 Specification 3 Public Record Office Victoria Version 1.0 April 2000

2 PROS 99/007 Specification 3: VERS Standard Electronic Record Format 1 Table of Contents 1.0 Introduction The principle of self sufficiency Requirements for a Long Term Electronic Record Format Integrity VERS Long Term Format (VERS Encapsulated Objects) extensible Markup Language (XML) Standard Encodings Documents Database Tables Onion Records Digital Signatures Other Standard Encodings Using Digital Signatures for Authentication Paper Records and Evidence What Does a Digital Signature Really Prove? The Lifespan of a Digital Signature Digital Signatures Public and Private keys Securing the Private Key Public Key Infrastructure Certificates Certificate Paths Certificates and Archives Encryption Physical Storage Media Recommendations for Small Agencies Recommendations for Medium Agencies Recommendations for Large Agencies Recommendations for Transfer Formats Recommendations for the Future Appendix One: XML DTD Appendix Two: Digital Signature Infrastructures Who signs the record and when? Signing by creator at point of record creation Signing by application at point of record archiving Summary Where is the private key of the signer kept? Keyring Files Key Databases Dumb Smartcards Smart Smartcards Biometrics Summary... 33

3 PROS 99/007 Specification 3: VERS Standard Electronic Record Format 2 3. Where is the public key of the signer kept? Use unsecured public keys Public Keys stored as Records within VERS Unsecured Agency Directory Summary Appendix Three: Digital Signature Implementation Options Option 1: Records signed by the application with local storage of private keys & no public key infrastructure Option 2: Records signed by Users with file or database storage of private keys & public keys stored as records Option 3: Records signed by Users with private keys stored in Smartcards and public keys stored as records Appendix Four: Digital Storage Media for VERS... 41

4 PROS 99/007 Specification 3: VERS Standard Electronic Record Format 3 This document specifies the standard long term record format for archiving electronic records in accordance with standards issued by Public Record Office Victoria. It should be used in conjunction with PROS 99/007 Standard for the Management of Electronic Records, PROS 99/007 Specification 1: System Requirements for Archiving Electronic Records, and PROS 99/007 Specification 2: VERS Metadata Scheme. 1.0 Introduction There are three basic principles that need to be adopted in using a long term format for the purposes of archiving electronic records. These are: Self sufficiency. The electronic record must be as independent of systems, outside data, and documentation as possible. Structured textual encoding. At a minimum, the information that encapsulates the content should be encoded as a structured piece of text rather than as binary data. Information integrity. Being able to show who created the record, when it was created, and that it has not subsequently been modified is the key to evidentiary integrity. 1.1 The principle of self sufficiency To minimise the probability of losing a record, it is necessary to minimise the dependency of the record on systems, other data, or documentation. The ideal record is self sufficient. The rationale behind this principle is simple. Dependency increases the points of failure. If access to a record is dependent on a system, for example, then the loss of that system means the loss of the record. To cite an example, a large collection of records requires some means to allow users to find the records they are interested in. One method is to provide an index. But what happens if this index is lost? The records may still exist, but if it is not possible to recreate the index the contents may be inaccessible. Self sufficiency requires that a record must include a copy of its indexing information. If the external index is destroyed it should be able to be rebuilt using the information stored in the records themselves. No record can be completely self sufficient because that would require the storage of all the supporting documentation for the long term record with the record itself. However, if a specification or standard is sufficiently widely published that a copy can reasonably be expected to be found in a public library (or the electronic equivalent) for the foreseeable future, it is sufficient to reference the specification or standard in the record. As a corollary, only widely published specifications or standards should be used within a record as, otherwise, the standard or specification would need to be included in each record. In summary, a good design for an archivable record is record centric. It minimises the dependency of the record on systems, outside data, and documentation. Very well known information can be included by reference to reduce overhead.

5 PROS 99/007 Specification 3: VERS Standard Electronic Record Format Requirements for a Long Term Electronic Record Format Long term preservation of information can be viewed as a transmission protocol. The sending computer is the system that creates and (perhaps) initially stores the information. The receiving computer is the, as yet unbuilt, system in the future that will display the record. A transmission protocol cannot work unless both the sending and receiving hosts exactly agree on the encoding of the information that passes between them. This can be difficult enough to achieve when the two systems can be tested against each other, but in the case of archiving of electronic information the receiving system has not yet been constructed when the record is transmitted by the sending system. Thus a well designed long term record format has three highly desirable characteristics: Simple encoding. The encoding of the record should be as simple and as easy to understand as possible. Self describing. The atoms of information in the record should be clearly identifiable and labelled to indicate their meaning. Consider examining a record and finding a stream of undifferentiated bits. It is impossible to determine where each atom of information starts and stops, the data type of the atom, or the meaning of the atom. The simplest self describing encoding is to encode the atoms as text with each atom delimited by special characters, tag it with a label, and structure the information to show relationships. Self documenting. Some atoms of information will require complex explanations to explain the meaning of the atom. Consider a digital signature. It is easy enough to tag the data that forms the signature with a label Digital Signature, but to check the signature requires a lot more information. What algorithm was used to generate the digital signature (and what were the values of any parameters)? Exactly what data in the record is covered by the digital signature? Is the digital signature encoded (e.g. has the binary digital signature been turned into text)? An archived record must include sufficient documentation to allow a future user to understand what was done. A reference to an external publication is sufficient documentation if the external publication will be available indefinitely. The requirement for a simple, self describing, and self documenting encoding suggests a textual encoding. However, there are two problems with a pure textual encoding of a record. The first problem is efficiency. For example, binary encoding of a 24 bit RGB image requires 3 octets for each pixel. A simple textual encoding would require a minimum of 6 octets (e.g. 0,0,0; ) and a maximum of 12 octets (e.g. 255,255,255; ), or between 200% and 400% space overhead for the RGB data. In addition to the space overhead, both parsing and generating the textual encoding is normally more expensive than the parsing and generating the equivalent binary encoding. It is often preferable to use a binary encoding for simple efficiency. The second problem is complexity. Many types of data are inherently complex. Describing a printed page, for example, requires describing the position of every character on the page together with the characteristics of the character such as weight, orientation, and skew. It would be possible to develop a textual encoding to describe a page, but this requires specialist

6 PROS 99/007 Specification 3: VERS Standard Electronic Record Format 5 knowledge to ensure that the textual encoding is suitable. It is far preferable to use existing standards for complex data, even if they use a complex binary encoding. It is possible to include binary encodings within an archived object. The key is to: Choose a binary encoding that has been published and is therefore available to be referenced, or is sufficiently simple that it can be documented within the record. Include in the archived object documentation on what binary encoding has been chosen. In summary, a good design for long term electronic record format will be based on a simple textual encoding that marks up the data to indicate its extent, syntactic meaning, semantic meaning, and relationship to other data in the record. The use of binary encodings for specific elements in the record is acceptable when this allows the use of specialist standards, provided the use of these standards is well documented within the record. 1.3 Integrity In many applications, the archived information is useless, or loses value, unless it can demonstrate who created the information, when it was created, and that it has not been subsequently altered. Where this integrity requirement is imposed, it significantly complicates the design of an archived record. This Standard advocates the use of digital signatures to demonstrate the integrity of the record (see and appendices two and three). A digital signature is a cryptographic technique used to generate a unique signature that depends on the entity signing the object and contents of the object. Up to two signatures can be used to protect the VERS Encapsulated Object from forgery. A record is normally signed separately by the creator of the record and by the system itself. These two signatures protect the record from forgery by any one party acting alone. The creator s signature ensures that a forgery cannot be perpetrated by a system administrator or by a third party. The system s signature ensures that the creator cannot forge the record after the event. This process requires two keys, one of which must be kept private, and one which is publicly available. A mathematical algorithm is used to ensure that the data is authentic or secure to a very high degree. The greater the key length, the higher the security of the system. A key is simply a very long prime number. Common key lengths are 40 bits, 128 bits, and 1024 bits. A private key must be kept secret and be held by only one user. The public key is published so as to be accessible to all users of the security system. Digital signatures have the advantage that the record carries its own integrity check and consequently the integrity of the system that holds the records has less relevance. 2.0 VERS Long Term Format (VERS Encapsulated Objects) The VERS Long Term Format consists of an object (known as a VERS Encapsulated Object or VEO) represented in extensible Markup Language (XML). This object will contain contextual information about the record and may also contain document files, image files,

7 PROS 99/007 Specification 3: VERS Standard Electronic Record Format 6 sound files, movie files, etc. The VEO is also signed using digital signature technology to ensure authenticity. For information about the generic VERS Long Term Record Format see PROS 99/007 Specification 1. While a compact data format like a binary data format is desirable to encode long term records, a binary format is dependent on the program that interprets the binary data to extract the content. To make the record self sufficient, a textual encoding is preferred. While less efficient, the contents of a record can be inspected using simple text editing software and consequently the record is not dependant on software or documentation. XML is the text based encoding chosen for the VERS Long Term Record Format. 2.1 extensible Markup Language (XML) The recommended Long Term Record Format is expressed using XML (extensible Markup Language). XML is a text based markup language. XML specifications are easily extensible (unlike HTML) and are relatively simple. The XML standard is defined in Extensible Markup Language (XML) Standard Encodings The data that forms a document 2 may be encoded in many ways when the document is included in the record. For example, a report could be encoded as a PDF file, or a Word file. A Document in the record can contain several representations of the same physical document. Each encoding represents one representation of the physical document. It should be noted when storing documents that XML requires that data be stored as character data (i.e. binary data must be encoded). Contents of XML tags must be textual characters. All binary data must be encoded to textual information. The encoding used should be documented in the File Encoding element. The data cannot include the characters <, >, or &. Where these characters are found within the data, they must be replaced by the strings <, > and & respectively. For VEOs this encoding should be done in Base64 3. Base64 is an Internet standard that is a fundamental component of systems. For the long term preservation of records, standard encodings for three types of documents have been defined: documents, database tables, and records. Agencies may choose to use other encodings for alternate representations of documents but the standard encodings detailed below must be used for permanent or long term temporary public records Documents The documents which are currently best able to be conserved as long term electronic records are items which can be printed. Examples include Word documents, database reports, s, spreadsheets, and drawings. 1 Extensible Markup Language (XML) 1.0, W3C Recommendation REC-xml , 2 In its widest sense a document could be a sound file, an image, a digital video as well as the more traditional word processing document or . 3 Multipurpose Internet Mail Extensions (MIME), Part One: Format of Internet Message Bodies, Section 6.8 Base64 Content-Transfer-Encoding, IETF RFC 2045,

8 PROS 99/007 Specification 3: VERS Standard Electronic Record Format 7 In this Standard, documents are represented using the Portable Document Format (PDF) Version 1.3 produced by Adobe Systems Incorporated. 4 The primary selection criteria for a document format was confidence that, for the foreseeable future, it would be possible to write a viewer for the document from publicly available information. Microsoft Word file format, for example, would not be an appropriate format, as the description of this format has not been published. The PDF standard has been published and is freely available. PDF is flexible and PDF can be generated from any application that can generate Postscript (the standard printing language); thus anything that can be printed can be represented in PDF. PDF can also be generated from scanned documents. Scanned documents can be converted to an electronic document which is very close (or identical) in appearance to the original paper document. The text of the scanned image can be accessed, altered or used after employing optical character recognition software. PDF is reasonably efficient in terms of size. In the VERS prototype 5, PDF generated from Word documents was typically 50 to 80 percent of the size of the original Word document. PDF is much more efficient than Postscript. PDF is a binary format and hence must be encoded into text before inserting the data into the VEO. See above on the use of Base64 to encode binary data as text. Encoding in Base64 means that the file increases in size by 25% Database Tables Database tables are collections of sets of data. A database row encodes a single data set, and database columns encode the data set categories. A database table may also have associated forms, queries and macros that encode how the database is commonly used. An XML DTD has been defined to mark up the rows of a database table. <!ELEMENT vers:databasetable (vers:databasetablerow)*> <!ELEMENT vers:databasetablerow (vers:databasetableelement)*> <!ELEMENT vers:databasetableelement (#PCDATA)> A database table is represented as zero or more rows (database records). Each row comprises zero or more elements (columns or fields). Developing grammars sufficient to fully describe the functionality of a database, including its schema, query language and fixed queries, may be a very time consuming and arduous process. Agencies should fully consider the database functionality which is desirable for long term preservation (which may be functionality considerably less than that desired for a fully functioning database) and concentrate on preserving and describing only those aspects of the database which will be useful in the long term and which are required to be kept for legislative or historical reasons. 4 Portable Document Format Reference Manual, Version 1.3, Adobe Systems Incorporated, March For further information about the VERS prototype see Victorian Electronic Records Strategy Final Report, Public Record Office Victoria, March 1999, available at

9 PROS 99/007 Specification 3: VERS Standard Electronic Record Format Onion Records The digital signatures that secure a VERS record also prevent any modification of the record. In some circumstances it might be necessary to modify the metadata associated with a record. For example, the need may arise to refile a record, to add additional descriptive information, or to make a new linkage to another record. To allow the metadata to be modified without disturbing the evidentiary integrity, the VERS XML DTD allows a record to be included as the content within a new record. This layering of record metadata is referred to as producing Onion Records. The content in the case of an Onion Record is a complete record (i.e. an XML VEO) Digital Signatures Digital Signature technology must be used to sign the VEO in order to ensure record authenticity (see discussion 3.0 below). It is recommended that any published and freely available Digital Signature Standard (such as the National Institute of Standards and Technology s Digital Signature Standard 6 ) be used as long as it is fully documented in the Signature Format Description element of the VEO. Both the Signature and Public Key are binary data and need to be encoded to textual information. For VEOs this encoding should be done in Base64 7. The encoding used should be documented in the Signature Format Description 8 element of the VEO metadata Other Standard Encodings It is expected that other standard encodings will be defined after further research. Agencies should apply to PROV for further information and assistance in choosing standard encodings for computer file formats which are not covered by the encodings given above. 3.0 Using Digital Signatures for Authentication One of the fundamental reason for keeping records is as evidence. The business requirements of an organisation impose different evidential standards on different types of records. A second external requirement is the certainty of change. Many computer security techniques are in their infancy, particularly the use of digital signatures. In can be expected that, over time, the cost of digital signature security will fall and required standards will rise. Any solution put in place today must look forward to a different environment in the future. The use of digital signatures requires an infrastructure to apply the signatures and to store the associated public and private keys. This infrastructure can be implemented in a variety of ways, but implementation decisions have consequences for the strength of the proof that the resulting digital signature will give and the cost of the infrastructure. Like most systems, strong proof requires an expensive infrastructure. This is particularly true of non-repudiation. 6 National Institute of Standards and Technology, Federal Information Processing Standards Publication, Digital Signature Standard, FIPS PUB 186-1, 15 December 1998, 7 Multipurpose Internet Mail Extensions (MIME), Part One: Format of Internet Message Bodies, Section 6.8 Base64 Content-Transfer-Encoding, IETF RFC 2045, 8 See PROS 99/007 Specification 2 VERS Metadata.

10 PROS 99/007 Specification 3: VERS Standard Electronic Record Format Paper Records and Evidence 9 In a traditional record keeping system, authenticity is shown by a mixture of Pragmatism. Courts have taken the pragmatic view that records kept as part of the everyday transaction of business can generally be taken at face value as, if these records were not reasonably accurate, the business could not be carried out. Provenance. Provenance is essentially the history of the record, including being able to show who had the record over time, and what happened to it. Signatures (where necessary). A small set of significant records are signed. Typically these are records which demonstrate an incurred liability or act as evidence of a decision. The standard of proof required depends on the type of record. Many current paper records, for example, are neither signed nor dated and are completely unprotected against modification or substitution. In an electronic record keeping system, authenticity is expected to be shown in a similar fashion. However, electronic records are considered to be easier to undetectably modify than paper records, hence the interest in digital signatures that allow the detection of modifications. In theory, digital signatures can also be used to serve the same non-repudiation function as the handwritten signature on paper records. 3.2 What Does a Digital Signature Really Prove? In theory, a digital signature proves who signed the record and that the record has not been modified since the signature was applied. In practice, however, the strength of this proof depends strongly on the process by which digital signatures are applied. In many ways, a digital signature is closer in concept to a seal than to a conventional handwritten signature. A handwritten signature is unique to an individual; no other person can match the sequence of muscle movements that produces the signature. There is consequently a very strong association between a handwritten signature and the signer. A seal, however, is applied mechanically. Anyone in possession of the seal can seal a document. It is consequently impossible to prove who sealed a document from the seal itself, as there is a weak association between the seal on a document and the person that executed the seal. It is possible to trust seals provided there is a strong emphasis on control of the seal. Like a seal, a digital signature is mechanically applied, and can be applied by anyone in possession of the appropriate private key. The evidentiary value of a digital signature, like a seal, is based on the system that associates the signer and the public/private keypair. A poor system will give little evidentiary integrity (just as an uncontrolled seal will result in sealed documents that have little weight). On the other hand, a strong system may be sufficiently expensive to outweigh the value of the records. 9 For a further discussion of electronic records as evidence see PROS 99/007 Standard for the Management of Electronic Records.

11 PROS 99/007 Specification 3: VERS Standard Electronic Record Format 10 It is necessary for agencies to identify the options that provide a maximum amount of evidentiary status while minimising this cost. 3.3 The Lifespan of a Digital Signature The conventional use of digital signatures is to protect messages for relatively short periods of time. Typical examples include the protection of messages during transmission over the Internet, and the authentication users or systems during communication. Using digital signatures in a record keeping or archival environment requires applying digital signatures to objects that may exists for decades or centuries. It is necessary to preserve sufficient information to validate the digital signatures applied to records even though decades or centuries may have passed. 3.4 Digital Signatures A well designed digital system infrastructure allows a user to verify that a message has not been modified and gives an indication of who signed the message. It is important to note that applying a digital signature does not encrypt the message; the original message remains unchanged after applying a digital signature. The actual process of applying and checking a digital signature is simple (see figure 1). The first step is to apply a hash function (a computer algorithm) to the original message. The hash function simply converts the long string of bits that forms the original message into a single number known as the hash value. A good hash function has a number of properties: If the hash function is reapplied to a message the same hash value is generated. If you change the message, even by one bit, the hash function will generate a different hash value. Given a particular hash value it is impossible to work out a message that would generate that value.

12 PROS 99/007 Specification 3: VERS Standard Electronic Record Format 11 Message Private Key 1. Message passed to hash function & converted to hash value Hash Function 2. Hash value encrypted using Signer's private key to give digital signature 3. Digital signature appended to message Digital Signature Message Digital Signature Figure 1: The process of applying digital signatures The hash value is then encrypted using the signer s private key. The resulting encrypted hash value is the digital signature. Message Digital Signature Public Key 1. Message passed to hash function & converted to hash value Hash Function 2. Digital signature decrypted with Signer's public key to give original hash value Encryptor Decryptor =? 3. Original and recalculated hash values compared. Accept 4a. Message accepted if both hash values are the same (message has not been altered since signing) Reject 4b. Message rejected if hash values are different (either message has been changed, or was not signed by purported Signer) Figure 2: the process of checking digital signatures

13 PROS 99/007 Specification 3: VERS Standard Electronic Record Format 12 To check a digital signature is equally simple. The user recalculates the hash value from the message. The digital signature is then decrypted using the signer s public key to retrieve the original hash value. If the two hash values are identical the message is unchanged and was actually signed by the purported signer. If the two hash values differ, then either the message has been modified since it was signed, or the wrong public key was used to decrypt the hash value. 3.5 Public and Private keys Public key cryptography is normally used to encrypt and decrypt the hash value (secret key cryptography could also be used). This form of cryptography uses a pair of linked keys, known as the public and private keys. Anything encrypted by one of the keys can be decrypted by the other. One key (the private key) is kept secret, and the other key (the public key) is published. Knowledge of the public key does not allow the user to calculate the private key. To sign a message, the signer uses their private key to encrypt the hash value. The receiver of the message uses the signer s public key to decrypt the hash value. Note that if the receiver uses the wrong public key, the decrypted hash value will not match the hash value calculated from the message. 3.6 Securing the Private Key Possession of the private key allows a user to sign a record. Clearly, proving that it really was that user that signed that record requires examining the association between a user and their private key. Could the user have lent their private key to another user? Could the private key have been used without the owner s knowledge? Could the private key have been stolen? The strength of the association between the user and their private key depends on how the key is stored. Some form of electronic storage is necessary. Private keys can be up to 1000 characters long (about three times as long as this paragraph), and are essentially random characters. In other words they are impossible to remember and difficult to type in accurately. 3.7 Public Key Infrastructure To check the validity of a digital signature requires the public key of the person who signed the record. Users require access to thousands of public keys as they communicate with various people over their life. But how are these public keys obtained? Like private keys, public keys are sufficiently long to make it necessary to store them in an electronic directory. Apart from the technical problems with constructing a global directory, retrieving a public key from a directory raises the issue of trust: can the user trust the public key returned from the directory? The Public Key Infrastructure (PKI) has been developed to deal with this question of trust. The PKI is simple in theory, but fiendishly complex in practice.

14 PROS 99/007 Specification 3: VERS Standard Electronic Record Format Certificates The PKI is built around certificates (see figure 3). Essentially, a certificate is an assertion by someone (the Certification Authority) that a particular subject (user) has a particular public key. The basic information in a certificate is: Issuer. This is the name of the Certification Authority (CA) that issued the certificate. Validity. The period over which the certificate is valid Certificate Issuer Validity Subject Public Key Signature Subject. The name of the user (or system) that owns the public key Figure 3: Digital Certificate Public Key. The public key belonging to the user. Digital signature 1. Retrieve Signer's Certificate from certificate database Certificate DB Check Public Key 2. Check signature on certificate using public key. This proves the owner created certificate. Note: Knowledge of the public key is built into all computers. Extract 3. Extract Signer's public key from validated certificate Signer's public key Figure 4: An example of Public Key Infrastructure implemented within a single agency With a certificate, the question of trust boils down to two questions: Do you trust the Issuer when they state that a particular subject has a particular public key? (How much trust would you place in a certificate issued by Fly-by-Night Pty Ltd?)

15 PROS 99/007 Specification 3: VERS Standard Electronic Record Format 14 Can you check that a certificate was really issued by the purported Certification Authority? (Just because the certificate says that it was issued by Acme Signatures Inc., it doesn t mean that it was!) The second question can, of course, be solved by signing the certificate with the Certification Authority s private key. But this brings us nearly back to our starting point: to validate the public key of the subject, we need to validate the public key of the Certification Authority Certificate Paths This simple approach works for small systems that are managed by one authority. It does not work if you need the public key of a user in another organisation (for example in another agency of government). This approach can be handled by another layer of certificates. Certificate paths can be longer than the example shown in figure 5 (for example there may be an Australian Government Certification Authority), but they all depend on each system knowing, a priori, at least one high level public key. Lotus Notes, for example, comes pre installed with the public keys of several US Certification Authorities such as Verisign. All this is quite straightforward, except for three details. A system is given a certificate to check and to do this it needs the public key of the certification authority that signed the certificate. But to do this, it must (i) identify who signed the certificate, (ii) work out where to go to ask for a copy of the signer s certificate, and (iii) that copy must be on a certificate path that leads to a public key known by the system doing the checking. The last point needs to be clarified. A certification authority may have several certificates, each signed by a different superior certification authority. For example, in addition to an external agency having its certificate signed by the Victorian Government certification authority, it may also have a certificate signed by a commercial certification authority. The Victorian Government certificate is used by other government agencies (because that is the key the agency s systems have been loaded with). Commercial companies will use the certificate signed by the commercial certification authority (because that is the key the commercial systems have been loaded with). Instead of a single path of certificates, there is actually a web of certificates. Validating a public key involves navigating this web. A variety of algorithms have been developed to allow this web of certificates to be navigated.

16 PROS 99/007 Specification 3: VERS Standard Electronic Record Format 15 Digital signature (signed by external agency officer) XCheck Check 1. Retrieve Signer's Certificate from external agency certificate database 2. Can't check validity of certificate as external agency s public key is not known 3. Retrieve external agency s Certificate from Victorian government certificate database Vic Govt Public Key External Certificate DB Victorian Government Certificate DB 4. Check signature on external agency s certificate using Victorian Government's public key. Note: Knowledge of the government's public key is built into all government computers. Extract 5. Extract external agency's public key from validated certificate Check 6. Check signature on Signers's certificate using external agency's public key. Extract 7. Extract external agency's public key from validated certificate Signer's public key Figure 5: An example of Public Key Infrastructure implemented within the Victorian Government Certificates and Archives From the VERS perspective, a major problem with the PKI is that no attention has been paid to the archival implications of digital signatures. Clearly, to check the digital signature of a document in 50 years requires that the public key of the signer is still accessible. However, public key technology was primarily developed to protect messages passing across a network. Public keys have consequently only been designed to be valid for very short periods of time and so destruction of old public keys is not considered a problem. In fact, certificates are only valid over a specified period over which the Certification Authority warrants that it will maintain information about the status of the certificate.

17 PROS 99/007 Specification 3: VERS Standard Electronic Record Format Encryption This Standard does not recommend encryption of records stored in VERS long term format. PROV recognises that preventing unauthorised access to records is an important feature of an archive and encryption may significantly simplify the provision of this feature. PROV also recognises that without encryption, access control is dependent on the archive software preventing access to records. Also, the possibility of bugs and back doors in the hardware, operating system and archive software must be dealt with. However, if the record is encrypted, preservation of the record depends on preservation of two separate pieces of data: the record itself, and the key used to decrypt the record. Loss of either of these means loss of the record.

18 PROS 99/007 Specification 3: VERS Standard Electronic Record Format Physical Storage Media 10 The physical storage of electronic records is as important as the long term digital format of the records themselves. VEOs must be stored on media which is relatively long lasting, has a reasonably high capacity and which is widely supported by storage media vendors. In order to protect against media obsolescence, deterioration or for transfer, media must be refreshed periodically. Refreshing is the process of physically copying records from one piece of media to another. The process of refreshing can be made entirely automatic. This Standard recommends the use of a small range of types of magnetic tape, which PROV believe encompasses the needs of small to large agencies. Magnetic tape is the preferred medium because of high densities, high capacities, reliability, industry acceptance and independence from vendor file systems. For smaller agencies, CD-ROM and successor technology may be suitable because of lower volumes, and cost constraints. For transfers to other agencies or to PROV, the use of the Internet is recommended, but if this is not viable or not feasible (due to, say, security issues), then a range of tapes and removable discs is suggested. All storage systems should store at least two copies of each of the records, and PROV recommends adopting different storage technologies for the primary and secondary copies. This reduces the chance of data loss due to a bad manufacturing batch, or problems with the readers. PROV particularly cautions against adopting systems that use new technology. New technology is often attractive as it promises high capacity at a lower cost than existing technology. Unfortunately, the history of computer storage is littered with new technology that either did not live up to its initial promise (particularly with regard to reliability), or quickly went out of production due to the failure of the company that developed it. In addition PROV recommends care in selecting components so that selection of one particular component (media type, data storage management software, host operating system or host hardware) does not force the selection of the other components. A good data storage system should be flexible and handle many components. 4.1 Recommendations for Small Agencies For agencies that generate up to 10 Gigabytes of data annually, PROV recommends storage on either Travan magnetic tapes, writable CDs, or Zip drives. At the low end, a manual data storage system would be around $1000, but it should be noted that this system would require manual loading and unloading of media and would consequently have a relatively high running cost. Purchase of a small CD-R jukebox (robot) would avoid this manual handling and would cost between $10,000 and $30,000 depending on capacity. 10 For a more detailed discussion of physical storage media see Appendix Four: Digital Storage Media for VERS.

19 PROS 99/007 Specification 3: VERS Standard Electronic Record Format Recommendations for Medium Agencies For agencies that generate between 10 Gigabytes and 1.5 Terabytes of data annually, PROV recommends storage on Quantum DLT drives. Normal data storage practice is to store two independent copies, so this translates to between 20 Gigabytes and 3 Terabytes of storage annually. The expected cost of such a system would be around $44,000 capital cost and around $16,000 per annum consumables. This figure comprises two drives (around $12,000 each), a robot (around $20,000). This costing does not include staff costs. These would be between 0.5 and 1.0 effective full time positions. 4.3 Recommendations for Large Agencies For agencies that generate over 1.5 Terabytes of data annually, PROV recommends storage on 3490E/Timberline drives with 9840 drives for the second copy. PROV also recommends that at least two independent copies be made of data on separate media technologies. This means that the actual increase in storage is twice the amount of data generated. The expected cost of such a system would be around $700,000 capital cost and around $10,000 per Terabyte of data stored in the system annually. This figure would buy a large silo (e.g. a StorageTek silo) and associated drives. Staff costs would be between 1 and 2 effective full time positions. Because these systems are very widely used for data storage, they can be connected to a very wide range of host machines running a range of operating systems. 4.4 Recommendations for Transfer Formats PROV may accept transfer of records from an agency by means of the Internet in the future. However, at present, PROV will accept only a limited set of media formats: ZIP discs CDs written according to ISO format tapes 4.5 Recommendations for the Future It is strongly recommended that any agency implementing a data storage system should obtain expert assistance in planning the system, including capacity required, location, off site backup and disaster recovery selecting hardware and data management software to suit the agencies particular environment installing and testing of the hardware and software setting up systems and processes to ensure that data will be managed reliably for the long term.

20 PROS 99/007 Specification 3: VERS Standard Electronic Record Format 19 Appendix One: XML DTD The following is the XML Document Type Definition for the VERS Encapsulated Object. Definitions for each of the elements can be found in PROS 99/007 Specification 2: VERS Metadata Scheme. <!-- Definition of VERS Encapsulated Object VERSION > <!ELEMENT vers:versencapsulatedobject ( vers:veoformatdescription, vers:version, vers:signatureblock*, vers:signedobject)> <!ATTLIST vers:versencapsulatedobject xmlns:vers CDATA #IMPLIED xmlns:naa CDATA #IMPLIED> <!ELEMENT vers:version (#PCDATA)> <!-- currently should be > <!ELEMENT vers:veoformatdescription (vers:text)> <!ELEMENT vers:signatureblock ( vers:signatureformatdescription, vers:signaturedate?, vers:signer?, vers:signature, vers:certificateblock+)> <!ELEMENT vers:signatureformatdescription (#PCDATA)> <!ELEMENT vers:signaturedate (#PCDATA)> <!ELEMENT vers:signer (#PCDATA)> <!ELEMENT vers:signature (#PCDATA)> <!ELEMENT vers:certificateblock ( vers:signerscertificate, vers:certificatereference?)> <!ELEMENT vers:signerscertificate (#PCDATA)> <!ELEMENT vers:certificatereference (#PCDATA)> <!ELEMENT vers:signedobject ( vers:objectmetadata, vers:objectcontent)> <!ELEMENT vers:objectmetadata ( vers:objecttype, vers:objecttypedescription, vers:objectcreationdate)> <!ELEMENT vers:objecttype (#PCDATA)> <!ELEMENT vers:objecttypedescription (#PCDATA)> <!ELEMENT vers:objectcreationdate (#PCDATA)> <!ELEMENT vers:objectcontent (vers:record vers:file)> <!ELEMENT vers:text (#PCDATA)> <!ELEMENT vers:record ( vers:recordmetadata, vers:document+)>

21 PROS 99/007 Specification 3: VERS Standard Electronic Record Format 20 <!ELEMENT vers:document ( vers:documentmetadata, vers:encoding+)> <!ELEMENT vers:encoding ( vers:encodingmetadata, vers:documentdata)> <!ELEMENT vers:documentdata (#PCDATA vers:versencapsulatedobject)*> <!ELEMENT vers:recordmetadata ( naa:agent+, naa:rightsmanagement, naa:title, vers:subject*, naa:description*, naa:language*, naa:relation*, naa:coverage*, naa:function*, naa:date, naa:type?, naa:aggregationlevel, naa:format?, naa:recordidentifier, naa:managementhistory, naa:usehistory?, naa:preservationhistory?, naa:location?, naa:disposal, naa:mandate*, vers:veoidentifier, vers:transaction*)> <!-- NAA Metadata --> <!-- See Recordkeeping metadata standard for Commonwealth --> <!-- agencies 1.0 for more details --> <!ELEMENT naa:agent ( naa:agenttype+, naa:jurisdiction*, naa:corporateid?, naa:corporatename+, naa:personid?, naa:personalname*, naa:sectionname*, naa:positionname*, naa:contactdetails*, naa: *, naa:digitalsignature*)> <!ELEMENT naa:rightsmanagement ( naa:securityclassification, naa:caveat*, naa:codeword*, naa:releasabilityindicator*, naa:accessstatus?, naa:usagecondition*, naa:encryptiondetails?)> <!ELEMENT naa:title ( naa:schemetype+, naa:schemename, naa:titlewords, naa:alternative*)> <!ELEMENT vers:subject ( vers:keywordlevel?, vers:keyword+)> <!ELEMENT naa:relation ( naa:relateditemid+, naa:relationtype+, naa:relationdescription*)> <!ELEMENT naa:coverage ( naa:jurisdication*, naa:placename*, naa:periodname*)> <!ELEMENT naa:function ( naa:functiondescriptor+, naa:activitydescriptor+, naa:thirdleveldescriptor*)> <!ELEMENT naa:date ( naa:datetimecreated, naa:datetimetransacted, naa:datetimeregistered)> <!ELEMENT naa:format ( naa:mediaformat, naa:dataformat, naa:medium, naa:extent*)> <!ELEMENT naa:recordidentifier (vers:veoidentifier)> <!ELEMENT naa:managementhistory (vers:managementevent+)> <!ELEMENT vers:managementevent ( naa:eventdatetime, naa:eventtype, naa:eventdescription)> <!ELEMENT naa:usehistory (vers:use+)> <!ELEMENT vers:use ( naa:usedatetime, naa:usetype, naa:usedescription)> <!ELEMENT naa:preservationhistory (vers:action+)> <!ELEMENT vers:action ( naa:actiondatetime, naa:actiontype, naa:actiondescription,

22 PROS 99/007 Specification 3: VERS Standard Electronic Record Format 21 naa:nextaction?, naa:nextactiondue?)> <!ELEMENT naa:location ( naa:currentlocation, naa:homelocationdetails, naa:homestoragedetails, naa:rksid?)> <!ELEMENT naa:disposal ( naa:disposalauthorisation+, naa:sentence, naa:disposalactiondue?, naa:disposalstatus?)> <!ELEMENT naa:mandate ( naa:mandatetype+, naa:refersto+, naa:mandatename+, naa:mandatereference*, naa:requirement+)> <!ELEMENT vers:veoidentifier ( vers:agencyidentifier?, vers:seriesidentifier?, vers:fileidentifier, vers:versrecordidentifier?)> <!ELEMENT vers:transaction ( vers:transactionidentifier, vers:originator, vers:recipient*, vers:actionrequired*, vers:originatorscopy?, vers:transactiontype*, vers:businessprocedurereference*, vers:transactionreference*, vers:transactionlinkage*)> <!ELEMENT naa:agenttype (#PCDATA)> <!ELEMENT naa:jurisdiction (#PCDATA)> <!ELEMENT naa:corporateid (#PCDATA)> <!ELEMENT naa:corporatename (#PCDATA)> <!ELEMENT naa:personid (#PCDATA)> <!ELEMENT naa:personalname (#PCDATA)> <!ELEMENT naa:sectionname (#PCDATA)> <!ELEMENT naa:positionname (#PCDATA)> <!ELEMENT naa:contactdetails (#PCDATA)> <!ELEMENT naa: (#PCDATA)> <!ELEMENT naa:digitalsignature (#PCDATA)> <!ELEMENT naa:securityclassification (#PCDATA)> <!ELEMENT naa:caveat (#PCDATA)> <!ELEMENT naa:codeword (#PCDATA)> <!ELEMENT naa:releasabilityindicator (#PCDATA)> <!ELEMENT naa:accessstatus (#PCDATA)> <!ELEMENT naa:usagecondition (#PCDATA)> <!ELEMENT naa:encryptiondetails (#PCDATA)> <!ELEMENT naa:schemetype (#PCDATA)> <!ELEMENT naa:schemename (#PCDATA)> <!ELEMENT naa:titlewords (#PCDATA)> <!ELEMENT naa:alternative (#PCDATA)> <!ELEMENT vers:keywordlevel (#PCDATA)> <!ELEMENT vers:keyword (#PCDATA)> <!ELEMENT naa:description (#PCDATA)> <!ELEMENT naa:language (#PCDATA)> <!ELEMENT naa:relateditemid (#PCDATA)> <!ELEMENT naa:relationtype (#PCDATA)> <!ELEMENT naa:relationdescription (#PCDATA)> <!ELEMENT naa:jurisdication (#PCDATA)> <!ELEMENT naa:placename (#PCDATA)> <!ELEMENT naa:periodname (#PCDATA)> <!ELEMENT naa:functiondescriptor (#PCDATA)> <!ELEMENT naa:activitydescriptor (#PCDATA)> <!ELEMENT naa:thirdleveldescriptor (#PCDATA)> <!ELEMENT naa:datetimecreated (#PCDATA)> <!ELEMENT naa:datetimetransacted (#PCDATA)> <!ELEMENT naa:datetimeregistered (#PCDATA)> <!ELEMENT naa:type (#PCDATA)>

23 PROS 99/007 Specification 3: VERS Standard Electronic Record Format 22 <!ELEMENT naa:aggregationlevel (#PCDATA)> <!ELEMENT naa:mediaformat (#PCDATA)> <!ELEMENT naa:dataformat (#PCDATA)> <!ELEMENT naa:medium (#PCDATA)> <!ELEMENT naa:extent (#PCDATA)> <!ELEMENT naa:eventdatetime (#PCDATA)> <!ELEMENT naa:eventtype (#PCDATA)> <!ELEMENT naa:eventdescription (#PCDATA)> <!ELEMENT naa:usedatetime (#PCDATA)> <!ELEMENT naa:usetype (#PCDATA)> <!ELEMENT naa:usedescription (#PCDATA)> <!ELEMENT naa:actiondatetime (#PCDATA)> <!ELEMENT naa:actiontype (#PCDATA)> <!ELEMENT naa:actiondescription (#PCDATA)> <!ELEMENT naa:nextaction (#PCDATA)> <!ELEMENT naa:nextactiondue (#PCDATA)> <!ELEMENT naa:currentlocation (#PCDATA)> <!ELEMENT naa:homelocationdetails (#PCDATA)> <!ELEMENT naa:homestoragedetails (#PCDATA)> <!ELEMENT naa:rksid (#PCDATA)> <!ELEMENT naa:disposalauthorisation (#PCDATA)> <!ELEMENT naa:sentence (#PCDATA)> <!ELEMENT naa:disposalactiondue (#PCDATA)> <!ELEMENT naa:disposalstatus (#PCDATA)> <!ELEMENT naa:mandatetype (#PCDATA)> <!ELEMENT naa:refersto (#PCDATA)> <!ELEMENT naa:mandatename (#PCDATA)> <!ELEMENT naa:mandatereference (#PCDATA)> <!ELEMENT naa:requirement (#PCDATA)> <!ELEMENT vers:agencyidentifier (vers:text)> <!ELEMENT vers:seriesidentifier (vers:text)> <!ELEMENT vers:fileidentifier (vers:text)> <!ELEMENT vers:versrecordidentifier (vers:text)> <!ELEMENT vers:transactionidentifier (vers:text)> <!ELEMENT vers:originator (vers:text)> <!ELEMENT vers:recipient (vers:text)> <!ELEMENT vers:actionrequired (vers:text)> <!ELEMENT vers:originatorscopy (#PCDATA)> <!ELEMENT vers:transactiontype (vers:text)> <!ELEMENT vers:businessprocedurereference (vers:text)> <!ELEMENT vers:transactionreference (vers:text)> <!ELEMENT vers:transactionlinkage (vers:text)> <!ATTLIST naa:agenttype scheme CDATA #IMPLIED> <!ATTLIST naa:jurisdiction scheme CDATA #IMPLIED> <!ATTLIST naa:corporateid scheme CDATA #IMPLIED> <!ATTLIST naa:corporatename scheme CDATA #IMPLIED> <!ATTLIST naa:personid scheme CDATA #IMPLIED> <!ATTLIST naa:personalname scheme CDATA #IMPLIED> <!ATTLIST naa:sectionname scheme CDATA #IMPLIED> <!ATTLIST naa:positionname scheme CDATA #IMPLIED> <!ATTLIST naa:contactdetails scheme CDATA #IMPLIED> <!ATTLIST naa: scheme CDATA #IMPLIED> <!ATTLIST naa:digitalsignature scheme CDATA #IMPLIED> <!ATTLIST naa:securityclassification scheme CDATA #IMPLIED> <!ATTLIST naa:caveat scheme CDATA #IMPLIED> <!ATTLIST naa:codeword scheme CDATA #IMPLIED> <!ATTLIST naa:releasabilityindicator scheme CDATA #IMPLIED>

24 PROS 99/007 Specification 3: VERS Standard Electronic Record Format 23 <!ATTLIST naa:accessstatus scheme CDATA #IMPLIED> <!ATTLIST naa:usagecondition scheme CDATA #IMPLIED> <!ATTLIST naa:encryptiondetails scheme CDATA #IMPLIED> <!ATTLIST naa:schemetype scheme CDATA #IMPLIED> <!ATTLIST naa:schemename scheme CDATA #IMPLIED> <!ATTLIST naa:titlewords scheme CDATA #IMPLIED> <!ATTLIST naa:alternative scheme CDATA #IMPLIED> <!ATTLIST vers:keywordlevel scheme CDATA #IMPLIED> <!ATTLIST vers:keyword scheme CDATA #IMPLIED> <!ATTLIST naa:description scheme CDATA #IMPLIED> <!ATTLIST naa:language scheme CDATA #IMPLIED> <!ATTLIST naa:relateditemid scheme CDATA #IMPLIED> <!ATTLIST naa:relationtype scheme CDATA #IMPLIED> <!ATTLIST naa:relationdescription scheme CDATA #IMPLIED> <!ATTLIST naa:jurisdication scheme CDATA #IMPLIED> <!ATTLIST naa:placename scheme CDATA #IMPLIED> <!ATTLIST naa:periodname scheme CDATA #IMPLIED> <!ATTLIST naa:functiondescriptor scheme CDATA #IMPLIED> <!ATTLIST naa:activitydescriptor scheme CDATA #IMPLIED> <!ATTLIST naa:thirdleveldescriptor scheme CDATA #IMPLIED> <!ATTLIST naa:datetimecreated scheme CDATA #IMPLIED> <!ATTLIST naa:datetimeregistered scheme CDATA #IMPLIED> <!ATTLIST naa:datetimetransacted scheme CDATA #IMPLIED> <!ATTLIST naa:type scheme CDATA #IMPLIED> <!ATTLIST naa:aggregationlevel scheme CDATA #IMPLIED> <!ATTLIST naa:mediaformat scheme CDATA #IMPLIED> <!ATTLIST naa:dataformat scheme CDATA #IMPLIED> <!ATTLIST naa:medium scheme CDATA #IMPLIED> <!ATTLIST naa:extent scheme CDATA #IMPLIED> <!ATTLIST naa:eventdatetime scheme CDATA #IMPLIED> <!ATTLIST naa:eventtype scheme CDATA #IMPLIED> <!ATTLIST naa:eventdescription scheme CDATA #IMPLIED> <!ATTLIST naa:usedatetime scheme CDATA #IMPLIED> <!ATTLIST naa:usetype scheme CDATA #IMPLIED> <!ATTLIST naa:usedescription scheme CDATA #IMPLIED> <!ATTLIST naa:actiondatetime scheme CDATA #IMPLIED> <!ATTLIST naa:actiontype scheme CDATA #IMPLIED> <!ATTLIST naa:actiondescription scheme CDATA #IMPLIED> <!ATTLIST naa:nextaction scheme CDATA #IMPLIED> <!ATTLIST naa:nextactiondue scheme CDATA #IMPLIED> <!ATTLIST naa:currentlocation scheme CDATA #IMPLIED> <!ATTLIST naa:homelocationdetails scheme CDATA #IMPLIED> <!ATTLIST naa:homestoragedetails scheme CDATA #IMPLIED> <!ATTLIST naa:rksid scheme CDATA #IMPLIED> <!ATTLIST naa:disposalauthorisation scheme CDATA #IMPLIED> <!ATTLIST naa:sentence scheme CDATA #IMPLIED> <!ATTLIST naa:disposalactiondue scheme CDATA #IMPLIED> <!ATTLIST naa:disposalstatus scheme CDATA #IMPLIED> <!ATTLIST naa:mandatetype scheme CDATA #IMPLIED> <!ATTLIST naa:refersto scheme CDATA #IMPLIED> <!ATTLIST naa:mandatename scheme CDATA #IMPLIED> <!ATTLIST naa:mandatereference scheme CDATA #IMPLIED> <!ATTLIST naa:requirement scheme CDATA #IMPLIED> <!ELEMENT vers:documentmetadata ( vers:documentagent+, vers:documenttitle+, vers:documentsubject*, vers:documentdescription*, vers:documentlanguage*, vers:documentrelation*, vers:documentcoverage*,

25 PROS 99/007 Specification 3: VERS Standard Electronic Record Format 24 vers:documentdate, vers:documenttype*, vers:documentsource+ )> <!ELEMENT vers:documentagent (vers:text)> <!ELEMENT vers:documenttitle (vers:text)> <!ELEMENT vers:documentsubject (vers:text)> <!ELEMENT vers:documentdescription (vers:text)> <!ELEMENT vers:documentlanguage (vers:text)> <!ELEMENT vers:documentrelation (vers:text)> <!ELEMENT vers:documentcoverage (vers:text)> <!ELEMENT vers:documentdate (vers:text)> <!ELEMENT vers:documenttype (vers:text)> <!ELEMENT vers:documentsource (vers:text)> <!ELEMENT vers:encodingmetadata ( vers:fileencoding, vers:fileidentifier?, vers:filerendering)> <!ELEMENT vers:fileencoding (vers:text)> <!ELEMENT vers:fileidentifier (vers:text)> <!ELEMENT vers:filerendering ( vers:renderingtext+, vers:renderingkeywords?)> <!ELEMENT vers:renderingtext (vers:text)> <!ELEMENT vers:renderingkeywords (#PCDATA)> <!ELEMENT vers:file ( vers:filemetadata, vers:filedisposal?)> <!ELEMENT vers:filedisposal ( vers:disposalschedule, vers:disposaldate, vers:authorizingofficer)> <!ELEMENT vers:filemetadata ( naa:agent+, naa:rightsmanagement, naa:title, vers:subject*, naa:description*, naa:language*, naa:relation*, naa:coverage*, naa:function*, vers:date, naa:type?, naa:aggregationlevel, naa:format?, naa:recordidentifier, naa:managementhistory, naa:usehistory?, naa:preservationhistory?, naa:location?, naa:disposal, naa:mandate*, vers:veoidentifier)> <!ELEMENT vers:date ( naa:datetimecreated, naa:datetimetransacted, naa:datetimeregistered, vers:datetimeclosed?)> <!ELEMENT vers:datetimeclosed (#PCDATA)> <!ELEMENT vers:disposalschedule (#PCDATA)> <!ELEMENT vers:disposaldate (#PCDATA)> <!ELEMENT vers:authorizingofficer (#PCDATA)>

26 PROS 99/007 Specification 3: VERS Standard Electronic Record Format 25 Appendix Two: Digital Signature Infrastructures In developing a digital signature infrastructure there are three broad areas where implementation options are feasible. These areas are: When the record is digitally signed and by whom The association between the private key and the signer Where the public key of the signer is kept 1. Who signs the record and when? Who should sign a record and at what point in the record s life should it be signed? The first aspect to consider when answering this question is immutability. A signature locks the record. Once signed, the record cannot be modified. This immutability has both positive and negative features. On the positive side, the signature can demonstrate who signed the record, when it was signed, and that it has not been subsequently tampered with. On the negative side, the record cannot be modified even if this is necessary (e.g. to add more information). So the point at which the signature is applied will be a compromise; sufficiently late that information in the record will not change, but sufficiently early to provide maximum protection to the information. The second aspect to consider is responsibility. When a person (or a system) signs a record they are taking responsibility for authenticity and reliability of the record. A signature by the officer authorising the record has a different meaning to the signature of an Electronic Document Management System. 1.1 Signing by creator at point of record creation Record Creation Event Private Key Metadata Content Encapsulator Signed VEO Record Keeping System Figure 6: Signing by creator at record creation The first option is that the person (or system) that creates the record signs it at the point of creation. In the paper world, this is equivalent to an officer signing the a record as the last action before filing it. In an electronic environment, a digital signature could be affixed as part of the work flow (for example, as a step in the process of authorising an action or creating a

27 PROS 99/007 Specification 3: VERS Standard Electronic Record Format 26 document). Alternatively, the digital signature could be affixed a side effect of taking an action in the system (for example, checking a document into an EDMS as a version instead of a draft, or putting a document up on a Web server). Finally the user could consciously invoke a program to turn a document into a record and file it, and this program could affix the digital signature. The major advantages of the creator signing the record at point of creation are: Responsibility. It is possible for the system to explicitly prompt the user to agree to the signing of the record. This ensures that the application of the digital signature is a conscious act of will by the creator. Even if the signature is automatically applied by the system (without an explicit act of will by the creator), the signature explicitly ties the record to a particular user and a particular time without depending on other systems. Both aspects increase the evidentiary weight of the record. Protection. Signing at point of creation gives maximum protection against alteration. Once signed, the evidentiary status of the record is not dependent on the security of the database or data storage system that is holding the record. Once again, this increases the evidentiary weight of the record. The disadvantages to the creator signing the record at point of creation are: Immutability. Once signed, the record cannot be modified (is immutable). This means that the record must be, at point of creation, in the VERS archive format. Apart from the storage issue (to be considered in the next bullet point), any valid alteration or augmentation of the metadata associated with the record requires the formation of an onion record where the new metadata is layered around the original record and the resulting record resigned. Metadata may be legitimately altered over the life of a record, examples include refiling the record, correcting the descriptive information, and making new links between related records. Metadata may also be extended, for example the continual accretion of audit logs recording accesses to the record and management decisions about the record. Storage. Immutability requires the record to be in the VERS archive format at the point of creation. At this point it may still be necessary to keep a copy of the content in the original format in another system (e.g. for further work). This will require storage of multiple copies. 1.2 Signing by application at point of record archiving The second option is to sign the record when it is transferred to a Record Keeping System as a VEO. Technically, the previous option satisfied this definition (the VEO was created and transferred to the Record Keeping System immediately it was created), but the model in this scenario is for the record to be first managed in an application (e.g. an EDMS or RMS) for a period of time. Subsequently the VEO is formed, signed and transferred to the Record Keeping System. This transfer may occur after a set period of time (e.g. 1 year), or may be triggered by an event (e.g. closing of a project, or a file). In the following discussion, it is assumed that the record is initially stored in an EDMS, but the record may be stored in other types of system (e.g. an RMS).

28 PROS 99/007 Specification 3: VERS Standard Electronic Record Format 27 Record Creation Event Metadata Content Application Application's Private Key Metadata Content Encapsulator Signed VEO Record Keeping System Figure 7: Signing by application at point of record archiving If the VEO is created by a system well after the actual creation of the record, the creator of the record cannot sign it as the creator s private key is unlikely to be available when the record is signed. If the system stored the creator s private key to allow later signing, this would destroy the evidential validity of the signature as the system could use the stored key to sign any record at any time. Asking the user to subsequently sign the record during transfer will not work, first because the user may not be available, and second because the user would be required to inspect the record to ensure that it really was the record. The alternative to the creator signing the VEO during record creation is for the EDMS to sign the VEO during transfer to the Record Keeping System. This signature signifies that at the time of creating the VEO, the EDMS believed that the record was created by the recorded user, at the recorded time, and has not been subsequently changed. The long term evidentiary status of the record clearly depends on a chain of authenticity. The digital signature will guarantee the evidential status after construction of the VEO and transfer to the Record Keeping System. But the accuracy of the information included in the VEO clearly depends on the security of the EDMS. Essentially, in this model, the EDMS has to act as a vault that protects information stored in it from undetectable modification. This is achieved by providing a limited set of functions for modifying information and logging all uses of these function. The major advantages of the EDMS signing the record at some time after creation include: Simplified private key management. Individual creators of records do not need to be issued with a public/private keypair, only the EDMS itself. Simplified metadata management. A problem with creating and signing the VEO at creation of the record was the difficulty of modifying or extending the metadata. This problem is less severe if the VEO is created subsequently. While the record is held within the EDMS, any of the metadata may be modified or extended. The EDMS audit logs document the changes. This audit log forms part of the VEO when it is finally produced.

29 PROS 99/007 Specification 3: VERS Standard Electronic Record Format 28 This is a particular benefit as changes to the metadata are most likely early in the life of the record. Clear functional delineation. In this model, the EDMS becomes the system where documents and records are kept while they are actively being worked upon. The Record Keeping System is where the records are kept after they have become fixed and only need to be viewed. Reduced load on Record Keeping System. Many documents and records created in an agency have an extremely short life and many will be discarded before creation as a VERS object. The major disadvantages of signing the record after creation include: Weakened evidential status. The evidential status of a record depends on an evidential chain. To decide whether a record is reliable now depends on four issues (i) how the EDMS knew who the user was that created the record; (ii) the integrity of the EDMS to prevent undocumented modifications to the record (including software back doors and bugs); (iii) the integrity of the conversion to a VEO; and (iv) the digital signature after conversion. 1.3 Summary Storing a record in an EDMS (or similar application) significantly simplifies implementation of the VERS Record Keeping System. The major disadvantage is the longer chain of evidence required to prove integrity. However, this chain of evidence is no different to that required to introduce records from an HR or financial system into court; which is commonly done now. In practice, different records may be treated differently. Records that are normally unsigned today could be initially managed within an EDMS and signed by it when the VEO is subsequently created. Such records will have a slightly stronger evidential status than similar paper records. On the other hand, records that are formally signed today could be signed immediately upon creation by the user. 2. Where is the private key of the signer kept? A digital signature does not actually prove who signed a record. All it proves is that someone in possession of a particular private key signed the record. The proof that a particular person signed a record consequently depends on the system that stores the private keys and ensures that only one person can use a particular key. A secure infrastructure implies a strong association that a particular person did actually sign the record. A weak infrastructure has a weak association. This system is doubly crucial due to the complexity of the private key. Unlike conventional passwords which are selected by the user and are normally selected to be easy to remember, private keys are long (up to four times the length of this paragraph), and are composed of random characters. The length and randomness of the private key make it impossible for users to remember the key, or to type it in when required. Private keys must be electronically stored somewhere.

30 PROS 99/007 Specification 3: VERS Standard Electronic Record Format 29 The two crucial aspects of storing private keys are: How strong is the association between the user and the private key? How secure is the storage of the private key? 2.1 Keyring Files The cheapest and simplest solution is to store the private key in the user s home directory. This solution is adopted (by default) by PGP where the private key is stored in a special keyring file. This keyring file is only readable by the user, or by software being run under the authority of the user. When it is necessary to sign a digital object, the user runs the signature software (or the signature software is run on their behalf) which reads the keyring file to extract the private key. 1. User logs in to envrionment User's Environment Application 2. User runs Application Keyring File 3. Application access user's Keyring file to get private key 4. Application signs VEO on behalf of user VEO Figure 8: Keyring Files This approach is cheap to implement as no special hardware to store private keys is required to be installed or maintained. However, storing the private key in a file on a fileserver only provides a relatively weak association between the user and the private key, and is relatively insecure. Basically, the association between the user and the private key is achieved by the user s logon identity which is based on the knowledge of a user name and password. The association between the user and the private key is relatively weak because the private key can be used by anyone who: Can read the file (in particular system administrators can normally bypass system security). Has been given the account password by the user Uses the computer while the user is logged in.

31 PROS 99/007 Specification 3: VERS Standard Electronic Record Format 30 Discovers the account password. This may occur by simply guessing, or an exhaustive search of the possible passwords, and is more likely if the user chooses a poor password (i.e. one that is short, contains only letters, is a common word or easily found out). It may also occur due to observing a user logging in, or due to a compromise of system security (e.g. a keystroke sniffer). Fundamentally, the private key is relatively insecure when stored as a file as access to the private key is only protected by means of the normal file system security. Most operating systems have security holes, and many have a lot of holes. Although storing the private key in a file on the fileserver gives a relatively weak association between the user and the private key, and is relatively insecure, the level of security may be sufficient. This security is no worse than is currently accepted within many agencies for their normal operations. The sender of an , for example, is usually only identified by the login account from which the was sent, and documents within many agencies are only protected using the normal file system security. 2.2 Key Databases An alternative to storing the private keys in a file is to store the key in a database. This is, for example, how some Lotus Notes implementations store private keys. 1. User logs in to environment User's Environment Application Key Database 2. User runs Application 3. Application access key database to get private key 4. Application signs VEO on behalf of user VEO Figure 9: Key Databases Like keyring files, storing the private key in a database is a relatively simple solution. It has an advantage over files in that the database security can be higher than the file system security. In addition, there can be a stronger association between the user and the public key as it may be necessary to for the user to authenticate themselves to the database before being allowed to retrieve the private key. However, even if provided, this level of authentication is often turned off for convenience. In summary, using key databases provides similar advantages and disadvantages to storing private keys in files, but key databases may provide slightly stronger security and association between users and keys. 2.3 Dumb Smartcards The weakness with storing the private key in a file or database on the computer is that this depends on the normal system security. Anyone with access to the file or database, or anyone

32 PROS 99/007 Specification 3: VERS Standard Electronic Record Format 31 who can break the normal system security, can use the private key. An alternative is to store the private key outside the computer on a smartcard under the user s control. 1. User logs in to environment User's Environment Application 2. User runs Application Smartcard Reader 4. Application gets users private key from smartcard VEO 5. Application signs VEO on behalf of user Smartcard 3. User inserts Smartcard Figure 10: Dumb Smartcards Smartcards are simply pieces of plastic which contain an embedded computer chip. The chip can vary in complexity; at one extreme the chip is a small piece of memory, at the other the chip can be a sophisticated computer in its own right. When inserted into a smartcard reader, connections are made to the chip and information can be transferred to and from the chip. Smartcard technology is becoming quite common; for example the current thick plastic Telstra phonecards are simple smartcards. Simple smartcards can be used to store private keys. When it is necessary to sign a digital object, the user inserts their smartcard into a smartcard reader. Access to the smartcard can be protected by a password which the user is prompted to enter (this protects against casual theft of the smartcard). The signature program then reads the private key from the smartcard and uses it to sign the object. For security, it is essential that the signature program deletes its copy of the private key once the signature has been calculated. Clearly, implementing a smartcard solution costs money. Smart card readers have to be added to all computers on which documents will be signed (probably most, if not all, computers). This cost includes purchasing the hardware, installing it on the computers, and ongoing maintenance and support. In addition, an infrastructure needs to be developed to create and distribute smartcards to users. Even simple smartcards provide a stronger association between the user and the private key than storing the key in a file or database because the private key is stored on a object that the user can directly control. The user can remove the smartcard from the computer when it is not being used to sign objects and also simply having access to a user s account no longer means that objects can be signed as if from that user. In addition, the private key will be available for shorter period in the computer and this will make it more difficult to copy or access the private key. However, a dumb smartcard is not a complete solution to private key security. Although it is possible for a user to remove the smartcard from the computer, there is nothing that makes

33 PROS 99/007 Specification 3: VERS Standard Electronic Record Format 32 them remove the smartcard. A user could leave the card in the computer for days. This can be protected against by requiring the user to enter a password every time the smartcard is actually used. Smartcards can, of course, be lent or stolen. Passwords can protect the card against unauthorised use, but not use authorised by the card holder. From the point of view of protecting the private key from access, the use of a Smartcard means that the private key is held in the computer for shorter periods. However, the private key must be read from the card and stored in the computer when it is used. There is nothing to prevent the software from saving the private key somewhere and not deleting it after use. At a more paranoid level, an intruder could obtain a core image of the running program and analyse it to capture the private key. 2.4 Smart Smartcards One problem with the dumb smart card described in the previous section is a security weakness. To use the private key, it must be read from the smartcard and copied into the memory of a computer. There is no way of ensuring that this copy is destroyed after use. 1. User logs in to envrionment User's Environment Application 2. User runs Application 3. User Smartcard inserts Smartcard 5. VEO sent to smartcard for signing Smartcard Interface 4. Application passes VEO to smartcard for signing VEO 6. Application outputs VEO Figure 11: Smart Smartcards To address this weakness, an alternative is to use a smart smartcard. The chip on a smartcard can be a reasonably powerful computer in it own right. The smartcard computer can be programmed to calculate digital signatures independently of the main computer. To sign a digital object with a smart smartcard, the user inserts it into the host computer. The host computer passes the object to be signed to the smartcard which calculates the digital signature using the private key kept on the card. The signature is returned to the host computer. The private key never leaves the smart card. By keeping the private key on the smartcard, and making no provision to extract the key from the card, a smart smartcard provides the ultimate secure storage.

34 PROS 99/007 Specification 3: VERS Standard Electronic Record Format 33 The use of a smart smartcard does not give a stronger association between the smartcard and its owner than the use of a dumb smartcard. Possession of the smartcard (and the password to use, if required) allows the possessor to sign objects. 2.5 Biometrics Biometrics is the measurement of biological features such as fingerprints, palm prints, and retinal scans. Biometrics does not replace the use of a private key in a digital signature, or make the storage of a digital signature more secure. The use of biometrics can, however, strengthen the association between the private key and the user. For example, a smart smartcard can store the user s retinal scan and only sign an object after being given a matching retinal scan freshly scanned from the user. Essentially, the biometrics provide a more reliable replacement for the password. Users cannot disclose or loan their retinal scan! In practice, however, the strength of the association still depends on the system. The smartcard, for example, will sign a record after it receives the correct retinal scan. The smartcard cannot know if this retinal scan was freshly scanned, or has been previously stored by the system and replayed. The obvious weakness of biometrics is the cost of the scanners necessary to generate the biometric. 2.6 Summary The two key aspects to the storage of private keys are: The strength of the association between the private key and the user The security of the storage of the private key. The security of the storage is a straightforward technical problem. Solutions range from storing the key as data in a computer system, to storage on a smartcard, to processing on a smartcard. Security is increased as potential access to the private key is reduced. Security is maximised when the private key is locked on the smartcard from which it cannot be copied. The cost of implementing a security solution increases as the security increases. For most records handled within government, storing the private key in the user s home directory or in a database is likely to give sufficient security. Records created by particular users (e.g. Ministers, Departmental Secretaries, and Assistant Secretaries) may be sufficiently important to warrant at least a dumb smartcard solution. The association between the private key and the user is a more difficult problem to solve. In most cases, the association depends on the user knowing a password which either provides access to an account, or to the smartcard. Users often disclose their password to other users. The use of biometrics to replace the password provides a stronger association, although at a significant increase in cost. 3. Where is the public key of the signer kept? To check a digital signature requires the public key of the signer. A public key infrastructure (PKI) can ensure that the public key can be trusted. There are, however, three issues with implementing a PKI in a Victorian government agency:

35 PROS 99/007 Specification 3: VERS Standard Electronic Record Format 34 PKIs are not designed to reliably store certificates for long periods of time PKI implementations are complex and difficult to run There is currently no WOVG PKI. The following discussion refers to user certificates and CA certificates. User certificates contain the public key of a user and are signed by certification authorities. CA certificates contain the public key of a certification authority and are signed by other certification authorities. Each VEO contains copies of the user certificates for each user that signed the record. This allows the digital signatures protecting the contents of the VEO to be checked without accessing an external PKI. The only remaining issue is checking the validity of the certificate contained within the VEO. 3.1 Use unsecured public keys VEO Certificate Signer's Public Key Q: The three top VEOs were signed by this user. Was the fourth? A: Are all of the public keys in the VEOs the same? VEO VEO VEO Certificate Signer's Public Key Certificate Signer's Public Key Certificate Signer's Public Key? Figure 12: Use of Unsecured Public Keys It is possible to check the validity of the public keys without using a PKI. Since each VEO contains the public key of the user that signed the record, it is not necessary to use a PKI to obtain the user certificate. To check the validity of the public key, all that is necessary is to compare the key with that stored in other records signed by the user around the same time. If all of these stored public are identical, then either someone has forged the entire body of records by that user, or the public key is correct. Conceptually, this approach mirrors how we validate conventional handwritten signatures, particularly of historical records. If we have a document that is purported to be signed by a particular person, we compare the signature on the purported document with other documents supposed to be signed by that person. If all of the signatures are the same (or very similar), then the assumption is that they are valid. Since the user certificates are part of the preserved record, there is no problem in storing the user certificates as long as required. The difficulty with using just this approach is that it is not possible to formally check the validity of the certificate if this is subsequently necessary.

36 PROS 99/007 Specification 3: VERS Standard Electronic Record Format Public Keys stored as Records within VERS VEO Content Digital Signature Certificate Creator's Public Key VEO Certificate CA's Public Key Digital Signature Certificate CA's Public Key Figure 13: Public Keys stored as Records within VEO A certificate is simply a data structure which could be stored in the Record Keeping System like any other record. Effectively, the Record Keeping System is keeping the records of the public keys issued to a particular user (or certification authority). These certificate records can be linked together to form a PKI. The advantage of this approach is that the Record Keeping System is responsible for preserving the public keys as long as they are required. In addition, a file of certificate records can be transferred or copied to other repositories if the records that refer to them are transferred. An issue with this approach is the requirement that the process for issuing a new public/private key must be extended to generate a certificate record. 3.3 Unsecured Agency Directory The third option is to store public keys in an organisational directory (for example in a Lotus Notes public address book). The public keys need not be stored within certificates. Clearly, the user checking a digital signature must trust that the organisational directory has returned the correct public key (and no substitution has occurred while the public key was in transit on the network). There is little reason why the user should not trust the directory and network in this fashion. Many agencies do not currently encrypt, nor sign, traffic over the network and consequently trust both their servers and their network. If either were subverted, the intruder could do far worse damage than altering the public keys used for checking signatures on records.

37 PROS 99/007 Specification 3: VERS Standard Electronic Record Format 36 VEO Content Digital Signature Certificate Creator's Public Key Agency Public Key DB Figure 14: Unsecured Agency Directory Note that the assumption is that the public key is only being used to check the validity of records. If it is also being used for other security applications (e.g. as the basis for encrypting traffic over the network) then the security issues become far more severe. The organisational directory will need to be set up to store the sequence of public keys that have been allocated to individual users over time. It will need to be integrated into the process that allocates public/private key pairs. The directory must be capable of returning the key that was in use at a particular time. If the records are ever transferred from the agency (e.g. to PROV or to another government agency), the public keys must be transferred with the records. Again, the difficulty with using just this approach is that it is not possible to formally check the validity of the public key if this is subsequently necessary. 3.4 Summary A key concern with the storage of public keys is their long term storage. The public keys need to be kept for as long as the records signed by that key are kept. The only effective method of long term storage is to treat the public key (or the certificate containing the public key) as a record and store them in the Record Keeping System. This is particularly useful if the records are migrated as it means the public keys can be migrated or copied with them. There is currently no large scale public key infrastructure systems widely deployed within Australia. This, however, is expected to change over the next two to five years.

38 PROS 99/007 Specification 3: VERS Standard Electronic Record Format 37 Appendix Three: Digital Signature Implementation Options Option 1: Records signed by the application with local storage of private keys & no public key infrastructure Record 1. Record content & metadata is stored in Application Application 2. Record is subsequently encapsulated as a VEO using Application s private key Appln Private Key Appln Public Key 3. Public key is only included in VEO. No Public Key Infrastructure is in place Record Keeping System Figure 15: Illustration of Option 1 In this option, records are initially stored within an application such as an EDMS. VEOs are only created when the record is transferred to the Record Keeping System. The VEOs are signed by the application as part of the encapsulation process. This requires: That the application capture sufficient metadata to allow the VEO to be created at a subsequent point in time. In particular, the application must capture information about who created the record and when it was created. That the application provides a vault that only allows modification to the record (and its associated) metadata through audited access points. That this information is securely transferred to the Capture System. With this option only the applications are issued with a public/private key pairs. Individual users are not issued with public/private keys. The keypair issued to the application is stored securely in a file or database. The private key is used by the application to sign all generated VEOs. A certificate containing the matching public key is included in each record generated by the application. No public key infrastructure is implemented to authenticate the certificates.

39 PROS 99/007 Specification 3: VERS Standard Electronic Record Format 38 The public key is authenticated, when necessary, by comparing the public key contained in the corpus of records produced by the application. While simple to implement, this package has the following weaknesses: A complicated chain of evidence. Showing that a particular user generated a record involves showing (i) that the application accurately captured the users identity, (ii) that it is only possible to modify records within the application, (iii) that the VEO generation is accurate, and (iv) that the record has not been tampered with subsequent to signing. Lack of the ability to formally demonstrate that the certificates stored in the records are valid. Option 2: Records signed by Users with file or database storage of private keys & public keys stored as records Record Key DB 1. Record content stored in Application Application 2. Record is encapsulated, signed with user's private key, and stored in Record Keeping System 3. Public keys are stored as records in the RKS Record Keeping System Figure 16: Illustration of Option 2 In this package, VEOs are created and signed by the user when the record is created (e.g. when checking a version into an EDMS). The VEOs are then immediately stored in the Record Keeping System. This means that the information is being stored twice; once in the EDMS and once in the Record Keeping System. The users private key is kept in a file in their directory (i.e. PGP fashion), or in a database (e.g. in a Lotus Notes public address book). The users public key is included in a certificate included within each record signed by the user. The user certificates are signed by a certification authority. The certificates for this certification authority are kept as records

40 PROS 99/007 Specification 3: VERS Standard Electronic Record Format 39 within the Record Keeping System. Each normal record is linked to the CA record that can be used to verify its integrity. This package is more difficult to implement that the previous package. The advantage over the previous package is that the evidence chain is much simpler and it is possible to show a conscious decision by the creator to sign the record. It is also possible to formally verify the certification chain. The package has the following weaknesses: User identity. In practice, the identity of the user is based on the user s login. Anyone who has access to the user s computer account (e.g. by cracking or guessing the password, being told the password, leaving the account logged in, or system administrators) can sign records as if by the user. The Record Keeping System must be tightly linked to the digital signature infrastructure. The Capture components must be able to retrieve the private key from the file or directory in which it is contained. Whenever the public key of a certificate authority is modified, a new Certificate record must be created in the Record Keeping System. Since this package uses a (simple) public key infrastructure, it will be possible to link into Whole of Victorian Government PKI or Australian PKIs. However, this will add additional challenges in archiving the certificate records from the certificate authorities. Option 3: Records signed by Users with private keys stored in Smartcards and public keys stored as records This package is identical to the previous one, except that private keys are stored on smartcards. The advantage of this is a user s identity is linked to the possession of the smartcard and is not linked to a login id. There is consequently less scope for people forging signatures. The smartcard could be linked to other security practices such as building access or computer access. In practice, however, the cost of implementing a smartcard solution would be likely to be prohibitive. It would be necessary to attach smartcard readers to many, if not all, machines. It is necessary to implement a smartcard creation and distribution infrastructure. Since there is a high implementation cost for this approach, it is assumed that a formal public key infrastructure would be put into place. Each record created would include the creator s certificate. Whenever a certificate is created within the department, a record is made of the certificate.

41 PROS 99/007 Specification 3: VERS Standard Electronic Record Format 40 Record Smartcard 1. Record content stored in Application Application 2. Record is encapsulated, signed with user's private key, and stored in Record Keeping System 3. Public keys are stored as records in the RKS Record Keeping System Figure 17: Illustration of Option 3

42 PROS 99/007 Specification 3: VERS Standard Electronic Record Format 41 Appendix Four: Digital Storage Media for VERS

43 CSIRO Mathematical and Information Sciences DIGITAL STORAGE MEDIA FOR VERS By Robert Bell and Andrew Waugh Report for Department of Infrastructure September 1999 CSIRO Mathematical and Information Sciences 723 Swanston St Carlton VIC 3053

44 Digital Storage Media for VERS 2 Summary This report provides recommendations for agencies within the Victorian Government as to the best technology currently available to store VERS records within Agencies or within PROV. The report considers a range of factors which are important for long-term safe keeping of information. These include the: types of permanent storage media, media characteristics media life and durability capacity of the media transfer rates and access times obtainable platforms which support the media industry acceptance of the type of media the ease of use. The report recommends a small range of types of magnetic tape, which encompasses the needs of small to large agencies, and PROV. Magnetic tape is the preferred medium because of high densities, high capacities, reliability, industry acceptance and independence from vendor file systems. For smaller agencies, CD-ROM and successor technology may be suitable because of lower volumes, and cost constraints. For transfers, the use of the Internet is recommended, but if this is not viable or not feasible (due to, say, security issues), then a range of tapes and removable discs is suggested. All storage systems should store at least two copies of records, and we would recommend adopting different storage technologies for the primary and secondary copies. This reduces the chance of data loss due to a bad manufacturing batch, or problems with the readers. We would particularly caution against adopting systems that use new technology. New technology is often attractive as it promises high capacity at a lower cost than existing technology. Unfortunately, the history of computer storage is littered with new technology that either did not live up to its initial promise (particularly with regard to reliability), or quickly went out of production due to the failure of the company that developed it. In addition we would recommend care in selecting components so that selection of one particular component (media type, data storage management software, host operating system or host hardware) does not force the selection of the other components. A good data storage system should be flexible and handle many components. Recommendations for small agencies For agencies that generate up to 10 Gigabytes of data annually, we recommend storage on either Travan magnetic tapes, writable CDs, or Zip drives. Report prepared for DOI by CSIRO Mathematical and Information Sciences October 1999 Version 1.0

45 Digital Storage Media for VERS 3 At the low end, a manual data storage system would be around $1000, but it should be noted that this system would require manual loading and unloading of media and would consequently have a relatively high running cost. Purchase of a small CD-R jukebox (robot) would avoid this manual handling and would cost between $10,000 and $30,000 depending on capacity. Recommendations for medium agencies For agencies that generate between 10 Gigabytes and 1.5 Terabytes of data annually, we recommend storage on Quantum DLT drives. Normal data storage practice is to store two independent copies, so this translates to between 20 Gigabytes and 3 Terabytes of storage annually. The expected cost of such a system would be around $32,000 capital cost and around $16,000 per annum consumables. This figure comprises two drives (around $12,000 each), a robot (around $20,000). This costing does not include staff costs. These would be between 0.5 and 1.0 effective full time position. Recommendations for large agencies For agencies that generate over 1.5 Terabytes of data annually, we recommend storage on 3490E/Timberline drives with 9840 drives for the second copy. We also recommend that at least two independent copies be made of data on separate media technologies. This means that the actual increase in storage is twice the amount of data generated. The expected cost of such a system would be around $700,000 capital cost and around $10,000 per Terabyte of data stored in the system annually. This figure would buy a large silo (e.g. a StorageTek silo) and associated drives. Staff costs would be between 1 and 2 effective full time positions. Because these systems are very widely used for data storage, they can be connected to a very wide range of host machines running a range of operating systems. Recommendations for PROV For PROV, we recommend storage as for large agencies. Because many of the records stored in PROV are accessed infrequently, an option would be to store some of the media off-line on racks outside the robot. This would require a smaller robot (possibly equivalent to that required for a medium sized agency), but with a high staff cost, greater access time, and greater chance of misplacing media. PROV may wish to keep Ion beam technology such as the HD-Rosetta under review. This technology has the potential for very reliable storage of very high density information. Report prepared for DOI by CSIRO Mathematical and Information Sciences October 1999 Version 1.0

46 Digital Storage Media for VERS 4 Recommendations for transfer formats We recommend that PROV accept transfer of records from an agency by means of the Internet and by a limited set of media formats. We recommend PROV follow the approach taken by NARA s CERA which copies records to new media held within the PROV system, and returns the original media to the agencies. This allows PROV to control the quality and format of the media storing records in its repository. We recommend that PROV accept the following media formats: ZIP discs CDs written according to ISO format tapes Where to from here? It is strongly recommended that any large or medium agency, or PROV itself, implementing a data storage system should obtain expert assistance in the planning the system, including capacity required, location, off site backup and disaster recovery selecting hardware and data management software to suit the agencies particular environment installation and testing of the hardware and software setting up of systems and processes to ensure that data will be managed reliably for the long term. It is recommended that a small agency should obtain expert assistance in these areas, possibly in conjunction with the planning for a VERS system. Report prepared for DOI by CSIRO Mathematical and Information Sciences October 1999 Version 1.0

47 Digital Storage Media for VERS 5 Table of Contents 1 Background Requirements Structure of the Report Digital Storage Technology On-line and removable media Automated and manual operation Refreshing media and moving to new technology Hierarchical Storage Management Media Types Removable magnetic disc (e.g. floppies, Zip, Jazz, SuperDisk) Removable optical discs (e.g. CD-ROM, DVD, and various optical disc) Magnetic tape (e.g. DLT, 3490E, Travan, QIC, Exabyte, 4 mm) Ion-beam etching (e.g. HD-Rosetta) Optical tape (e.g. ICI, Rome Labs) Media Life Expectancy General Recommendation for storage Tape Technology Why Tape? Assessment of Media Tapes CDs Drives, Robots, and Hosts Recommendations Large Agencies and PROV Medium Sized Agencies Small Agencies Transfer Media Project Specification Long Term Storage Media for Agencies Long Term Storage Media for PROV References Glossary...25 Report prepared for DOI by CSIRO Mathematical and Information Sciences October 1999 Version 1.0

48 Digital Storage Media for VERS 6 Background Requirements The Victorian Electronic Strategy envisages storing the electronic records of the Victorian government as electronic objects instead of printing them to paper. Clearly, this will result in the storage of a significant amount of data within Victorian agencies and, eventually, by Public Record Office Victoria. This report was commissioned by PROV to identify what storage technologies could be used within agencies and within PROV to reliably store electronic records in a cost effective fashion. The consultancy specification issued by PROV is included in Section 6. The following requirements for long-term storage of records in electronic form are common to both the Agencies and PROV: longevity of medium durability of medium high capacity low cost widely acceptable on-line / near-line The differences between the requirements for PROV and the Agencies are mainly dependent on the volumes of information to be handled, for off-line versus on-line access, the timescale for storage the cost constraints. In the following discussion, distinctions will be made between the recommendations for the Agencies and PROV based on these discriminating factors. Structure of the Report The report commences with a discussion of digital storage technology, including a survey of available media types. We then make and justify a general recommendation that storage systems should be based on tape based technology in section 3 and follow this, in section 4, with an assessment of potential tape media. From this assessment we make specific recommendations for various applications in section 5. Section 6 makes recommendations as to the media on which records should be transferred to PROV. The remaining sections are supporting information. These include the project specification received from PROV, References, and a glossary. Report prepared for DOI by CSIRO Mathematical and Information Sciences October 1999 Version 1.0

49 Digital Storage Media for VERS 7 Digital Storage Technology On-line and removable media Media is divided into on-line, near-line, and off-line. On a typical desktop PC, the hard disc is an example of an on-line media. The data on the hard disc is accessible (or on line ) at all times. The floppy disc and the CD-ROM are examples of off-line media. A user might have hundreds of floppy discs (or CDs), but the data on them is off-line and only becomes accessible when the floppy or CD is actually loaded into the reader on the computer. The classic record jukebox is an example of a near-line system. This uses off-line media, but has a small robot to load the media from a storage area into the player. Access to the data is faster than if the off-line media had to be manually loaded, but not as fast as from an on-line media. Although uncommon on desktop PCs, jukeboxes (or silos) to store computer media are manufactured and extensively used. Off-line and near-line media is referred to as removable media because it can be removed from the computer. Removable media storage is still far cheaper than on-line disc, particularly as the storage volume becomes large and the cost of the drives is amortised over a large number of storage volumes. For example, tape can be as cheap as $2 per Gigabyte for the media costs, whereas the cheapest on-line disc is around $25 to $50 per Gigabyte (The Age Green Guide, 9th September 1999). Removable media provides the highest density storage. For example, a StorageTek Redwood cartridge can store 50 Gigabyte in a box around 15 cm square by 2 cm deep. Current non-volatile storage for electronic information can be broadly classified into the following removable types: 1. Removable magnetic disc (e.g. floppies, Zip, Jazz, SuperDisk) 2. Removable optical discs (e.g. CD-ROM, DVD, and various optical disc) 3. Magnetic tape (e.g. DLT, 3490E, Travan, QIC, Exabyte, 4 mm) 4. Ion-beam etching (e.g. HD-Rosetta) 5. Optical tape (e.g. ICI, Rome Labs) Media technology is continually evolving. New companies bring out new technologies, new media types, and new formats, with the promise of greater storage capacity at lower cost. However, an organisation aiming to achieve highly reliable, long term, data storage is not the place to experiment with leading edge technologies. Even when supported by established vendors, it is very common for new technologies to have problems with quality control, leading to, for example, batches of tapes with a high error rate, or readers that damage the media. New technologies can become obsolete very quickly when the sole supplier ceases to support the product. Providing highly reliable, long term, storage is best achieved by adopting industry standard formats and systems with a proven track record. Selection of systems based on new technology should be left to organisations operating at the extreme edge of data storage requirements (i.e. very large volumes) which have extensive experience in data storage and specialist staff. Report prepared for DOI by CSIRO Mathematical and Information Sciences October 1999 Version 1.0

50 Digital Storage Media for VERS 8 Automated and manual operation The use of removable media leads to the issue of loading and unloading the media from the readers. The use of robots to automatically load media is universal in medium and large data storage centres (and is implicit in the use of near-line storage). A robot consists of a media storage section, several readers, and a robot arm that automatically retrieves media from the storage and inserts it into the reader for use. The use of robots has a number of advantages over manual loading and unloading of media. These include: Reduced operational cost due to the saving of the wages of the operational staff who would otherwise be required to load and unload media Greater responsiveness to demands to load media Twenty-four by seven availability Greater reliability Lower chance of mislabeling or misplacing media Low cost refreshing of media and migration to new media technology (this is covered in more detail below) The ability to implement Hierarchical Storage Management solutions (this is covered in more detail below) In summary, robots give a far better service at a lower running cost (when staff costs are considered). In the remainder of the report we assume that data storage system will be built around a robot, except, perhaps, for the smallest agencies. Refreshing media and moving to new technology No piece of media lasts forever, nor does a particular type of technology. For this reason it is necessary to periodically Copy data from an old piece of media to a new piece of media (of the same technology). This is known as refreshing. Copy data from media in one format to a new, replacement, format. Manual operation of a data storage system makes refreshing and movement to a new technology prohibitively expensive. A robot, however, makes these tasks simple. The system can automatically refresh media upon trigger events (after a particular number of reads, after a particular life, or upon reaching a particular error rate). The system keeps track of the information necessary to fire these trigger events. Refreshing can be programmed to occur automatically at times of low demand. Migrating from one technology to another is simple if the robot is equipped with media readers of different technology. Migration is then effectively the same as refreshing, except the refresh is to the new technology. It should be noted that, as new technology is invariably of higher density than the old technology, migration increases the capacity of the robot without increasing costs. Report prepared for DOI by CSIRO Mathematical and Information Sciences October 1999 Version 1.0

51 Digital Storage Media for VERS 9 The cost of refreshing with a robot is the cost of the replacement media. The number of pieces of media that need to be replaced annually is proportional to the total number of pieces managed divided by the average lifespan of the media. The cost of migrating to a new technology is primarily the cost of the new readers. While there is the cost of the new media, this is offset against the cost of the media that would have been purchased for refreshing. In addition, the improvement in storage capacity normally means that the total number of new media required is far less than if refreshed to the old media. Finally, the greater capacity of the new media means that upgrading to a new technology effectively add significant additional capacity to the robot. Hierarchical Storage Management Media Types Hierarchical Storage Management (HSM) is a technique where the system automatically moves data between media to optimise performance. Typically, data is moved between disc (rapid access, but high storage cost) and tape (slower access, but far lower storage cost). Data is initially stored on the disc until a highwater capacity threshold is reached. Data that has not been recently used, or which is large, is automatically copied to tape. If the user attempts to access data that has been migrated to tape, the system automatically copies the data back to the disc. The advantage of HSM systems is that data storage is managed transparently to the user and programs run by the user. The data always appears to be on disc, but occasionally takes longer to access. Removable magnetic disc (e.g. floppies, Zip, Jazz, SuperDisk) The format of removable discs depends on the underlying operating system because the need to provide random access to the data on the disc. This leads to dependency on operating systems and we have DOS or Mac formatted discs, Zip drives, etc. This makes removable magnetic discs unsuitable for long-term storage, but perhaps suitable for short-term low-cost interchange. Commodity drives such as Zips are reported to have reliability problems, and may not be suitable for reliable interchange. A recent installation of a SuperDisk and software driver at the Joint Bureau of Meteorology/CSIRO Supercomputing Facility recently locked up a PC so that Windows NT had to be completely re-installed. However, the cheapness of these drives and media may allow them to be part of the solution for smaller agencies. Removable optical discs (e.g. CD-ROM, DVD, and various optical disc) Consumer optical discs (CD-ROM, DVD) are often stated to have a life of over 50 years, and be virtually indestructible. This is not necessarily so. The lifespan of media is often assumed to be limited by chemical deterioration. As chemical deterioration is dependent on temperature, lifespans can be estimated by extrapolating tests which heat the media for various periods of time and measure the resulting bit error rate. (This testing approach is used to estimate the lifespan of all Report prepared for DOI by CSIRO Mathematical and Information Sciences October 1999 Version 1.0

52 Digital Storage Media for VERS 10 types of media including tape.) Kodak, for example, predict that (at the 95% confidence level) that 95% of properly recorded discs stored at the recommended dark storage condition (25 C, 40% RH) will have a lifetime of greater than 217 years [Koda] using this approach. Clearly, media stored in hotter environments will have shorter lifetimes (e.g. the window ledge of a car, or, more realistically, the heat from a fire may irreparably damage CDs without physically destroying them). It should be noted that this is true for any media. However, Media Sciences note that [MedS] Longevity is normally not determined by aging effects, although manufacturers quote studies that predict lifetimes of 20, 50, or even 100 years. Instead, longevity is usually limited by the cumulative effects of small scratches and contaminants that are introduced through normal handling and use. Do not tempt fate by assuming that your discs are bulletproof and can withstand abuse. CD-ROM and CD-R longevity can only be achieved by starting with a high quality disc and by exercising care in handling and storage Media Sciences go on to note that the label side of discs in particular is thin and relatively unprotected against scratches. Furthermore, there has been an explosion of variant formats and media, particularly with re-writeable media and DVDs, with little standardisation (The Age, December 1997). For example, Sony recently released the World s first DVD+RW drive, featuring backward compatibility with most CD-sized media, including CD Audio, CD-ROM, CD-I, CD-Extra, Photo CD, Video CD, DVD-ROM and DVD video disks. (The Age, 31st August 1999, IT2, p6). This illustrates the huge and bewildering variety of CD and DVD formats. As a storage media, CD-ROMs provide only modest transfer speeds between the media and the computer. CD-ROM have handling problems (easy to touch the recording surface, easy to place a disc on a surface, hard to provide one-off labelling.) Larger optical discs suffer from the same problems as magnetic discs, in that they are dependent on an operating system format. There is little compatibility between generations, and many bad experiences with migrations to new technologies. The growth rates for recording densities for magnetic disc and magnetic tape have continued to exceed the growth rates for optical media, and so the market segment for optical disc is shrinking compared with the others. In general, optical technologies are being pushed hard by the magnetic harddisc technologies, which continue to provide higher growth rates in densities and cost reduction [Moor]. As well, magnetic disc technologies are now being incorporated into magnetic tape (e.g. heads) and providing magnetic tape with a boost in its growth rates. Optical discs are being squeezed between disc and tape for large-scale storage. Optical tends to be mainly used for distribution and small-scale storage, not for major storage. DVD has provided a jump in capacity and speed, but there is a widening divide over formats which seems likely to limit the acceptability. There is no longer any major reason (cost, access speed, capacity) to select on-line optical disc over commodity on-line magnetic disc, and for large-scale near-line and off-line, tape have advantages in storage density and interoperability. Report prepared for DOI by CSIRO Mathematical and Information Sciences October 1999 Version 1.0

53 Digital Storage Media for VERS 11 Magnetic tape (e.g. DLT, 3490E, Travan, QIC, Exabyte, 4 mm) Magnetic tape remains the interchange medium of choice for enterprises interchange was one of the primary reasons for tape developments. It is interesting and perhaps surprising that 1/2 inch open-reel magnetic tape, the first format for computer tape invented in 1953, is still in use in Australia as the standard for interchange of information between large financial institutions, e.g. banks, credit unions, mailing houses, etc. The format has changed only in the change from 7 to 9 tracks, and increases in density from 200 bits per inch through various intermediates to 6250 bits per inch. However, this 1/2 inch open reel format is not a feasible solution. The drives are believed to be becoming difficult to obtain and they are slow; the tapes have low capacity, and low-density. By way of contrast to magnetic discs, magnetic tape is a serial medium, and can be formatted in any way. Most modern medium to high-end tape drives do have a way to provide semi-random access, by storing an index of tape locations for each file on the tape, and providing a mechanism for fast positioning to the required location. Searching involves moving the tape at speeds which are typically ten times that of read/write speeds. The formatting is defined by ANSI standards, and by the characteristics of the tape drive itself, and can be independent of any operating system. There are ANSI and IEEE standards describing the labelling and formatting of data on serial media such as tapes. Ion-beam etching (e.g. HD-Rosetta) Ion-beam etching (e.g. HD-Rosetta) is a promising new technique for providing deeparchive storage in a system independent way. The basic technique involves etching highly durable archive, e.g. sheets of stainless steel or titanium, or silicon. These media could survive common fires temperatures without loss. The main data could be written at densities approaching Terabytes per square inch. The basic idea is to etch onto the media basic instructions (including format descriptions, coding schemes, and the specification of the technique to read the main data) at a magnification which could be read with a low-powered optical microscope (in a presumed absence of the original technology used to create the plates). A future archivist could presumably de-code the encoding scheme from this, and then go on to reproduce the original technology to recover the full data. The technology is available under the name HD-Rosetta [Nors]. Optical tape (e.g. ICI, Rome Labs) Optical tape has been in use for some years, and newer versions are being developed. ICI marketed a version for some years, with something like 1 Terabyte per reel. The technology has been used in Australia by ACERS, but it is believed the drives and tapes are no longer made or sold. In the US, optical tape technology is being developed which promises 1 Terabyte in a 3480 form-factor, based on work done at the Rome Laboratories. Commercial availability is expected in 2000 (IEEE Mass Storage Systems Symposium, March 1999). Report prepared for DOI by CSIRO Mathematical and Information Sciences October 1999 Version 1.0

54 Digital Storage Media for VERS 12 Media Life Expectancy The following table is taken from a 1996 presentation [VanB] and gives life expectancies of various media (including various tape formats, optical disc, paper, and microfilm for comparison) when stored at 20 degrees Celsius and 40% relative humidity. Data Storage Product Format/Technology Common Life Expectancy (Years) Magnetic Tape 3480/3490/3490e 5 20 cartridge Digital Linear Tape 5 20 DD-2/DD QIC 2 10 D8 (Data 8 mm) 2 10 CD-ROM CD-ROM 5 50 WORM CD-R 2 30 Magneto-Optical 2 30 Paper High quality (Low lignin) Microfilm Medium Term Archival High quality Life Expectancy (Years) The low common life expectancy is one which all media should be able to reliably survive. The higher high quality life expectancy is one which only media from the best vendors will achieve. Life expectancies can be increased by reducing the storage temperature or relative humidity (and, of course, decreased if stored at a higher temperature or relative humidity). Physical damage due to handling can dramatically shorten the expected life expectancy. There can be no absolute guarantees on the long-term preservation of anything, but probabilities can be given on the likelihood of errors on the media. For magnetic tape, data is usually stored with extensive error detection and error correction codes. Indeed, for the standard format for 3480 tape cartridges, as much tape space is assigned for the error detection and correction as for the data itself. This allows correction of so-called transient errors. Good tape drives might produce a single bit error once in every bits read or written. The error checking and correction codes might extend this to a hard error once in every bits read or written. With these figures, simple arithmetic might suggest that if writing is the dominant activity in an archive, and say 10 Terabytes (8X10 13 bits) was written each year, then permanent errors due to media failure might be one bit in say 10 4 years. However, error rates are based on accelerated testing which simulates aging, but cannot reproduce genuine aging, so there is a fair degree of uncertainty in these estimates. The above analysis assumes total randomness in the incidence of errors. In fact, errors actually occur in a highly correlated manner. A tape drive running near the limits of its signal strength, for example, will produce a high rate of error over the entire length of a tape, or over an entire track. A tape which has been subject to large temperature variations may be subject to shrinkage and consequently errors throughout its length. If there is a probability of one unrecoverable error in bits, then in two years there would be probability of about 50% or encountering an error with about Terabytes. The risk can be reduced to negligible levels by storing multiple independent Report prepared for DOI by CSIRO Mathematical and Information Sciences October 1999 Version 1.0

55 Digital Storage Media for VERS 13 copies of data. With two copies, the chance of a total loss becomes about 1 in bits. System and human failures, and then drive failures will far outweigh the chances of media failure. However, a note of caution should be sounded in applying these type of statistics. To actually reduce the error rate the two copies must be truly independent. If the two copies are written using the same technology onto media from the same batch, the copies are not truly independent and a bad batch of media could cause unrecoverable loss of data. It is for this reason that we recommend that a different type of media be used to store the second copy at large data storage centres. General Recommendation for storage Tape Technology Why Tape? In general, we recommend tape based storage, particularly for the larger agencies. So, why magnetic tape? If you search the computer advertisements in The Age Green Guide, you will struggle to find any mention of magnetic tape. Tape has died for the desk-top, and even its last application (backup) has been overtaken by removable disc. However, the place to look for how to handle long-term storage of large volumes of data are the large government, government corporations, and large financial and telecommunications companies which have been successfully managing electronic storage of data for decades. There, data integrity and security is critical to business continuation, and dual-site operations are common. Predominantly, the corporate data storage is based on large-sized IBM mainframes, with IBM, EMC or StorageTek attached disc for on-line data. All the data in regular daily use is on-line. In addition, StorageTek or IBM robotic libraries are used to handle near line data, and tape drives from StorageTek and/or IBM are used for near line or off-line data. Dual sites are common, with almost continuous availability of data at both sites. Tape is used for the deep archive of non-active data, for Hierarchical Storage Management (see glossary), and for the time-critical task of backup during ever-shortening windows. Since retrieval from tape can also be vital to business continuation, high speed tape devices with low access times are used. Also, these systems typically use large mainframe computers, and for a considerable portion of the life of these systems, tape has been faster than disc for large-scale data transfers. Indeed, tape drives have been available in Australia and in use which achieve 11 to 15 Megabyte/s, whereas the only disc now available is based on commodity disc drives, the best of which typically achieve only 9 Megabyte/s peak speeds per platter. (Packaging to use RAID and striping can deliver higher speeds to applications). The above large data centre sites nearly always include 18 or 36 track drives, and IBM Magstar, STK Redwood or STK 9840 drives for higher capacity. For mid-range and server systems, key data tends to be consolidated onto large servers or the mainframes, and stored on similar tape or mid-range tape such as DLTs. So, tape can provide: high integrity, higher speeds, operating system independence, file system independence, greater capacity, higher storage density (per volume and mass), and lower incremental cost for additional capacity. Report prepared for DOI by CSIRO Mathematical and Information Sciences October 1999 Version 1.0

56 Digital Storage Media for VERS 14 One of the key advantages to tape is that storage is basically three-dimensional, rather than the two dimensional format for disc. Disc storage basically is on 2-D platters, with a read/write mechanism for each platter, with multiple platters per module. Tape is written in two dimensions, but is wrapped up into three, and requires only one read/write mechanism for multiple volumes, not multiple read/write mechanisms for each volume. The read/write mechanism tends to be much more expensive, but as volumes increase the advantage of tape increases. Multiple copies can more easily be made with tape than disc. When disc is used to make multiple copies, mirroring or RAID is typically used. This guards against losses due to hardware failures, but provides little protection against the more common losses caused by human or system failures. With tape, it is far easier to provide true backups by taking genuine copies of the data at various intervals, so that recovery is possible back to previous copies of data. In conclusion, for large-scale serious information storage, tape is essential. For smallscale low-cost short-term archive, then CD-ROM may be acceptable. For interchange with small scale Agencies, removal discs like Zip and SuperDisk will be adequate. Because of the large-scale commodity market, CD-ROM (and possibly DVD) will be an important storage medium, with low costs and widespread availability. This will dictate its use for small-scale low-access-rate applications, but not for high storage density, high capacity and high speeds. Assessment of Media A full assessment of appropriate media may need to consider the following factors: Volume (capacity) Creation / access / churn rate Number of copies / sites Back-up / security / protection Migration to new versions of everything Vendor and system longevity Refresh rate for media Support staff effort Speed (transfer rate, access time) Vendor spread Industry acceptance, support life Robotic support Cost (will dominate for large storage) Weight / Floor space / Resiliency Error rate Media life - years, passes Technology Report prepared for DOI by CSIRO Mathematical and Information Sciences October 1999 Version 1.0

57 Digital Storage Media for VERS 15 Roadmap for future products Standards conformance (media and format) Reliability of drives Service quality from vendor Not all of the above can be considered in this report. Collecting the data from vendors to form a reliable opinion on all of the above would take several months of work. Instead, some of the most important aspects of the above will be considered. The following table shows some of the available tape media, some of the characteristics, some assessments of longevity characteristics, and some approximate costs. The same data for a CD system is given for a comparison. Some of the measures are subjective or non-comparable, because each vendor tends to give data which favours its technology. Data is missing from some cells, and a subjective measure of high (H) medium (M) and low (L) is given. Costs are difficult to state. For some high-end products, list price is given, but street-prices can be less than half of the figure shown. For tapes, only short-length passes are quoted for the durability figures given (i.e. a short segment of the tape is accessed). Beware of comparing the number of passes of Serpentine tapes. For example, the DLT 7000 needs 32 passes to read the full tape, so the quoted 1 million passes actually indicates accesses of the full length of the tape. Report prepared for DOI by CSIRO Mathematical and Information Sciences October 1999 Version 1.0

58 Digital Storage Media for VERS 16 Manufacturer Drive type Max capacity G byte Transfer rate Mbyte/s Tape Technology Av. access time (s) H > 60s M ~ 30s L ~ 10s Type Linear or serpentine or helical Life (year) Durability H ~ 30 years M ~ 10 years L ~ 2 years Report prepared for DOI by CSIRO Mathematical and Information Sciences October 1999 Version 1.0 Drive cost $k H ~ 100K M ~ 10K L ~ 1K Serviceability Various M L M M M n.a. n.a k passes IBM + others M L H H k passes 3490E S H H k passes 3590= S H H Magstar 40k passes Magstar- 7 7 L S H M 30 n.a. n.a. 10 MP Phillips NNTP n.a. n.a. n.a. S n.a. H H n.a. n.a. 5 StorageTek Timberline S H H 57 list ~ 40 Redwood H M M 225 list k passes ~ (Eagle) S H 71 list k passes ~ 54 Quantum DLT n.a. S n.a. n.a. n.a. n.a. 5 1M passes, 14k hrs DLT S M $ M passes, 30k hrs Sony AIT H L n.a. 5.9 n.a. n.a. 5 30K passes DTF n.a. H 30 n.a. n.a. n.a. n.a. 5 Exabyte 8 mm n.a. n.a. n.a. H L n.a. n.a. 8 n.a passes Mammoth n.a. H L n.a. 4.1 n.a. n.a. 5 IBM, HP, Seagate (Open Linear Tape) n.a. n.a. n.a. S n.a. n.a. n.a. n.a. n.a. 8 Tape cost $ Tape cost / Gbyte Technol ogy life years

59 Digital Storage Media for VERS 17 Manufacturer Drive type Max capacity G byte Transfer rate Mbyte/s Tape Technology Av. access time (s) H > 60s M ~ 30s L ~ 10s Type Linear or serpentine or helical Life (year) Durability H ~ 30 years M ~ 10 years L ~ 2 years Drive cost $k H ~ 100K M ~ 10K L ~ 1K HP, Sony 4 mm & DDS n.a. H 2000 passes n.a $ Various QIC n.a. n.a. n.a. S M 5-30 n.a. n.a. n.a. n.a. 10 Ampex D n.a. H M M n.a. n.a. n.a. 10 Imation Travan n.a. S 10k passes L 1.0 n.a. n.a. 5 Ecrix VXA n.a. n.a. n.a. n.a. 1.8 n.a. n.a. n.a. n.a. = not available at time of writing Tape cost $ Tape cost / Gbyte Technol ogy life years Manufacturer Drive type Max capacity G byte Transfer rate Mbyte/s CD Technology Av. access time (s) H > 60s M ~ 30s L ~ 10s Type Linear or serpentine or helical Various Various 0.65 Up to 1.8 M Not applicable n.a. = not available at time of writing Life (year) Durability H ~ 30 years M ~ 10 years L ~ 2 years M to H for quality discs Serviceability Serviceability Drive cost $k H ~ 100K M ~ 10K L ~ 1K CD cost $ Tape cost / Gbyte n.a $ Technol ogy life years Report prepared for DOI by CSIRO Mathematical and Information Sciences October 1999 Version 1.0

60 Digital Storage Media for VERS 18 Tapes Technology covers many aspects. Perhaps the most important is the recording technology, as that has implications for reliability and number of passes. The common methods are linear tracks on the tape, often with multiple passes (called serpentine, because of the snakes and ladders path over the tape), and helical scan. Helical scan is common in video equipment, and provides high bit density rates by passing the tape over a rapidly spinning drum at an angle to the tape. There is far more tape contact at a much higher speed than for the serpentine drives, and a far more complicated tape path. This combination of speed, contact, and complexity causes reliability problems with helical scan drives. With advances in magnetic tape technology, and the incorporation of disc drive technology into magnetic tape drives, the higher relative capacity of helical scan drives is now being reached by serpentine technologies. Consequently, helical scan is clearly on the way out. See the attachment from Imation about linear versus helical recording techniques [Imat]. Drop tests show the ruggedness of the media. For example, for the 3490E and similar cartridges, tests show less than 1% loss after 4 drops from 1.5 m. Even if the cartridge is damaged in a drop, a recovery cartridge can be used to replace the original and allow the data to be recovered. Other measurements show that these tapes can pass through a cycle of 5000 loads/unloads without terminal damage. There is enormous attention paid during design and manufacture to increase the reliability of tapes. Imation (formerly 3M), one of the biggest manufacturers, notes that the special shape of the joins on its cartridge shells minimises the plastic splash inside cartridge. The 3480-class and Travan cartridges can have a feature called back-coating - an extra layer on the tape which reduces static losses, crinkling, etc. Clean environments are another important part of ensuring data integrity. A machine room is the best environment, and an office environment is not good, because of dust, fibres, temperature variations, etc.. Greg Johnson notes some of the requirements for cleanliness, and some procedures to minimise tape errors. [John] Most drives need cleaning during normal use. This is done automatically in an automated cartridge system. Some drives seem to need excessive cleaning. The Travan drives are to be cleaned as often as every eight hours of tape motion. Re-tensioning every load is recommended. For the DLT 7000, a cleaning tape is recommended to be used only 20 times ($80), compared with up to 500 for 3480 ($17). CDs CD storage systems are built around the standard CD technology, widely used in PCs. The strength of this is that the technology is a commodity item. Consequently, blank media, media writers and media readers are widely available and relatively cheap. The weakness is that CD storage systems are limited by the standard CD technology. A CD stores 0.65 Gigabytes which is relatively small compared with most tapes. The basic transfer rate is 150 kilobytes per second, but standard writers will write up to four times this rate (600 kilobytes per second) and standard readers will read up to 32 times the basic rate (4800 kilobytes per second). Both are relatively slow and are unlikely to be improved due to the physical limitations of the spinning disc. Report prepared for DOI by CSIRO Mathematical and Information Sciences October 1999 Version 1.0

61 Digital Storage Media for VERS 19 These limitations mean that they are not used by organisations managing large volumes. CD storage systems are primarily attached to PC type servers for relatively modest storage systems. An important consequence of this is that the standard data management software does not support CD technology. A second consequence is that the data storage systems have relatively low storage capacity (100 to 300 Gigabytes). A final consequence is that, as products, CD data storage systems have relatively short lifecycles. New products appear frequently, replacing older products in vendors product lineups. On the other hand, because of the ubiquity of CD technology in PCs, the CD may prove to be a suitable transfer medium between VERS Archive Systems. In the commodity PC world, DVD discs have been touted as the replacement for CDs. For data storage, however, the technology is still too new to be an effective competitor. The price of DVD technology is relatively expensive as it has not yet achieved commodity status. DVDs, in fact, may never replace CDs, particularly if a new technology appears with better storage capacity or performance. DVDs also suffer a proliferation of standards. DVDs are a technology to watch for the near future for smaller data storage systems, rather than a currently viable approach. Drives, Robots, and Hosts As discussed in section 0, it is assumed that the data storage systems for at least medium and large agencies are based around robot systems which automatically load and unload media from the drives. This section briefly considers the major vendors of robotic systems for various tape formats. IBM makes libraries (Automated Cartridge Systems) for 3480/3490, and both varieties of Magstar drives. StorageTek makes libraries for 3480/3490, all the StorageTek drives, and for DLT; IBM Magstar drives can be attached to the StorageTek libraries. Many vendors make libraries for DLT drives. There are libraries available for many other drives, e.g. 4 mm, Exabyte Mammoth, AIT, Ampex and Sony. The availability of automation for Travan drives is not known. The largest libraries are from IBM, StorageTek, and Grau. The StorageTek ones hold nearly 6000 cartridges, and 16 can be joined together to allow access to nearly cartridges from many kinds of host computer. Robotic systems range from about $ for small systems, to around $ for systems with about 6000 slots. Most drives use various levels of SCSI connection to hosts, providing support for speeds of 10, 20 or 40 Mbyte/s, depending on the level. Mainframes tend to use Enterprise System connections at 17 Mbyte/s, and this year should see the first of the Fibre Channel connections at 100 Mbyte/s. Most of these drives can be attached to a large range of computers. The first three are supported on mainframes. The first five are supported on a large range of mid-range computers, including those from IBM, Compaq, HP, SGI and Sun. The last four are supported on NT servers. In fact, in their SCSI form, these drives can be supported on nearly every type of computer. However, picking the right combination of vendors to supply servers, HSM, robotics, drives and tapes needs careful consideration and access to the experience of existing sites. Report prepared for DOI by CSIRO Mathematical and Information Sciences October 1999 Version 1.0

62 Digital Storage Media for VERS 20 Recommendations The recommendations depend most of all on the capacity required, the level of data security/reliability required, the transfer rates required, the access rates and the costs. If you want high security, high capacity, high transfer rates and high access rates, the costs will be high. If capacities are low, and transfer and access rates are low, then costs will be lower, but inevitably the security and reliability will also drop. All the good characteristics go together, to meet market requirements. The following table summarises important characteristics of common technology. Technology StorageTek Timberline (3490E) IBM Magstar StorageTek 9840 IBM Magstar- MP Quantum DLT 7000 Imation Travan CD-R Industry acceptance High Mainframes and SCSIbased systems Medium drives Mainframe & SCSI High drives Mainframe & SCSI Mainly at IBM sites with IBM software High 1 M drives SCSI Media - Capacity Gbyte, cost, & cost per Gbyte $9-26$ $11-$16 Media - Longevity Storage Equipment Rating (on line, near line, off line) years Near-line and off-line n.a. Near-line and off-line 20 $148 $ years Near-line and off-line 7 n.a. Near-line and off-line 35 $106 $3 30+ years Near-line and off-line Storage Equipment - Longevity Readers Storage Equipment - Capacity (capacity range) 5+ years Tbyte per silo 4 years Tbyte in STK silo 4 years 120 Tbyte per silo Storage Equipment Mean Load Time/Seek time/transfer rate 15 s 6 Mbyte/s 58 s 9-14 Mbyte/s 15 s 10 Mbyte/s 4 years ~ 3.5 Tbyte L 7 Mbyte/s 2 years 17 Tbyte 90 s 5 Mbyte/s Moderate 10 Gbyte n.a. Off-line 1 year n.a. n.a. 1.0 Mbyte/s Low years Near-line and n.a s acceptance $3 (in bulk) off-line Gbyte 1.8 Mbytes/s with large data storage $5 Large Agencies and PROV For the high-end (over 1.5 Terabytes per year with two copies kept), the 3490E /StorageTek Timberline tape and drive gives the highest industry acceptance, probably the highest reliability, high transfer rates, and low access times. However, capacity is not great, with a maximum of 1.6 Gbyte per cartridge uncompressed. (No compression figures are quoted in this paper, except here. On the text data records envisaged here, then compression rates of perhaps 2:1 can be expected, and should be done in hardware in the drives, not in software [to reduce software dependency]). If higher capacities than this are required with similar resiliency and transfer rates, then the best choice for low access times is the StorageTek A caution is that this drive has been in general availability since only December 1998, and a little more feedback from the field is needed. Approximately drives have been delivered. Early experiences were good. For similar capacity, the IBM Magstar could be considered, but this has much longer access times, and requires IBM robotic systems, Report prepared for DOI by CSIRO Mathematical and Information Sciences October 1999 Version 1.0

63 Digital Storage Media for VERS 21 which have not had a good record at several overseas sites. For large scale storage, the StorageTek Powderhorn library series is undoubtedly the market leader. In practice, a combination of 3490/Timberline for the first copy, and 9840 drives for the second and subsequent copies makes a lot of sense. Using two different media technologies guard against potentially huge losses from the deadly combination of a bad piece of media damaging a drive, which in turn damages all subsequent media mounted on that drive, which in turn damage all the compatible drives, etc. Many of the records deposited with PROV are infrequently accessed. Because of this it may be appropriate for PROV to store many of their tapes off-line. This would mean that a smaller tape storage system would be required, but at the cost of requiring greater manual handling of tapes in loading and unloading them from the storage system. In addition, there is a greater chance of misplacing (misfiling) the off-line tapes with a consequent loss of records. The manual effort in loading the tapes is of particular importance when it is required to refresh the off-line tapes. Medium Sized Agencies Small Agencies Transfer Media For the medium-sized agencies (between 10 Gigabytes and 1.5 Terabytes of data per year with two copies kept), IBM Magstar-MP could be useful, as it has a low access time and good speed. However, Quantum DLT drives have a far higher acceptance (1 million delivered), and have widespread use in Australia. At a site familiar to the authors, there were many initial teething problems with these drives, with SCSI-bus resets, excessive calls for cleaning tapes, and more recently brand-new tapes delivered which were unusable. Reliability has been poor when used intensively for HSM applications. There is another problem in that there were many reports early that the tapes lost their index file (written at the ends of the tape, and when a tape was mounted for reading, it could take up to three hours for the tape to be available, while the entire tape was read and the index re-created. During this time, SCSI bus resets were common unless the timeout had been set to a large value, and drives sharing the same bus could over-write the contents of any tape being written. Most of these problems are tolerable, but not in an intensive operation. Staff costs to handle the problems are going to outweigh the money saved on cheaper drives. For agencies storing less than 10 Gigabytes of data per year (with two copies kept), Travan may be a good solution. However, at this end, the removable optical or magnetic disc technology may be preferable, with CD-ROM/DVD or 250 Mbyte Zip drives for example. Taking two copies at all stages (or separate drives or, especially, separate drive types) will very significantly reduce the likelihood of losses. It is envisaged that PROV will operate a storage system for permanent records that are no longer kept by agencies, just as it currently does for paper records. This raises the issue of transferring records between the agencies and PROV. Report prepared for DOI by CSIRO Mathematical and Information Sciences October 1999 Version 1.0

64 Digital Storage Media for VERS 22 We recommend that PROV follow the lead of NARA s CERA and when a piece of media is received from an agency, copy the records from the transfer media, and return the transfer media to the agency. This policy allows PROV to control the quality of the media holding the State s historical record. In addition, it also allows PROV to verify the contents of the tape; including that anything has been written to the tape at all. PROV should accept a variety of transfer mechanisms. Compatibility with the equipment currently in use in the agencies will become a consideration. The high-end tape solutions will not be available on the low-end desktop systems, and would be too expensive anyway. For small-scale transfers, network technology should be used. Networked systems are becoming pervasive, security can be adequate, and there is nearly always plenty of network capacity outside prime-time. Networked transfer applications are less error prone that manual operations with removable media. Where networked transfers are not possible, because of bandwidth or security or capacity requirements, then low-end removal disc drives such as Zip or SuperDisk, or CDs, will be reasonable for low-end desk-top systems. Travan, and then DLT tape would be the next steps in capacity and performance. Finally, for high-capacity and to interface directly with the high-capacity archives, 3590, Magstar or 9840 tapes could be used by the large agencies. We recommend PROV adopt a range of transfer media that covers the typical range agencies may use. A reasonable set today would be: Zip Disk CD Travan PROV, of course, should only install capacity to accept particular media formats after this media format is installed by an agency. Project Specification Research required on Digital Storage media. PROV require a consultant familiar with VERS to research the longevity, storage capacity and VERS appropriateness of currently available storage media. The consultant must produce a report with clear recommendations of 1. media appropriate for government agency use when implementing a VERS compliant repository system and 2. the medium most appropriate for use by PROV to store VERS record objects. Long Term Storage Media for Agencies There are several issues to consider: Report prepared for DOI by CSIRO Mathematical and Information Sciences October 1999 Version 1.0

65 Digital Storage Media for VERS 23 Large agencies may need to store large numbers of records on-line or nearline in an electronic 'archive.' This precludes the use of low range storage media like CD-ROMs. However some smaller agencies may require a smaller and cheaper storage option for which CD-ROMs would be appropriate. Unless the media chosen to transfer records to PROV are restricted, PROV may be required to accept records on a large variety of different media types with ensuing interoperability problems and cost implications for conversion. PROV would prefer that the number of recommended storage media be restricted to 4. PROV would prefer that media be recommended for both smaller and larger agencies taking into account the following: Longevity of medium -- Agencies will require a medium which is longlasting in order to reduce the requirement for continual media refresh Durability of medium -- Agencies will require a medium which is robust and which can be stored at a minimal cost. High capacity -- Agencies will require a medium which has a high capacity in order to reduce the size of the physical storage required but attention must be paid to that fact that smaller agencies may want to choose a lower capacity medium for cost reasons. Low-cost -- Agencies will require a medium which is relatively low-cost in order to reduce the ongoing maintenance costs for storage. Widely acceptable -- Agencies will require a medium which has a wide use to reduce the risk of choosing a medium which will not be able to be supported by the IT industry. On-line/Near-line -- Agencies may require a medium which is able to operate on-line or near-line at all times. Long Term Storage Media for PROV Some factors to consider: Longevity of medium -- PROV requires a medium which is long-lasting in order to reduce the requirement for continual media refresh Durability of medium -- PROV requires a medium which is robust and which can be stored in the storage conditions which will be available at North Melbourne. High capacity -- PROV requires a medium which has a high capacity in order to reduce the size of the physical storage required. Low-cost -- PROV requires a medium which is relatively low-cost in order to reduce the ongoing maintenance costs for the archival storage of long term records. Widely acceptable -- PROV requires a medium which has a wide use to reduce the risk of choosing a medium which will not be able to be supported by the IT industry. Report prepared for DOI by CSIRO Mathematical and Information Sciences October 1999 Version 1.0

66 Digital Storage Media for VERS 24 On-line/Near-line -- PROV does not require a medium which is able to operate on-line or near-line at all times. It is likely that access to records will be made available on-line only to those who have submitted a request for that access and therefore the majority of records can be stored off-line. Report prepared for DOI by CSIRO Mathematical and Information Sciences October 1999 Version 1.0

67 Digital Storage Media for VERS 25 References [Age1] The Age, 9 December 1997, IT section [Age2] The Age Green Guide, 9th September 1999 [Age3] [John] The Age, 31st August 1999, IT2, p6 Greg Johnson, Magnetic Tape and Digital Media Life Expectancies, [IEEE} IEEE Mass Storage Systems Symposium, March 1999 [Imat] [Koda] [MedS] Summary on Linear vs. Helical Recording Technologies in Entry- Level to Mid-Range Tape Backup Products (Imation 1999) Lifetime of KODAK Writable CD and Photo CD Media, Stinson, Ameil, and Zaino, Eastman Kodak, 1995, (visited Sep 1999) Frequently asked questions about compact discs, Media Storage Inc, (visited Sep 1999) [Moor] Moore, Fred. Strategic Storage Snapshots [Nors] [Roth] [VanB] HD-Rosetta Archival Storage System, Norsam Technologies, (visited Sep 1999) Rothenbeg, John, Ensuring the Longevity of Digital Documents. Scientific American, January 1995, p42 How long do Digital Storage Materials Last?, John W.C. Van Bogart, Preservation and Digitisation: Principles, Practice and Policies, 1996, (visited Sep 1999) Glossary 3480 The original IBM half-inch magnetic tape cartridge. The original used 18-track recording, and stored about 200 Mbyte, and had a maximum transfer rate of 3 Mbyte/s. Later variants include the 3490 (36-track, 400 Mbyte), the 3490E (36-track, double length, about 800 Mbyte) and the 3490EE (36-track, quadruple length, about 1.6 Gbyte). ANSI American National Standards Institute. Old name for the US national standards institute, but commonly used as an adjective, e.g. in ANSI standard tape labels, which is a standard describing the labelling of magnetic tapes on the media itself to facilitate identification and interchange. Report prepared for DOI by CSIRO Mathematical and Information Sciences October 1999 Version 1.0

68 Digital Storage Media for VERS 26 CD CD-ROM Cartridge Cassette DAT DVD Exabyte Floppy Format Gigabyte Compact Disc. There are three types. Ordinary CDs (also known as CD-ROM) have the content physically pressed onto the CD at a manufacting plant. This type of CD on which software or music is distributed. Recordable CDs (CD-R) can be written to once; the data is then permanently recorded on the CD. The data on a Read/writeable CDs can be erased and the CD written to many times. In this report we refer to Recordable CDs. See CD. CD Read-only-memory. A version of CD which is not normally writable in the field. An enclosed tape storage form, in which there is only one spool within each piece of media. Not an agreed definition. An enclosed tape storage form, in which there are two spools within each piece of media. Not an agreed definition. Digital Audio Cassette. A 4 mm wide tape cassette. Digital Video Disc - a successor to CDs, with the same form-factor, but higher capacity. A company and brand of helical-scan tape drives and 8 mm wide magnetic tape cassettes. The technology is based on 8 mm cassettes used in video recorders. Floppy, in contrast to rigid, the normal disc configuration. Floppies were the original removal discs for personal computers. Originally 8 inch, then 5 1/4 inch, then 3 1/2 inch square. Imation SuperDisk drives can read and write the 3 1/2 inch floppies, as well as higher capacity media. Used in many ways. It can mean a description of a particular recording technology, or of how data is recorded onto media, or of the operating-specific way an item of media is pre-recorded to allow fast random access to a file system or 1024 Mbyte, where 1 Mbyte is 1000 or 1024 kbyte, and 1 kbyte is 1000 or 1024 byte. A recent standard defines more precisely that G M and k retain their original decimal meanings, and the new prefixes Gi, Mi and ki are used for 2 30, 2 20 and 2 10 respectively. HD-Rosetta A new recording technology, designed to last as long as the rosetta stone, and to be the key to unravelling data stored a long time ago, without access to the intervening technology. (See section 2.5). Helical Scan A format for recording on tape in which the read-write heads traverse the tape at a (small) angle to the longitudinal direction of the tape). The read-write heads are then not restricted to the speed of the magnetic tape over the heads as in a longitudinal format, but can be moved far more rapidly for a far higher density of recording, and a cost of far higher tape to head contact speed and contact area. See also Serpentine. Report prepared for DOI by CSIRO Mathematical and Information Sciences October 1999 Version 1.0

69 Digital Storage Media for VERS 27 Hierarchical Storage Management. See HSM. HSM ICI IEEE Jazz Label Hierarchical Storage Management. Software which controls a storage system with multiple levels of storage, usually encompassing fast access with high cost, and slower access and lower cost. The software provides transparent access to the storage levels, without users having to be aware of the physical location. Typically, there are two levels of storage - fast, low-capacity and expensive (disc), and slower, high-capacity and cheaper (tape). When the first level starts to fill, the system automatically copies data from there onto a lower level, and removes the data from the first level, but retains metadata and directory information on the first level. When the data is required, the user or application accesses the data as normal as if it were on the first level, and the system automatically restores the data to the first level from a lower level. The only difference to the user or application is the longer access time. Typically, the delay may be as little as 25 s. Imperial Chemical Industries. Manufacturer of an optical tape. Institute of Electrical and Electronic Engineers. A type of removal disc and drive made by Iomega In this context, an identifying record stored at the beginning of a magnetic tape (often called a volume). It usually contains a Volume Serial Number (VSN), various dates, file identifiers, and the means to ensure that volumes can contain multiple files, and that files can span volumes. Megabyte 1000 or 1024 Kbyte (see Gigabyte) Near-Line The storage of information in an automated mounting system, so that access times are between those of on-line (usually magnetic disc) and off-line (usually tapes stored on racks). See also Off-Line and On- Line. Off-Line On-Line The storage of information separately from the means to read or write it, e.g. on racks, in a vault, etc. See also Near-Line and On-Line. The storage of information together with the means to read and write it, so that fast access is available; usually on magnetic disc. See also Near-Line and Off-Line. Optical Disc A disc format, in which the data is recorded using optical technology, e.g. with lasers burning pits in the surface of special coatings. Optical Tape A tape format, in which the data is recorded using optical technology. QIC Quarter-inch-cartridge. A widespread format for data storage, originally from the 1980s and particularly used with the advent of workstations. Actually a cassette. Report prepared for DOI by CSIRO Mathematical and Information Sciences October 1999 Version 1.0

70 Digital Storage Media for VERS 28 RAID Redundant Array of Inexpensive Discs. A large and powerful hard disc unit constructed of small, cheap, hard discs developed for PCs. Reliability is obtained by storing redundant information. Random Access The ability to read and write information at any location in a medium. See also Serial Access Removable Media. Items which are able to store information, and which are able to be taken out of the drive mechanism which reads or writes them. RomeLabs US Air Force Laboratory SCSI Small Computer Systems Interconnect. A standard for the connection of peripheral devices to computers. Originally developed for workstation class systems, the standard has been extended and redefined and can now provide reasonably high connection speeds, but with limitations, e.g. on distance. Serial Access The information on the media can only be accessed by starting at the beginning of the media and reading until the information desired is retrieved. See also Random Access Serpentine A recording format, in which data is stored along the length of a tape in one direction using one or more tracks, and then more information is stored in the other direction using one or more tracks. The name is a oblique reference to snaking, or the game of snakes and ladders, in which the path is alternately left to right, then right to left, then left to right, etc, (provided you don t land on the head of a snake or at the bottom of a ladder). See also Helical Scan SuperDisk A removable disc and drive from Imation. It can also read and write 3 1/2 inch floppy discs. Terabyte Travan Zip 1000 or 1024 Gbyte (see Gbyte). A tape and drive from Imation. A removable disc and drive from Iomega. Report prepared for DOI by CSIRO Mathematical and Information Sciences October 1999 Version 1.0