Content authentication for digital media based recording devices

FIELD OF THE INVENTION

[0001] The present invention relates to digital media based devices for recording images and/or audio and, more particularly, to the digital signature based authentication of digitally recorded data and metadata associated with that data.

BACKGROUND

[0002] Digital media based recording devices have become popular for recording high quality digital images and sounds. There are now numerous types of devices that record images and sounds on digital media. These include digital still cameras, digital video cameras and digital audio recording devices. Distinctions between these devices are becoming increasingly blurred over time. For example, many recent digital still cameras can record short motion sequences and record sound, and many digital video cameras can now record still images.

[0003] Digital cameras generally create a digital image by exposure of a charge-coupled device (CCD) sensor array to a photographic scene, followed by conversion of data generated by the CCD to digital image data that is stored on storage media, generally within the camera. Digital video recorders record motion video as a sequence of still images, which are typically compressed before being stored. Sound is recorded using a microphone and converted to digital data using an analogue to digital converter. Thereafter, the digital data stored in the device as one or more digital media files may be transferred to a personal computer or other more permanent storage for printout, listening, viewing, and transmission for example.

[0004] One problem with digitally recorded data however, is the ease with which such data can be manipulated or modified, thereby creating a false representation of the original scene or event. Such problems are particularly prevalent in certain fields such as forensics and legal or law enforcement fields, where it is essential to prove the authenticity of images or recorded sound. Because of the ease with which digital images and sounds may be altered to distort the appearance of the original recording, proof of authenticity can often be difficult, and sometimes impossible.

[0005] Conventional approaches to proving authenticity of digital data have involved the use of digital signatures based on public key/private key cryptography—also known as “asymmetric key cryptography”. Digital signatures are produced from digital data using a private key. This usually involves encrypting a hash of the data with the private key, in which the encrypted hash constitutes the digital signature. Digital signatures are designed so that they are, in practice, impossible to produce without knowledge of the private key. A digital signature can then be verified using the corresponding public key without knowledge of the private key. This is typically accomplished by decrypting the signature using the public key and comparing the resulting hash value with a hash calculated from the signed data. If the hash values match, then the signature is valid and proves that the signed data was in possession of the holder of the private key when it was signed.

[0006] When verifying a digital signature, it is necessary to be sure that the public key being used actually belongs to the claimed signer. One means of ascertaining the owner of a key is with a digital certificate. A digital certificate is an electronic document issued by a trusted party called a certification authority (CA) that asserts that a particular key belongs to a particular signer. The certificate contains information identifying the owner of the key, the public key itself and the digital signature of the CA. Digital certificates often contain other information, such as a serial number and expiration date. Digital certificates often conform to a standard format (eg. X.509), and may be kept in registries so that authenticating users can look up public keys of signers.

[0007] One application of digital signatures to digital media based recording devices is described in U.S. Pat. No. 6,269,446 (Schumacher et al.), which applies to digital cameras. Schumacher et al. improves on earlier work described in U.S. Pat. No. 5,499,294 (Friedman). The approach of Schumacher et al. involves the use of an embedded private key in a digital camera, with the private key being used to create a digital signature based on a message digest of the image data and associated metadata. In that instance, the metadata is derived from time and satellite (GPS) location information. Thereafter, a user wishing to authenticate the image data and its associated metadata obtains a public key that corresponds to the embedded private key. Through use of the public key, the user of the Schumacher et al. system is able to determine whether the digital image data has been modified since it was originally recorded by the digital camera.

[0008] One drawback of the Schumacher et al. system is that the authenticating software needs to have prior knowledge of the public key of each camera whose images are required to be authenticated. If a software application must authenticate images from multiple cameras, the user of the application must supply the public key of each camera to the software prior to attempting to authenticate images from each respective camera. This makes the Schumacher et al. system impractical if there are many cameras or many instances of the authentication software. In many applications, it may not be convenient for a user of the authentication software to obtain the key for every camera.

