Security enhancement for handheld digital cameras

Abstract

The present disclosure relates to methods for user authentication, encryption, third-party application authentication and authorization, and signing, in relation to the use of handheld digital cameras. These methods are achieved by combining a user device connected to a camera with a plurality of devices connected to the user device via a network. The camera authenticates the user using an authentication function provided in the user device. A storage area within the camera is encrypted, and is unlocked using a data authentication key transmitted from the user device to the camera, without requiring the user to enter a password. Signing of images is performed using a private key of the user, not of the camera manufacturer. The camera authenticates third-party applications, and authorizes access to camera functions or images on the basis of a selection by the user.

Description

Enhanced security for handheld digital cameras

[0001] This disclosure relates to security for handheld digital cameras.

[0002] Smartphones are equipped with a wide range of security features. In particular, data stored on smartphones is protected by user authentication and encryption. Furthermore, many third-party applications installed on smartphones are distributed only after review by distributors, such as Apple Inc. (Cupertino, California). Users also have detailed control over the access third-party applications have to smartphone functions or data.

[0003] In contrast, handheld digital cameras lack security features: for example, user authentication is either not implemented or is poorly implemented, images captured by users are not encrypted, and neither the camera manufacturer nor the user has the technical means to authenticate or authorize third-party applications that access the camera.

[0004] In journalism in particular, the security of handheld digital cameras is directly linked to the safety of journalists and their sources, and the current situation where anyone can turn on a camera and view the images inside does not reflect society's demand for privacy control.

[0005] U.S. Patent No. 10659457 International Publication No. 2021 / 039953

[0006] This disclosure relates to methods for user authentication, encryption, authentication and authorization of third-party applications, and signing when using a handheld digital camera. These methods are realized by combining a user device connected to the camera with multiple devices connected to the camera via a network. The camera authenticates the user using the authentication function of the user device. The camera's storage area is encrypted and unlocked using a data authentication key sent by the user device to the camera without requiring the user to enter a password. Images are signed using the user's private key, not the camera manufacturer's. The camera authenticates third-party applications and grants them access to camera functions or images based on the user's selection.

[0007] Figure showing the devices that make up the example system and the connections between them. Figure showing the system architecture of the camera in the example system. Figure showing the system architecture of the user device in the example system. Figure showing the system architecture of the user authentication server in the example system. Figure showing the system architecture of the time stamping authority server in the example system. Figure showing the system architecture of the third-party application server in the example system. Figure showing the system architecture of the third-party application developer device in the example system. Figure showing a good user of the example system and access to each device. Figure showing a malicious user of the example system and access to each device. Figure showing the interface for creating a camera user account in the example system. Camera, camera manufacturer application, and Sequence diagram showing the processing flow of the camera, camera manufacturer application, and user authentication server (part 1) Sequence diagram showing the processing flow of the camera, camera manufacturer application, and user authentication server in the initial preparation for camera user authentication (part 2) Sequence diagram showing the processing flow for executing camera user authentication Sequence diagram showing the flow of sending and receiving a data authentication key for unlocking the camera's built-in data storage Sequence diagram showing the process flow for unlocking the camera's built-in data storage Sequence diagram showing the encryption and unlocking process flow when encrypting the camera's built-in data storage using software Sequence diagram showing the flow of sending and receiving a data authentication key when encrypting the camera's removable recording mediaSequence diagram showing the encryption and unlocking process flowSequence diagram showing the process for creating a third-party application developer accountSequence diagram showing the process for issuing an application ID for a third-party applicationDiagram showing the interface for registering a third-party applicationSequence diagram showing the process for launching a third-party application installed on a user device for the first timeDiagram showing the interface for setting permission for third-party application access to the cameraSequence diagram (part 1) showing the flow for setting permission for third-party application access to the cameraSequence diagram (part 2) showing the flow for authenticating a third-party applicationSequence diagram showing the flow for authorizing third-party application access to camera functions or dataSequence diagram showing the flow for preparing for signatureDiagram showing the interface for enabling signatureSequence diagram showing the flow for saving images and signing

[0008] To alleviate the problems described in the Background section, this disclosure discloses methods for user authentication, encryption, third-party application authentication and authorization, and signing, which are achieved by combining a user device connected to a camera with multiple devices connected to the user device via a network.

[0009] Definitions: In this disclosure, a general-purpose computer refers to a device that can be used for a wide range of computing purposes, including smartphones, wearable devices such as smart glasses, tablet computers, laptop computers, and desktop computers.

[0010] In this specification, a handheld device means a device that can be grasped with two or more fingers of one hand and is primarily used while held in the hand. In contexts involving hand size, the dimensions of each part of the hand are assumed to be the average values ​​for women for each dimension as shown in Non-Patent Document 1. In this specification, "connected" means "functionally connected," and means that other components other than the connected device may or may not be used in the connection, whether directly or indirectly.

[0011] In this specification, the term "person skilled in the art" refers to an imaginary person with ordinary knowledge in the technical field of this specification. In this specification, descriptions of methods, numerical values ​​or formulas, operations or series of operations, processes, components, circuits, networks, protocols, structures, materials, and features that are widely known in the technical field of this specification are omitted or simplified. For example, descriptions of error handling and the like that are obvious to those skilled in the art are omitted. In this specification, the term "implementer" refers to a person who implements the contents of this specification.

[0012] This specification describes the claims by illustrating an imaging system (hereinafter referred to as the "exemplary system"). The description of the exemplary system is not a complete or exhaustive description of the requirements or specifications of an imaging system that can be realized by the present disclosure. Furthermore, although the components of the exemplary system in this specification are limited to those necessary for the description, this limitation does not preclude the presence or addition of other components.

[0013] As used herein, an "embodiment" is a representation that illustrates either a) part or all of any one or more claims of the present disclosure, or b) the known art, through visualization techniques such as drawings, graphs, photographs, videos, computer graphics, three-dimensional computer models, physical mockups, and the like. The terminology used to describe the various embodiments contained herein is intended to describe the particular embodiment and is not intended to be limiting. Each embodiment is not intended to limit the subject matter it represents to a single preferred form. Rather, the various embodiments herein are intended to encompass alternatives, modifications, and equivalents that may be included within the spirit and scope of the claims.

[0014] The various computers, components, modules, algorithms, protocols, programs, and networks included in the embodiments of this specification may be implemented in various ways using hardware, software, or a combination of both. Listing these various combinations of implementations is not meaningful herein; it will be clear to those skilled in the art that implementers may implement them appropriately in light of various requirements and constraints. Each block included in the embodiments of this specification collectively describes its function and does not imply that the block is physically or logically independent from other components. The system architecture diagrams in this disclosure are conceptual diagrams and do not necessarily completely or accurately represent the physical connections or signal flows between components. In this disclosure, when a device "includes" a program, it means that the device physically, logically, or functionally includes the program, and includes cases where the device realizes part or all of the program's functionality by obtaining data from other devices via a network. In this disclosure, a device's private key or public key refers to a private key or public key managed on the device by the device administrator, regardless of the use of the key (signature, encryption, or authentication).

[0015] In this specification or the claims of this disclosure, the order of blocks, processes, or operations is illustrative and does not exclude the possibility that the order may be changed or that the processes may be parallelized. For example, if five processes A, B, C, D, and E are listed in this order, and the order does not affect the overall process even if they are changed, the remaining 119 possible orders of these processes are not listed, but unless the order is explicitly limited, the order of these processes is not limited to A, B, C, D, and E.

[0016] For each count noun in this disclosure, the number of objects referred to by the count noun is one or more, unless the number is explicitly stated. In this disclosure, "several" means that there is one or more of the object referred to. Also, modifiers that generally imply order, such as "first," are merely labels used to distinguish the objects referred to by the noun and do not imply any kind of order (e.g., spatial, temporal, or logical) in this disclosure, unless the context clearly indicates an order.

[0017] In this disclosure, the conjunction "or" is used as a conjunction that includes any combination of the elements it groups together. For example, "A, B, or C" may mean A alone, A and B, or A, B, and C. Also, when the terms "comprise" or "comprise" are used in this disclosure, these terms denote the presence of the elements they refer to, but do not exclude the presence or addition of other elements.

[0018] In the present disclosure, when there is a phrase that includes a verb or verb phrase but does not include a subject, the subject, such as a user or manufacturer of a device or a computer, is not limited.

[0019] In this disclosure, terms referring to elements of a user interface refer to either elements of a physical user interface or a GUI (Graphical User Interface). Furthermore, terms used in this disclosure are selected with common usage in the technical field of this specification in mind. For example, a "server" refers to a server in computer terms, not a person who serves food and drinks. Furthermore, an "account" refers to a user's identity in a computer system.

