WO2009113200A1 - 監視システムとその改ざんチェック方法 - Google Patents

監視システムとその改ざんチェック方法 Download PDF

Info

Publication number
WO2009113200A1
WO2009113200A1 PCT/JP2008/069368 JP2008069368W WO2009113200A1 WO 2009113200 A1 WO2009113200 A1 WO 2009113200A1 JP 2008069368 W JP2008069368 W JP 2008069368W WO 2009113200 A1 WO2009113200 A1 WO 2009113200A1
Authority
WO
WIPO (PCT)
Prior art keywords
signature
monitoring data
information
display
verification
Prior art date
Application number
PCT/JP2008/069368
Other languages
English (en)
French (fr)
Inventor
宗光 桑原
Original Assignee
株式会社 日立国際電気
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社 日立国際電気 filed Critical 株式会社 日立国際電気
Publication of WO2009113200A1 publication Critical patent/WO2009113200A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

Definitions

  • the present invention relates to a monitoring system for remotely monitoring the state of, for example, a facility or a river using a camera or the like and a tamper check method thereof.
  • imaging devices such as network cameras are arranged at a plurality of sites to be monitored, and time-series monitoring video data captured by these imaging devices is received and stored by the video storage device.
  • the video storage device reads out the corresponding monitoring video data, distributes it to the requesting client terminal, and reproduces the distributed monitoring video data in the client terminal.
  • monitoring data alteration checking is performed at the client terminal, and if the alteration is detected as a result or it is determined that the monitoring data is suspicious, the reproduction processing of the monitoring data is restricted. However, when the monitoring data reproduction process is restricted in this way, there is no way for the user of the client terminal to know the reason.
  • the main object of the present invention is to provide a monitoring system and a falsification check method that enable a client user to clearly confirm the result of a falsification check of monitoring data.
  • one aspect of the present invention employs the following configuration. That is, in a monitoring system comprising a monitoring data storage device that stores monitoring data and a terminal device that receives and reproduces monitoring data distributed from the monitoring data storage device via a communication network, the monitoring data storage device Thus, the authentication information generated using the first key information is added to the monitoring data, and the monitoring data with the authentication information added is transmitted to the terminal device via the communication network.
  • the terminal device receives the monitoring data to which the authentication information is added, transmitted from the monitoring data storage device, and acquires second key information corresponding to the first key information.
  • the display information representing the determination result is displayed on a display device in association with the monitoring data to be reproduced.
  • FIG. 1 is a block diagram showing a configuration of a monitoring system according to an embodiment of the present invention.
  • FIG. 2 is a block diagram showing the configuration of the client terminal of the monitoring system shown in FIG.
  • FIG. 3 is a diagram for explaining a first example in the case where video data with a signature is downloaded from the video storage device to the client terminal in the monitoring system shown in FIG.
  • FIG. 4 is a diagram showing the structure of a clip file used in the first embodiment shown in FIG.
  • FIG. 5 is a diagram for explaining a second example in the case where video data with a signature is downloaded from the video storage device to the client terminal in the system shown in FIG. FIG.
  • FIG. 6 is a diagram for explaining a third example in the case where video data with a signature is downloaded from the video storage device to the client terminal in the system shown in FIG.
  • FIG. 7 is a flowchart showing the procedure and contents of signature verification processing in the client terminal shown in FIG.
  • FIG. 8A is a diagram illustrating a display example of a verification result when signature verification is performed simultaneously with video display by the signature verification processing illustrated in FIG. 7.
  • FIG. 8B is a diagram illustrating a display example of a verification result when signature verification is performed simultaneously with video display by the signature verification processing illustrated in FIG. 7.
  • FIG. 8C is a diagram illustrating a display example of a verification result when signature verification is performed simultaneously with video display by the signature verification processing illustrated in FIG. 7.
  • FIG. 8A is a diagram illustrating a display example of a verification result when signature verification is performed simultaneously with video display by the signature verification processing illustrated in FIG. 7.
  • FIG. 8B is a diagram illustrating a display example of a verification result when signature verification is
  • FIG. 8D is a diagram illustrating a display example of a verification result when signature verification is performed simultaneously with video display by the signature verification processing illustrated in FIG. 7.
  • FIG. 8E is a diagram illustrating a display example of a verification result when signature verification is performed simultaneously with video display by the signature verification processing illustrated in FIG. 7.
  • FIG. 9A is a diagram illustrating a display example of a verification result when signature verification is performed separately from video display by the signature verification processing illustrated in FIG. 7.
  • FIG. 9B is a diagram illustrating a display example of a verification result when signature verification is performed separately from video display by the signature verification processing illustrated in FIG. 7.
  • FIG. 9C is a diagram illustrating a display example of verification results when signature verification is performed separately from video display by the signature verification processing illustrated in FIG. 7.
  • FIG. 9A is a diagram illustrating a display example of a verification result when signature verification is performed separately from video display by the signature verification processing illustrated in FIG. 7.
  • FIG. 9B is a diagram illustrating a display example of
  • FIG. 9D is a diagram illustrating a display example of a verification result when signature verification is performed separately from video display by the signature verification processing illustrated in FIG. 7.
  • FIG. 9E is a diagram illustrating a display example of a verification result when signature verification is performed separately from video display by the signature verification processing illustrated in FIG. 7.
  • FIG. 10 is a diagram illustrating a second display example of the verification result when the signature verification is performed simultaneously with the display of the video by the signature verification processing illustrated in FIG.
  • FIG. 11 is a diagram showing a first example of a report dialog that displays a list of verification results obtained by the signature verification processing shown in FIG.
  • FIG. 12 is a diagram illustrating a second example of a report dialog that displays a list of verification results obtained by the signature verification processing illustrated in FIG. FIG.
  • FIG. 13 is a diagram showing a third example of a report dialog for displaying a list of verification results obtained by the signature verification processing shown in FIG.
  • FIG. 14 is a diagram showing a fourth example of a report dialog for displaying a list of verification results obtained by the signature verification processing shown in FIG.
  • FIG. 1 is a block diagram showing a configuration of a monitoring system according to an embodiment of the present invention.
  • the monitoring system of this embodiment includes a network camera 1 installed at a monitoring location, a client terminal 3 used by a client, and a video storage device 2 in which these network camera 1 and client terminal 3 are connected via a network 4. And.
  • the network camera 1 has a camera unit and a communication interface unit. Then, the monitoring target is imaged continuously or at regular intervals by the camera unit, the video signal is A / D converted, and further encoded and compressed by a predetermined encoding method, and then the network 4 is transmitted as monitoring data by the communication interface unit. Is transmitted to the video storage device 2.
  • the encoding method include JPEG (Joint Photographic Experts Group 2), MPEG2 (Motion Picture Experts Group 2), MPEG4 (Motion Picture Experts Group 4), and H.264. H.264 is used.
  • the control module 24 switches the switch 23 to the terminal A side. For this reason, the created signature ID is selected by the switch 23 and stored in the storage module 25.
  • the control module 24 switches the switch 23 to the terminal B side. Therefore, a dummy signature ID is selected by the switch 23 instead of the signature ID and stored in the storage module 25.
  • the video storage device 2 reads out the video data Stream (i) designated by the download request and the corresponding signature ID from the storage module 25, and outputs them.
  • the data is transmitted from the distribution module 26 to the client terminal 3 that is the request source.
  • the video data Stream (i) is stored in the body portion of the HTTP packet, and the signature ID is stored in the header portion of the HTTP packet.
  • the client terminal 3 is composed of a personal computer, for example, and is configured as follows.
  • FIG. 2 is a block diagram showing the configuration. That is, the client terminal 3 includes a communication module 31, a storage module 32, a storage control module 33, and a reproduction module 34, and further includes a digital / analog converter (D / A) 35, a display device 36, A control module 37 and an input device 38 are provided.
  • D / A digital / analog converter
  • the communication module 31 executes a communication processing operation for receiving an HTTP packet with the video storage device 2 according to a protocol defined by the network 4 under the control of the main control module 37.
  • the storage module 32 uses, for example, a hard disk and has an area for storing video data received from the video storage device 2 and a signature ID.
  • the storage control module 33 extracts the video data Stream (i) from the body part of the received HTTP packet and the signature ID from the header part of the HTTP packet.
  • a process of storing the data Stream (i) and the signature ID in the storage module 32 is executed.
  • the video data Stream (i) and the signature ID are associated with each other (so-called strings).
  • XML eXtensible Markup Language
  • the playback module 34 includes a signature verification unit 341, a video decompression unit 342, and a verification result display control unit 343.
  • the signature verification unit 341 receives the video data Stream (i) received by the communication module 31 in real time and the video data Stream (i) stored in the storage module 32 when the video data Stream (i) is read and played back.
  • the signature verification for the signature ID corresponding to the data Stream (i) is executed.
  • the video decompression unit 342 receives the video data Stream (i) ⁇ ⁇ ⁇ received by the communication module 31 and the video data read from the storage module 32 from the storage control module 33 regardless of the verification result of the signature verification unit 341.
  • Stream (i) is expanded and the digital video signal obtained by this expansion processing is output.
  • the digital video signal is converted into an analog signal by the D / A 35 and then supplied to the display device 36 for display.
  • the display device 36 is composed of a liquid crystal display, for example.
  • the verification result display control unit 343 determines whether the public key hash value and the fingerprint FP (i) match each other by the signature verification unit 341 and the verification result of the signature Stream_sig (i). Is selectively generated, and display data indicating that the signature may have been tampered is selectively generated, and the generated display data is supplied to the display device 36 to Display it superimposed on the playback video.
  • the main control module 37 comprehensively controls the operation of the client terminal 3.
  • the input device 38 includes a keyboard and a mouse, for example, and is used by a user to input a video data download request, playback request, verification request, and the like.
  • the signature generation module 22 of the video storage device 2 when the signature flag is set to ON, the secret key S_key (i) for each frame is received for the received video data Stream (i). Based on the signature Stream_sig (i) ⁇ , and the generated signature Stream_sig (i) ⁇ and the fingerprint FP (i) ⁇ ⁇ which is the hash value of the public key paired with the private key S_key (i) ⁇ ⁇ A signature ID is created.
  • the generated signature ID is selected by the switch 23 and stored in the storage module 25 in association with the video data Stream (i).
  • a dummy signature ID is selected by the switch 23 instead of the signature ID, and this dummy signature ID is associated with the video data Stream (i). Stored in the storage module 25.
  • the user designates video data to be browsed based on the browse menu of the video storage device 2, and inputs a download request for the video data.
  • a download request for video data is transmitted from the client terminal 3 to the video storage device 2.
  • the video data Stream (i) designated by the download request and the corresponding signature ID are read from the storage module 25 for each frame.
  • the read video data Stream (i) is stored in the body portion of the HTTP packet, and the signature ID is stored in the header portion of the HTTP packet.
  • the HTTP packet is sent from the distribution module 26 to the requesting client terminal 3. Sent to.
  • the read signature ID is a dummy signature ID
  • the video data Stream (i) is stored in the body portion of the HTTP packet, but the dummy signature ID is not stored in the header portion of the HTTP packet. .
  • the process of storing the video data Stream (i) inserted in the HTTP packet and the signature ID in the storage module 332 is performed by the storage control module. 33. That is, in the case of video data with a signature, the video data Stream (i) and the signature ID are extracted from the body part and the header part of the received HTTP packet, respectively.
  • the extracted video data Stream (i) and the signature ID are stored in the storage module 32 as a video file and a signature file, respectively.
  • FIG. 3 shows a first example of the storage format.
  • the video data and the signature ID are stored in the storage module 32 as an independent video file and signature file for each frame.
  • the storage control module 33 reads a dummy signature ID stored in advance in the memory in the storage control module 33 and stores the dummy signature ID in the storage module 32 as a signature file.
  • the file name of the video data Stream (i) and the file name of the signature ID are described in the clip file of the XML document for each frame by the storage control module 33, and this clip file is stored in the storage module 32. Is done.
  • FIG. 4 shows a description example of this clip file. As shown in the figure, for each frame of video data, a video file and a signature file are described as elements 41 so as to be surrounded by a start tag ⁇ frame> and an end tag ⁇ / frame>.
  • an attribute name “value” 42 of the element “video file”, its attribute value “video file name” 43, and an element “signature file” An attribute name “value” 42 and an attribute value “signature file name” 43 are described.
  • the video file and the signature file are associated with each other for each frame. If a dummy signature ID is stored in the signature ID file, the dummy signature ID file is included as an element between the start tag ⁇ frame> and the end tag ⁇ / frame> together with the video file element. It is described in.
  • the storage format for storing the video file and the signature file in the storage module 34 in association with each other is not limited to the first example, and the following second and third examples are also considered. It is done.
  • a plurality of video data storage files and signature ID storage files are prepared, and the video data and signature ID extracted from the HTTP packet are stored in the video data storage file and signature ID storage, respectively.
  • a plurality of frames are stored together in a file.
  • FIG. 5 is a diagram for explaining the storage format.
  • the storage module 32 is provided with a plurality of video data storage files Vfg1, Vfg2,..., Vfgn and a plurality of signature ID storage files Sfg1, Sfg2,.
  • the video data storage files Vfg1, Vfg2,..., Vfgn are assigned identification numbers obtained by removing the extension from the file name of the video file (for example, 0001 if the file name is 0001.jpg).
  • each of the signature ID storage files Sfg1, Sfg2,..., Sfgn is assigned an identification number obtained by removing the extension from the file name of the signature file (for example, 0001 if the file name is 0001.sig).
  • the video data and the signature ID are added to the video data storage file Vfg1 and the signature ID storage file Sfg1, respectively.
  • the next video data storage file Vfg2 and signature ID storage file Sfg2 are selected.
  • the video data and signature ID are sequentially added to these files Vfg2 and Sfg2, respectively.
  • every time 1024 video data and signature data are stored in one video data storage file and signature ID storage file the next video data storage file and signature ID storage file are selected. Then, video data and signature data are stored in these.
  • the type of data to be written to the file JPEG, MPEG-4, H.264, signature, etc.
  • An individual header is added to each video data and signature ID.
  • the video data and the data length of the signature ID are written.
  • 1024 video data and signature IDs are written in video data storage files Vfg1, Vfg2,..., Vfgn and signature ID storage files Sfg1, Sfg2,.
  • the file names are associated with each other by identification numbers 0001, 0002,.
  • the signature ID storage file describes the signature ID and the start address and data length of the corresponding video data described in the corresponding video data storage file together with the line feed code. is there.
  • FIG. 6 shows the storage format. As shown in the figure, 1024 pieces of video data are stored in the video data storage files Vfg1, Vfg2,..., Vfgn, respectively, as in FIG. Note that the main header is described in the video data storage files Vfg1, Vfg2,..., Vfgn, and that each video data is provided with an individual header as in FIG.
  • the signature ID storage files Sfg1, Sfg2,..., Sfgn are respectively the signature IDs of the video data described in the corresponding video data storage files Vfg1, Vfg2,. Data length and line feed code are described.
  • the video data and the signature ID are the file names assigned to the video data storage files Vfg1, Vfg2,..., Vfgn and the signature ID storage files Sfg1, Sfg2,. These are associated with each other by identification numbers 0001, 0002,.
  • FIG. 7 is a flowchart showing the processing procedure and processing contents.
  • the hash value of the public key obtained in advance from a management center (not shown) and stored in the main control module 37 is calculated, and this hash value matches the fingerprint FP (i) ⁇ ⁇ included in the signature ID. It is determined whether or not to perform (step S61). If the result of this determination is that they do not match, it is determined in step S68 that the public key used for verification is not paired with the private key used for signature creation. In this case, the verification result display control unit 343 generates a warning message indicating that the public key may be incorrect in step S69, and supplies the display data of the warning message to the display device 36 shown in FIG. Display.
  • the signature verification unit 341 calculates the hash value (value A) of the video data Stream (i) in step S62, and the signature ID in step S63.
  • the signature Stream_sig (i) included in is expanded using the public key to obtain the B value.
  • the calculated A value and B value are compared to determine whether or not they match. As a result of the determination, if the A value and the B value match, it is determined in step S65 that the signature Stream_sig (i) is valid. If not, the signature Stream_sig (i) is determined invalid in step S66. To do.
  • the verification result display control unit 343 in FIG. 2 If it is determined that the signature Stream_sig (i) is invalid, the verification result display control unit 343 in FIG. 2 generates display data of a warning message indicating that the signature may have been tampered with in step S67.
  • the display data is supplied to the display device 36 for display.
  • FIG. 8A to 8E show a first display example of the signature verification result.
  • FIG. 8A is a display example of a video frame when there is no possibility that the signature has been tampered with, and in particular, a verification result message is not displayed.
  • 8B, 8C, and 8D are display examples when there is a possibility of falsification, FIG. 8B displays “Caution” as a warning message 81, and FIG. 8C shows “a video that may have been falsified”. This is a case where a warning message 82 “is detected.” Is displayed.
  • FIG. 8D displays a message that there is a possibility of falsification through a dialog 83, and an “OK” button 83a is displayed in this dialog.
  • FIG. 8E shows a display example when the public key is incorrect, and a warning message “There is a possibility that the public key is incorrect. Please set the correct public key.” Is displayed by the dialog 84. Also in this case, an “OK” button 84a is displayed on the dialog 84, and the dialog 84 continues to be displayed until the user clicks the “OK” button 84a.
  • FIG. 10 shows a second display example in which four video streams are displayed on a multi-screen, and a signature verification result is displayed on each screen in a manner similar to a traffic light.
  • the upper left and lower right are examples of video data display when there is no possibility that the signature has been tampered with, and the traffic light is lit in “blue”.
  • the upper right is a display example when the signature may have been tampered with, and “red” lights up on the traffic light.
  • the currently displayed video frame is in the real-time playback mode, it is updated to the next video frame, but the above dialog continues to be displayed until the user clicks the “OK” button.
  • the user does not miss that a video frame that may have been altered has been found. Can be confirmed.
  • the lower left is a display example when the public key is incorrect, and the traffic light is lit yellow.
  • (3-2) When playing back video data stored in the storage module It is assumed that the user designates a desired video data stream stored in the storage module 32 and inputs a playback request in the input device 38 . Then, the storage control module 33 sequentially reads out the corresponding video data and its signature ID from the storage module 32 for each frame. For example, if the storage format of the video data and the signature ID is as shown in FIG. 3, the storage control module 33 first opens the clip file, and between the first start tag ⁇ frame> and the end tag ⁇ / frame>. It is determined whether or not the element “video file” is described.
  • the attribute value “video file name” of the attribute “value” corresponding to the element “video file” and the attribute value “signature file name” of the attribute name “value” corresponding to the element “signature file” ”And a video file and a signature file are read based on the read attribute values. Thereafter, the reading process is repeated until all the pairs of the element “video file” and the element “signature file” described in the clip file are read.
  • the storage control module 33 sends the video data storage files Vfg1, Vfg2,..., Vfgn and the corresponding signature ID storage files Sfg1,.
  • Sfg2,..., Sfgn are sequentially selected one by one, and the video data and signature ID are sequentially read out in units of frames based on the information of the individual headers from the selected video data storage file and the corresponding signature ID storage file.
  • the storage control module 33 first selects and selects the signature ID storage files Sfg1, Sfg2,.
  • the signature ID of the video data, the head address of the video data, and the data length signature ID are read from the signature ID storage file.
  • the corresponding video data is read from the video data storage file.
  • the signature ID and the like stored in one selected signature ID storage file are sequentially read, and the corresponding video data is sequentially read from the corresponding video data storage file.
  • the next signature ID storage file is selected and the same reading process is executed.
  • the video decompression unit 342 of the playback module 34 decompresses the video data of the video file each time one video file is read by the storage control module 33.
  • the digital video signal reproduced by this expansion processing is converted into an analog signal by the D / A 35 and displayed on the display device 36.
  • the signature verification unit 341 of the playback module 34 executes a signature verification process for the signature included in the read signature ID.
  • the processing procedure and processing contents of this signature verification processing are the same as those described above with reference to FIG. That is, when it is determined that the signature is invalid, a message indicating that the signature may be falsified is displayed as shown in FIGS. 8B to 8D, or the traffic light is red as shown in FIG. Light. If the public key is not correct, a message indicating that the public key may be incorrect is displayed as shown in FIG. 8E, or the traffic light is lit in yellow as shown in FIG.
  • the storage control module 33 stops reading the next video file and signature file. This stop state is, for example, until the user clicks the “OK” button 83a, 84a of the dialog 83, 84 shown in FIGS. 8D and 8E, or the “red” display device position, “yellow” display device position of the traffic light. It continues until the user clicks.
  • the storage control module 33 reads the signature file of the video data stream designated by the verification request in the order of frames, and passes it to the signature verification unit 341 of the reproduction module 34.
  • the signature file reading process is also performed by referring to the clip file as described above.
  • the signature verification unit 341 executes the verification process every time the signature file is passed and stores the result.
  • the stored verification results are collected and passed to the verification result display control unit 343.
  • 9A to 9E show a first example in which a signature is verified separately from video display.
  • the verification result display control unit 343 If all the verification results for all the received frames are valid, the verification result display control unit 343 generates a message indicating that the falsification has been made, and displays the message using a dialog 91 as shown in FIG. 9A, for example. Display overlaid on top.
  • messages 92 and 93 indicating that the signature may have been tampered with.
  • 94 are generated and displayed as shown in FIGS. 9B to 9D in a state of being superimposed on the video. If the public key is not correct, a message 95 indicating that the public key may be incorrect is generated, and displayed as shown in FIG.
  • the display result of the signature verification ends when a certain time elapses or when the user clicks the “OK” buttons 94a and 95b of the dialog.
  • the progress bars 91b and 94b may be displayed in the dialogs 91 and 94, and the progress degree may be displayed on the progress bars 91b and 94b during the verification process.
  • the display form is not limited to FIG. 9A to FIG. 9E, and a display model imitating a traffic light as shown in FIG. 10 may be used.
  • the initial state the top frames of the four video data streams stored in the storage module 32 are displayed on the multi-screen.
  • the screen selected by the recording control module 33 and the playback module 34 is selected.
  • the signature verification process is executed for the video data stream corresponding to the above. Then, after the verification for the frame is completed, the result is displayed on the corresponding screen in the form of a traffic light.
  • the signature verification result for the video data stream obtained by the signature verification unit 341 of the reproduction module 34 is stored as a verification report in the storage module 32 by the storage control module 33.
  • the verification report is displayed on the display device 36 in a predetermined format when the user inputs a display request using the input device 38.
  • FIG. 11 shows a first example of the display format.
  • icons corresponding to a plurality of video files constituting one video stream are displayed in a tree together with file names (for example, 2007-07-06-27-10-57-30-000.JPG). Is displayed in association with the status.
  • a corresponding icon an icon indicated as NG in the figure
  • the icon is displayed in “red”
  • the public key is also displayed.
  • a “?” Mark is added to a corresponding icon (an icon indicated as ERROR in the figure), and the icon is displayed in “yellow”.
  • the corresponding icon For a video file whose signature is determined to be valid, the corresponding icon is displayed in, for example, “blue”. In this state, it is assumed that the user clicks, for example, an icon with the “!” Mark. Then, a corresponding image file is read from the storage module 32 by the storage control module 33, and this image file is expanded by the video expansion unit 342 of the reproduction module 34, and then displayed by another dialog with a file name. 36.
  • FIG. 12 shows a second example of the display format of the verification report.
  • icons corresponding to a plurality of video files constituting one video stream are sequentially displayed so that a part thereof overlaps.
  • the corresponding icon icon indicated as NG in the figure
  • the corresponding icon (the icon labeled ERROR in the figure) is colored “yellow”.
  • 11 and 12 the icon of the video file for which the signature is determined to be valid is colored “blue”.
  • the storage control module 33 reads the corresponding image file from the storage module 32, and this image file is decompressed by the playback module 34. After being decompressed by the unit 342, it is displayed on the display device 36 by another dialog with a file name.
  • FIG. 13 shows a third example of the display format of the verification report.
  • a data file name display area E1 and an icon display area E2 are provided in the report dialog.
  • file names of a plurality of video files constituting one video data stream are displayed together with symbols (OK, NG, ERR) indicating verification results.
  • icons of a plurality of video files constituting one video data stream are displayed in a matrix with file names. These icons are colored in different colors depending on the verification result. For example, an icon corresponding to a video file whose signature is determined to be valid is colored “blue”, an icon corresponding to a video file whose signature is determined to be invalid is colored “red”, and the public key may be incorrect.
  • the icon corresponding to the video file determined to have the property is colored “yellow”. For example, when the user clicks on the icon colored “red”, the storage control module 33 reads the corresponding image file from the storage module 32, and this image file is read by the video decompression unit 342 of the playback module 34. After being decompressed, it is displayed on the display device 36 by another dialog with a file name.
  • FIG. 14 shows a fourth example of the display format of the verification report.
  • the icon described in the third example and a thumbnail of the video are displayed together.
  • the client terminal 3 performs the signature verification process based on the video data sent from the video storage device 2 and its signature ID, and the signature is generated based on the verification result. It is determined whether there is a possibility of falsification and whether there is a possibility that the public key is incorrect, and a message indicating the determination result or a mark (for example, traffic light color lighting) or symbol (for example, OK, NG, ERR) ) Is displayed superimposed on the video data. Therefore, the user of the client terminal 3 can clearly recognize the result of the falsification check by distinguishing whether the video data has been falsified or the public key is incorrect.
  • a mark for example, traffic light color lighting
  • symbol for example, OK, NG, ERR
  • the verification result of each frame constituting one video data stream is displayed as a verification report with a mark or a symbol added to the report dialog. For this reason, the user can confirm at a glance which frame in the video data has been tampered with.
  • the file name of the video data and the file name of the signature ID are described for each frame in the clip file of the XML document. Therefore, even when writing of additional information to the user data area of video data is restricted, it is possible to clearly associate the video file and the signature file for each frame.
  • the present invention is not limited to the above embodiment.
  • the case where video data is distributed as monitoring data has been described as an example.
  • the present invention is applicable not only to video data but also to sound data and text data.
  • the case where the signature is added to the video data and the downloaded video playback software and the verification is performed is described as an example.
  • the verification is performed by adding the message authentication code (MAC).
  • MAC message authentication code
  • the present invention is applicable. In this case, however, a common key is used instead of the secret key and the public key.
  • the configuration of the monitoring data storage device and the terminal device, the processing procedure and processing content, the signature verification method, the display form of the verification result, and the like can be variously modified without departing from the gist of the present invention.
  • the present invention is not limited to the above-described embodiment as it is, and can be embodied by modifying the constituent elements without departing from the scope of the invention in the implementation stage.
  • various inventions can be formed by appropriately combining a plurality of constituent elements disclosed in the embodiment. For example, some components may be deleted from all the components shown in the embodiment. Furthermore, you may combine suitably the component covering different embodiment.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Closed-Circuit Television Systems (AREA)
  • Storage Device Security (AREA)