[0009] One solution is for the cameras to all have the same private key/public key pair, but such weakens the security of the system considerably. This solution is generally unacceptable because if the private key in any one camera is compromised, the whole system is compromised. Another solution is the use of a networked Public Key Infrastructure (PKI) involving one or more certificate authorities and public databases of keys and certificates. That solution has the disadvantage that it requires that the authenticating user has access to the public key/certificate databases. Further, that solution also requires the involvement of third party certificate authorities, which may be inconvenient for some applications.

SUMMARY

[0010] It is an object of the present invention to substantially overcome, or at least ameliorate, one or more disadvantages of existing arrangements by providing an improved authentication arrangement for digital files, such as digital media files.

[0011] Authentication in this sense means to establish that data in the media file has not been modified since the data was recorded by the recording device. The term “media file” is thus used herein to refer to data recorded by a digital still camera, a digital video camera, a digital audio recorder or other digital recording device. A media file may also contain metadata associated with the recorded data. Such metadata is data that describes or provides information about the source data and its capture. This metadata may also be authenticated.

[0012] According to a first aspect of the invention, there is provided a method, in a data processing system which comprises a recording device and a certificate authority terminal, of determining if a file is modified or not, said method comprising the steps of:

[0013] generating a first public key and a first private key by the recording device;

[0014] transferring the first public key to the certificate authority terminal by the recording device;

[0015] encoding a certificate including the first public key received from the recording device by using a second private key by the certificate authority terminal;

[0016] transferring the encoded certificate to the recording device by the certificate authority terminal;

[0017] hashing said file to provide a digital signature by using the first private key in the recording device;

[0018] attaching the certificate received from the certificate authority terminal and the digital signature to said file in the recording device; and

[0019] distributing to a client terminal said file as a communication package assimilated at least said file, the digital signature and the certificate by the recording device.

[0020] According to another aspect of the invention, there is provided a processing system for determining if a file is modified or not, includes a recording device and a certificate authority terminal, said system comprising:

[0021] said recording device comprising:

[0022] a generator for generating a first public key and a first private key; and

[0023] a first transmitter for transferring the first public key to the certificate authority terminal;

[0024] said certificate authority terminal comprising:

[0025] an encoder for encoding a certificate including the first public key received from the recording device by using a second private key; and

[0026] a second transmitter for transferring the encoded certificate to the recording device;

[0027] said recording device further comprising:

[0028] a provider for hashing said file to provide a digital signature by using the first private key;

[0029] attaching means for attaching the certificate received from the certificate authority terminal and the digital signature to said file; and

[0030] a distributor for distributing to a client terminal said file as a communication package assimilated at least said file, the digital signature and the certificate.

[0031] According to a another aspect of the invention, there is provided apparatus comprising:

[0032] first storage media for storing at least a digital certificate and a pair of cryptographic keys comprising a private key, and a public key corresponding to said private key;

[0033] a recording arrangement for recording event data;

[0034] second storage media for storing at least said recorded event data;

[0035] a signing processor for generating a digital signature using at least said stored private key and said recorded event data; and

[0036] a controller arranged to cause said apparatus to:

[0037] (i) supply said stored public key to a certificate generating authority;

[0038] (ii) store said digital certificate in at least said second storage media, said certificate being formed using said public key and supplied to said apparatus from said certificate generating authority; and

[0039] (iii) record event data and to associate a digital signature generated by said signing processor with said event data.

[0040] According to another aspect of the invention, there is provided a device for processing data intended for subsequent authentication, said device comprising:

[0041] means for receiving a digital certificate generated from a private key of a certifying authority and incorporating a public key of said device;

[0042] means for generating a digital signature for said data and a private key of said device, said private key of said device complementing said public key of said device to collectively form a device key-pair; and

[0043] means for associating said data, said certificate and said digital signature as a communication package for transfer from said device.

[0044] According to another aspect of the invention, there is provided a method, in a recording device, of determining if a file is modified or not, said method comprising the steps of:

[0045] generating a first public key and a first private key;

[0046] transferring the first public key to a certificate authority terminal;

[0047] hashing said file to provide a digital signature by using the first private key;