[0020] In this disclosure, when a computer program, its processes, or its threads are described or illustrated as the subject of an action, the description or illustration summarizes, from a functional perspective, a series of operations performed by a computer by referencing the instructions and data in the program. A computer program itself is a collection of instructions and data and cannot be the subject of an action. However, it will be clear to those skilled in the art that, in general, when describing or recognizing the process a computer executes by referencing a program, the program, its processes, or its threads may be expressed or understood as imaginary subjects of an action. In this disclosure, a description of a process in which a program or its processes are the subject of an action, such as "Program X executes process Y" or "Program X does Y," means that "a computer equipped with Program X references Program X and executes process Y." Furthermore, a description of a process in which a program or its processes are the object, such as "send Y to Program X," means that the process is performed on a computer equipped with the program.

[0021] Generally, a running computer program is often composed of multiple processes or multiple threads running in parallel. In this disclosure, unless the number of processes or threads of a running computer program is specified, the number of processes or threads of the running program is one or more, and is not limited to one. When multiple processes or multiple threads running in parallel on a single computer are shown in a single diagram, these processes or threads are illustrated as imaginary actors in place of the computer. When some of the multiple processes or multiple threads running in parallel on a single computer are the targets of processing (e.g., data transmission or authentication), these processes or threads are illustrated as imaginary subjects in place of the computer.

[0022] Cryptographic algorithms and hash functions become obsolete. Therefore, this specification does not refer to the adoption of a specific cryptographic algorithm or hash function. Implementers should select an appropriate cryptographic algorithm or hash function at the time of implementation. Also, while this specification assumes various threats to information security, it does not guarantee that these assumptions and their defenses are complete or comprehensive.

[0023] In this disclosure, a "hash value" refers to the output value obtained by inputting a value into a one-way hash function.

[0024] In this disclosure, the term "operating system" is used to encompass not only the kernel that acts as an intermediary between the hardware and application programs of a device, but also a group of programs that provide various basic functions to users of the device, including programs for implementing a GUI environment, messaging, settings, key management, etc.

[0025] In this disclosure, a private key belonging to a person, or a private key of a person, means a private key that becomes available when a device having the private key authenticates the person, and is used at the will of the person.

[0026] In this specification, lines beginning with an open angle bracket and ending with a close angle bracket are headings. Lines beginning with an open double angle bracket and ending with a close double angle bracket are subheadings. These headings and subheadings are for reference and readability purposes only and should not be used to interpret the content of this specification.

[0027] <System Configuration> Figure 1 shows the devices that make up an example system and their connections. These devices are a handheld digital camera (hereinafter referred to as "camera") 0001, a user device 0002, a user authentication server 0003, a time-stamping authority server 0004, a third-party application server 0005, and a third-party application developer device 0006. Although not shown in Figure 1, devices such as a LAN (Local Area Network) or a USB (Universal Serial Bus) hub may be present between the camera 0001 and the user device 0002. The camera 0001, user device 0002, user authentication server 0003, time-stamping authority server 0004, third-party application server 0005, and third-party application developer device 0006 are connected via a network 0007. The network 0007 is a wide area network such as the Internet.

[0028] FIG. 2 shows the components that make up the camera 0001 and the connections between these components. The camera 0001 includes a lens module 0008, an image sensor 0009, an image processor 0010, a system controller 0011, and a communication interface 0012. The camera 0001 includes a non-volatile internal data storage 0013, such as a solid-state drive (SSD). The camera 0001 may also include a removable recording media drive 0014. If the camera 0001 includes a removable recording media drive 0014, a user can insert a removable recording media 0015 into it. The removable recording media 0015 may be connected to the camera 0001 as an external device using an interface such as USB instead of the removable recording media drive 0014. The camera 0001 includes a non-volatile memory 0016 for storing setting information (hereinafter referred to as "setting storage").

[0029] The camera 0001 includes a secure element 0017. Generally, a secure element is a tamper-resistant chip that encrypts and decrypts data. The secure element 0017 is tamper-resistant. The secure element 0017 stores a private key, and can receive data from an external device, encrypt this data using the private key, and transmit the encrypted data to an external device. The secure element 0017 does not include an interface for reading out the private key from an external device.

[0030] The system controller 0011 includes semiconductor components such as a CPU (Central Processing Unit) 0018, RAM (Random-Access Memory) 0019, ROM (Read-Only Memory) 0020, and clock 0021. The CPU 0018 loads a program (hereinafter referred to as the "camera control program") stored in the ROM 0020 or the internal data storage 0013 into the RAM 0019 and executes it to control each component of the camera 0001. The CPU 0018 also uses the RAM 0019 as an area for temporarily storing various data, such as metadata, associated with still images or videos (hereinafter, still images and videos are collectively referred to as "images"; videos include audio) captured by the user. In addition to the CPU 0018, the system controller may also include one or more coprocessors specialized for specific processes, such as encryption.

[0031] The lens module 0008 is composed of optical components such as a lens 0022 and aperture blades 0023, and a lens controller 0024 that drives these components. The housing of the lens module 0008 may be detachable from the housing of the camera 0001. The lens module 0008 guides incident light from a subject to the image sensor 0009. The image sensor 0009 converts the optical image acquired through the lens module 0008 into an electrical signal. The image sensor 0009 also digitizes this electrical signal through A / D conversion. The image processor 0010 performs image processing such as demosaicing, noise reduction, and resolution conversion on the electrical signal from the image sensor 0009. The image processor 0010 records the results of this processing in the internal data storage 0013 or removable recording media 0015. The camera 0001 may transmit images to the user device 0002 via the communication interface 0012.

[0032] The communication interface 0012 includes a communication controller 0025 and relays communication between the camera control program and the user device 0002 through a port 0026 or an antenna 0027. The port may be one that conforms to known standards such as USB or Ethernet (registered trademark). The combination of the communication controller 0025 and antenna 0027 may be one that conforms to known standards such as IEEE (Institute of Electrical and Electronics Engineers) 802.11.

[0033] FIG. 3 illustrates components constituting a user device 0002 and the connections between these components. The user device 0002 is a general-purpose computer such as a smartphone, tablet computer, notebook computer, or desktop computer. The user device 0002 includes a CPU 0028, RAM 0029, ROM 0030, data storage 0031, and a communication interface 0032. The CPU 0028 loads various programs stored in the ROM 0030 or data storage 0031 into the RAM 0029 and executes them. The CPU 0028 stores data output from these programs in the data storage 0031. The communication interface 0032 includes a communication controller 0033. The communication interface 0032 further includes a port 0034 or an antenna 0035. The user device 0002 may also include a touchscreen system 0036. The touchscreen system 0036 includes a touchscreen 0037 and its controller 0038. If the user device 0002 is equipped with a touchscreen system 0036, the user operates the user device 0002 by touching the touchscreen 0037. The user device 0002 may also be equipped with a display system 0039. The display system 0039 includes a display 0040 and its controller 0041. If the user device 0002 is equipped with the display system 0039, the user device 0002 displays various user interface elements to the user. The user device 0002 is equipped with a biometric authentication system 0042 that uses fingerprint reading or facial recognition. The biometric authentication system 0042 is used to log in to or unlock the user device 0002.

[0034] Figure 4 illustrates the components that make up the user authentication server 0003 and the connections between these components. The user authentication server 0003 is a general-purpose computer. It includes a CPU 0043, RAM 0044, ROM 0045, data storage 0046, a communication interface 0047, a user input interface 0048, and a display system 0049. The CPU 0043 loads programs stored in the ROM 0045 or data storage 0046 into the RAM 0044 and executes them. The CPU 0043 records data required to execute these programs and data output as a result of the execution in the data storage 0046. The data storage 0046 is a non-volatile storage device, such as an SSD. The user input interface 0048 includes input devices such as a keyboard 0050 or mouse 0051 that accept operations by the user of the user authentication server 0003. The display 0052 of the display system 0049 is controlled by a display controller 0053 and displays various user interface elements to the user of the user authentication server 0003. The communication interface 0047 includes a communication controller 0054, and relays communication with other devices connected to the network 0007 via a port 0055 or an antenna 0056. The port 0055 may conform to known standards such as Ethernet (registered trademark). The combination of the communication controller 0054 and antenna 0056 may conform to known standards such as IEEE802.11.

[0035] Figure 5 illustrates components constituting the time-stamping authority server 0004 and the connections between these components. The time-stamping authority server 0004 is a general-purpose computer. It includes a CPU 0057, a RAM 0058, a ROM 0059, a data storage 0060, a communication interface 0061, a user input interface 0062, and a display system 0063. The CPU 0057 loads programs stored in the ROM 0059 or data storage 0060 into the RAM 0058 and executes them. The CPU 0057 records data required for executing these programs and data output as a result of the execution into the data storage 0060. The data storage 0060 is a non-volatile storage device, such as an SSD. The user input interface 0062 includes input devices such as a keyboard 0064 or a mouse 0065 that accept operations by the user of the time-stamping authority server 0004. Furthermore, the display 0066 of the display system 0063 is controlled by a display controller 0067, and displays various user interface elements to a user of the time-stamping authority server 0004. The communication interface 0061 includes a communication controller 0068, and relays communications with other devices connected to the network 0007 via a port 0069 or an antenna 0070. The port 0069 may conform to a known standard such as Ethernet (registered trademark). Furthermore, the combination of the communication controller 0068 and the antenna 0070 may conform to a known standard such as IEEE802.11.