Abstract

　クライアント端末（３）において、映像蓄積装置２から送られた映像データとその署名ＩＤをもとに署名検証部（３４１）で署名検証処理を行い、その検証結果をもとに署名が改ざんされた可能性の有無と、公開鍵が正しくない可能性の有無をそれぞれ判定する。そして、判定結果を表すメッセージ或いはそれに代わるマークや記号を検証結果表示制御モジュール（３４３）により生成し、これを映像データに重畳して表示デバイス（３６）に表示させる。また、１つの映像データストリームを構成する各フレームの検証結果を記憶制御モジュール（３３）により記憶モジュール（３２）に保存しておき、検証結果表示制御モジュール（３４３）により、上記保存された検証結果をレポート・ダイアログとして表示デバイス（３６）に一覧表示させる。

Description

監視システムとその改ざんチェック方法
　この発明は、例えば施設や河川等の状態をカメラ等を用いて遠隔監視する監視システムとその改ざんチェック方法に関する。
　遠隔監視システムは、例えば監視対象の複数のサイトにネットワークカメラ等の撮像装置を配置し、これらの撮像装置で撮像された時系列の監視映像データを映像蓄積装置で受信して蓄積する。そして、クライアント端末からの配信要求に応じて、上記映像蓄積装置が該当する監視映像データを読み出して上記要求元のクライアント端末へ配信し、当該クライアント端末において上記配信された監視映像データを再生するように構成される（例えば、特開２００５－１４３０１６号公報を参照）。
　ところで、最近監視データの改ざんを防止してその正当性を維持するために、監視データに署名やメッセージ認証コードなどの認証情報を付加する対策が講じられている。その際、認証情報の付加方法としては例えば映像データのユーザデータ領域に記述する方法が用いられる。しかし、監視データによってはユーザデータ領域への付加情報の書き込みが制限されている場合があり、このような場合には認証情報を付加することができない。
　また、クライアント端末において監視データの改ざんチェックが行われ、その結果改ざんが検出された場合や疑わしいと判定されると、監視データの再生処理が制限される。しかし、このように監視データの再生処理が制限された場合、クライアント端末のユーザにとってはその理由を知る術がない。
　この発明の主たる目的は、監視データの改ざんチェックの結果をクライアントユーザが明確に確認することを可能にした監視システムとその改ざんチェック方法を提供することである。
　上記目的を達成するためにこの発明の一観点は、以下のような構成を採用したものである。すなわち、監視データを蓄積する監視データ蓄積装置と、この監視データ蓄積装置から通信ネットワークを介して配信された監視データを受信し再生する端末装置とを備える監視システムにあって、上記監視データ蓄積装置により、上記監視データに対し第１の鍵情報を用いて生成される認証情報を付加して、この認証情報が付加された監視データを上記通信ネットワークを介して上記端末装置へ送信する。一方、上記端末装置では、上記監視データ蓄積装置から送信された、上記認証情報が付加された監視データを受信すると共に、上記第１の鍵情報に対応する第２の鍵情報を取得する。そして、上記監視データに付加された認証情報に対し上記第２の鍵情報をもとに検証処理を行って、上記監視データが改ざんされた可能性の有無と、上記第２の鍵情報が正しくない可能性の有無をそれぞれ判定し、上記判定結果を表す表示情報を上記再生対象の監視データに対応付けて表示デバイスに表示させるように構成したものである。
図１は、この発明の一実施形態に係わる監視システムの構成を示すブロック図である。 図２は、図１に示した監視システムのクライアント端末の構成を示すブロック図である。 図３は、図１に示した監視システムにおいて、映像蓄積装置からクライアント端末へ署名付きの映像データをダウンロードする場合の第１の例を説明するための図である。 図４は、図３に示した第１の実施例で使用されるクリップファイルの構成を示す図である。 図５は、図１に示したシステムにおいて、映像蓄積装置からクライアント端末へ署名付きの映像データをダウンロードする場合の第２の例を説明するための図である。 図６は、図１に示したシステムにおいて、映像蓄積装置からクライアント端末へ署名付きの映像データをダウンロードする場合の第３の例を説明するための図である。 図７は、図２に示したクライアント端末における署名検証処理の手順と処理内容を示すフローチャートである。 図８Ａは、図７に示した署名検証処理により映像の表示と同時に署名検証を行ったときの検証結果の表示例を示す図である。 図８Ｂは、図７に示した署名検証処理により映像の表示と同時に署名検証を行ったときの検証結果の表示例を示す図である。 図８Ｃは、図７に示した署名検証処理により映像の表示と同時に署名検証を行ったときの検証結果の表示例を示す図である。 図８Ｄは、図７に示した署名検証処理により映像の表示と同時に署名検証を行ったときの検証結果の表示例を示す図である。 図８Ｅは、図７に示した署名検証処理により映像の表示と同時に署名検証を行ったときの検証結果の表示例を示す図である。 図９Ａは、図７に示した署名検証処理により映像の表示とは別に署名検証を行ったときの検証結果の表示例を示す図である。 図９Ｂは、図７に示した署名検証処理により映像の表示とは別に署名検証を行ったときの検証結果の表示例を示す図である。 図９Ｃは、図７に示した署名検証処理により映像の表示とは別に署名検証を行ったときの検証結果の表示例を示す図である。 図９Ｄは、図７に示した署名検証処理により映像の表示とは別に署名検証を行ったときの検証結果の表示例を示す図である。 図９Ｅは、図７に示した署名検証処理により映像の表示とは別に署名検証を行ったときの検証結果の表示例を示す図である。 図１０は、図７に示した署名検証処理により映像の表示と同時に署名検証を行ったときの検証結果の第２の表示例を示す図である。 図１１は、図７に示した署名検証処理により得られた検証結果を一覧表示するレポート・ダイアログの第１の例を示す図である。 図１２は、図７に示した署名検証処理により得られた検証結果を一覧表示するレポート・ダイアログの第２の例を示す図である。 図１３は、図７に示した署名検証処理により得られた検証結果を一覧表示するレポート・ダイアログの第３の例を示す図である。 図１４は、図７に示した署名検証処理により得られた検証結果を一覧表示するレポート・ダイアログの第４の例を示す図である。
　以下、図面を参照してこの発明の一実施形態を説明する。　
　図１は、この発明の一実施形態に係わる監視システムの構成を示すブロック図である。この実施形態の監視システムは、監視場所に設置されたネットワークカメラ１と、クライアントが使用するクライアント端末３と、これらのネットワークカメラ１及びクライアント端末３がネットワーク４を介して接続される映像蓄積装置２とを備えている。
　ネットワークカメラ１はカメラ部と通信インタフェース部とを有する。そして、監視対象をカメラ部により連続的に又は一定時間置きに撮像し、その映像信号をＡ／Ｄ変換しさらに所定の符号化方式により符号化圧縮したのち、監視データとして通信インタフェース部によりネットワーク４を介して映像蓄積装置２へ送信する。符号化方式としては例えばＪＰＥＧ（Joint Photographic Experts Group）、ＭＰＥＧ２（Motion Picture Experts Group 2）、ＭＰＥＧ４（Motion Picture Experts Group 4）又はＨ．２６４が用いられる。
　映像蓄積装置２は、例えば蓄積配信機能を有するサーバ装置からなり、以下のように構成される。すなわち、上記ネットワークカメラ１からネットワーク４を介して送られた映像データStream(i) (i=1,2,3,…) は、ストリームごとに受信モジュール２１で受信されて蓄積モジュール２５に格納されると共に、署名生成モジュール２２に入力される。署名生成モジュール２２は、署名フラグがオンに設定されている場合に、上記受信された映像データStream(i)に対して、そのストリームごとに秘密鍵S_key(i)を用いて署名Stream_sig(i)を生成する。そして、この生成した署名Stream_sig(i)と、上記秘密鍵S_key(i)と対をなす公開鍵のハッシュ値であるフィンガプリントFP(i)とを合わせて署名ＩＤを作成する。上記署名フラグがオンになっていると、制御モジュール２４によりスイッチ２３が端子Ａ側に切り替わる。このため、上記作成された署名ＩＤはスイッチ２３により選択されて蓄積モジュール２５に格納される。これに対し映像蓄積装置の署名フラグがオフに設定されている場合には、制御モジュール２４によりスイッチ２３が端子Ｂ側に切り替わる。このため、上記署名ＩＤに代わってダミーの署名ＩＤがスイッチ２３により選択されて蓄積モジュール２５に格納される。
　また映像蓄積装置２は、クライアント端末３から映像データのダウンロード要求が到来した場合に、当該ダウンロード要求により指定された映像データStream(i)とそれに対応する署名ＩＤを蓄積モジュール２５から読み出し、これらを配信モジュール２６から要求元のクライアント端末３に向けて送信する。このとき、上記映像データStream(i)はHTTPパケットのボディ部に格納され、署名ＩＤはHTTPパケットのヘッダ部に格納される。
　クライアント端末３は、例えばパーソナル・コンピュータからなり、以下のように構成される。図２はその構成を示すブロック図である。すなわち、クライアント端末３は、通信モジュール３１と、記憶モジュール３２と、記憶制御モジュール３３と、再生モジュール３４とを備え、さらにディジタル／アナログ変換器（Ｄ／Ａ）３５と、表示デバイス３６と、主制御モジュール３７と、入力デバイス３８とを備えている。
　通信モジュール３１は、主制御モジュール３７の制御の下で、ネットワーク４で規定されるプロトコルに従い、前記映像蓄積装置２との間でHTTPパケットを受信するための通信処理動作を実行する。記憶モジュール３２は例えばハードディスクを使用したもので、映像蓄積装置２から受信した映像データ及び署名ＩＤを記憶する領域を有する。記憶制御モジュール３３は、主制御モジュール３７の制御の下で、上記受信されたHTTPパケットのボディ部から映像データStream(i)を取り出すと共にHTTPパケットのヘッダ部から署名ＩＤを取り出し、この取り出した映像データStream(i)及び署名ＩＤを上記記憶モジュール３２に記憶させる処理を実行する。またそれと共に、上記映像データStream(i) と署名ＩＤとを相互に対応付け（いわゆるひも付け）るため、映像データStream(i) のファイル名及び署名ＩＤのファイル名を、映像データのフレームごとにＸＭＬ（eXtensible Markup Language）文書のクリップファイルに記載する。
　再生モジュール３４は、署名検証部３４１と、映像伸長部３４２と、検証結果表示制御部３４３を備える。署名検証部３４１は、通信モジュール３１で受信された映像データStream(i) をリアルタイムに再生する場合、及び記憶モジュール３２に記憶された映像データStream(i) を読み出して再生する場合に、当該映像データStream(i) に対応する署名ＩＤに対する署名検証を実行する。
　映像伸長部３４２は、上記署名検証部３４１の検証結果とは無関係に、上記通信モジュール３１により受信された映像データStream(i) 、及び記憶モジュール３２から記憶制御モジュール３３から読み出された映像データStream(i) を伸長し、この伸長処理により得られたディジタル映像信号を出力する。このディジタル映像信号はＤ／Ａ３５によりアナログ信号に変換されたのち表示デバイス３６に供給されて表示される。表示デバイス３６は例えば液晶ディスプレイからなる。
　検証結果表示制御部３４３は、上記署名検証部３４１による公開鍵のハッシュ値とフィンガプリントFP(i) との一致／不一致の判定結果と、署名Stream_sig(i) の検証結果に基づいて、公開鍵が正しくない可能性があることを表す表示データと、署名が改ざんされた可能性があることを表す表示データを選択的に生成し、この生成された表示データを表示デバイス３６に供給して上記再生映像に重畳して表示させる。　
　主制御モジュール３７は、クライアント端末３の動作を統括的に制御する。入力デバイス３８は例えばキーボード及びマウスからなり、利用者が映像データのダウンロード要求、再生要求、検証要求等を入力するために使用される。
　次に、以上のように構成された監視システムの動作を説明する。　
　（１）映像データとその署名ＩＤの蓄積
　映像蓄積装置２では、例えばネットワークカメラ１ごとに、署名を行うか否かを表す情報がオペレータにより予め指定入力される。この署名を行うか否かを表す情報は、署名フラグとして装置２内のメモリに保存される。
　この状態でネットワークカメラ１において監視動作が開始され、監視対象物の映像データStream(i) (i=1,2,3,…) が送信されたとする。そうすると、この映像データStream(i) は映像蓄積装置２において受信モジュール２１で受信されたのち蓄積モジュール２５に格納される。またそれと並行して映像蓄積装置２の署名生成モジュール２２では、署名フラグがオンに設定されているときには、上記受信された映像データStream(i) に対してそのフレームごとに秘密鍵S_key(i) をもとに署名Stream_sig(i) が生成され、この生成された署名Stream_sig(i) と、上記秘密鍵S_key(i) と対をなす公開鍵のハッシュ値であるフィンガプリントFP(i) とにより、署名ＩＤが作成される。そして、この作成された署名ＩＤはスイッチ２３により選択され、上記映像データStream(i) に対応付けられて蓄積モジュール２５に格納される。これに対し、署名フラグがオフに設定されているときには、上記署名ＩＤに代わってダミーの署名ＩＤがスイッチ２３により選択され、このダミーの署名ＩＤが上記映像データStream(i) に対応付けられて蓄積モジュール２５に格納される。
　（２）映像データ及び署名ＩＤのダウンロード
　さて、クライアント端末３において利用者が、映像蓄積装置２の閲覧メニューをもとに閲覧対象の映像データを指定した上で、当該映像データのダウンロード要求を入力したとする。そうすると、クライアント端末３から映像蓄積装置２に対し映像データのダウンロード要求が送信される。映像蓄積装置２では、クライアント端末３から映像データのダウンロード要求が到来すると、当該ダウンロード要求により指定された映像データStream(i) とそれに対応する署名ＩＤが、フレームごとに蓄積モジュール２５から読み出される。そして、この読み出された映像データStream(i) はHTTPパケットのボディ部に格納され、かつ署名ＩＤはHTTPパケットのヘッダ部に格納され、このHTTPパケットが配信モジュール２６から要求元のクライアント端末３に向け送信される。　
　なお、読み出された署名ＩＤがダミーの署名ＩＤの場合には、映像データStream(i) はHTTPパケットのボディ部に格納されるが、ダミーの署名ＩＤはHTTPパケットのヘッダ部には格納されない。
　クライアント端末３では、自端末宛てのHTTPパケットが通信モジュール３１で受信されると、このHTTPパケットに挿入された映像データStream(i) 及び署名ＩＤを記憶モジュール３３２に記憶する処理が、記憶制御モジュール３３により実行される。すなわち、先ず署名付きの映像データの場合には、上記受信されたHTTPパケットのボディ部及びヘッダ部からそれぞれ映像データStream(i) 及び署名ＩＤが抽出される。そして、この抽出された映像データStream(i) 及び署名ＩＤはそれぞれ映像ファイル及び署名ファイルとして記憶モジュール３２に格納される。図３は、その記憶フォーマットの第１の例を示すもので、映像データ及び署名ＩＤはフレームごとにそれぞれ独立する映像ファイル及び署名ファイルとして記憶モジュール３２に格納される。
　なお、署名のない映像データの場合には、上記受信されたHTTPパケットのヘッダ部から署名ＩＤが抽出されない。そこで、記憶制御モジュール３３は、記憶制御モジュール３３内のメモリに予め保存されているダミーの署名ＩＤを読み出し、このダミーの署名ＩＤを署名ファイルとして記憶モジュール３２に格納する。
　またクライアント端末３では、記憶制御モジュール３３により、上記映像データStream(i) のファイル名及び署名ＩＤのファイル名がフレームごとにＸＭＬ文書のクリップファイルに記載され、このクリップファイルが記憶モジュール３２に格納される。図４にこのクリップファイルの記載例を示す。同図に示すように、映像データのフレームごとに、映像ファイル及び署名ファイルをそれぞれ要素４１として、開始タグ<frame>と終了タグ</frame>とにより囲むように記載する。また、開始タグ<frame>と終了タグ</frame>との間には、要素「映像ファイル」の属性名「値」４２とその属性値「映像ファイル名」４３と、要素「署名ファイル」の属性名「値」４２とその属性値「署名ファイル名」４３が記載される。　
　このように記載することで、映像ファイルと署名ファイルとはフレームごとに相互に対応付けられる。なお、署名ＩＤのファイルにダミーの署名ＩＤが格納されている場合には、このダミーの署名ＩＤのファイルが要素として映像ファイルの要素と共に開始タグ<frame>と終了タグ</frame>との間に記載される。
　なお、上記映像ファイル及び署名ファイルを相互に対応付けて記憶モジュール３４に格納するときの記憶フォーマットとしては、上記第１の例に限らず、以下に示す第２の例及び第３の例も考えられる。　
　先ず第２の例は、映像データ格納用のファイルと署名ＩＤ格納用のファイルをそれぞれ複数個用意し、HTTPパケットから取り出した映像データ及び署名ＩＤをそれぞれ上記映像データ格納用ファイル及び署名ＩＤ格納用ファイルに複数フレーム分ずつまとめて格納するようにしたものである。
　図５はその記憶フォーマットを説明するための図である。同図に示すように、記憶モジュール３２には、複数の映像データ格納用ファイルＶfg1，Ｖfg2，…，Ｖfgnと、これらに対応する複数の署名ＩＤ格納用ファイルＳfg1，Ｓfg2，…，Ｓfgn が用意される。映像データ格納用ファイルＶfg1，Ｖfg2，…，Ｖfgnには、映像ファイルのファイル名から拡張子を除いた識別番号（例えばファイル名が0001.jpgであれば0001）が付与される。一方、署名ＩＤ格納用ファイルＳfg1，Ｓfg2，…，Ｓfgnにはそれぞれ、署名ファイルのファイル名から拡張子を除いた識別番号（例えばファイル名が0001.sigであれば0001）が付与される。
　そして、HTTPパケットが受信されて映像データ及び署名ＩＤが抽出されるごとに、これらの映像データ及び署名ＩＤがそれぞれ上記映像データ格納用ファイルＶfg1及び署名ＩＤ格納用ファイルＳfg1に追記される。そして、映像データ格納用ファイルＶfg1及び署名ＩＤ格納用ファイルＳfg1にそれぞれ１０２４個分の映像データ及び署名データが格納されると、次の映像データ格納用ファイルＶfg2及び署名ＩＤ格納用ファイルＳfg2が選択され、これらのファイルＶfg2，Ｓfg2にそれぞれ映像データ及び署名ＩＤが順次追記される。以後同様に、１つの映像データ格納用ファイル及び署名ＩＤ格納用ファイルにそれぞれ１０２４個分の映像データ及び署名データが格納されるごとに、次の映像データ格納用ファイル及び署名ＩＤ格納用ファイルが選択されて、これらに映像データ及び署名データが格納される。
　なお、各映像データ格納用ファイルＶfg1，Ｖfg2，…，Ｖfgn及び署名ＩＤ格納用ファイルＳfg1，Ｓfg2，…，Ｓfgnにはそれぞれメインヘッダが設けられる。このメインヘッダには、ファイルに書き込むデータの種類（JPEG、MPEG-4、H.264、署名など）が書き込まれる。また、各映像データ及び署名ＩＤにはそれぞれ個別ヘッダが付加される。この個別ヘッダには、映像データ及び署名ＩＤのデータ長が書き込まれる。
　したがって、この第２の例では、映像データ及び署名ＩＤは１０２４個ずつ映像データ格納用ファイルＶfg1，Ｖfg2，…，Ｖfgn及び署名ＩＤ格納用ファイルＳfg1，Ｓfg2，…，Ｓfgnに記載され、これらのファイル単位でそのファイル名の識別番号0001，0002，…，0024により相互に対応付けられる。
　次に第３の例は、署名ＩＤ格納用ファイルに、署名ＩＤと、対応する映像データ格納用ファイルに記載される該当映像データの先頭アドレスとデータ長を改行コードと共に記載するようにしたものである。　
　図６はその記憶フォーマットを示す図である。同図に示すように、映像データ格納用ファイルＶfg1，Ｖfg2，…，Ｖfgnにはそれぞれ、前記図５と同様に１０２４個分の映像データが格納される。なお、映像データ格納用ファイルＶfg1，Ｖfg2，…，Ｖfgnにメインヘッダが記載される点と、各映像データに個別ヘッダが付与される点も、前記図５と同様である。一方、署名ＩＤ格納用ファイルＳfg1，Ｓfg2，…，Ｓfgnにはそれぞれ、対応する映像データ格納用ファイルＶfg1，Ｖfg2，…，Ｖfgnに記載された各映像データの署名ＩＤと、当該映像データの先頭アドレスと、データ長と、改行コードが記載される。
　したがって、この第３の例においても、映像データと署名ＩＤとは、映像データ格納用ファイルＶfg1，Ｖfg2，…，Ｖfgn及び署名ＩＤ格納用ファイルＳfg1，Ｓfg2，…，Ｓfgnに付与されたファイル名の識別番号0001，0002，…，0024により相互に対応付けられる。
　（３）映像データの再生に伴う署名検証
　（３－１）受信した映像データをリアルタイムに再生する場合
　映像蓄積装置２から送信されたHTTPパケットが通信モジュール３１で受信されると、再生モジュール３４の映像伸長部３４２が、上記HTTPパケットのボディ部から取り出された映像データStream(i) を伸長する。この伸長処理により再生されたディジタル映像信号はＤ／Ａ３５によりアナログ信号に変換されて表示デバイス３６に表示される。
　また、この映像データStream(i) の再生処理と並行して、再生モジュール３４の署名検証部３４１が、上記HTTPパケットのヘッダ部から取り出された署名ＩＤに対する署名検証処理を実行する。図７は、その処理手順と処理内容を示すフローチャートである。
　すなわち、先ず図示しない管理センタ等から予め取得して主制御モジュール３７に保存しておいた公開鍵のハッシュ値を計算し、このハッシュ値を上記署名ＩＤに含まれるフィンガプリントFP(i) と一致するかどうかを判定する（ステップＳ６１）。この判定の結果、不一致だったとすると、検証に用いた公開鍵は署名の作成に用いた秘密鍵とペアではないとステップＳ６８で判断する。この場合、検証結果表示制御部３４３はステップＳ６９により、公開鍵が正しくない可能性がある旨の警告メッセージを生成し、当該警告メッセージの表示データを図２に示した表示デバイス３６に供給して表示させる。
　一方、上記公開鍵のハッシュ値とフィンガプリントFP(i) が一致すると、署名検証部３４１はステップＳ６２で映像データStream(i) のハッシュ値（値Ａ）を計算すると共に、ステップＳ６３で署名ＩＤに含まれる署名Stream_sig(i) を上記公開鍵を用いて伸長してＢ値を求める。そして、ステップＳ６４により上記計算されたＡ値とＢ値とを比較し、両者が一致するか否かを判定する。この判定の結果、上記Ａ値とＢ値が一致すればステップＳ６５により上記署名Stream_sig(i) は有効と判断し、これに対し不一致であればステップＳ６６で上記署名Stream_sig(i) は無効と判断する。署名Stream_sig(i) が無効と判断されると、図２における検証結果表示制御部３４３はステップＳ６７において、署名が改ざんされた可能性がある旨の警告メッセージの表示データを生成し、この警告メッセージの表示データを表示デバイス３６に供給して表示させる。
　図８Ａ乃至図８Ｅは、上記署名検証結果の第１の表示例を示すものである。同図において、図８Ａは署名が改ざんされた可能性がない場合の映像フレームの表示例であり、特に検証結果のメッセージは表示されない。図８Ｂ，図８Ｃ，図８Ｄは改ざんされた可能性がある場合の表示例であり、図８Ｂは「注意」を警告メッセージ８１として表示し、図８Ｃは「改ざんされた可能性のある映像を検出しました。」なる警告メッセージ８２を表示した場合である。図８Ｄは改ざんされた可能性がある旨のメッセージをダイアログ８３により表示するもので、このダイアログには「ＯＫ」ボタン８３ａが表示される。このとき、表示中の映像フレームはリアルタイム再生モードであるため次の映像フレームに更新されるが、上記ダイアログ８３は利用者が「ＯＫ」ボタン８３ａをクリックするまで表示され続ける。このようにすることで、映像フレームの表示が一定の時間間隔で順次更新される再生モードの場合でも、改ざんが行われた可能性がある映像フレームが見つかったことを、利用者は見逃すことなく確認することができる。図８Ｅは公開鍵が正しくない場合の表示例であり、「公開鍵が正しくない可能性があります。正しい公開鍵を設定してください。」なる警告メッセージがダイアログ８４により表示される。この場合も、ダイアログ８４には「ＯＫ」ボタン８４ａが表示され、利用者がこの「ＯＫ」ボタン８４ａをクリックするまでダイアログ８４は表示され続ける。
　なお、映像をリアルタイム再生する場合の署名検証結果の表示例としては、他に以下のようなものが考えられる。図１０はその第２の表示例を示すもので、４つの映像ストリームをマルチ画面表示し、各画面において署名検証結果を信号機を模して表示するようにしたものである。同図において、左上と右下は署名が改ざんされた可能性がない場合の映像データの表示例であり、信号機は「青」が点灯する。右上は署名が改ざんされた可能性がある場合の表示例であり、信号機は「赤」が点灯する。このとき、表示中の映像フレームはリアルタイム再生モードであるため次の映像フレームに更新されるが、上記ダイアログは利用者が「ＯＫ」ボタンをクリックするまで表示され続ける。このようにすることで、映像フレームの表示が一定の時間間隔で順次更新される再生モードの場合でも、改ざんが行われた可能性がある映像フレームが見つかったことを、利用者は見逃すことなく確認することができる。左下は、公開鍵が正しくない場合の表示例であり、信号機は黄色が点灯する。
　（３－２）記憶モジュールに記憶された映像データを再生する場合
　利用者が、入力デバイス３８において、記憶モジュール３２に記憶された所望の映像データストリームを指定した上で再生要求を入力したとする。そうすると、記憶制御モジュール３３は記憶モジュール３２から該当する映像データとその署名ＩＤをフレームごとに順次読み出す。　
　例えば、映像データ及び署名ＩＤの記憶フォーマットが図３に示すものだった場合には、記憶制御モジュール３３は先ずクリップファイルを開き、先頭の開始タグ<frame>と終了タグ</frame>との間に要素「映像ファイル」が記載されているか否かを判定する。そして記載されていれば、当該要素「映像ファイル」に対応する属性「値」の属性値「映像ファイル名」と、要素「署名ファイル」に対応する属性名「値」の属性値「署名ファイル名」を読み出し、この読み出した各属性値に基づいて映像ファイル及び署名ファイルを読み出す。以後、クリップファイルに記載されたすべての要素「映像ファイル」及び要素「署名ファイル」のペアを読み出し終わるまで、上記読み出し処理を繰り返す。
　また、映像データ及び署名ＩＤの記憶フォーマットが図５に示すものだった場合には、記憶制御モジュール３３は映像データ格納用ファイルＶfg1，Ｖfg2，…，Ｖfgnとそれに対応する署名ＩＤ格納用ファイルＳfg1，Ｓfg2，…，Ｓfgnを１つずつ順に選択し、この選択した映像データ格納用ファイルとそれに対応する署名ＩＤ格納用ファイルから個別ヘッダの情報に基づいて映像データ及び署名ＩＤをフレーム単位で順次読み出す。
　さらに、映像データ及び署名ＩＤの記憶フォーマットが図６に示すものだった場合には、記憶制御モジュール３３は先ず署名ＩＤ格納用ファイルＳfg1，Ｓfg2，…，Ｓfgnを一つずつ順に選択し、選択した署名ＩＤ格納用ファイルから映像データの署名ＩＤ、当該映像データの先頭アドレス及びデータ長署名ＩＤを読み出す。そして、この読み出された先頭アドレス及びデータ長署名ＩＤに基づいて、映像データ格納用ファイルから対応する映像データを読み出す。以後、選択した１つの署名ＩＤ格納用ファイルに格納された署名ＩＤ等を順次読み出し、さらに対応する映像データ格納用ファイルから対応する映像データを順次読み出す。そして、１つの署名ＩＤ格納用ファイルに格納されたすべての署名ＩＤ等の読み出しが終了すると、次の署名ＩＤ格納用ファイルが選択されて同様の読み出し処理が実行される。
　再生モジュール３４の映像伸長部３４２は、上記記憶制御モジュール３３により映像ファイルが１つ読み出されるごとに、当該映像ファイルの映像データを伸長する。この伸長処理により再生されたディジタル映像信号はＤ／Ａ３５によりアナログ信号に変換されて表示デバイス３６に表示される。また、この映像データの再生処理と並行して、再生モジュール３４の署名検証部３４１は、上記読み出された署名ＩＤに含まれる署名に対する署名検証処理を実行する。この署名検証処理の処理手順及び処理内容は、先に図６に述べたものと同じである。すなわち、署名が無効と判定された場合には、図８Ｂ乃至図８Ｄに示すように署名が改ざんされた可能性がある旨のメッセージが表示されるか、或いは図１０に示すように信号機が赤色点灯する。また公開鍵が正しくない場合には、図８Ｅに示すように公開鍵が正しくない可能性がある旨のメッセージが表示されるか、或いは図１０に示すように信号機が黄色点灯する。
　ただし、記憶された映像データを再生するモードでは、署名が無効と判定されるか又は公開鍵が正しくないと判定されると、その時点で映像データの再生が停止される。すなわち、署名が無効と判定されるか又は公開鍵が正しくないと判定されると、記憶制御モジュール３３は次の映像ファイル及び署名ファイルの読み出しを停止する。この停止状態は、例えば図８Ｄ，図８Ｅに示したダイアログ８３，８４の「ＯＫ」ボタン８３ａ，８４ａを利用者がクリックするまで、又は信号機の「赤色」表示デバイス位、「黄色」表示デバイス位を利用者がクリックするまで継続される。
　（４）映像データの再生を行わずに署名検証を行う場合
　利用者が、入力デバイス３８において、記憶モジュール３２に記憶された所望の映像データストリームを指定した上でその署名検証要求を入力したとする。そうすると、記憶制御モジュール３３は記憶モジュール３２から該当する映像データの最初のフレームを読み出す。この映像データの最初のフレームは再生モジュール３４の映像伸長部３４２により伸長され、さらにＤ／Ａ３５によりアナログ信号に変換されたのち表示デバイス３６に表示される。
　次に記憶制御モジュール３３は、上記検証要求により指定された映像データストリームの署名ファイルをフレーム順に読み出し、再生モジュール３４の署名検証部３４１に渡す。なお、上記署名ファイルの読み出し処理も、前述したようにクリップファイルを参照することにより行われる。署名検証部３４１は、署名ファイルが渡されるごとにその検証処理を実行しその結果を保存する。そして、全フレームの署名ファイルに対する検証処理が終了すると、上記保存された検証結果をまとめて検証結果表示制御部３４３に渡す。図９Ａ乃至図９Ｅは、映像の表示とは別に署名を検証する場合の第１の例を示したものである。
　検証結果表示制御部３４３は、渡された全フレーム分の検証結果のすべてが署名有効であれば、改ざんが内旨のメッセージを生成して、これを例えば図９Ａに示すようにダイアログ９１により映像上に重ねて表示させる。これに対し、渡された全フレーム分の検証結果の中に署名が無効と判定された検証結果が１つでも含まれていれば、署名が改ざんされた可能性がある旨のメッセージ９２，９３，９４を生成して、これを映像に重畳させた状態で図９Ｂ～図９Ｄに示すように表示させる。また公開鍵が正しくない場合には、公開鍵が正しくない可能性がある旨のメッセージ９５を生成して、これを先頭フレームの映像に重畳させた状態で図９Ｅに示すように表示させる。上記署名検証の表示結果は一定時間が経過するか又はダイアログの「ＯＫ」ボタン９４ａ，９５ｂを利用者がクリックすると終了する。なお、図９Ａ，図９Ｄに示すようにダイアログ９１，９４内にプログレスバー９１ｂ，９４ｂを表示させ、検証処理中にその進行度合いをプログレスバー９１ｂ，９４ｂに表示させるとよい。
　また、表示形態としては、図９Ａ乃至図９Ｅに限らず図１０に示したように信号機を模したものを使用してもよい。この場合、初期状態においては記憶モジュール３２に記憶された４つの映像データストリームの先頭フレームがマルチ画面表示される。そして、この状態で利用者が、上記４つの画面の一つ又は複数を選択したのち同画面に表示された「検証」ボタンをクリックすると、記録制御モジュール３３及び再生モジュール３４により上記選択された画面に対応する映像データストリームに対する署名検証処理を実行する。そして、前記フレームに対する検証が終了したのち、その結果が対応する画面に信号機を模して表示される。
　（５）署名検証結果の管理
　再生モジュール３４の署名検証部３４１により得られた映像データストリームに対する署名検証結果は、記憶制御モジュール３３により記憶モジュール３２に検証レポートとして記憶される。この検証レポートは、利用者が入力デバイス３８において表示要求を入力したときに、所定のフォーマットで表示デバイス３６に表示される。
　図１１はその表示フォーマットの第１の例を示すものである。この例では、レポート・ダイアログにおいて、１つの映像ストリームを構成する複数の映像ファイルに対応するアイコンが、ファイル名（例えば2007-07-06-27-10-57-30-000.JPG）と共にツリー状に関連付けられて表示される。そして、署名が無効と判定された映像ファイルについては、対応するアイコン（図中ＮＧと記したアイコン）に“！”マークが付されると共に当該アイコンが「赤色」で表示され、また公開鍵が正しくない可能性があると判定された映像ファイルについては、対応するアイコン（図中ＥＲＲＯＲと記したアイコン）に“？”マークが付されると共に、当該アイコンが「黄色」で表示される。なお、署名が有効と判定された映像ファイルについては、対応するアイコンが例えば「青色」で表示される。また、この状態で利用者が例えば上記“！”マークが付されたアイコンをクリックしたとする。そうすると、記憶制御モジュール３３により記憶モジュール３２から対応する画像ファイルが読み出され、この画像ファイルが再生モジュール３４の映像伸長部３４２により伸長されたのち、ファイル名が付された別のダイアログにより表示デバイス３６に表示される。
　図１２は、上記検証レポートの表示フォーマットの第２の例を示すものである。この例では、レポート・ダイアログにおいて、１つの映像ストリームを構成する複数の映像ファイルに対応するアイコンがその一部が重なるように順に表示される。そして、署名が無効と判定された映像ファイルについては対応するアイコン（図中ＮＧと記したアイコン）が「赤色」に色付けされ、また公開鍵が正しくない可能性があると判定された映像ファイルについては対応するアイコン（図中ＥＲＲＯＲと記したアイコン）が「黄色」に色付けされる。なお、図１１及び図１２において、署名が有効と判定された映像ファイルのアイコンは「青色」に色付けされる。また、この状態で利用者が例えば上記「赤色」に色付けされたアイコンをクリックすると、記憶制御モジュール３３により記憶モジュール３２から対応する画像ファイルが読み出され、この画像ファイルが再生モジュール３４の映像伸長部３４２により伸長されたのち、ファイル名が付された別のダイアログにより表示デバイス３６に表示される。
　図１３は、上記検証レポートの表示フォーマットの第３の例を示すものである。この例では、レポート・ダイアログにデータファイル名表示エリアＥ１とアイコン表示エリアＥ２が設けられる。データファイル名表示エリアＥ１には、１つの映像データストリームを構成する複数の映像ファイルのファイル名が、検証結果を表す記号（OK,NG,ERR）と共に表示される。また、アイコン表示エリアＥ２には、１つの映像データストリームを構成する複数の映像ファイルのアイコンがファイル名と共にマトリクス状に表示される。これらのアイコンは、検証結果に応じて異なる色に着色される。例えば、署名が有効と判定された映像ファイルに対応するアイコンは「青色」に、署名が無効と判定された映像ファイルに対応するアイコンは「赤色」にそれぞれ着色され、さらに公開鍵が正しくない可能性があると判定された映像ファイルに対応するアイコンは「黄色」に着色される。また、利用者が例えば上記「赤色」に色付けされたアイコンをクリックすると、記憶制御モジュール３３により記憶モジュール３２から対応する画像ファイルが読み出され、この画像ファイルが再生モジュール３４の映像伸長部３４２により伸長されたのち、ファイル名が付された別のダイアログにより表示デバイス３６に表示される。
　図１４は、上記検証レポートの表示フォーマットの第４の例を示すものである。この例では、上記第３の例で述べたアイコンと、映像のサムネイルが一緒に表示される。
　以上説明したようにこの実施形態では、クライアント端末３において、映像蓄積装置２から送られた映像データとその署名ＩＤをもとに署名の検証処理が行われ、その検証結果をもとに署名が改ざんされた可能性の有無と、公開鍵が正しくない可能性の有無がそれぞれ判定され、その判定結果を表すメッセージ或いはそれに代わるマーク（例えば信号機の色の点灯）や記号（例えばOK,NG,ERR）が映像データに重畳されて表示される。このためクライアント端末３の利用者は、改ざんチェックの結果を映像データに対する改ざんなのか或いは公開鍵が正しくないのかを区別して、明確に認識することが可能となる。
　また、１つの映像データストリームを構成する各フレームの検証結果が、検証レポートとしてレポート・ダイアログにマークや記号を付して一覧表示される。このため、利用者は映像データ中のどのフレームにおいて改ざんが行われたかを一目で確認することが可能となる。
　さらにこの実施形態では、映像データのファイル名及び署名ＩＤのファイル名がフレームごとにＸＭＬ文書のクリップファイルに記載される。このため、映像データのユーザデータ領域への付加情報の書き込みが制限される場合でも、映像ファイルと署名ファイルをフレームごとに明確に対応付けることが可能となる。
　なお、この発明は上記実施形態に限定されるものではない。例えば、前記実施形態では、監視データとして映像データを配信する場合を例にとって説明したが、映像データに限らず音データやテキストデータを配信する場合にも、この発明は適用可能である。また、前記実施形態では映像データ及びダウンロード映像再生ソフトにそれぞれ署名を付加してその検証を行う場合を例にとって説明したが、メッセージ認証コード（ＭＡＣ；Message Authentication Code）を付加して検証を行う場合にも、この発明は適用可能である。ただし、この場合には秘密鍵及び公開鍵に代えて共通鍵が用いられる。　
　その他、監視データ蓄積装置及び端末装置の構成とその処理手順及び処理内容、署名検証方法、検証結果の表示形態等についても、この発明の要旨を逸脱しない範囲で種々変形して実施できる。
　要するにこの発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を適宜組み合せてもよい。