[0048] attaching a certificate received from the certificate authority terminal and the digital signature to said file; and

[0049] distributing to a client terminal said file as a communication package assimilated at least said file, the digital signature and the certificate by the recording device,

[0050] wherein the certificate received from the certificate authority includes the first public key and is encoded by using a second private key generated in the certificate authority terminal.

[0051] According to another aspect of the invention, there is provided a storage medium storing a program for executing a process of determining if a file is modified or not, said program comprising the step of:

[0052] generating a first public key and a first private key;

[0053] transferring the first public key to a certificate authority terminal;

[0054] hashing said file to provide a digital signature by using the first private key;

[0055] attaching a certificate received from the certificate authority terminal and the digital signature to said file; and

[0056] distributing to a client terminal said file as a communication package assimilated at least said file, the digital signature and the certificate by the recording device,

[0057] wherein the certificate received from the certificate authority includes the first public key and is encoded by using a second private key generated in the certificate authority terminal.

[0058] Other aspects of the invention are also disclosed.

[0059] In an advantageous implementation, the digital recording device is equipped with not only the means for producing a media file either stored in an internal medium for later transmission or transmitted directly to an external digital storage medium, but also means for first generating a digital signature of all or part of the data in the media file, and the means for storing a digital certificate. Digital signatures generated by the device depend on a private key stored within the digital recording device. The private key is not known by anyone except perhaps the manufacturer of the digital recording device. To authenticate the data in a media file, the user needs to know the public key corresponding to the recording device's private key. To allow the software to obtain the public key and to ascertain that the public key is itself authentic, the public key and a digital certificate certifying the authenticity of the public key is added to the media file produced by the digital recording device. The certificate contains another digital signature certifying that the public key supplied is a valid public key corresponding to the private key stored in the digital recording device.

BRIEF DESCRIPTION OF THE DRAWINGS

[0060] One or more embodiments of the present invention will now be described with reference to the drawings, in which:

[0061]FIG. 1A is a schematic block diagram representation of a structure of a recording device according to the present disclosure;

[0062]FIG. 1B is a functional block diagram representation of the recording device of FIG. 1A;

[0063]FIG. 2 illustrates the data and steps of creating and installing public and private keys and the certificate for the recording device of FIGS. 1A and 1B;

[0064]FIG. 3 shows in more detail the steps involved in producing and installing the keys and the certificate;

[0065]FIG. 4 illustrates the process of authenticating a digital media file produced by the digital recording device of FIGS. 1A and 1B; and

[0066]FIG. 5 is a schematic block diagram of a computer system upon which keys and certificates described can be generated for communication with the recording device of FIGS. 1A and 1B.

DETAILED DESCRIPTION INCLUDING BEST MODE

[0067]FIG. 1A shows a digital recording device <b>100</b> which includes sensors <b>150</b> for capturing images or audio, or both, intended for recording. The device <b>100</b> further includes a non-volatile recording medium such as a read-only memory (ROM) <b>109</b> for storing program instructions that control the operation of the device <b>100</b> via a processing unit (or CPU) <b>160</b>, which reads and executes the instructions obtained from the ROM <b>109</b>. The CPU <b>160</b> operates to extract captured image and audio information from the sensors <b>150</b> and format the same for retention in a non-volatile digital mass storage medium <b>108</b>, which may be formed by a magnetic disk drive or magneto-optical drive, or flashROM for example. In some implementations, the functionality of the ROM <b>109</b> may be incorporated into the storage medium <b>108</b>. A random access memory (RAM) <b>180</b> is also shown and provides the CPU <b>160</b> with a (volatile) intermediate storage capacity for key, signature and certificate processing. Image and audio data captured may be output from the recording device <b>100</b> via a communications module <b>190</b> to a external connection <b>195</b>, which may be formed by wired or optical cable, or wireless methods such as radio frequency or infrared links. In some implementations, one or more of the components <b>160</b>-<b>190</b> may be formed in a single integrated circuit chip device.