[0036] FIG. 6 illustrates components constituting a third-party application server 0005 and the connections between these components. The third-party application server 0005 is a general-purpose computer. It includes a CPU 0071, RAM 0072, ROM 0073, data storage 0074, a communication interface 0075, a user input interface 0076, and a display system 0077. The CPU 0071 loads programs stored in the ROM 0073 or data storage 0074 into the RAM 0072 and executes them. The CPU 0071 records data required to execute these programs and data output as a result of the execution into the data storage 0074. The data storage 0074 is a non-volatile storage device, such as an SSD. The user input interface 0076 includes input devices such as a keyboard 0078 or mouse 0079 that accept operations by the user of the third-party application server 0005. The display 0080 of the display system 0077 is controlled by a display controller 0081 and displays various user interface elements to a user of the third-party application server 0005. The communication interface 0075 includes a communication controller 0082 and relays communications with other devices connected to the network 0007 via a port 0083 or an antenna 0084. The port 0083 may conform to a known standard such as Ethernet (registered trademark). The combination of the communication controller 0082 and antenna 0084 may conform to a known standard such as IEEE 802.11.

[0037] FIG. 7 illustrates components constituting a third-party application developer device 0006 and the connections between these components. The third-party application developer device 0006 is a general-purpose computer. It includes a CPU 0085, RAM 0086, ROM 0087, data storage 0088, a communication interface 0089, a user input interface 0090, and a display system 0091. The CPU 0085 loads programs stored in the ROM 0087 or data storage 0088 into the RAM 0086 and executes them. The CPU 0085 records data required to execute these programs and data output as a result of the execution into the data storage 0088. The data storage 0088 is a non-volatile storage device, such as an SSD. The user input interface 0090 includes input devices such as a keyboard 0092 or a mouse 0093 that accept operations by the user of the third-party application developer device 0006. Furthermore, the display 0094 of the display system 0091 is controlled by a display controller 0095 to display various user interface elements to a user of the third-party application developer device 0006. The communication interface 0089 includes a communication controller 0096 and relays communications with other devices connected to the network 0007 via a port 0097 or an antenna 0098. The port 0097 may conform to a known standard such as Ethernet (registered trademark). Furthermore, the combination of the communication controller 0096 and the antenna 0098 may conform to a known standard such as IEEE 802.11.

[0038] The user device 0002 is equipped with a first application program (hereinafter also referred to as the "camera manufacturer application") 0099 shown in Figure 11 and subsequent figures, and a web browser. The camera manufacturer application 0099 is equipped with functions for user authentication, encryption, and signing, which will be described later, as well as a function for remotely controlling the camera 0001 to take pictures. The camera manufacturer application 0099 further has a function for setting authentication and authorization for third-party applications, which will be described later. The user device 0002 may also be equipped with a third-party application 0100 shown in Figure 22 and subsequent figures as a second application program. The third-party application 0100 is equipped with a function for remotely controlling the camera 0001 to take pictures.

[0039] The user device 0002 is equipped with a key management program. The key management program encrypts secrets such as passwords or private keys and stores them in the data storage 0031. In addition, the key management program decrypts the encrypted private key or password in response to a request from the camera manufacturer application 0099 or a third-party application 0100 and provides the decrypted private key or password to these programs. Generally, a key management program is often included in the operating system of a general-purpose computer or can be installed. These key management programs reduce the operational burden on the user by providing secrets such as passwords to various applications on behalf of the user.

[0040] The third-party application developer device 0006 is a device used by the third-party application developer to communicate with the user authentication server 0003 .

[0041] The camera 0001 stores the public key of the time-stamping authority server 0004 in the configuration storage 0016. The time-stamping authority server 0004 has a time synchronization server function protected by a public-key cryptographic communication protocol, such as NTS (Network Time Security). This time synchronization server function may be based on a known protocol such as NTP (Network Time Protocol). The camera manufacturer application 0099 and the third-party application 0100 each have a port forwarding function that relays communication with the time-stamping authority server 0004 in response to a request from the camera 0001. The camera 0001 uses this port forwarding function to periodically establish end-to-end encrypted communication with the time-stamping authority server 0004 and synchronize the time on the camera 0001's clock 0021 with the time on the time-stamping authority server 0004. The camera 0001 does not have a function that allows the user to set the clock 0021 to an arbitrary time.

[0042] Each of the user authentication server 0003, time-stamping authority server 0004, and third-party application server 0005 communicates with other devices based on a protocol such as HTTP (Hypertext Transfer Protocol). These servers also require encrypted communication using a protocol such as TLS (Transport Layer Security) when communicating with other devices. The third-party application server 0005 has the public key of the user authentication server 0003. The third-party application server 0005 authenticates the user authentication server 0003 through challenge-response authentication using this public key. This authentication is explained later in "Authentication and Authorization of Third-Party Applications."

[0043] <System Users> Because this disclosure is about information security, we cannot proceed with the explanation without assuming threats. Assuming threats requires assuming users. The users of the example system are shown below.

[0044] {Good Users} Good users and their access to their respective devices are shown in Figure 8. 1. Administrator 0101 of camera 0001. That is, the person who registers a user account with the user authentication server 0003 and camera 0001 and allows user 0102 of camera 0001 to use this account. 2. User 0102 of camera 0001. That is, the person to whom the user account registered with the user authentication server 0003 and camera 0001 belongs. 3. Photographer 0103. That is, the person who takes pictures using camera 0001. The photographer does not necessarily match user 0102 of camera 0001. For example, a passerby who is asked by user 0102 of camera 0001 to take a photo is photographer 0103, but not user 0102 of camera 0001. 4. User 0104 of user device 0002. That is, the person registered as a user of the operating system of user device 0002. 5. Administrator 0105 of the user authentication server 0003, i.e., a person who has privileged access to the user authentication server 0003 and is responsible for the effective use, maintenance, and security of the user authentication server 0003. 6. Administrator 0106 of the time-stamping authority server 0004, i.e., a person who has privileged access to the time-stamping authority server 0004 and is responsible for the effective use, maintenance, and security of the time-stamping authority server 0004. 7. Third-party application developer 0107, i.e., a person who is responsible for the design and implementation of third-party applications. 8. Administrator 0108 of the third-party application server 0005, i.e., a person who has privileged access to the third-party application server 0005 and is responsible for the effective use, maintenance, and security of the third-party application server 0005.

[0045] In Figure 8, dashed blocks represent the possibility of grouping by the same person or entity. Unless explicitly excluded, in the following description, as shown in block 0109, a camera user 0102 refers to a person who is the administrator 0101 of a camera 0001, the photographer 0103, and the user 0104 of a user device 0002. The administrator 0105 of the user authentication server 0003 may be a person belonging to the manufacturer of the camera 0001. As shown in block 0110, the administrator 0106 of the time-stamping authority server 0004 may be a person belonging to the manufacturer of the camera 0001. As shown in block 0111, the administrator of a third-party application server 0005 may be the same as the third-party application developer 0107.

[0046] <<Malicious Users>> The relationship between malicious users and their respective devices is illustrated in Figure 9. 1. First direct attacker 0112: A person or group of people who gain physical access to both the camera 0001 and the user device 0002 and attempt to illegally obtain captured images. 2. Second direct attacker 0113: A person or group of people who gain physical access to the camera but not the user device and attempt to illegally obtain images stored on the removable recording media 0015 or internal data storage 0013 in the camera 0001. 3. First man-in-the-middle attacker 0114: A man-in-the-middle attacker between the camera and the user device. For example, a person or group of people who are the administrator of the LAN connecting the camera and the user device and eavesdrop on communications on this LAN. Another example is a person or group of people who installs eavesdropping malware in a USB hub that mediates communications between the camera and the user device. 4. First online attacker 0115: A person or group of people who attempt to illegally log in to a user account registered on the user authentication server. For example, a person who attempts to take over a user's account registered on an authentication server by means of trying passwords leaked from an external system. 5. Secondary online attacker 0116. That is, a person or group of people who have taken over the user authentication server and taken control of the server's functions and the data that can be read and written from this server. 6. Impersonation attacker 0117. That is, a person or group of people who attempt an impersonation attack by embedding data that identifies another person in the metadata of images they have taken. 7. Third-party application attacker 0118. That is, a person or group of people who reverse-engineer a third-party application and attempt to forge the third-party application by illegally obtaining secrets contained in the third-party application.

[0047] In Figure 9, the dashed arrows represent each attacker's access to the device or communication path. Regarding malicious users, a single entity may combine multiple attacks.

[0048] <Camera User Authentication> In the example system, camera user authentication refers to camera 0001 verifying that the person attempting to use camera 0001 is a person to whom a specific account registered in user authentication server 0003 belongs, and that this account is registered in camera 0001. The method for authenticating camera users is described below.

[0049] <<Initial Preparation for Authentication of Camera User>> As a prerequisite for authentication of the camera user, the manufacturer of the camera 0001 writes the camera manufacturer's public key certificate into the configuration storage 0016 when manufacturing the camera 0001.