Claims (14)

  1. 　監視データを蓄積する監視データ蓄積装置と、この監視データ蓄積装置から通信ネットワークを介して配信された監視データを受信し再生する端末装置とを備える監視システムであって、
    　前記監視データ蓄積装置は、
    　　第１の鍵情報を用いて生成される認証情報を、前記監視データに対し付加する手段と、
    　　前記認証情報が付加された監視データを、前記通信ネットワークを介して前記端末装置へ送信する手段と
    を備え、
    　前記端末装置は、
    　　前記監視データ蓄積装置から送信された、前記認証情報が付加された監視データを受信する受信手段と、
    　　前記第１の鍵情報に対応する第２の鍵情報を取得する手段と、
    　　前記受信された監視データに付加された認証情報に対し、前記第２の鍵情報をもとに検証処理を行い、前記監視データが改ざんされた可能性の有無と、前記第２の鍵情報が正しくない可能性の有無をそれぞれ判定する検証手段と、
    　　前記判定結果を表す表示情報を生成し、この生成された表示情報を前記再生対象の監視データに対応付けて表示デバイスに表示させる手段と
    を備える監視システム。
  2. 　前記受信手段は、
    　　前記受信された監視データに署名情報が付加されているか否かを判定する手段と、
    　　前記判定の結果に基づいて、前記署名情報が付加されている場合は当該監視データと署名情報とを相互に対応付けて記憶モジュールに記憶する過程と、
    　　前記判定の結果に基づいて、前記署名情報が付加されていない場合には予め記憶されてあるダミー署名情報を前記監視データと対応付けて前記記憶モジュールに記憶する手段とを備える請求項１記載の監視システム。
  3. 　前記受信手段は、前記監視データのファイル名及び認証情報のファイル名を、当該監視データのフレームごとにＸＭＬ（eXtensible Markup Language）文書のクリップファイルに記載した状態で、記憶モジュールに記憶させる請求項１記載の監視システム。
  4. 　前記認証情報を付加する手段は、
    　　監視データに対して予め定めた単位ごとに秘密鍵をもとに署名を生成する手段と、
    　　前記生成された署名と、前記秘密鍵と対をなす第１の公開鍵のハッシュ値からなるフィンガプリントとを含む署名情報を生成する手段と
    を備え、
    　前記検証手段は、
    　　予め取得した第２の公開鍵のハッシュ値を算出する手段と、
    　　前記受信された監視データに付加された認証情報に含まれるフィンガプリントと、前記算出されたハッシュ値とを比較する手段と、
    　　前記比較の結果両者が不一致だった場合に、前記第２の公開鍵は前記秘密鍵とペアをなす第１の公開鍵と同じものではないと判定する手段と
    を備える請求項１記載の監視システム。
  5. 　前記認証情報を付加する手段は、
    　　監視データに対して予め定めた単位ごとに秘密鍵をもとに署名を生成する手段と、
    　　前記生成された署名と、前記秘密鍵と対をなす第１の公開鍵のハッシュ値からなるフィンガプリントとを含む署名情報を生成する手段と
    を備え、
    　前記検証手段は、
    　　前記受信された監視データのハッシュ値を計算する手段と、
    　　前記受信された監視データに付加された認証情報に含まれる署名を、予め取得した第２の公開鍵を用いて伸長する手段と、
    　　前記計算された監視データのハッシュ値と、前記伸長された署名の値とを比較して、両者が一致するか否かを判定する手段と、
    　　前記両者が一致すれば前記署名は有効と判定し、不一致であれば前記署名は無効と判定する手段と
    を備える請求項１記載の監視システム。
  6. 　前記検証手段は、前記監視データに対し予め定めた単位ごとに検証処理を行って前記判定結果を得る場合に、前記単位ごとに得られる判定結果を一覧表示するための一覧表示情報を生成し、この生成された一覧表示情報を前記表示デバイスに表示させる手段を、さらに備える請求項１記載の監視システム。
  7. 　前記表示させる手段は、
    　　前記署名情報が改ざんされた可能性がある旨のメッセージとその確認ボタンとを含む表示情報を生成して、この表示情報を監視データに対応付けて表示デバイスに表示させる手段と、
    　　前記表示された確認ボタンが操作されるか、又は表示開始時点から予め設定した一定時間が経過するまで、前記表示情報を表示し続ける手段と
    を備える請求項１記載の監視システム。
  8. 　監視データを蓄積する監視データ蓄積装置と、この監視データ蓄積装置から通信ネットワークを介して配信された監視データを受信し再生する端末装置とを備える監視システムにおいて使用される改ざんチェック方法であって、
    　前記監視データ蓄積装置が、第１の鍵情報を用いて生成される認証情報を、前記監視データに対し付加する過程と、
    　前記監視データ蓄積装置が、前記認証情報が付加された監視データを、前記通信ネットワークを介して前記端末装置へ送信する過程と、
    　前記端末装置が、前記監視データ蓄積装置から送信された、前記認証情報が付加された監視データを受信する過程と、
    　前記端末装置が、前記第１の鍵情報に対応する第２の鍵情報を取得する過程と、
    　前記受信された監視データに付加された認証情報に対し、前記取得された第２の鍵情報をもとに検証処理を行い、前記監視データが改ざんされた可能性の有無と、前記第２の鍵情報が正しくない可能性の有無をそれぞれ判定する検証過程と、
    　前記端末装置が、前記判定結果を表す表示情報を生成し、この生成された表示情報を前記再生対象の監視データに対応付けて表示デバイスに表示させる過程と
    を具備する改ざんチェック方法。
  9. 　前記監視データを受信する過程は、
    　　前記受信された監視データに署名情報が付加されているか否かを判定する過程と、
    　　前記判定の結果に基づいて、署名情報が付加されている場合は当該監視データと署名情報とを相互に対応付けて記憶モジュールに記憶する過程と、
    　　前記判定の結果に基づいて、署名情報が付加されていない場合には予め記憶されてあるダミー署名情報を前記監視データと対応付けて前記記憶モジュールに記憶する過程と
    を備える請求項８記載の改ざんチェック方法。
  10. 　前記監視データを受信する過程は、前記監視データのファイル名及び認証情報のファイル名を、当該監視データのフレームごとにＸＭＬ（eXtensible Markup Language）文書のクリップファイルに記載した状態で、記憶モジュールに記憶させる請求項８記載の改ざんチェック方法。
  11. 　前記認証情報を付加する過程は、
    　　監視データに対して予め定めた単位ごとに秘密鍵をもとに署名を生成する過程と、
    　　前記生成された署名と、前記秘密鍵と対をなす第１の公開鍵のハッシュ値からなるフィンガプリントとを含む署名情報を生成する過程と
    を備え、
    　前記検証過程は、
    　　予め取得した第２の公開鍵のハッシュ値を算出する過程と、
    　　前記受信された監視データに付加された認証情報に含まれるフィンガプリントと、前記算出されたハッシュ値とを比較する過程と、
    　　前記比較の結果両者が不一致だった場合に、前記第２の公開鍵は前記秘密鍵とペアをなす第１の公開鍵と同じものではないと判定する過程と
    を備える請求項８記載の改ざんチェック方法。
  12. 　前記認証情報を付加する過程は、
    　　監視データに対して予め定めた単位ごとに秘密鍵をもとに署名を生成する過程と、
    　　前記生成された署名と、前記秘密鍵と対をなす第１の公開鍵のハッシュ値からなるフィンガプリントとを含む署名情報を生成する過程と
    を備え、
    　前記検証過程は、
    　　前記受信された監視データのハッシュ値を計算する過程と、
    　　前記受信された監視データに付加された認証情報に含まれる署名を、予め取得した第２の公開鍵を用いて伸長する過程と、
    　　前記計算された監視データのハッシュ値と、前記伸長された署名の値とを比較して、両者が一致するか否かを判定する過程と、
    　　前記両者が一致すれば前記署名は有効と判定し、不一致であれば前記署名は無効と判定する過程と
    を備える請求項８記載の改ざんチェック方法。
  13. 　前記検証過程は、前記監視データに対し予め定めた単位ごとに検証処理を行って前記判定結果を得る場合に、前記単位ごとに得られる判定結果を一覧表示するための一覧表示情報を生成し、この生成された一覧表示情報を前記表示デバイスに表示させる過程を、さらに備える請求項８記載の改ざんチェック方法。
  14. 　前記表示させる過程は、
    　　前記署名情報が改ざんされた可能性がある旨のメッセージとその確認ボタンとを含む表示情報を生成して、この表示情報を監視データに対応付けて表示デバイスに表示させる過程と、
    　　前記表示された確認ボタンが操作されるか、又は表示開始時点から予め設定した一定時間が経過するまで、前記表示情報を表示し続ける過程と
    を備える請求項８記載の改ざんチェック方法。