[0068]FIG. 1B shows the main functional components of the recording device <b>100</b> and how such are used to produce a digital media file <b>120</b> for output via the connection <b>195</b>. The digital recording device <b>100</b> incorporates an image sensor <b>101</b> and a microphone <b>102</b> for respectively detecting images and audio desired for recording and which, in the described arrangement, form the sensors <b>150</b> of FIG. 1A. Typically, the device <b>100</b> would also include a lens (not shown) to focus the light onto the sensor <b>101</b>, the sensor <b>101</b> operating to produce digital luminance data that is stored temporarily in an image data buffer <b>103</b>. The luminance data is typically formed of red, green and blue components. The luminance data is then preferably compressed using an appropriate compression function <b>105</b>, such as JPEG, JPEG2000 or MPEG and the resulting compressed data <b>112</b> stored as part of the digital media file <b>120</b> in the digital storage medium <b>108</b>. As illustrated, audio information can be simultaneously detected by the microphone <b>102</b> and converted to digital audio data by an analogue to digital converter (ADC) <b>121</b> before being temporarily stored in an audio data buffer <b>104</b>. The audio data is also compressed using an appropriate compression function <b>105</b>, such as MP3, and is also added to the recorded data <b>112</b> as part of the digital media file <b>120</b>. The buffers <b>103</b> and <b>104</b> may be implemented using the RAM <b>180</b> or dedicated memories and the compression functions may, as appropriate, be performed by the CPU <b>160</b> or specific hardware devices (not illustrated). In other implementations, the image buffer <b>103</b> or audio buffer <b>104</b> may not be present and the audio and image data is compressed and written directly to the digital storage medium <b>108</b>. In further implementations, the compression function <b>105</b> may be omitted, such that the recorded data <b>112</b> is formed by uncompressed audio and/or image data. In some implementations, the microphone <b>102</b>, ADC <b>121</b>, and the audio data buffer <b>104</b> may not be present; and in other implementations, the image sensor <b>101</b> and image data buffer <b>103</b> may not be present.

[0069] As shown in FIG. 1B, the recording device <b>100</b> includes a module <b>106</b> configured to generate metadata <b>111</b> associated with the recorded data <b>112</b>. The metadata <b>111</b> may include the date and time that the data was recorded, the GPS location coordinates at which the recording took place, and other data specified by the user, such as exposure settings and text data input. The metadata <b>111</b> is stored as part of the digital media file <b>120</b>. In some implementations, this facility may be omitted, and no metadata is stored in the digital media file <b>120</b>.

[0070] A private key <b>113</b>, public key <b>114</b> and digital certificate <b>115</b> are preferably stored in non-volatile but re-writable storage, such as flash ROM, which may be used to form the storage <b>108</b>, or part thereof. That data may alternatively be stored in the ROM <b>109</b>, where such would not be able to be altered or changed, however such has the disadvantage that it prevents a change in certificate authorities, or having a local certificate authority maintained by the user. Such also makes the manufacturer responsible for managing keys and forces the user to trust the manufacturer with the key generation. For these reasons, it is preferable to have the device <b>100</b> generate new keys on demand, which necessitates the keys <b>113</b>, <b>114</b> and certificate <b>115</b> being re-writable. The private key <b>113</b> may optionally be stored in tamper-proof hardware in high-end high-security applications. The public key <b>114</b> is typically included in the certificate <b>115</b> and so a separately stored copy of the public key, as indicated at <b>114</b> in FIG. 1B, is not strictly necessary. However, separately storing the public key <b>114</b> from the certificate <b>115</b> allows for the possibility of not using the certificate <b>115</b>. In this fashion, use of the certificate <b>115</b> is optional, and such allows the recording device <b>100</b> to be ignorant of the format of the certificate <b>115</b>.