[0050] FIG. 10 illustrates an interface for creating a camera user account provided by the camera manufacturer application 0099 (described in FIG. 11 and subsequent figures). In preparation for camera user authentication, the camera user 0102 launches the camera manufacturer application 0099 on the user device 0002 and opens the user account creation interface 0005. In the interface 0005, the camera user 0102 enters a login identifier (hereinafter referred to as the "login ID") and password in input fields 0119 and 0120, respectively. In the illustrated system, the login ID is a character string that uniquely identifies the camera user, such as the camera user's email address. After entering the login ID and password, the camera user 0102 presses the send button 0121.

[0051] 11 illustrates an example of the processing flow of the camera 0001, camera manufacturer application 0099, and user authentication server 0003 during the initial preparation for camera user authentication. When the camera user 0102 presses the send button 0121 after entering a login ID and password, the camera manufacturer application 0099 sends the login ID and password entered in input fields 0119 and 0120 to the user authentication server 0003 in message 0122.

[0052] In process 0123, upon receiving the login ID and password, the user authentication server 0003 creates an account and issues a permanent account ID to this account. The account ID may be a random number that does not overlap with other account IDs. Also in process 0123, the user authentication server 0003 inputs a string obtained by adding a salt string to the password into a one-way hash function. The user authentication server 0003 stores the association between the account ID and the output value of this function in the data storage 0046. In message 0124, the user authentication server 0003 notifies the camera manufacturer application 0099 of the successful account creation.

[0053] In process 0125, the camera manufacturer application 0099 creates a pair of private and public keys. The camera manufacturer application 0099 stores this key pair in the data storage 0031 of the user device 0002 by referencing a key management program. The camera manufacturer application 0099 encrypts this private key with the password described above. Next, in message 0126, the camera manufacturer application 0099 sends this public key and the encrypted private key to the user authentication server 0003.

[0054] In operation 0127, the user authentication server 0003 stores the association of the account ID with the encrypted private key in the data storage 0046. The user authentication server 0003 also issues a user certificate including the account ID and the public key using the private key of the user authentication server 0003. In message 0128, the user authentication server 0003 sends this user certificate to the camera manufacturer application 0099.

[0055] In process 0129 , the camera manufacturer application 0099 transmits the received user certificate to the camera 0001 .

[0056] In process 0130 , the camera 0001 verifies the user certificate using the certificate of the camera manufacturer, and then stores it in the setting storage 0016 .

[0057] In the above explanation, the camera manufacturer application 0099 creates a key pair for the camera user 0102, but the camera 0001 may also create it and send it to the camera manufacturer application 0099. The processing flow in this case is shown in FIG. 12. After creating an account, the camera manufacturer application 0099 instructs the camera 0001 to generate a key pair in message 0131. In process 0132, the camera 0001 generates a private key and public key pair and sends it to the camera manufacturer application 0099. The camera manufacturer application 0099 stores this key pair in the data storage 0031 of the user device 0002 by referencing a key management program. The camera manufacturer application 0099 encrypts this private key with the password of the camera user 0102. The processing thereafter is the same as the flow from message 0126 onwards in FIG. 11.

[0058] <<Camera User Authentication Execution>> FIG. 13 shows an example of a processing flow for executing authentication after the initial preparation.

[0059] The camera user 0102 unlocks or logs in to the user device 0002 and opens the camera manufacturer application 0099. In message 0133, the camera manufacturer application 0099 requests authentication from the camera 0001. In process 0134, upon receiving the authentication request, the camera 0001 generates a random number. The camera 0001 encrypts this random number with the public key included in the user certificate and sends it as a challenge to the camera manufacturer application 0099 in message 0135.

[0060] In process 0136, the camera manufacturer application 0099 decrypts the received challenge using the private key of the camera user 0102 to obtain the original random number. Using this random number as a key, the camera manufacturer application 0099 requests the start of shared key encryption communication 0138 with the camera 0001 by message 0137. If the start of this shared key encryption communication is successful, the camera 0001 determines that authentication of the camera user 0102 has been successful.

[0061] The explanations below of <Image encryption>, <Third-party application authentication and authorization>, and <Image signature> are based on the premise that communication between the camera 0001 and the camera manufacturer application 0099 is encrypted using this shared key encryption. These explanations also assume that communication between the user authentication server 0003 and the camera manufacturer application 0099 occurs while the camera user 0102 is logged in to the account that he created on the user authentication server 0003.

[0062] <<Basis of Camera User Authentication Method>> When user authentication is implemented in conventional cameras, the method is to enter a password using a touchscreen on the back of the camera body. This method is inconvenient and vulnerable. According to the authentication method of the above-described exemplary system, even if the camera 0001 does not have biometric authentication hardware, if the user device 0002 has a biometric authentication system 0042, it can be used to authenticate the camera user. Therefore, those skilled in the art will understand that this is advantageous in terms of implementation costs. However, apart from this advantage, the basis of the camera user authentication method of the exemplary system would not be obvious even to those skilled in the art. These basis will be clarified below.

[0063] The reason why the camera user's private key is stored in the user authentication server 0003 is that the private key may be lost due to reasons such as the loss or theft of the user device 0002. In this case, if the user stores the account password in a location other than the user device 0002, the private key and user certificate can be re-obtained from the user authentication server 0003.

[0064] The user authentication server 0003 does not store the user's password, and therefore cannot use the user's private key. However, if the user has set a weak password, a first online attacker 0115 may obtain and decrypt the private key. In this case, a second online attacker 0116 may be able to decrypt the private key using a brute force attack or dictionary attack.

[0065] The reason why attacks by the first man-in-the-middle attacker 0114 need to be prevented is that there are cases where it is not possible to trust the communication path between the camera 0001 and the user device 0002. For example, when a user connects the camera 0001 to the user device 0002 via a LAN provided by a photo studio, the user may not know what is on this LAN.

[0066] The first reason for using the user device 0002 to authenticate camera users is ease of operation. As mentioned above, when starting up the camera, if a password is required to be entered on the touch screen on the camera body, it is difficult to enter a complex password because the keyboard displayed on the touch screen on the camera body is small. Furthermore, if the camera is frequently turned off to conserve battery power, the requirement to enter a password not only increases the operational burden but also leads to lost photo opportunities.

[0067] On the other hand, with the authentication method revealed here, the user can complete authentication by simply unlocking the user device 0002 without being prompted to enter a password. Generally, biometric authentication is used to unlock devices such as smartphones. Therefore, authentication can be completed in a short time.

[0068] The second reason for using the user device 0002 to authenticate camera users is security. If a password is required to be entered on the touchscreen on the camera housing, it is expected that many users will set a simple password. Breaking such a password is relatively easy. On the other hand, with the authentication method revealed here, the challenge is an encrypted random number that is unknown even to the camera user, making it difficult for the second direct attacker 0113 to break user authentication by the camera 0001 using a dictionary attack or brute force attack.

[0069] The first direct attacker 0112 can break through the user authentication by the camera 0001 by unlocking the user device 0002. However, if the user device 0002 is equipped with a biometric authentication system 0042, unlocking the device is not easy. Generally, devices such as smartphones are often protected by biometric authentication. In addition, multiple attempts to unlock the device can result in long waiting times or the data in the device can self-destruct, making intrusion difficult in many cases.

[0070] The reason that challenge-response authentication between the camera 0001 and the user device 0002 is used to authenticate the camera user is to enable offline authentication. In the example system, after the initial preparations for authenticating the camera user are completed, the camera 0001 or the user device 0002 do not communicate with the user authentication server 0003 when performing user authentication. Therefore, even if the user device 0002 is offline or the user authentication server 0003 is unavailable due to some kind of failure, the camera 0001 can perform user authentication.

[0071] <Image Encryption> In the exemplary system, the camera 0001 encrypts images stored in the camera 0001 to protect these images from a first direct attacker 0112 or a second direct attacker 0113. This encryption is performed not for each image file, but for the entire recording area in which the image files are stored.

[0072] <<Prerequisites for Image Encryption>> Some known removable storage media are equipped with encryption hardware, but these removable storage media are not widely adopted due to limitations such as price, compatibility, and functionality.

[0073] Common removable storage media that do not have encryption hardware can be encrypted in software. In the example system, the removable storage media 0015 can be encrypted in software using the CPU 0018 of the camera 0001, or using a specialized co-processor for cryptographic processing if present in the camera 0001. A shared key cryptosystem is typically used to encrypt the storage media.

[0074] Meanwhile, the internal data storage 0013 may be, for example, an SSD, which is widely used in general-purpose computers. Many of these types of data storage are equipped with hardware-based self-encryption functionality. Data storage with self-encryption functionality (hereinafter referred to as "self-encrypting storage") becomes accessible upon receiving a pre-assigned shared key, and remains accessible until the power is turned off. The operation of sending a shared key to the self-encrypting storage is hereinafter referred to as "unlocking."

[0075] The exemplary system uses a single shared key for encryption or unlocking for both the removable recording medium 0015 and the internal data storage 0013. Hereinafter, this shared key will be referred to as a "data authentication key."