PCT/JP2008/069368 2008-03-12 2008-10-24 監視システムとその改ざんチェック方法 WO2009113200A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2008-062959 2008-03-12
JP2008062959A JP4295344B1 (ja) 2008-03-12 2008-03-12 監視システム

Publications (1)

Publication Number Publication Date
WO2009113200A1 true WO2009113200A1 (ja) 2009-09-17

Family

ID=40921887

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2008/069368 WO2009113200A1 (ja) 2008-03-12 2008-10-24 監視システムとその改ざんチェック方法

Country Status (2)

Country Link
JP (1) JP4295344B1 (ja)
WO (1) WO2009113200A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011097486A (ja) * 2009-11-02 2011-05-12 Hitachi Kokusai Electric Inc 映像署名システム

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000194962A (ja) * 1998-12-28 2000-07-14 Secom Co Ltd 画像センサ、及び、画像監視システム
JP2001036862A (ja) * 1999-07-19 2001-02-09 Mega Chips Corp 画像改竄判別機能付き画像記録システム及び画像記録方法
JP2003216237A (ja) * 2002-01-21 2003-07-31 Nec San-Ei Instruments Ltd 遠隔監視システム
JP2004213358A (ja) * 2002-12-27 2004-07-29 Sogo Keibi Hosho Co Ltd 監視方法および監視システム
JP2004282677A (ja) * 2003-01-21 2004-10-07 Canon Inc 画像処理方法
JP2005094420A (ja) * 2003-09-18 2005-04-07 Victor Co Of Japan Ltd 監視システムにおける認証方法、監視システム，監視カメラ
JP2006165944A (ja) * 2004-12-07 2006-06-22 Hitachi Ltd イメージデータへの登録方法及び装置、登録プログラム及びそれを記録した記録媒体、並びにイメージデータの検証方法及び装置、検証プログラム及びそれを記録した記録媒体

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000194962A (ja) * 1998-12-28 2000-07-14 Secom Co Ltd 画像センサ、及び、画像監視システム
JP2001036862A (ja) * 1999-07-19 2001-02-09 Mega Chips Corp 画像改竄判別機能付き画像記録システム及び画像記録方法
JP2003216237A (ja) * 2002-01-21 2003-07-31 Nec San-Ei Instruments Ltd 遠隔監視システム
JP2004213358A (ja) * 2002-12-27 2004-07-29 Sogo Keibi Hosho Co Ltd 監視方法および監視システム
JP2004282677A (ja) * 2003-01-21 2004-10-07 Canon Inc 画像処理方法
JP2005094420A (ja) * 2003-09-18 2005-04-07 Victor Co Of Japan Ltd 監視システムにおける認証方法、監視システム，監視カメラ
JP2006165944A (ja) * 2004-12-07 2006-06-22 Hitachi Ltd イメージデータへの登録方法及び装置、登録プログラム及びそれを記録した記録媒体、並びにイメージデータの検証方法及び装置、検証プログラム及びそれを記録した記録媒体