[0071] As also illustrated in FIG. 1B, the CPU <b>160</b> operates to perform a process <b>107</b> in which the private key <b>113</b> is used by a generate signature sub-process <b>117</b> to produce a digital signature <b>118</b> which is stored as part of the digital media file <b>120</b>. Preferably, the digital signature process <b>107</b> conforms to the known Digital Signature Standard (DSS) specified by the United States National Institute of Standards and Technology (NIST). The process <b>107</b> also involves the CPU <b>160</b> computing an SHA-1 hash function <b>116</b> of the data to be signed, which provides a hash result <b>130</b>. The hash function <b>116</b> is followed by the signature generation process <b>117</b>, which in practice encrypts the hash result <b>130</b> with the private key <b>113</b>. In the arrangement illustrated, the data that is signed includes the recorded data <b>112</b> and the associated metadata <b>111</b>, illustrated collectively as data <b>131</b>. In other implementations, the signed data <b>131</b> may not include all of the recorded data <b>112</b> and may not include all of the associated metadata <b>111</b>.

[0072] As also depicted in FIG. 1B, the CPU <b>160</b>, well as adding the generated signature <b>118</b> to the digital media file <b>120</b>, also adds a copy <b>119</b> of the certificate <b>115</b> to the digital media file <b>120</b>, this being indicated by an insert certificate function <b>110</b>.

[0073] In a typical physical implementation, the compression function <b>105</b> and SHA-1 hash function <b>116</b> are preferably performed by application specific integrated circuits, whereas the remaining functions may be conveniently implemented by the CPU <b>160</b>.

[0074] Once formed by the recording device <b>100</b>, the digital media file <b>120</b>, comprising the metadata <b>111</b>, recorded data <b>112</b>, signature <b>118</b> and certificate <b>119</b> may be output from the device <b>100</b> by the CPU <b>160</b>. Such can thereby cause transfer of the file <b>120</b> from the storage <b>108</b> via the communications module <b>190</b> and link <b>195</b> to a computer system <b>500</b>, as shown in FIG. 5. As illustrated, the link <b>195</b> may be direct (via the dashed line) or via a computer network <b>520</b>.

[0075] Preferably, authentication of the recorded data <b>112</b> and metadata <b>111</b> is performed by a software application running on the general-purpose computer system <b>500</b>, wherein the authentication processes may be implemented as software, such as an application program executing within the computer system <b>500</b>. In particular, the steps of the process are effected by instructions in the software that are carried out by the computer. The instructions may be formed as one or more code modules, each for performing one or more particular tasks. The software may also be divided into two separate parts, in which a first part performs the authentication methods and a second part manages a user interface between the first part and the user. The software may be stored in a computer readable medium, including the storage devices described below, for example. The software is loaded into the computer from the computer readable medium, and then executed by the computer. A computer readable medium having such software or computer program recorded on it is a computer program product. The use of the computer program product in the computer preferably effects an advantageous apparatus for authenticating recorded data.

[0076] The computer system <b>500</b> comprises a computer module <b>501</b>, input devices such as a keyboard <b>502</b> and mouse <b>503</b>, output devices including a printer <b>515</b>, a display device <b>514</b> and loudspeakers <b>517</b>. A Modulator-Demodulator Modem transceiver device <b>516</b> is used by the computer module <b>501</b> for communicating to and from a communications network <b>520</b>, for example connectable via a telephone line <b>521</b> or other functional medium. The modem <b>516</b> can be used to obtain access to the Internet, and other network systems, such as a Local Area Network (LAN) or a Wide Area Network (WAN). Where appropriate, a network card (not illustrated) may form part of the I/O interface <b>508</b> for direct connection between the computer module <b>501</b> and a LAN or WAN.

[0077] The computer module <b>501</b> typically includes at least one processor unit <b>505</b>, a memory unit <b>506</b>, for example formed from semiconductor random access memory (RAM) and read only memory (ROM), input/output (I/O) interfaces including a audio-video interface <b>507</b> for the display <b>514</b> and loudspeakers <b>517</b>, and an I/O interface <b>513</b> for the keyboard <b>502</b> and mouse <b>503</b> and optionally a joystick not illustrated, and an interface <b>508</b> for the modem <b>516</b> or direct device connection, as illustrated. A storage device <b>509</b> is provided and typically includes a hard disk drive <b>510</b> and a floppy disk drive <b>511</b>. A magnetic tape drive not illustrated may also be used. A CD-ROM drive <b>512</b> is typically provided as a non-volatile source of data. The components <b>505</b> to <b>513</b> of the computer module <b>501</b>, typically communicate via an interconnected bus <b>504</b> and in a manner which results in a conventional mode of operation of the computer system <b>500</b> known to those in the relevant art. Examples of computers on which the described arrangements can be practised include IBM-PC's and compatibles, Sun Sparcstations or alike computer systems evolved therefrom.