[0076] <<Encryption of Internal Data Storage>> FIG. 14 illustrates an example of a procedure for transmitting and receiving a data authentication key for unlocking the internal data storage 0013. In FIG.

[0077] If the internal data storage 0013 is locked, the camera 0001 requests a data authentication key from the camera manufacturer application 0099. In branch 0139, the camera manufacturer application 0099 refers to the key management program, and if a data authentication key is stored in the data storage 0031 of the user device 0002, it sends this key to the camera 0001. In branch 0139, if a data authentication key is not stored in the data storage 0031, the camera manufacturer application 0099 requests an encrypted data authentication key for the camera user 0102 from the user authentication server 0003.

[0078] At branch 0140, if the requested data authentication key exists in the data storage 0046, the user authentication server 0003 sends it to the user device camera manufacturer application 0099. When the camera manufacturer application 0099 receives the data authentication key from the user authentication server 0003, it decrypts the received data authentication key using the private key of the camera user 0102 in process 0141 and stores it in the key management program. In message 0142, the camera manufacturer application 0099 also sends this data authentication key to the camera 0001.

[0079] If the requested data authentication key does not exist in the data storage 0046 of the user authentication server 0003 at branch 0140, the user authentication server 0003 sends an empty response to the camera manufacturer application 0099 as message 0143. In response to this response, the camera manufacturer application 0099 generates a random number as a data authentication key in process 0144. The camera manufacturer application 0099 also references the key management program and stores this data authentication key in the data storage 0031 of the user device 0002. Next, the camera manufacturer application 0099 encrypts this data authentication key with the user's public key and sends the encrypted data authentication key to the user authentication server 0003 in message 0145. The camera manufacturer application 0099 sends this data authentication key to the camera 0001 in message 0146.

[0080] In process 0147 , the user authentication server 0003 associates the received encrypted data authentication key with the account ID of the camera user 0102 and stores it in the data storage 0046 .

[0081] The camera manufacturer application 0099 transmits the data authentication key to the camera 0001 according to the procedure shown in FIG.

[0082] Figure 15 is a continuation of Figure 14. In process 0148, the camera 0001 attempts to unlock the internal data storage 0013 using this data authentication key. If unlocking is successful in branch 0149, the camera 0001 maintains access to the internal data storage 0013 until power is turned off.

[0083] If the camera 0001 fails to unlock the internal data storage 0013 using this data authentication key, it notifies the camera manufacturer application 0099 of the unlock failure using message 0150. Upon receiving this notification, the camera manufacturer application 0099 asks the camera user 0102 using message 0151 whether or not to reset the internal data storage 0013. Resetting the internal data storage 0013 means discarding the data and setting a new data authentication key. If the camera user 0102 selects reset, the camera manufacturer application 0099 instructs the camera 0001 using message 0152 to set the previously sent data authentication key in the internal data storage 0013. In this case, the camera 0001 resets the internal data storage 0013 in process 0153. If the camera user 0102 does not select reset, the camera 0001 maintains the contents and lock state of the internal data storage 0013.

[0084] Software encryption of internal data storage

[0085] Once self-encrypting storage is accessible, it remains accessible until power is removed. Therefore, if the camera 0001 is powered on when the first direct attacker 0112 or the second direct attacker 0113 gains physical access to the camera 0001, they can obtain data in the internal data storage 0013 by transplanting the internal data storage 0013 into another device while the power is still supplied. The example system may encrypt the internal data storage 0013 in software to prevent this attack.

[0086] Generally, software-based encryption of data storage refers to creating an encrypted file system on the data storage. Creating an encrypted file system is, for example, an operation consisting of the following two steps. The first step is to create a logical block device in the operating system to which the data storage is connected, which encrypts and decrypts input and output to and from the data storage. The second step is to create a file system on this logical block device. This operation will be clear to those skilled in the art. In the following, gaining access to an encrypted file system will also be referred to as "unlocking," just like unlocking using the self-encryption function.

[0087] Even when the built-in data storage 0013 of the camera 0001 is encrypted using software, the camera 0001 receives a data authentication key from the camera manufacturer application 0099 according to the procedure shown in FIG.

[0088] Figure 16 is a continuation of Figure 14 for the case where the internal data storage 0013 of the camera 0001 is encrypted by software. In process 0154, the camera 0001 attempts to unlock the encrypted file system on the internal data storage 0013 using the data authentication key. If unlocking is successful in branch 0155, the camera 0001 maintains access to the encrypted file system until power is turned off. In this case, if the first direct attacker 0112 or the second direct attacker 0113 transplants the internal data storage 0013 to another device, access to the encrypted file system will be lost.

[0089] If the camera 0001 fails to unlock the encrypted file system using this data authentication key, it notifies the camera manufacturer application 0099 of the unlock failure in message 0156. Upon receiving this notification, the camera manufacturer application 0099 asks the camera user 0102 in message 0157 whether or not to reset the encrypted file system. Resetting the encrypted file system means discarding the file system and creating a new encrypted file system with a new data authentication key. If the camera user 0102 selects reset, the camera manufacturer application 0099 sends message 0158 to the camera 0001, requesting that a new encrypted file system be created on the internal data storage 0013 using the data authentication key previously sent. In this case, the camera 0001 creates a new encrypted file system in process 0159. If the camera user 0102 does not select reset, the camera 0001 maintains the contents and lock state of the encrypted file system.

[0090] <<Encryption of removable storage media>>

[0091] As described above, the removable recording medium 0015 inserted into the camera 0001 can be encrypted by software. Similar to the software encryption of the internal data storage 0013, the software encryption of the removable recording medium 0015 can be realized by, for example, creating a logical block device that encrypts and decrypts input and output to and from the removable recording medium 0015, and creating a file system on this block device.

[0092] 17 illustrates the procedure for transmitting and receiving a data authentication key for creating an encrypted file system on the removable recording medium 0015 and for unlocking the encrypted file system on the removable recording medium 0015. When the camera 0001 detects the removable recording medium 0015 with a message 0160, the camera 0001 requests a data authentication key from the camera manufacturer application 0099. The procedure for transmitting and receiving the data authentication key after this request is the same as branch 0139 in FIG. 14. Through this procedure, the camera 0001 receives the data authentication key from the camera manufacturer application 0099.

[0093] Figure 18 is a continuation of Figure 17. In process 0161, the camera 0001 attempts to use the data authentication key to unlock the encrypted file system on the removable recording medium 0015. If unlocking is successful in branch 0162, the camera 0001 maintains access to the encrypted file system until the power is turned off or the removable recording medium 0015 is removed.

[0094] If the camera 0001 fails to unlock the encrypted file system using this data authentication key, it notifies the camera manufacturer application 0099 of the unlock failure in message 0163. Upon receiving this notification, the camera manufacturer application 0099 asks the camera user 0102 in message 0164 whether or not to reset the encrypted file system. If the camera user 0102 selects reset, the camera manufacturer application 0099 sends message 0165 to the camera 0001, requesting that a new encrypted file system be created on the removable recording medium 0015 using the data authentication key previously sent. In this case, the camera 0001 creates a new encrypted file system in process 0166. If the camera user 0102 does not select reset, the camera 0001 maintains the contents and lock state of the encrypted file system.

[0095] According to the above method, there is no need to require the camera user 0102 to enter a password using the touch screen on the camera body when encrypting the camera's built-in data storage 0013 or removable recording medium 0015. If the data authentication key is lost due to loss or theft of the user device 0002, the camera user 0102 can re-obtain the data authentication key from his or her own account on the user authentication server 0003. Furthermore, because the data authentication key is a random number, it is difficult for a first direct attacker 0112 or a second direct attacker 0113 to succeed in a brute force attack or dictionary attack.

[0096] <Authentication and Authorization of Third-Party Applications> Camera manufacturers may provide application developers with SDKs (Software Development Kits) or APIs (Application Programming Interfaces) for building third-party applications that access their cameras. However, as far as the inventor has researched, there is no prior art that allows a camera to authenticate and authorize third-party applications.

[0097] Third-party application authentication refers to the camera verifying that a third-party application attempting to access the camera is registered in advance with the camera. Third-party application authorization refers to the camera allowing the third-party application to control various aspects of the camera based on the authentication result and predefined settings.

[0098] The following describes how third-party applications are authenticated and authorized in an exemplary system.

[0099] <<Preparing a Third-Party Application>> Figure 19 illustrates the flow of creating a third-party application developer account. The third-party application developer 0107 accesses the user authentication server 0003 using a web browser on the third-party application developer device 0006. The GUI displayed in the web browser for creating an application developer account may be the same as the one illustrated in Figure 10. In message 0167, the user authentication server 0003 receives a login ID and password from the third-party application developer device 0006. In process 0168, the user authentication server 0003 associates the login ID of the third-party application developer 0107 with an account ID and stores the associated ID in the data storage 0046. The user authentication server 0003 also associates the password and a hash value of the salt string with the account ID and stores the associated ID in the data storage 0046. In message 0169, the user authentication server 0003 notifies the third-party application developer device 0006 of the success of the account creation.