Also Published As

Publication number Publication date
JP4295344B1 (ja) 2009-07-15
JP2009219034A (ja) 2009-09-24

Similar Documents

Publication Publication Date Title
CN106411915B (zh) 用于多媒体捕获的嵌入式装置
CN107534704B (zh) 一种经由通信网络连接的信息处理方法、设备和介质
CN103988210B (zh) 信息处理设备、服务器设备、信息处理方法、以及服务器处理方法
US20090317784A1 (en) Remote delivery system and remote delivery method
US20010005446A1 (en) Multimedia information playback apparatus and method
US8786717B2 (en) Information processing apparatus, information processing method and program
WO2017033348A1 (ja) 署名生成システム、署名生成装置及び署名生成方法
JP2009525003A (ja) ユーザにデイリーズ（ｄａｉｌｉｅｓ）および編集済みビデオを提供するための方法およびシステム
US20070061582A1 (en) Image processing method, image processing apparatus, and storage medium
US8375216B2 (en) Document verification apparatus and method
US8505104B2 (en) Apparatus and method for recording and reproducing images
JP5154468B2 (ja) 情報処理装置、通信端末装置、情報処理装置の制御方法、通信端末装置の制御方法、制御プログラム、および、記録媒体
JP6663455B2 (ja) サインの記録方法、及びサインの記録装置
US20130326601A1 (en) Communication system
WO2009113200A1 (ja) 監視システムとその改ざんチェック方法
GB2436444A (en) Image storage system having a plurality of storage devices
US20090240848A1 (en) Method and Device for the Transfer of a Data Flow a Data Source to a Data Sink
JP2019205140A (ja) 撮像装置、情報処理装置、生成方法、及び検証方法
JP7273007B2 (ja) 認証装置、認証方法及び認証プログラム
KR101024129B1 (ko) 화상 배신 장치
KR101399746B1 (ko) Ｎ―스크린 영상 서비스 제공 방법 및 장치
JP2010213156A (ja) 映像再生装置、方法、及びプログラム
JP2005352863A (ja) 電子押印を利用したデジタルデータ交換システムおよびデジタルデータ交換方法、デジタルデータ交換プログラム
JP2007174369A (ja) 状況管理システム
JP6467945B2 (ja) サーバ装置及び画像プリント装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08873315

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08873315

Country of ref document: EP

Kind code of ref document: A1