[0078] Typically, the application program is resident on the hard disk drive <b>510</b> and read and controlled in its execution by the processor <b>505</b>. Intermediate storage of the program and any data fetched from the network <b>520</b> may be accomplished using the semiconductor memory <b>506</b>, possibly in concert with the hard disk drive <b>510</b>. In some instances, the application program may be supplied to the user encoded on a CD-ROM or floppy disk and read via the corresponding drive <b>512</b> or <b>511</b>, or alternatively may be read by the user from the network <b>520</b> via the modem device <b>516</b>. Still further, the software can also be loaded into the computer system <b>500</b> from other computer readable media. The term “computer readable medium” as used herein refers to any storage or transmission medium that participates in providing instructions and/or data to the computer system <b>500</b> for execution and/or processing. Examples of storage media include floppy disks, magnetic tape, CD-ROM, a hard disk drive, a ROM or integrated circuit, a magneto-optical disk, or a computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external of the computer module <b>501</b>. Examples of transmission media include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including email transmissions and information recorded on websites and the like.

[0079] The method of authentication may alternatively be implemented in dedicated hardware such as one or more integrated circuits performing the functions or sub functions of authentication. Such dedicated hardware may include graphic, processors, digital signal processors, or one or more microprocessors and associated memories.

[0080] With the digital media file <b>120</b> downloaded to the computer module <b>501</b> and, for example, stored in the HDD <b>510</b>, the certificate <b>119</b> allows the authentication application to authenticate the digital media files including the data <b>111</b> and <b>112</b> without having prior knowledge of the public key <b>114</b> of the device <b>100</b> that recorded the data <b>111</b> and <b>112</b>.

[0081] The simplest way to achieve this is to use the same certificate authority to produce certificates for all recording devices whose images will be authenticated by a given authenticator. Authentication can then be performed using only the public key of the certificate authority. Even where it is not practical to use a single certificate authority, the use of certificates can reduce the number of public keys that the authenticators (ie. the computer <b>500</b>, the authentication application and its users) need to trust. In the preferred implementation, the public keys of the one or more certificate authorities are stored in the software that is used for authentication. Such software may be obtained from the certificate authority for example by a user of the computer system <b>500</b> downloading the software from a server computer <b>550</b> operated by the certificate authority <b>560</b> and connected to the network <b>520</b>, as illustrated in FIG. 5.

[0082]FIG. 2 shows the steps involved in creating the public and private keys and the certificate. As shown in FIG. 2, the recording device <b>100</b> has a further function <b>201</b> for generating an encryption/decryption key pair formed of the public key <b>114</b> and a private key <b>113</b>. The keys <b>113</b> and <b>114</b> preferably constitute an RSA private key/public key pair of length 2048 bits or longer. Alternatively, keys for other encryption algorithms may be used. For example, an elliptic curve encryption algorithm may be used instead of RSA. In other implementations, the keys <b>113</b> and <b>114</b> may be generated by the manufacturer of the device <b>100</b> and embedded in the device <b>100</b> together with the certificate <b>115</b> during the manufacturing process. However, preferably, the keys <b>113</b> and <b>114</b> are generated by the recording device <b>100</b> and are stored in non-volatile storage media <b>109</b>.