[0100] As a prerequisite for authenticating the third-party application 0100 shown in Figure 22 and subsequent figures, an ID for this application (hereinafter referred to as the "application ID") is required. Figure 20 illustrates the process for issuing an application ID. The third-party application developer 0107 accesses the user authentication server 0003 using the web browser described above and opens the GUI 0170. When the third-party application developer 0107 presses the button 0171, the third-party application developer device 0006 sends a message 0172 requesting the user authentication server 0003 to issue an application ID.

[0101] In operation 0173, the user authentication server 0003 issues an application ID. The application ID may be a random string of characters. The user authentication server 0003 associates the application ID with the application developer account ID and stores it in the data storage 0046. The user authentication server 0003 sends the application ID to the third-party application developer device 0006 in message 0174. The third-party application developer device 0006 displays the received application ID to the third-party application developer 0107 in GUI 0175.

[0102] During development of the third-party application 0100 , the third-party application developer 0107 includes this application ID in the third-party application 0100 .

[0103] Prior to the release of the third-party application 0100, the third-party application developer device 0006 registers the application with the user authentication server 0003. FIG. 21 shows an example of a GUI for registering a third-party application 0100. The third-party application developer 0107 connects to the user authentication server 0003 using the web browser described above and opens the GUI 0176 based on the issued application ID. In the GUI 0176, the third-party application developer 0107 sends data for identifying the third-party application 0100 to the user (hereinafter referred to as the "application descriptor"), such as the name or icon of the application, to the user authentication server 0003. Upon receiving the application descriptor, the user authentication server 0003 associates it with the application ID and stores it in the data storage 0046.

[0104] Regarding installation of the third-party application 0100 on the user device 0002, the acquisition path and installation method vary depending on the operating system of the user device 0002. The exemplary system does not limit these acquisition paths and installation methods.

[0105] <Storing Keys and Access Permissions> Figure 22 shows an example of the processing flow when a third-party application 0100 installed on the user device 0002 is launched for the first time. In process 0177, the third-party application 0100 creates a private key and public key pair (hereinafter referred to as the "application key pair"). In message 0178, the third-party application 0100 sends this public key and application ID to the camera 0001. In process 0179, the camera 0001 temporarily stores the received application ID and public key in RAM 0019.

[0106] In message 0180, the third-party application 0100 passes to the camera manufacturer application 0099 an application ID and an address (hereinafter referred to as the "application notification address") for sending push notifications to this third-party application 0100. The message 0180 can be sent, for example, by the third-party application 0100 requesting the operating system to transition to the camera manufacturer application 0099.

[0107] The application notification address is an address that the third-party application 0100 obtains from the operating system of the user device 0002. Push notifications to the application notification address are sent via a network operated by the developer of the operating system of the user device 0002 (hereinafter referred to as the "application notification network").

[0108] 22, in message 0181, the camera manufacturer application 0099 sends the application ID to the user authentication server 0003. Using the received application ID as a search key, the user authentication server 0003 searches for application descriptors of the third-party application 0100 in the data storage 0046. In message 0182, the user authentication server 0003 sends these application descriptors to the camera manufacturer application 0099.

[0109] 23 shows an example of a GUI 0183 for setting permission for access to the camera 0001 by the third-party application 0100. The camera manufacturer application 0099 displays the received application descriptor to the camera user 0102, asking whether to allow the third-party application 0100 to access the camera 0001. The type of access to the camera 0001 includes, for example, taking pictures using the camera 0001, reading image files recorded on the internal data storage 0013 or removable recording media 0015, or writing image files to the internal data storage 0013 or removable recording media 0015. In implementing access permission, the type of access is determined by the camera's functions.

[0110] 24 shows an example of the processing that occurs after the camera user 0102 presses the button 0184 for setting access permissions in the GUI 0183. If the camera user 0102 does not allow any type of access at branch 0185, the camera manufacturer application 0099 instructs the camera 0001 to discard the public key and application ID in RAM 0019 by message 0186. The camera manufacturer application 0099 also notifies the third-party application 0100 by message 0187 that no access is permitted.

[0111] If the camera user 0102 allows any type of access at branch 0185, and if the camera user 0102 allows reading and writing of files in the internal storage 0013 or removable recording media 0015, the camera manufacturer application 0099 refers to the key management program to obtain a data authentication key and sends it to the camera 0001 in message 0188. The camera 0001 temporarily stores this data authentication key in RAM 0019.

[0112] If the camera user 0102 allows any type of access at branch 0185, the camera manufacturer application 0099 sends the application ID and the type of access to be allowed to the camera 0001 in message 0189. Upon receiving these, the camera 0001 stores them in RAM 0019 in process 0190. The camera 0001 then generates a random number as a secret ID (hereinafter referred to as the "application public key ID") for identifying the public key in RAM 0019 received in message 0178, and sends this random number to the camera manufacturer application 0099 in message 0191. As will be described later, the application public key ID is a secret to prevent attacks from third-party application attackers 0118. In message 0192, the camera manufacturer application 0099 sends the application public key ID, application ID, and application notification address to the user authentication server 0003.

[0113] Figure 25 is a continuation of Figure 24. In process 0193, the user authentication server 0003 sends an authentication request to the third-party application server 0005. In response to this authentication request, the third-party application server 0005 authenticates the user authentication server 0003 through challenge-response authentication using the public key of the user authentication server 0003 (messages 0194, 0195, and 0196).

[0114] After this authentication, in message 0197, the user authentication server 0003 sends the third-party application public key ID and the application notification address to the third-party application server 0005. The third-party application server 0005 sends a notification including the received application public key ID to the application notification address in message 0198. This notification is sent to the third-party application 0100 as a push notification via the aforementioned application notification network.

[0115] Because the application public key ID is a secret that the camera user 0102 does not need to know, the notification should not be displayed to the camera user 0102. The third-party application server 0005 may send an additional push notification to inform the camera user 0102 that the application public key ID has been sent.

[0116] The third-party application 0100 sends its application ID and the application public key ID received in message 0198 as message 0200 in process 0199 to the camera 0001. In process 0201, the camera 0001 verifies whether the received pair of application ID and application public key ID matches the application ID and application public key ID in RAM 0019. Here, the application ID and application public key ID in RAM 0019 are the pair of application ID received in message 0178 in Fig. 22 and application public key ID generated in process 0190 in Fig. 24.

[0117] If these match, the camera 0001 associates the public key in RAM 0019, i.e., the public key received in message 0178 of Fig. 22, and the type of permitted access, i.e., the type of access received in message 0189 of Fig. 24, with the application public key ID and stores them in the setting storage 0016. If the data authentication key received in message 0188 of Fig. 24 is in RAM 0019, the camera 0001 sends this to the third-party application 0100 in message 0202. The camera 0001 also notifies the third-party application 0100 in message 0203 that the application public key ID has been saved.

[0118] Upon receiving this notification, in process 0199, the third-party application 0100 references the key management program and stores the application public key ID in the data storage 0031 of the user device 0002. Next, the third-party application 0100 references the key management program and stores the application key pair generated in process 0177 of Figure 22 in the data storage 0031. If the data authentication key is received in message 0202, in process 0204 the third-party application 0100 references the key management program and stores this data authentication key in the data storage 0031 of the user device 0002.

[0119] In this way, the camera 0001 and the third-party application 0100 store the keys required for authentication and authorization, the type of access allowed, and the application public key ID.

[0120] 26 illustrates an example of authentication processing of a third-party application 0100 by a camera 0001. A camera user 0102 unlocks or logs into the user device 0002 and opens the third-party application 0100.

[0121] The third-party application 0100 references the key management program to obtain the application public key ID from the data storage 0031 of the user device 0002, and uses this as an argument to request authentication from the camera 0001 in message 0205. In process 0206, the camera 0001 searches the configuration storage 0016 for a public key associated with the received application public key ID. The camera 0001 generates a random number and encrypts it with this public key. The camera 0001 sends the encrypted random number to the third-party application 0100 as a challenge in message 0207.

[0122] In process 0208, the third-party application 0100 obtains the original random number by decrypting the received challenge using the private key of the application key pair. Using this random number as a key, the third-party application 0100 requests the start of shared-key cryptographic communication 0210 with the camera 0001 via message 0209. If the start of this shared-key cryptographic communication is successful, the camera 0001 determines that authentication of the third-party application 0100 has been successful.

[0123] 27 illustrates an example of the access authorization process after successful authentication of the third-party application 0100. The camera 0001 receives a message 0205 from the third-party application 0100. In process 0211, the camera 0001 determines whether the message 0205 is a message requesting a process that is subject to access authorization. Examples of processes that are subject to access authorization include taking a photo or reading an image file from the internal data storage 0013 or the removable recording medium 0015.

[0124] If unlocking is required to access the internal data storage 0013 or the removable recording medium 0015, the camera 0001 requests a data authentication key from the third-party application 0100 in message 0212. The third-party application 0100 obtains the data authentication key by referring to the key management program and sends it to the camera 0001 in message 0213.