[0083] The recording device <b>100</b> provides to a user thereof a means of accessing the stored public key <b>114</b>, so that, as seen in FIG. 2, the user can send a copy <b>207</b> of the public key <b>114</b> to a certificate authority <b>560</b> for certification. The certificate authority <b>560</b> operates a function <b>211</b>, for example in the server computer <b>550</b>, to generate a digital certificate <b>217</b> which can be supplied to the user using an import certificate function <b>219</b> of the recording device <b>100</b>, which can then be stored as the certificate <b>115</b> described above. The certificate <b>217</b> is created using a private key <b>215</b> of the certificate authority <b>560</b>. Again, preferably, the certificate <b>217</b> conforms to the X.509 standard. Advantageously, the recording device <b>100</b> does not parse or check the certificate <b>217</b> as such is imported, and thus more than one certificate format, including future formats that may not yet have been conceived, may be supported without modifications to the recording device <b>100</b>. The user of the recording device <b>100</b> typically also supplies the certificate authority <b>560</b> with information <b>213</b> that is associated with the public key <b>114</b>, <b>207</b>. In this regard, the certificate <b>217</b> may contain miscellaneous information about the owner of the key <b>114</b>, <b>207</b> such as the time the certificate <b>217</b> was created. The owner of the key <b>114</b>, <b>207</b> must convince the certificate authority <b>560</b> that the information certified by the certificate <b>217</b> is correct and, in particular, that the public key <b>114</b>, <b>207</b> corresponds to a private key <b>115</b> owned by the user. In the described embodiment, this may be effected by the owner of the device <b>100</b> showing the device <b>100</b> to the certificate authority <b>560</b> and showing the public key <b>114</b>, <b>207</b> presented by the device <b>100</b>. The term “owner” in relation to the key <b>114</b>, <b>207</b> may either mean the *device* itself or the *person* owning the device. Such depends on what the certificate <b>217</b> is operating to certify. Either alternative may be used in some applications. Preferably, the information <b>213</b> includes at least the unique serial number (or device ID) of the recording device <b>100</b> and proof that the public key <b>207</b> was generated by the device <b>100</b> with the supplied serial number is given to the certificate authority <b>560</b>. The serial number of the recording device <b>100</b> can thus be included in the certificate <b>217</b>, as described previously. In other implementations, other information may be supplied to identify the owner of the public key <b>207</b>. In order to transfer the key <b>207</b> and information <b>213</b>, the recording device <b>100</b> may utilize the computer system <b>500</b> or a different computer network as an intermediary, for example where the direct connection <b>195</b> to the I/O interface <b>508</b> is used. Alternatively, and dependent upon the level of sophistication of the communications module <b>190</b>, communications between the device <b>100</b> and server <b>550</b> may be established directly via the network <b>520</b>. Alternatively, keys may be manually input into the server <b>550</b>.

[0084] Once the device <b>100</b> has stored a copy of the certificate <b>217</b> as the certificate <b>115</b>, the recording device <b>100</b> will then be ready to record data that can be authenticated.

[0085]FIG. 3 summarises, as a flowchart, a method <b>300</b> involved in producing and installing the keys and the certificate. The method <b>300</b> may be implemented typically as a number of software programs operating on the recording device <b>100</b>, the CA server <b>550</b> and possibly in concert with the computer system <b>500</b> and which operate in response to various user actions, and which have a nominal entry point as a start step <b>301</b>. In step <b>303</b> which follows, the user signals the device <b>100</b> to generate a key pair. This is performed using an appropriate user interface <b>185</b> arranged on the device <b>100</b>, seen in FIG. 1A. In step <b>305</b>, the recording device <b>100</b> generates the key pair <b>113</b>, <b>114</b>, this being accomplished using the function <b>201</b> seen in FIG. 2. In step <b>307</b>, again manipulating the user interface <b>185</b>, the user signals the device <b>100</b> to supply the generated public key <b>114</b> for user dissemination. In response, in step <b>309</b>, the device <b>100</b> delivers the copy <b>207</b> of the public key <b>114</b> to the user. This supply may be by way of the personal computer <b>500</b>, or for example to a user accessible location in the RAM <b>180</b> of the device <b>100</b>. In step <b>311</b>, the user supplies the public key copy <b>207</b>, from either the computer <b>500</b> or RAM <b>180</b>, together with the additional information <b>213</b>, to the certificate authority <b>560</b>, for example by way of the server <b>550</b>. At step <b>313</b>, the certificate authority <b>560</b> using the function <b>215</b> of FIG. 2, generates the certificate <b>217</b> and at step <b>315</b>, supplies the certificate <b>217</b> to the user. Again, this may occur via the computer <b>500</b> or directly to the RAM <b>180</b> of the device <b>100</b>. At step <b>317</b>, via the interface <b>185</b>, the user instructs the device <b>100</b> to store the certificate <b>217</b> as the certificate <b>115</b>, this being by way of the import certificate function <b>219</b> of FIG. 2. At step <b>319</b>, the device <b>100</b> stores the certificate <b>115</b> and the method ends at step <b>321</b>.

[0086]FIG. 4 shows the data and steps involved in authenticating the digital media file <b>120</b> according to a preferred implementation. These steps are preferably performed by a software application <b>400</b> running on the personal computer system <b>500</b> and includes two main independent processes involved in verifying the digital media file <b>120</b>, that has previously applied to the computer system <b>500</b>, for example as described above. The first process operates to verify that the digital signature <b>118</b> is a valid signature. The second process operates to verifying that the certificate <b>119</b> contained in the file <b>120</b> is genuine. In the preferred implementation, the signature verification process conforms to the Digital Signature Standard (DSS). In other implementations, other digital signature schemes may be used.

[0087] The first process of verifying the digital signature <b>118</b> includes firstly calculating a hash of the metadata <b>111</b> and the recorded data <b>112</b> stored in the file <b>120</b>. This hash is calculated using an SHA-1 algorithm <b>409</b> as specified by DSS. The resulting hash result <b>410</b> is used, together with an.,extracted version <b>413</b> of the public key <b>114</b> of the recording device <b>100</b>, as inputs to a DSS signature verification process <b>411</b>. The extracted public key <b>413</b> is obtained from the certificate <b>119</b> stored in the digital media file <b>120</b> and it will be recalled from the above that the public key <b>114</b> (<b>207</b>) was retained as part of the certificate <b>217</b>,<b>115</b>,<b>119</b>. Verifying the signature is performed by a function <b>411</b> that operates to decrypt the signature <b>118</b> using the regenerated public key <b>413</b> and comparing the decrypted signature with the hash result <b>410</b>. If the two are the same, the file <b>120</b> is authentic. The final verification step is also preferably performed in accordance with the DSS signature verification methodology.

[0088] The second process of verifying the certificate <b>119</b> is performed using a function <b>417</b> which verifies the digital signature on the certificate <b>119</b> using a public key <b>415</b> of the certificate authority <b>560</b>. Such does not need the public key of the device <b>413</b>. This is because what is desired is to check that the public key in the certificate matches the public key used to authenticate the file. In the described arrangement however, the public key (<b>413</b>) is obtained from the certificate <b>119</b>, and thus there is no need to access that key <b>413</b> separately. The certificate <b>119</b> is verified using the public key <b>415</b> of the certificate authority <b>560</b>, and the public key <b>114</b> (<b>413</b>) of the device <b>100</b> is just part of the data in the certificate <b>119</b>. Preferably, the certificate <b>119</b> conforms to the X.509 certificate format and any digital signature scheme suitable for use with X.509 certificates may be used.

Industrial Applicability

[0089] It is apparent from the above that the arrangements described are applicable to data capture and recording where verification of authenticity is desired. Such pervades the computer and data processing industries and has particular relevance to portable data capture devices, such as cameras, that may be connected to computer networks.

[0090] The foregoing describes only some embodiments of the present invention, and modifications and/or changes can be made thereto without departing from the scope and spirit of the invention, the embodiments being illustrative and not restrictive.

[0091] The present inventors and the present patent applicant note that the discussion in the “Background” section above regarding prior disclosures relates to those disclosures as merely public knowledge and such discussion is not to be construed as an admission by the inventors or the applicant that such disclosures represent all or part of the common general knowledge in the art in Australia or elsewhere.