[0125] At branch 0214, if the requested access is not permitted, the camera 0001 returns an error response to the third-party application 0100 in message 0215. If the requested access is permitted, the camera 0001 performs the requested processing and returns the execution result to the third-party application 0100 in message 0216.

[0126] <<Authentication and Authorization Basis for Third-Party Applications>> The above authentication and authorization basis may not be obvious even to those skilled in the art. We will clarify this below.

[0127] The first motivation for authentication and authorization of third-party applications is to allow camera users to control access to the images they capture. The second motivation is to allow the user authentication server administrator to know the existence and number of third-party applications. The third motivation is to allow the user authentication server administrator to block specific third-party applications from accessing the camera. Blocking based solely on SDK or API license agreements relies on legal means. With the above authentication and authorization method, the user authentication server administrator can avoid automating the issuance of application IDs and instead require third-party application developers to submit their applications in advance, and then issue application IDs after reviewing the submitted applications. Furthermore, when reviewing third-party applications, the user authentication server administrator can review them from a perspective different from that of the application distributor of the user device, namely, from the perspective of the camera's functions and performance.

[0128] The reason for storing the application key pair on the user device is offline authentication: after the public key and access permissions of the application key pair are stored on the camera, and the private key of this key pair is stored on the user device, authentication and authorization of third-party applications, as well as authentication of camera users, can be performed offline.

[0129] In a typical challenge-response authentication configuration, a third-party application sends a public key to the camera, which then issues a challenge. This simple configuration is vulnerable to attacks from a first direct attacker 0112 or a second direct attacker 0113. In this configuration, these attackers can register any application on the camera.

[0130] The reason for not using the application ID as the application public key ID is to protect against third-party application attackers. Third-party application developers are forced to embed an ID into their applications to identify their applications to the camera. Therefore, a third-party application attacker can obtain the third-party application developer's application ID by reverse engineering. Therefore, authentication using the application ID as a secret invites attacks by third-party application attackers.

[0131] The reason why the third-party application server pushes the application public key ID to the third-party application is also to protect against third-party application attackers. A third-party application attacker can create an application that impersonates a legitimate third-party application. The third-party application server cannot distinguish access from the impersonated application from the legitimate application. However, the legitimate third-party application developer never notifies the impersonated application of the application public key ID. Therefore, the impersonated application cannot gain access to the camera.

[0132] There may be cases where it is not desirable to pass the application notification address to the camera manufacturer application or user authentication server, in which case the third-party application may encrypt the application notification address with a public key specified by the third-party application server administrator.

[0133] <Signing an Image> <Signature of the Signature in the Example System> When signing an image in a camera using known technology, the camera signs it using the camera manufacturer's private key. With this signature method, it is virtually impossible to include metadata arbitrarily entered by the user in the signature. This limitation can be explained by, for example, assuming the following attack.

[0134] An impersonator opens the settings screen of their camera and enters the name of a prominent U.S. politician into the image creator field. The impersonator uses the camera to capture an image of someone vandalizing a foreign (or their own) flag and uploads the image to an online image sharing service. The uploaded image's metadata includes the politician's name as the image creator. Verification of the image's signature shows that the image was created by the politician and that the camera's manufacturer signed the image. If the camera targets image creators with signatures, various legal and political issues could arise.

[0135] As can be seen from the above example, camera manufacturers cannot use their own private keys to guarantee the content of the metadata entered by users. Therefore, even if a bona fide user enters their real name in the image creator field, camera manufacturers cannot sign the user's name included in the image metadata. In some cases, camera manufacturers may not guarantee any effectiveness of signatures made using their private keys.

[0136] In the exemplary system, the image is signed using the private key of the camera user 0102, not the private key of the manufacturer of the camera 0001. According to the method exemplified below, the camera user 0102 can voluntarily sign the image and the metadata contained in the image using his or her own private key that is uniquely associated with his or her identity.

[0137] <<Preparing for Signature>> Before signing, the camera user 0102 must prove his or her identity. Generally, methods for proving identity online include deemed proof through the completion of an online payment, the use of an online identity proof service, etc. When implementing the contents of this disclosure, the implementer can select or create an appropriate method at the time. The following explanation assumes that the camera user 0102 has been identified as the person to whom the camera user 0102's account belongs by some means, for example, the completion of an online payment.

[0138] FIG. 28 illustrates an example of the processing flow from generating a private key required for signing to issuing a certificate for verifying the signature (hereinafter referred to as a "signature certificate"). FIG. 29 illustrates an example of a GUI 0217 for setting a signature provided by the camera manufacturer application 0099. The camera user 0102 validates the signature using the GUI 0217. The camera user 0102 may set metadata to be included in the image, such as the image creator or copyright holder, as an arbitrary character string. In message 0218, the camera manufacturer application 0099 sends the signature settings provided using the GUI 0217 to the camera 0001.

[0139] In process 0219, the camera 0001 saves this setting in the setting storage 0016. Next, in process 0220, the camera 0001 generates a signing key pair in the secure element 0017. The camera 0001 obtains the public key of this pair from the secure element 0017 and sends this public key to the camera manufacturer application 0099 in message 0221.

[0140] The camera manufacturer application 0099 sends the received public key to the user authentication server 0003 in a message 0222. In process 0223, the user authentication server 0003 issues a signature certificate including the received public key using the private key of the user authentication server 0003. The user authentication server 0003 stores this signature certificate in the data storage 0046 together with an association with the account ID of the camera user 0102.

[0141] 《Signing and Signature Verification》

[0142] In the following description, a "file" does not necessarily refer to a file on a file system. A file may be a single piece of data that can be treated as a single unit by some means of reference, such as a database record. Also, the process of writing data to a file may be the process of creating another file that contains the contents of this file.

[0143] FIG. 30 illustrates the process flow after a signature is validated. The camera user 0102 unlocks the user device 0002, opens the camera manufacturer application 0099 or the third-party application 0100, and begins capturing images. Hereinafter, the term "camera application" refers to either of these applications. In FIG. 30, the camera application is indicated by the reference numeral 0224. When the camera 0001 receives an image saving instruction (i.e., a shutter release instruction for still image capture, or an instruction to start recording for video capture) from the camera application 0224 in message 0225, the camera 0001 creates, in process 0226, an image file (hereinafter referred to as the "original image file") based on the current recording format settings, such as image resolution and encoding, and a reduced-size image file of the original image file.

[0144] The method for creating a reduced image file may be any method as long as a person can recognize the reduced image file as a reduced version of the original image file when the images of the original image file and the reduced image file are displayed side by side. This method may be, for example, thinning out pixels from the image of the original image file, reducing the color depth, converting to grayscale, performing lossy compression, reducing the frame rate, etc.

[0145] Next, in process 0227, the camera 0001 writes metadata to the reduced-size image file. If metadata set by the camera user 0102, such as the image creator, is stored in the setting storage 0016, the camera 0001 writes this metadata to the reduced-size image file. The metadata in the reduced-size image file may further include shooting settings such as shutter speed, hardware information about the camera 0001, or software information such as the name of the camera application 0224. The hardware information does not include an identifier that uniquely identifies the camera 0001, such as a serial number. The metadata in the reduced-size image file also includes the time obtained from the clock 0021 and the time of the last time synchronization between the clock 0021 and the time stamp authority server 0004.

[0146] Next, in process 0228, the camera 0001 calculates a hash value for the thumbnail image file. The camera 0001 generates a signature for this hash value using the secure element 0017. In this signature, the secure element 0017 uses the private key of the camera user 0102 stored internally using the method in "Preparing a Signature." The camera 0001 sends the thumbnail image file, the hash value, and the signature to the camera application 0224.

[0147] In message 0229, the camera application 0224 sends a timestamp request to the TSA server 0004 using this hash value as an argument. In process 0230, the TSA server 0004 creates a file by concatenating the hash value and the timestamp of the time of reception, and signs this file using the private key of the TSA server 0004. Hereinafter, the combination of the hash value, timestamp, and signature by the TSA server 0004 is referred to as a "timestamp response." In message 0231, the TSA server 0004 sends this timestamp response to the camera application 0224. The camera application 0224 saves the thumbnail image file, hash value, signature, and timestamp response in the data storage 0031 of the user device 0002.

[0148] This is the signing process.

[0149] To verify the signature on an image or the timestamp response, the user sends the thumbnail image file, signature certificate, signature, and timestamp response to a party performing this verification (hereinafter referred to as the "verifier") by any means, for example, email. The verifier may obtain a public key from the user authentication server 0003 or the time-stamp authority server 0004 and verify the signature or timestamp response using a known encryption tool, for example, OpenSSL. Alternatively, the camera manufacturer may provide a GUI and functions for these verifications in the camera manufacturer application 0099. Alternatively, the user authentication server 0003 and the time-stamp authority server 0004 may each provide a GUI and functions for verifying the signature and timestamp response. In either case, it will be clear to those skilled in the art that verification of the signature on an image or the timestamp response can be achieved using known techniques.

[0150] <<Rationale of the Signature Method>> When implementing the above signature method, the implementer needs to know the data or functions that are intentionally excluded or limited from the method. Furthermore, some of the rationale for the above signature method may not be obvious even to those skilled in the art. Therefore, these will be explained below.

[0151] The signature certificate does not include information that identifies the camera user 0102, such as the account ID of the camera user 0102. If the signature certificate includes this information, privacy concerns arise. For example, if the camera user 0102 is a photographer who uses multiple names, it may become apparent from the signature certificate of the camera user 0102 that these names refer to the same person. For the same reason, the metadata that the camera 0001 adds to an image does not include information that identifies the camera 0001, such as a serial number.

[0152] The metadata that the camera 0001 includes in the thumbnail image file does not include information that identifies the camera user 0102, except for items set by the camera user 0102 himself. If the spoofing attacker 0117 executes an attack as exemplified in <<The Significance of Signatures in the Example System>>, the administrator 0105 of the user authentication server 0003 can identify the signer, i.e., the identity of the spoofing attacker 0117, from the signature certificate of the spoofing attacker 0117. Therefore, there is no need to include information that identifies the camera user 0102 in the metadata included in the thumbnail image file as a defense against spoofing attacks.

[0153] The private key of the camera user 0102 used to sign images cannot normally be extracted from the secure element 0017, that is, unless the secure element has a malfunction or a backdoor. Furthermore, the camera 0001 does not sign image files imported from outside, such as image files on the removable recording medium 0015. Due to these restrictions, the use of the private key of the camera user 0102 used to sign images is limited to signing images taken with the camera 0001. Furthermore, these restrictions eliminate the possibility that the camera 0001 can sign images that have been tampered with.

[0154] The signature on the image is only executed when the image is taken using the camera application 0224 on the user device 0002. In other words, the signature is only made when the user device 0002 is unlocked. Therefore, the signature is made at the will of the camera user 0102. If the photographer 0103 and the camera user 0102 do not match, for example, if the camera user 0102 asks a passerby to take the photo, the signature will be considered to be made at the will of the camera user 0102.

[0155] The reason for signing the reduced image file is that the original image file may be large in size. In this case, it takes time to calculate the hash value of the original image file. To avoid this problem, the camera signs the reduced version.

[0156] The reason why the time of the last time synchronization with the time-stamp authority server 0004 is included in the metadata is because this synchronization time can be an indicator of the reliability of the timestamp in the image metadata. Generally, the timestamp in the image metadata is based on the camera's internal clock, and therefore its reliability is usually low. In the example system, the camera 0001 does not have a function that allows the camera user 0102 to set an arbitrary time. Furthermore, communication between the camera 0001 and the time synchronization server on the time-stamp authority server 0004 is end-to-end protected. Therefore, the camera user 0102 cannot usually set the time of the clock 0021 arbitrarily. If the camera application 0224 cannot receive a timestamp response from the time-stamp authority server 0004 and the timestamp in the image metadata is close to the time of the last time synchronization, the difference between the time of the clock 0021 and the actual time is usually small. Therefore, the timestamp in the image metadata can be considered to be somewhat reliable.

Claims

1. A method for having a handheld digital camera authenticate its user, wherein the authentication is challenge-response authentication using public key cryptography, a first information processing device is a device managed by the user, the handheld digital camera has a public key for a second information processing device, the first information processing device generates a pair of a private key and a public key for the user within the first information processing device, the first information processing device transmits the user's public key to the second information processing device, the second information processing device uses the private key to issue a certificate including the user's public key, the second information processing device transmits the certificate to the first information processing device, the first information processing device transmits the certificate to the handheld digital camera, the handheld digital camera verifies the certificate using the public key of the second information processing device, the first information processing device transmits an authentication request to the handheld digital camera, and the handheld digital camera transmits a challenge generated using the public key included in the certificate to the first information processing device, the first information processing device decrypts the challenge using the user's private key; the first information processing device transmits a response obtained by the decryption to the handheld digital camera; and the handheld digital camera verifies the response.

2. A method for having a handheld digital camera authenticate its user, wherein the authentication is a challenge-response authentication using public key cryptography, a first information processing device is a device managed by the user, the handheld digital camera has a public key of a second information processing device, the handheld digital camera generates a pair of private key and public key of the user within the handheld digital camera, the handheld digital camera transmits the pair of private key and public key of the user to the first information processing device, the first information processing device transmits the public key of the user to the second information processing device, the second information processing device issues a certificate including the public key of the user using the private key, the second information processing device transmits the certificate to the first information processing device, the first information processing device transmits the certificate to the handheld digital camera, the handheld digital camera verifies the certificate using the public key of the second information processing device, and the first information processing device transmits an authentication request to the handheld digital camera, The handheld digital camera generates a challenge using the public key included in the certificate and sends it to the first information processing device; the first information processing device decrypts the challenge using the user's private key; the first information processing device sends a response obtained by the decryption to the handheld digital camera; and the handheld digital camera verifies the response.

3. A handheld digital camera that authenticates a user by the method of claim 1 or claim 2.

4. A method for causing a handheld digital camera to encrypt and decrypt data recorded on its internal data storage or removable recording media, said method using shared key cryptography, wherein an information processing device is connected to said handheld digital camera, said information processing device is a device managed by a user of said handheld digital camera, said handheld digital camera authenticates said user by the method of claim 1 or claim 2, said information processing device generates a shared key within said information processing device, said information processing device transmits said shared key to said handheld digital camera, and said handheld digital camera uses said shared key to unlock said internal data storage or to encrypt and decrypt said internal data storage or said removable recording media.

5. A handheld digital camera that encrypts and decrypts data recorded on its internal data storage or removable recording media by the method of claim 4.

6. A handheld digital camera equipped with an internal clock, characterized in that the user is not required to set the time on the clock, and the time on the clock is synchronized with the time on a time synchronization server through end-to-end encrypted communication.

7. A method for having a handheld digital camera authenticate a first computer program process included in a first information processing device that intends to use the handheld digital camera, wherein the authentication is a challenge-response authentication using public key cryptography, the first information processing device is a device managed by a user of the handheld digital camera, the first computer program process generates a private key / public key pair within the first information processing device, the first computer program process transmits the public key to the handheld digital camera, the first computer program process transmits an identifier of the first computer program to a second computer program process included in the first information processing device, the second computer program process transmits the identifier of the first computer program to the handheld digital camera, the handheld digital camera generates an identifier of the public key, the handheld digital camera transmits the identifier of the public key to the second computer program process, the second computer program process transmits the identifier of the public key to a second information processing device, and the second information processing device transmits the identifier of the public key to a third information processing device, the third information processing device sends the public key identifier to the first computer program process; the first computer program process sends an authentication request including the public key identifier to the handheld digital camera; the handheld digital camera identifies the public key using the public key identifier; the handheld digital camera generates a challenge using the public key; the handheld digital camera sends the generated challenge to the first computer program process; the first computer program process decrypts the challenge using the private key; the first computer program process sends a response obtained by the decryption to the handheld digital camera; and the handheld digital camera verifies the response.

8. A handheld digital camera that is controlled by receiving instructions from an information processing device connected to the handheld digital camera, wherein the computer program process that transmits the instructions is authenticated by the method of claim 7.

9. A method for causing a handheld digital camera to authorize instructions from a first computer program process that attempts to use said handheld digital camera, comprising: an information processing device connected to said handheld digital camera; said information processing device comprising said first computer program; said information processing device comprising a second computer program; said second computer program notifying said handheld digital camera of the type of instructions to authorize; said handheld digital camera authenticating said first computer program process according to the method of claim 7; and said handheld camera authorizing instructions from said first computer program process based on said authentication and said type of instructions to authorize.

10. A handheld digital camera controlled by receiving instructions from an information processing device connected to the handheld digital camera, the instructions from the computer program process transmitting the instructions being authorized by the method of claim 9.

11. A handheld digital camera that signs data generated by photographing using the handheld digital camera, wherein the signing is performed using a private key belonging to the user of the handheld digital camera.

12. A handheld digital camera according to claim 11, wherein the handheld digital camera authenticates the user of the handheld digital camera by the method of claim 1 or claim 2, the handheld digital camera generates a private key used for the signature of claim 11 within the handheld digital camera, and the handheld digital camera signs the data of claim 11 using the private key based on the success of the authentication.

13. A method for generating a certificate for verifying a signature of claim 11 or claim 12, comprising: an information processing device identifies the user of claim 11 by an identity verification means; a handheld digital camera of claim 11 or claim 12 generates a public key paired with the private key of claim 11 or claim 12; the handheld digital camera transmits the public key to the information processing device; and the information processing device generates the certificate including the public key as a certificate of the identified user using the private key of the information processing device.

14. A method for allowing a user of a handheld digital camera to obtain a timestamp for data generated by photographing using the handheld digital camera, the method comprising: the handheld digital camera transmitting a hash value of the data to a first information processing device connected to the handheld digital camera; the first information processing device transmitting the hash value to a time-stamp authority server; the time-stamp authority server generating a time-stamp response to the hash value; the time-stamp authority server transmitting the time-stamp response to the first information processing device; and the first information processing device storing the time-stamp response.

Images